¿Cómo evitar que la especificación de desarrollo cambie a mitad del desarrollo?

Hay un famoso dicho militar, atribuido a Helmut von Moltke: "Ningún plan de batalla sobrevive al contacto con el enemigo". Del mismo modo, no creo que sea posible realizar una especificación que no deba cambiarse, no a menos que pueda predecir el futuro y leer las mentes de los interesados (incluso entonces es posible que aún no hayan tomado su decisión, incluso si afirman que lo hicieron). En su lugar, sugeriría que lo aborde de varias maneras:

1. Haga una distinción clara de lo que se puede cambiar y lo que no. Comuníquelo claramente a las partes interesadas, hágales firmar explícitamente las cosas que no se pueden cambiar tan pronto como sea posible.
2. Prepárese para el cambio por adelantado. Utilice metodologías de código que permitan cambiar las partes intercambiables con mayor facilidad, invierta en la capacidad de configuración, la encapsulación y los protocolos claros que permitan cambiar y reemplazar las partes de manera independiente.
3. Hable con los interesados con frecuencia, solicite comentarios y aprobación. Esto te mantendría sincronizado y evitaría que dijeran "oh, eso no es lo que queríamos" cuando ya es demasiado tarde. Como se señaló en otras respuestas, las metodologías ágiles y los mini lanzamientos frecuentes lo ayudarían con eso.
4. Ponga en el horario el tiempo para acomodar los cambios inevitables. No tenga miedo de decir "vamos a necesitar más tiempo" temprano si piensa que lo haría; si el programa que le dan no es realista, es mejor saberlo (y que lo mencione en el registro) al principio que a el fin.
5. Si los cambios son demasiado extensos y amenazan la fecha límite, rechace y diga algo como "este cambio es posible, pero la fecha límite será X, haga su elección".
6. Realice un proceso formal para solicitar cambios, priorizar cambios y asignar cambios a versiones o lanzamientos. Si pudiera decirle a la gente "No puedo hacerlo en este lanzamiento, pero me complacerá programarlo para el próximo", es mucho mejor que decirles "llega demasiado tarde, su cambio no puede entrar" , adiós "y los convertiría en tus amigos. Estarían encantados de que los liberes a tiempo para que puedas liberarte antes del próximo lanzamiento que tendrá su cambio, y no a tu enemigo.

Entregar algo (vacilo en usar la palabra cualquier cosa) temprano y entregarlo a menudo. Es decir, usar algún tipo de metodología de desarrollo iterativo.

Esta es la base del desarrollo Agile, pero puede usarse con (casi) cualquier metodología.

Al dividir el proyecto en una serie de mini proyectos, obtienes más control, ya que puedes poner algo delante del cliente antes de tiempo, no estás limitado a un largo programa de desarrollo que se desactualiza cuando el cliente cambia su mente (como lo harán).

Cuando vean que el sistema evoluciona, algunos requisitos cambiarán, algunos se volverán redundantes y otros aumentarán de prioridad. Sin embargo, al tener un ciclo de vida del proyecto corto, podrá hacer frente a estos cambios.

La teoría de que es posible especificar completamente un proyecto de software de cualquier tamaño significativo es una fantasía completa. Se ha encontrado que esta teoría no funciona en organizaciones de grandes a pequeñas durante casi toda la historia del desarrollo de software.

¡DEBE encontrar alguna forma de adaptarse a los cambios a medida que avanza! Van a suceder, porque la mayoría de las partes interesadas, incluso si dicen 'sí, eso es lo que quiero' en realidad no tienen idea de lo que quieren hasta que está frente a ellos. Es por eso que tenemos tantas personas que adoptan métodos iterativos.

Ya sea que repitas el producto o lo que sea, DEBES encontrar una manera de adaptarse a estos cambios, porque tratar de encontrar formas de no tener cambios es solo pedirle a la gravedad que se apague por unos minutos para que puedas volar.

No intentes evitar el cambio, abraza . Cuanto más planifique con anticipación, más probable será que su plan cambie. Entonces, planea menos , no más. Adopte una metodología de desarrollo ágil en la que entregue pequeños trozos de código de trabajo con frecuencia, dando al cliente la oportunidad de cambiar las especificaciones cada dos semanas.

Estás haciendo la pregunta incorrecta. Los cambios específicos siempre ocurrirán en proyectos de desarrollo de software de cualquier tamaño.

A menudo se debe a que los requisitos del negocio cambian, pero también lo he visto porque los clientes (internos o externos) pueden tener dificultades para visualizar lo que es posible sin ver algo de lo que deban pasar, por lo que tienen una visión que cambia lentamente a medida que participar con la solución en desarrollo.

