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

61

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?

David
fuente
99
establecer un hito de congelación de funciones en el desarrollo y organizar / negociar las cosas de tal manera que todas las solicitudes de funciones enviadas después de ese hito pasen a la próxima versión, no a la actual. El punto clave aquí es, por supuesto, planificar más de un lanzamiento con anticipación y compartir esta comprensión con los clientes
mosquito
44
@gnat Está suponiendo que el OP funciona en una organización donde la implementación de un hito de congelación de características sería aceptable para las partes interesadas. Basado en la experiencia personal trabajando en equipos de desarrollo internos, si tuviera que proponer algo así, las partes interesadas me mirarían y dirían algo en el sentido de "¿Quién diablos crees que me estás diciendo cuando puedo y no puedo cambiar? mis solicitudes de funciones por capricho? ¿Qué crees que te estoy pagando? Conoce tu lugar ".
maple_shaft
29
¿Has intentado guardar la especificación en un archivo de solo lectura?
orlp
14
Por supuesto, los cobra: cada cambio en la especificación retrasa el lanzamiento, por lo que su respuesta a una solicitud de cambio debe ser una estimación de la nueva fecha de lanzamiento si el cambio se agrega a la especificación. Quien solicite el cambio es responsable de la demora y debe explicarlo exactamente de la misma manera que uno explicaría los gastos.
Simon Richter
77
¿No es por eso que existe Agile? No puede congelar la especificación, así que haga que su proceso maneje una especificación cambiante.
Craig

Respuestas:

89

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.
StasM
fuente
3
También puede 'congelarlos' en fases y llevar los cambios a la 'próxima versión' .
Grant Thomas el
3
Formalizar el proceso de cambio y tener un alcance claro es un gran consejo, si está haciendo un trabajo de contrato de precio / alcance fijo. En otros entornos, este enfoque es difícil, ya que le da prioridad al cronograma y al precio sobre el alcance y la calidad. Tal vez eso es lo que necesitas en una situación dada. Pero, de nuevo, tal vez no es ...
tarda el
3
+1 para el número 6. Tuve una excelente experiencia con el primer ministro implementando ese requisito solo.
Joshua Drake
3
Los ciclos cortos son clave. La gente está mucho menos molesta por algo que se ve empujado al siguiente sprint de dos semanas que cuando el "próximo lanzamiento" está a seis meses de distancia.
Adam Jaskiewicz
1
"invertir en configurabilidad, encapsulación" es muy, variar consejos peligrosos. Con demasiada facilidad puede conducir a un efecto de plataforma interna y capas vacías de abstracción, que en realidad hacen que sea mucho más difícil cambiar un sistema. El sistema más fácil de cambiar es el más simple.
Michael Borgwardt
40

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.

ChrisF
fuente
22

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.

Michael Kohne
fuente
2
La NASA lo hace con parte de su software, o al menos lo suficientemente bueno como para enviar transbordadores al espacio. Lo que pasa es que en realidad siguen el modelo de cascada. La especificación está realmente congelada. Al menos esto es lo que entiendo desde fuera de la organización.
Joshua Drake
55
He trabajado en varios proyectos donde pudimos especificar completamente sistemas bastante significativos (complementos de conmutadores telefónicos). La clave en todos estos casos es que estábamos apuntando al hardware que ya había sido desarrollado, y estábamos desarrollando especificaciones publicadas (ITU), por lo que ninguno de los dos podía cambiar. Por lo tanto, su argumento no es válido para todos los proyectos, ¡solo el 99% de ellos! ;)
TMN
@ TMN: tampoco estaría de acuerdo con el 99%. Creo que el desarrollo similar a una cascada es mucho, mucho más exitoso de lo que los agilistas le dan crédito. De lo contrario, ya no se usaría. La mayoría de los proyectos en los que he trabajado han sido como cascadas. La clave es establecer una línea de base, luego cualquier cambio que se presente se estima para tiempo y dinero adicionales. Luego, el cliente decide si se incluye o no el cambio y el cronograma y los dólares se deslizan en consecuencia.
Dunk
1
@Dunk: Sé que gran parte de nuestro éxito fue nuestra adhesión a una metodología desarrollada en Bell Labs. Fue una ingeniería real, con una trazabilidad completa desde los requisitos hasta las especificaciones, desde los diseños hasta los planes de prueba, el código y los resultados de las entregas. Cuando una prueba fallaba, podía ver exactamente qué requisitos no se cumplían y sabía exactamente dónde buscar el código que fallaba (o el diseño que fallaba). Se necesita mucha disciplina y supervisión para que la cascada funcione, pero tienes razón, puede funcionar bien.
TMN
1
@ TMN Me pregunto cuál es la clave del éxito. ¿El uso del modelo de cascada o tu enfoque disciplinado? Creo que la última es la más importante de las dos.
Ross Goddard
19

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.

