¿Cómo evitar que las especificaciones de desarrollo cambien a mitad del desarrollo?

Problema : Parece que con casi todos los esfuerzos de desarrollo en los que estoy involucrado, no importa cuánto tiempo se dedique a planificar antes de comenzar el desarrollo, siempre se requiere una gran cantidad de cambios a mitad o hacia el final del proyecto. Estos son a veces grandes cambios que requieren mucho desarrollo.

No trabajo para clientes que pagan dinero, este es un equipo de desarrollo interno en sitios web de desarrollo interno. Entonces, no es que pueda cobrar por eso ni nada. Y al final del día, tenemos que tratar de cumplir con los plazos.

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

Hay un famoso dicho militar, atribuido a Helmut von Moltke: "Ningún plan de batalla sobrevive al contacto con el enemigo". En el mismo sentido, no creo que sea posible hacer una especificación que no tenga que ser cambiada, no a menos que pueda predecir el futuro y leer las mentes de las partes interesadas (incluso entonces es posible que aún no hayan tomado una decisión, incluso si afirman que lo hicieron). En cambio, sugeriría abordarlo de varias maneras:

1. Haga una distinción clara sobre lo que se puede cambiar y lo que no. Comuníquelo claramente a las partes interesadas, haga que firmen explícitamente lo que no se puede cambiar lo antes posible.
2. Prepárese para el cambio de antemano. Utilice metodologías de código que permitan cambiar las partes modificables más fácilmente, invierta en configurabilidad, encapsulación y protocolos claros que permitan cambiar y reemplazar las partes de forma independiente.
3. Hable con las partes interesadas con frecuencia, solicite comentarios y aprobación. Esto te mantendrá sincronizado y evitará que digan "oh, eso no es lo que queríamos" cuando 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 "necesitaremos más tiempo" temprano si cree que lo haría; si el horario que le dan no es realista, es mejor saberlo (y tenerlo en el registro diciendo eso) al principio que al principio el fin.
5. Si los cambios son demasiado extensos y amenazan la fecha límite, retroceda y diga algo como "este cambio es posible, pero retrasará la fecha límite en X veces, haga su elección".
6. Realice un proceso formal para solicitar cambios, priorizar cambios y asignar cambios a versiones o lanzamientos. Si pudieras decirle a la gente "No puedo hacerlo en este lanzamiento, pero estaré feliz de programarlo para el próximo", es mucho mejor que decirles "llegas demasiado tarde, tu cambio no puede entrar , adiós "y los haría tu amigo; estarían felices de que lo liberes a tiempo para que puedas ser libre antes de llegar al próximo lanzamiento que tendrá su cambio, y no tu enemigo.

Entregue algo (dudo en usar la palabra cualquier cosa) temprano y entregue con frecuencia. Es decir, utilice algún tipo de metodología de desarrollo iterativo.

Esta es la base del desarrollo ágil, pero se puede usar con (casi) cualquier metodología.

Al dividir el proyecto en una serie de mini proyectos, obtienes más control, ya que puedes poner algo en frente del cliente temprano, no estás encerrado en un largo programa de desarrollo que queda desactualizado cuando el cliente cambia de opinión (como lo harán).

Cuando vean que el sistema evoluciona, algunos requisitos cambiarán, algunos serán redundantes y otros aumentarán en prioridad. Sin embargo, al tener un ciclo de vida corto del proyecto, 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 descubierto 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 acomodar 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 tanta gente adoptando métodos iterativos.

Ya sea que itere el producto o lo que sea, DEBE encontrar alguna forma de acomodar 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 pueda volar.

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

Estás haciendo la pregunta equivocada. Los cambios de especificaciones siempre sucederán en proyectos de desarrollo de software de cualquier tamaño.

A menudo se debe a que los requisitos comerciales cambian, pero también he visto que suceden porque los clientes (internos o externos) pueden tener dificultades para visualizar lo que es posible sin ver algo desde lo que iterar, por lo que tienen una visión que cambia lentamente a medida que interactúan con el Solución de 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 tirar todo lo que ya he escrito?"

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

No digo que sean una bala de plata para todos sus problemas, pero todos surgieron debido al deseo de manejar la situación que está describiendo, por lo que al menos valen la pena investigarlos.

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 tratar de evitarlo.

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

Sugeriría pensar en:

