Quiero explicar por qué no se debe cambiar la especificación durante el período de desarrollo

Quiero explicar por qué la especificación no debe cambiarse durante el período de desarrollo al nuevo empleado del departamento de planificación.

Una especificación casi siempre cambia durante el desarrollo para cualquier proyecto que no sea el más simple.

Los motivos son:

• El desarrollo o las pruebas de integración más probables del proyecto descubren cosas que no se notaron cuando se realizó la especificación original, desde casos extremos hasta facetas importantes. Por ejemplo, el desarrollador advierte que pueden llegar confirmaciones de mensajes fuera de servicio.

• La condición del mundo real que determina la especificación no está congelada. Por ejemplo, se crea un nuevo producto financiero que debe agregarse a las especificaciones de procesamiento directo.

• Las presiones de la fecha límite resultan en la poda de las características.

• Se descubren otras partes interesadas adicionales del proyecto (por ejemplo, a mitad del proyecto, se descubre un proyecto similar en un área diferente, y los subsistemas comunes deben ser centralizados / compartidos; esto me sucedió a mitad del proyecto de 2 años de duración, lo que resultó en una recuperación importante arquitectura).

• Los patrocinadores adicionales del proyecto tienen nuevos requisitos de especificaciones (uno de los ejemplos más famosos es la historia del desarrollo de Bradley Fighting Vehicle).

En cuanto a por qué los cambios en las especificaciones tienen un efecto adverso (no puede decir "no debe suceder" ya que, como puede ver, hay muchas razones por las que lo hacen, casi todas fuera de su control y muchas por una buena razón):

• Los cambios en las especificaciones resultan en cambios en el código, lo que lo distrae de completar las partes del proyecto que aún no están escritas (como todos sabemos, y evangelizado por Joel Spolsky, los cambios en el enfoque son muy malos para los desarrolladores)

• Algunos cambios de especificación (a veces aparentemente MUY menores) pueden dar lugar a la necesidad de rediseñar / rediseñar completamente el sistema, ya que se eligió entre 2 arquitecturas basándose en un supuesto tomado de la especificación .

• En el caso de TDD, se puede anular una gran parte del trabajo puesto a prueba.

• Si los cambios en las especificaciones provienen de otras partes interesadas, como se señaló anteriormente, pueden ser contradictorios con las especificaciones existentes, lo que resulta en una disminución significativa en la calidad del producto (ver Vehículo de combate, Bradley).

• El cambio de especificación podría violar algunos requisitos comerciales existentes que el cambiador / solicitante podría no haber tenido en cuenta o no le importó (esto es realmente lo mismo que el último punto).

Por supuesto, todo esto es una fecha de entrega extendida (a veces significativamente) del proyecto y una probabilidad potencialmente mayor de defectos.

Para el mejor ejemplo de cómo un cambio menor en la especificación puede crear problemas extremos, tengo 3 letras para usted:

Y2K .

Todo lo que hicieron fue cambiar la especificación para decir " debe funcionar después del año 2000 ".

Además, en algunas situaciones es cierto que la especificación NO DEBE cambiar (en lugar de "no debería cambiar sin una buena razón"):

• Parte de la especificación es (o depende de) una especificación de un sistema externo con el que deben interactuar.

• Parte de la especificación es (o depende de) un hardware en el que se implementa el sistema.

• Requisitos del contrato con un cliente (aunque la limitación se refiere estrictamente a cambiar la especificación sin trabajar primero con los cambios con el cliente y cambiar el contrato, en lugar de simplemente el hecho del cambio)

• Es posible que un sistema deba cumplir requisitos legales o reglamentarios específicos independientemente de la preferencia del cliente. Ejemplos: cifrado de tarjeta de crédito, protección de datos fiscales.

Prohibir cambios en las especificaciones durante el desarrollo es ideal para el programador, pero no es realista en un entorno del mundo real. La gente siempre querrá hacer cambios, incluso cuando la cosa se está enviando por la puerta. Nunca se detiene. Y algunas de esas personas pueden estar firmando su cheque de pago. Cuanto más se preocupan, más lo piensan y, por lo tanto, con mayor frecuencia quieren revisar el diseño. Debe poder tolerar cambiar el diseño antes de completarlo, incluso si eso significa comenzar de nuevo.

Lo importante es comunicar claramente las consecuencias de los cambios para que todos tengan expectativas realistas del proceso de diseño.

Los cambios tienen que ser discutidos adecuadamente, y la persona a cargo de la cosa necesita tener una comprensión clara del impacto que tendrán los cambios en la fecha de entrega. Para conseguir eso, tiene que hablar con el desarrollador. Sin embargo, dado que una discusión en curso sobre los cambios inundará al desarrollador y evitará que ocurra cualquier trabajo real, los cambios deben ponerse en cola y debatirse a intervalos planificados y poco frecuentes. Eso es lo que esperas, por supuesto.

Idealmente, le indica a las personas que tomen nota de los cambios que desean hacer y que lo mencionen en la reunión de coordinación semanal / quincenal / mensual / lo que sea. Durante la reunión se discute cada solicitud de cambio, incluida una discusión sobre las modificaciones subyacentes que deberán realizarse para implementar la función solicitada y, por lo tanto, el efecto en la fecha de finalización. Una vez que se establece el "costo" del cambio, pueden determinar si se incluye o no.

Lo importante que introduce este proceso es la noción de que cada cambio tiene un costo asociado, y el costo generalmente es mayor a medida que avanza el proyecto, ya que se debe duplicar más trabajo. Las personas que no trabajan en el desarrollo generalmente no tienen idea de cuánto costará un cambio; la única forma para que lo sepan es proponiéndola y midiendo su reacción. Crear un proceso de revisión de cambios bien definido los ayudará a ellos y a usted.

Tenga en cuenta que los programadores tienden a ser extremadamente optimistas sobre lo fácil que es hacer un cambio, o extremadamente pesimistas sobre lo imposible que será hacer. Intente averiguar qué es usted comparando sus estimaciones originales con los resultados, y ajústelo en consecuencia.

Quizás sería mejor decir que la especificación no debe cambiar sin una solicitud y proceso de cambio válido. Solicitar un cambio de especificación tiene efectos sobre el cronograma y el costo, por lo que deben tenerse en cuenta en la aprobación.

Dado que existe un proceso adecuado de gestión de cambios, no hay nada "incorrecto" en cambiar las especificaciones, pero es probable que sea muy costoso, por lo que sus clientes pueden no estar muy contentos. Puede protegerlos de sí mismos al tratar de obtener algunos buenos requisitos y especificaciones por adelantado, de modo que se necesiten menos cambios.

La mejor analogía que tengo es compararlo con la construcción de una casa. El arquitecto elabora los planos y luego elabora una estimación; el cliente acepta (o no) el plan. Si el cliente desea instalar un baño adicional, el trabajo se detiene, los planes tienen que cambiar, se realiza una nueva estimación y el cliente está de acuerdo (o no).

Escribir software no es diferente. una vez que se haya hecho el acuerdo (después del diseño y la estimación), si es necesario realizar algún cambio, el trabajo debe detenerse para poder hacer un nuevo plan, una nueva estimación y luego obtener la aprobación (o no) y luego se reanuda el trabajo.

donde sea que dije o no significa que el proyecto continúa sin los nuevos cambios. Por supuesto, siempre hay tiempo y materiales para elaborar nuevos planes y estimaciones.