¿Qué haces cuando hay una solicitud de último minuto para excluir una función de un lanzamiento?

Hay una característica que ya pasó las pruebas de aceptación, tanto internamente como por el cliente. Es una característica totalmente funcional. Sin embargo, ahora hay una solicitud para excluir esta característica de una próxima versión. Según el cliente, esta característica debe eliminarse porque los usuarios no han recibido capacitación sobre cómo usarla.

¿Cuál es el mejor curso de acción para manejar esta situación? ¿Deberíamos diseñar software anticipando que una característica podría ser excluida en el último minuto usando los ajustes de configuración? ¿Existen soluciones dependientes del contexto que podrían ser más correctas en algunas situaciones que en otras?

1. Eliminar la documentación de la función;
2. Deshabilite la interfaz para la función (ocultar elementos de menú o eliminar una opción de un comando de consola).

Todo lo demás es demasiado peligroso.

Mi empleador anterior vende algunos programas que permitieron diferentes funciones basadas en la licencia particular involucrada. Entonces, la capacidad de habilitar / deshabilitar características en tiempo de ejecución fue una característica diseñada. En general, la gente llama a esto "desarrollo basado en características" ( artículo de Wikipedia , libro decente sobre el tema ). Se requieren muchas pruebas para encontrar errores que pueden ser causados ​​al activar y desactivar las funciones. Dado que la mayoría de las personas en la oficina generan una clave de licencia para todas las funciones, las capacidades de funciones limitadas tienden a ejercerse de manera deficiente (y en más de una ocasión, no se prueban en absoluto hasta que un cliente llama a la mesa de ayuda).

Para su "corrección" de último minuto, la solución más rápida será ocultar los comandos de menú / teclas de acceso rápido / botón que activan esta función. Esto introducirá otros errores . Sea directo con sus clientes y gerentes de proyecto.

Nunca escribiría un código de modo que las características se puedan activar o desactivar, a menos que ese requisito se haya establecido por adelantado.

Eliminar o deshabilitar una característica es un cambio en la especificación, y al igual que cualquier otro cambio de especificación, requiere tiempo para implementar y verificar. Debe preguntar por qué se va a excluir la función: ¿sigue siendo demasiado defectuosa para ser lanzada? ¿El cliente no quiere esa característica en absoluto? ¿Hay alguna razón comercial para retrasar la función?

Particularmente en el caso en que se percibe que la característica es "demasiado defectuosa" para ser lanzada, debe ser cauteloso sobre si esa característica es "defectuosa" o si en realidad es la versión en su conjunto que aún no está lista para su lanzamiento y esa característica en particular es aquella en la que los problemas aparecen más, en cuyo caso, deshabilitar esa característica no te ayudará mucho ...

Respondemos a las solicitudes de última hora discutiendo la importancia del cambio para el cliente. Realizar cambios importantes justo antes de la implementación invalida toda la fase de prueba y aceptación, por lo que trasladamos la solicitud de cambio a una versión posterior o la fecha de implementación para que el cambio de última hora pueda probarse correctamente (clientes a menudo optan por mover el cambio a la próxima versión cuando se enteran de que la alternativa es mover la fecha de implementación :-))

La funcionalidad opcional es mejor (imho) activada / desactivada a través de la configuración. Como mencionas, esto debe diseñarse desde el principio.

Tuve que hacer esto en el pasado, a veces con características que lo han convertido en producción y han resultado ser un desastre. He hecho todo lo siguiente.

1) Cambio de configuración para desactivar la función. Funciona donde es configurable 2) Deshabilita / elimina todas las entidades de IU que activan la función. 3) Deshabilite el código en la función para que no haga nada (pero parece funcionar) Tuve que hacer esto donde no teníamos acceso al código de shell gui.

En cuanto a si debe diseñar la capacidad de activar o desactivar las características, miraría la imagen más grande y vería cómo agrega características actualmente. No es un gran paso convertir funciones en módulos que, en el peor de los casos, se descubren dinámicamente. Me gusta modular, así que tiendo a ir por este camino.