La pregunta que debe hacerse no es "¿cómo puedo bloquear la especificación", es "cómo puedo estructurar mi código y procesos para responder a un entorno cambiante sin desechar todo lo que ya he escrito?"

Esto lo lleva al mundo del bingo de palabras de moda: metodologías ágiles, desarrollo iterativo y soluciones técnicas como codificación modular / basada en componentes, integración continua ... y la lista continúa.

No estoy diciendo que sean una bala de plata para todos tus problemas, pero todos surgieron debido a un deseo de manejar la situación que estás describiendo, por lo menos vale la pena investigar.

Lo siento si eso no ofrece soluciones concretas, pero tiendo a pensar que un cambio de mentalidad para aceptar y gestionar el cambio pagará mayores dividendos que intentar evitarlo.

Un cambio es solo una sorpresa ... ¡si es una sorpresa!

Sugeriría pensar en:

• ¿De dónde vienen estos cambios de todos modos?
• ¿Por qué no estás al tanto de ellos antes?
• ¿Por qué no estás contribuyendo a estos cambios (y potencialmente estás haciendo más de ellos)?

El cambio es la naturaleza de lo que hacemos. ¿Desde cuándo codificó un algoritmo exactamente según lo previsto el día 1?

Pero si desea evitar que el desarrollador frustrado se "sorprenda" por los cambios a perpetuidad, creo que debe encontrarlo más cerca de la acción en la que se toman las decisiones. Después de todo, estoy seguro de que tiene un montón de ideas sobre cómo podría mejorar el producto. Obtenga un asiento en la mesa, o acepte para siempre que solo tendrá que lidiar con esos "cambios sorpresivos".

Bueno, eso es una llamada, los clientes siempre quieren más, pero aquí hay algunos puntos que debe considerar:

Maquetas de HTML: Siempre cree maquetas de HTML para definir la parte de la interfaz de usuario de una aplicación, muéstreles cómo se verá y pídales sus opiniones. Si encuentra algo razonable para cambiar, hágalo en el prototipo de HTML. Usando esto, resolverá muchas cosas como problemas de UI, flujo básico y algunos complementos (como Clasificación, Paginación, número de registros que se mostrarán, etc.)

Participación activa desde el otro extremo: Esto es muy importante si está desarrollando para una organización empresarial, ingrese a su negocio, pídales que aclaren sus dudas y, sin falta, pregúnteles qué cambios ¿Quieren en su flujo (si es necesario)?

Versión modular: Libere su código de manera modular, publique, pruebe, reciba comentarios y vuelva a publicar.

Es por esto que es casi imposible planear con mucha anticipación, pero no es una excusa para no planear nada. No te enamores demasiado de tus planes y no tendrás que preocuparte por que te rompan el corazón.

Dentro de su empresa, hay un costo para usar los recursos de TI, ya sea que alguien lo admita, lo rastree o tenga que presupuestarlo o no. La realidad es que su equipo solo puede crear tanto código en un período de tiempo determinado. Todos los departamentos y proyectos comparten este presupuesto.

No puedes evitar que alguien quiera cambiar los requisitos, pero no pueden escapar a las consecuencias. Los cambios pueden aumentar significativamente los tiempos de desarrollo. Ese es un hecho con el que tienen que lidiar o decidir no hacer el cambio. ¿Una solicitud de un departamento afecta a otro? Es posible que tenga que mover completamente su proyecto detrás de otros departamentos porque la solicitud de cambio afectará el cronograma de otro grupo.

La participación activa del usuario a lo largo del ciclo de desarrollo, y el uso de la metodología Agile que sea posible, realmente nos ayuda con nuestros productos.

Los cambios en las especificaciones son inevitables, pero al ser transparentes con los usuarios y, sobre todo, consultarlos frecuentemente significa que la mayoría de los cambios se capturan lo antes posible.

Para mí es bastante fácil.
Dígale a la persona, el "Propietario del producto" , que ordenó las funciones que está bien, pero que tiene que elegir un par de funciones planificadas que podría no tener para esta fecha límite.
Piense en ello como una media reunión de sprint con el PO donde le dice que el sprint no se reducirá a cero.

Ps. Si no es el "PO" , diría que no me hable, vaya al "PO"

  

¿Cuáles son algunas de las mejores formas que han encontrado para minimizar y evitar que los cambios en las especificaciones surjan a mitad de camino o después del desarrollo?

No hay mejores maneras. Depende de la administración limitar los cambios a las especificaciones en la fase determinada del desarrollo.