Bryan Oakley
fuente
No sé por qué esto no se me ocurrió antes, pero la idea de que tener código le permite a uno aceptar el cambio más fácilmente no puede ser correcta. ¿Es más fácil y lleva menos tiempo cambiar algunos diagramas o cambiar el código? Especialmente cuando el cambio es grande. Estoy de acuerdo en que no intente evitar el cambio, simplemente necesita señalar los impactos y aplicarlos de acuerdo con el cronograma. Los abrazos ágiles no cambian más que los métodos en forma de cascada. Incluso creo que maneja el cambio peor que la cascada, ya que puede ser un poco más costoso hacer cambios (dependiendo de cuándo ocurra el cambio).
Dunk
66
@Dunk Tienes razón en que es más barato cambiar un diagrama que un código, pero ¿cómo descubres que es necesario realizar un cambio? Muchas veces esto solo ocurrirá después de que le haya dado al usuario algo para usar y se dé cuenta de que le comunicó la idea equivocada, esto no es lo que quería, o también hay otras cosas que quería. El truco es descubrir cómo descubrir estos cambios lo antes posible.
Ross Goddard
@Ross: Esa es una de las razones para los prototipos. Se burla de una especie de sistema de trabajo y recibe comentarios. Es un mito que en cascada el cliente no sabe lo que está recibiendo hasta que se hace. He estado en proyectos que fueron lo suficientemente grandes donde la persona / personas de UI pasan los primeros meses burlándose de un prototipo representativo para garantizar que el cliente obtenga lo que quiere. Se podría afirmar que usar el sistema real es mejor, pero si termina tardando más en terminar porque el código necesita ser rediseñado con frecuencia, entonces no es una buena compensación.
Dunk
12

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.

MarcE
fuente
Sí. Para reformular la pregunta original: "¿Cómo podemos garantizar que entreguemos lo que el cliente quería al comienzo del proyecto, en lugar de lo que quería al final?"
Steve Bennett
5

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".

tarda
fuente
+1 "El cambio es la naturaleza de lo que hacemos" - Me gusta el cambio. El cambio puede ser algo bueno. Me da la oportunidad de ver si mis habilidades de diseño estaban a la altura o no. Si el cambio causa muchas modificaciones, hice un mal diseño. También brinda la oportunidad de hacer que el diseño sea más genérico. Da una excusa para arreglar lo que se apresuró para cumplir con el cronograma. Me permite volver y arreglar la basura de otras personas. Simplemente haga un seguimiento de las solicitudes de cambio e incorpórelas en el cronograma para que cuando entregue más tarde que el cronograma original, tenga evidencia para mostrar por qué.
Dunk
4

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.

Decifrador de codigos
fuente
4

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.

JeffO
fuente
4

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.

SkeetJon
fuente
3

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"

Farmor
fuente
1

¿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.

BЈовић
fuente
1

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?)

Daniel R Hicks
fuente
:) Si los clientes quieren una personalización loca, la pagarán con dinero y tiempo. Si el personal de ventas TIENE que hacer promesas para ofrecer características que aún no están disponibles la mayor parte del tiempo, la compañía tiene un problema mayor en general: tiene muchos competidores y no está en la cima de su juego, por ejemplo. Proveedor de bases de datos SyBase. O será irrelevante como empresa, o necesitará un CEO y diputados revolucionarios.
Trabajo
1

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.

Hans-Peter Störr
fuente
1

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.

Giorgio
fuente
0

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.

Job
fuente
0

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 ".

medivh
fuente