A veces, puede hacer que una función sea inaccesible como una solución temporal a corto plazo, más fácilmente que eliminarla realmente. Verifique si es aceptable tener artefactos visibles (por ejemplo, botones y opciones de menú visibles pero deshabilitados).

Debe hacer que una función sea fácilmente conmutable solo si es un requisito que los usuarios / administradores puedan activar / desactivar la función.

Si es lo suficientemente fácil como para que no te importe hacerlo con anticipación, probablemente sea igualmente fácil hacerlo cuando sepas que es necesario, y un poco más fácil quitarlo.

Si no puede desactivar la función sin un riesgo significativo de introducir nuevos errores, dígaselo a las personas. De lo contrario, básicamente se ofrece como voluntario para ser el chivo expiatorio cuando ocurren los problemas inevitables, a pesar de que el verdadero problema es lo que resultó en este cambio de requisitos de última hora.

Según sus ediciones, supongo que esta fue una característica bastante integral. Quitarlo puede tener un impacto en otras partes del sistema. Realmente, el cliente no debe esperar poder solicitar cambios fundamentales en el sistema sin incurrir en ningún costo. Los costos en este caso son para que usted desactive esto de alguna manera (tal vez simplemente comentando grandes extensiones de código) y luego vuelva a probar para asegurarse de que no se haya roto nada.

La forma más sencilla de "deshabilitar" una característica como esta sería eliminar / comentar los puntos de entrada en el nivel más alto. Por ejemplo: si el único punto de entrada a la función es un botón en la interfaz de usuario, simplemente comente la línea que crea el botón. Si hay varios puntos de entrada, puede que tenga que cavar más profundo para deshabilitarlo.

Depende mucho de si es peligrosamente defectuoso / roto / no deseado

Si no puede hacer nada inseguro y solo lo excluyen por razones de facilidad de uso, falta de documentos de capacitación o porque está roto, generalmente solo eliminamos el punto de entrada a esa función de la interfaz de usuario y dejamos todo lo demás en su lugar.

Si tiene errores, lo hacemos y agregamos excepciones explícitas en la lógica comercial central para que no se pueda ejecutar.

Lo peor es donde la característica no es deseada (el cambio regulatorio hace que el concepto sea ilegal, por ejemplo) y todas las referencias a la característica deben eliminarse por completo.

A medida que avanza en la lista, aumenta el potencial de error. Dependiendo de su situación, la primera o las dos primeras opciones pueden ser algo que puede ponerse rápidamente, la tercera casi nunca lo es.

En cuanto al diseño en los conmutadores de funciones, a menos que el cliente lo desee, generalmente no voy en esa dirección hasta que el cliente haya demostrado un historial de hacer ese tipo de elección demasiado tarde.

Mi suposición es que la administración había vendido esta característica como un complemento pagado, y que en el último minuto el cliente dijo que no quería pagar el complemento (probablemente dándose cuenta de que no vale la pena).

En vista de eso, la gerencia se equivocó.

He trabajado con varios sistemas en los que el acceso a las funciones fue impulsado por la configuración de seguridad. Esto hace que este tipo de características deshabilite relativamente trivial. Simplemente no habilite la función para ningún grupo de seguridad. A menos que la función esté habilitada para todos, se habrá realizado la prueba con ella deshabilitada.

Otras características que se pueden deshabilitar fácilmente están vinculadas a los valores del código. Estos generalmente manejan un caso particular de algo como un producto, cliente o lo que sea. La desactivación de estas características se puede hacer al no habilitar los valores de código relacionados.

Como otros han señalado, algunas características tienen puntos de entrada de UI específicos que se pueden eliminar. (Los casos anteriores pueden ser casos especiales de esto). Eliminar los puntos de entrada debería permitirle enviar la función sin habilitar el acceso. Esta suele ser la forma menos riesgosa de manejar este caso.

Si las características se desarrollan en las ramas de características, debería poder eliminar la fusión de la rama de características y volver a probar. Esto debería ser más simple que otros métodos para deshabilitar el código. Crear un parche de eliminación de funciones simplificará la reactivación de la función más adelante. Esto le da un equivalente aproximado de una rama de características.