• ¿De dónde demonios vienen estos cambios?
• ¿Por qué no los conoces antes?
• ¿Por qué no estás contribuyendo a estos cambios (y potencialmente haciendo aún más de ellos)?

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

Pero si desea evitar perpetuamente ser el desarrollador frustrado "sorprendido" por los cambios, creo que necesita encontrar su camino más cercano a la acción de dónde se toman las decisiones. Después de todo, estoy seguro de que tiene una gran cantidad de ideas sobre cómo podría mejorar el producto. Siéntese en la mesa o acepte para siempre que solo tendrá que lidiar con esos "cambios sorpresa".

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

Maquetas HTML : cree siempre maquetas 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, haga que suceda en el prototipo HTML. Con esto, resolverá muchas cosas, como problemas de IU, 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 se está desarrollando para una organización empresarial, entre en su negocio, pídales que aclaren sus dudas y, sin falta, pregúnteles qué cambios quieren en su flujo (si es necesario).

Lanzamiento modular: libere su código de forma modular, libere, pruebe, reciba comentarios y libérelo nuevamente.

Es por eso que es casi imposible planificar con demasiada anticipación, pero no es una excusa para no planificar en absoluto. No te enamores demasiado de tus planes y no tendrás que preocuparte de que te rompan el corazón.

Dentro de su empresa hay un costo por 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 puede evitar que nadie quiera cambiar los requisitos, pero no pueden escapar de las consecuencias. Los cambios pueden aumentar significativamente los tiempos de desarrollo. 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 invadirá el horario de otro grupo.

La participación activa de los usuarios durante todo el ciclo de desarrollo, y el uso de la mayor metodología ágil 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 con frecuencia significa que la mayoría de los cambios se capturan lo antes posible.

Para mi es bastante fácil.
Dígale a uno, el "Propietario del producto" , que ordenó las características que esto está bien, pero tiene que elegir un par de características planificadas que podría prescindir para este plazo.
Piense en ello como una reunión de medio sprint con el PO donde le dice que el sprint no se reducirá a 0.

PD. Si no es el "PO" , diría que no me hablen a través del "PO"

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

No hay mejores formas. Depende de la administración limitar los cambios a las especificaciones en la cierta fase 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). Entonces, la solución obvia es eliminar a los clientes. (¿De qué sirven de todos modos?)

Como no puede evitar el cambio, debe 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 poco código. Por lo tanto, debe presentar su diseño lo antes posible al cliente mediante el uso de prototipos (tal vez incluso un prototipo en papel), utilizar métodos ágiles, etc.

Podría considerar introducir alguna disciplina en el proceso de desarrollo utilizando 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 asignar 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), debe crear una nueva historia y estimar el esfuerzo de implementación. Luego puede dirigirse a su gerente (el propietario del producto ) y simplemente explicarle que la nueva función le costará ese tiempo extra. El gerente del proyecto tiene la responsabilidad de aceptar el esfuerzo adicional y ajustar el cronograma (posiblemente cancelando otras historias aún no implementadas).

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

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Pasé muchas tardes después del trabajo estresado e infeliz porque otro muchacho no entiende ni le importa cómo funciona el negocio del software. No tengo ningún problema para enfrentar a alguien más alto, pero no tengo el respaldo de mis compañeros nerds. Tener hijos es una perra, ¿eh? Probablemente renunciaré pronto.

Francamente, desearía que los programadores en general tuvieran más bolas. 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 es que pueda cobrar por eso ni nada. Y al final del día, tenemos que tratar de cumplir con los plazos "."

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

Mientras tanto, tratar de cumplir con los plazos le causa a usted y a sus compañeros de trabajo UNESCESARIO estrés; No puede pasar un fin de semana de calidad con amigos / familiares. Realmente es innecesario, porque quien sea que te esté tirando trabajo probablemente ni siquiera lo sepa, lo cual es triste.

Mi solución propuesta: colectivamente tener las pelotas para enfrentarlos y explicarles que no hay almuerzo gratis y que todo tiene un costo, que un mecánico automático 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 más si las especificaciones se cambiaron a mitad del trabajo, y hay una buena razón para ello. Si no están dispuestos a trabajar con usted de manera razonable, entonces, como grupo, se levantarán y se irán, y tendrán que contratar desarrolladores que puedan retomar el proyecto donde lo dejaron y entregarlo a tiempo.

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

Todavía tengo que ver a los programadores en huelga, pero esto habría 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. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Los programadores necesitan tener más bolas.

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