Sin embargo, debe diseñar su software de tal manera que espere los cambios. Entonces el impacto de los cambios sería mucho menor. El desarrollo iterativo e incremental es un buen comienzo.

Descubrí que, directa o indirectamente, los clientes son la causa de la mayoría de los cambios (y también de los errores más críticos, por cierto). Así que la solución obvia es eliminar clientes. (¿De qué sirven?)

Ya que no puedes evitar el cambio, necesitas abrazarlo. Creo que lo más importante que puede hacer es: debe intentar obtener las solicitudes de cambio del cliente lo antes posible , porque es menos costoso cambiar las cosas cuando solo hay un pequeño código. Por lo tanto, debe presentar su diseño lo antes posible al cliente mediante el uso de prototipos (quizás incluso un prototipo de papel), utilizar métodos ágiles, etc.

Podrías considerar introducir algo de disciplina en el proceso de desarrollo usando Una metodología como SCRUM. En SCRUM, un equipo hace un plan inicial al dividir la implementación de las características en historias , y asignando a cada historia una estimación del esfuerzo (número de horas de trabajo o días necesarios para implementar esa historia).

Si se solicita un cambio tardío (para una historia que ya se ha implementado), usted es necesario crear una nueva historia y estimar el esfuerzo de implementación para ella. Luego puede dirigirse a su gerente (el propietario del producto ) y simplemente explicar Que la nueva característica va a costar ese tiempo extra. El gerente del proyecto Luego tiene la responsabilidad de aceptar el esfuerzo extra y ajustar el calendario (posiblemente cancelando otras historias aún no implementadas).

Incluso si su equipo no va a implementar SCRUM u otro desarrollo completamente proceso, al menos podría introducir la planificación basada en historias , estime el esfuerzo de desarrollo para cada historia y ajuste el cronograma a medida que se solicitan nuevas historias.

enlace

Pasé demasiadas tardes después del trabajo estresadas e infelices porque otro miembro no comprende o no le importa cómo funciona el negocio de software. No tengo problemas para confrontar a alguien más arriba, pero no tengo el respaldo de mis compañeros nerds. Tener hijos es una perra, ¿eh? Probablemente renuncie pronto.

Francamente, desearía que los programadores en general tuvieran más balones. Veamos esto:

"" "No trabajo para clientes que pagan dinero, este es un equipo de desarrollo interno en sitios web de desarrollo interno. Por lo tanto, no puedo cobrar por ello ni nada. Y al final de El día, tenemos que intentar cumplir con los plazos. "" "

Si estaba tratando con un cliente que pagaba $ y se cubrió el culo con un contrato (http://vimeo.com/22053820?utm_source=swissmiss), los cambios en las especificaciones le costarán más tiempo a este cliente Y más dinero (o potencialmente mismo o menos tiempo pero exponencialmente más dinero). Su empresa está tratando de evitar cambiar la especificación sin incurrir en el costo de más tiempo y más dinero.

Mientras tanto, tratar de cumplir con los plazos provoca que usted y sus compañeros de trabajo TENGAN UN estrés innecesario; No puedes pasar un fin de semana de calidad con amigos / familia. Realmente es innecesario, porque quienquiera que te esté lanzando un trabajo probablemente ni siquiera lo sepa, lo cual es triste.

Mi solución propuesta: colectivamente tenga las bolas para enfrentarlos y explique que no hay almuerzo gratis y que todo ha costado, que un mecánico de automóviles tomaría más tiempo y cobraría más si las especificaciones se cambiaran a mitad del trabajo, que una agencia contratante tomaría más tiempo y cobraría más si las especificaciones se cambiaran a mitad del trabajo, y hay una buena razón para ello. Si no están dispuestos a trabajar con usted de una manera razonable, usted como grupo se levantará y se irá, y tendrá que contratar desarrolladores que puedan retomar el proyecto donde se dejó y entregar a tiempo.

Luego también hay una promesa de desarrollo ágil, lo que implica que no hay plazos difíciles.

Todavía estoy por ver a los programadores en huelga, pero esto hubiera sido algo. Los gerentes incompetentes son demasiado abundantes en las compañías de software. Demasiadas personas quieren obtener algo por nada, en Craigslist o dentro de una empresa real. enlace

Los programadores necesitan tener más bolas.

Un enfoque que encontré que funciona bastante bien (obviamente no con todos los gerentes) es "Creo que puedo hacer eso, sí. Depende: ¿cuánto tiempo adicional le asigna a este proyecto? Es bastante importante cambio que estás solicitando. "