¿Cómo le explica a un equipo "ágil" que todavía necesitan planificar el software que escriben?

50

Esta semana en el trabajo volví a agilizarme . Después de haber pasado por la metodología estándar de desarrollo ágil, TDD, propiedad compartida, ad hoc de nunca planear nada más que unas pocas historias de usuario en un pedazo de tarjeta, masticando verbalmente el cud sobre las tecnicidades de una integración de terceros ad nauseam sin hacer nada real pensando o con la debida diligencia y acoplando arquitectónicamente todo el código de producción a la primera prueba que viene a la cabeza de cualquiera en los últimos meses, llegamos al final de un ciclo de lanzamiento y miramos que la principal característica externamente visible que hemos estado desarrollando es demasiado lenta para uso, con errores, volviéndose laberínticamente complejo y completamente inflexible.

Durante este proceso, se realizaron "picos", pero nunca se documentaron y nunca se produjo un solo diseño arquitectónico (no hubo FS, entonces qué demonios eh, si no sabe lo que está desarrollando, ¿cómo puede planificarlo o investigarlo? ?) - el proyecto pasó de par en par, cada uno de los cuales solo se centró en una sola historia de usuario a la vez y el resultado fue inevitable.

Para resolver esto, salí del radar, fui (la temida) cascada, planifiqué, codifiqué y básicamente no cambié el par e intenté todo lo que pude para trabajar solo, centrándome en una arquitectura sólida y especificaciones en lugar de pruebas unitarias que vendrá más tarde una vez que todo esté inmovilizado. El código ahora es mucho mejor y en realidad es totalmente utilizable, flexible y rápido. Ciertas personas parecen haberse resentido realmente por hacer esto y se han esforzado por sabotear mis esfuerzos (posiblemente inconscientemente) porque va en contra del proceso sagrado de ágil.

Entonces, ¿cómo usted, como desarrollador, explica al equipo que no es "poco ágil" planificar su trabajo y cómo encaja la planificación en el proceso ágil? (No estoy hablando del IPM; estoy hablando de sentarme con un problema y dibujar un diseño de extremo a extremo que diga cómo se debe resolver un problema con suficiente detalle para que cualquiera que trabaje en el problema sepa qué arquitectura y patrones que deberían usar y dónde el nuevo código debería integrarse en el código existente)


fuente
26
El primer párrafo suena como una diatriba contra ágil. El resto todavía suena como una diatriba, solo contra el resto de su equipo. Es posible que desee parafrasear.
1
+1 está muy interesado en cómo las personas resuelven esto de una manera pragmática que le permite aprovechar lo mejor que tanto la cascada como el ágil tienen para ofrecer. Por cierto: ágil no es igual a "sin diseño", pero el diseño tiende a ser la primera víctima en el implacable ciclo de sprints ...
Marjan Venema
55
Bueno, hasta cierto punto lo he tenido hasta el cuello con "ágil". A cada paso, ágil parece estar impidiendo que alguien escriba una línea de código decente y todo comienza con la premisa ágil de "no documentamos", cuyo corolario es "no planificamos". No quiero odiar a los ágiles, pero por lo que puedo ver, siempre y cuando anime a las personas a no planificar su software, es, en el mejor de los casos, contraproducente y, en el peor, peligroso.
99
@Marjan Venema, esa es mi preocupación. Estoy seguro de que ágil nunca quiso decir "sin diseño" como "no optimizar prematuramente" no quiso decir "no escribir código eficiente". Pero esa parece ser la interpretación del mercado de masas. La forma en que Agile enfatiza la comunicación es excelente, y un cambio realmente refrescante, pero me parece que en el mundo ágil el software en sí mismo es más una idea de último momento.
99
Es obvio que está frustrado con una aplicación deficiente de los principios ágiles, pero esto parece una diatriba disfrazada como una pregunta. Para ser claros: Agile favorece "responder al cambio sobre seguir un plan", lo que significa que "mientras haya valor en los elementos de la derecha , valoramos más los elementos de la izquierda". Ciertamente es posible valorar muy poco seguir un plan , lo cual parece ser el caso aquí.
Rein Henrichs

Respuestas:

51

Creo (y quizás me esté arriesgando) que TODOS los proyectos deberían tener un poco de cascada clásica: la fase inicial de análisis y especificación es esencial. Debe saber lo que está haciendo y debe tenerlo por escrito. Obtener los requisitos por escrito es difícil y lleva mucho tiempo, y es fácil de hacer mal. Es por eso que muchos lo omiten, cualquier excusa servirá: "Oh, somos ágiles, así que no necesitamos hacer eso". Érase una vez, antes ágil, era "oh, soy realmente inteligente y sé cómo resolver esto, así que no necesitamos hacer eso". Las palabras han cambiado un poco, pero la canción es esencialmente la misma.

Por supuesto, esto es todo toro: debe saber lo que debe hacer, y una especificación es el medio por el cual el desarrollador y el cliente pueden comunicar lo que se pretende.

Una vez que sepa lo que tiene que hacer, esboce una arquitectura. Esta es la parte de "obtener el panorama general correcto". Aquí no hay una solución mágica, no hay una manera correcta, y no hay una metodología que lo ayude. Las arquitecturas son la SÍNTESIS de una solución, y provienen de un genio parcialmente inspirado y un conocimiento parcialmente ganado.

En cada uno de estos pasos habrá iteración: encontrará cosas incorrectas o faltantes, y vaya a solucionarlas. Eso es depuración. Se acaba de hacer antes de que se escriba cualquier código.

Algunos ven estos pasos como aburridos o no necesarios. De hecho, estos dos pasos son los más importantes para resolver cualquier problema: si se equivocan, todo lo que sigue será incorrecto. Estos pasos son como los cimientos de un edificio: si te equivocas, tendrás una Torre inclinada de Pisa.

Una vez que tenga el QUÉ (esa es su especificación) y el CÓMO (esa es la arquitectura, que es un diseño de alto nivel), entonces tendrá tareas. Por lo general, muchos de ellos.

Agrupe las tareas como desee, asígnelas como desee. Use la metodología de la semana que le guste o que funcione para usted. Y realice esas tareas, sabiendo hacia dónde se dirige y lo que necesita lograr.

En el camino habrá rastros falsos, errores, problemas encontrados con las especificaciones y la arquitectura. Esto provoca cosas como: "Bueno, toda esa planificación fue una pérdida de tiempo". Que también es toro. Simplemente significaba que tenías MENOS errores que tratar más adelante. A medida que encuentre problemas con las cosas de los primeros días de alto nivel, ARREGLELOS.

(Y sobre un tema secundario aquí: hay una gran tentación que he visto una y otra vez para tratar de cumplir con una especificación que es costosa, difícil o incluso imposible. La respuesta correcta es preguntar: "¿Se ha roto mi implementación o ¿se ha roto la especificación? "Porque si un problema puede resolverse rápida y económicamente cambiando la especificación, entonces eso es lo que debe hacer. A veces esto funciona con un cliente, a veces no. Pero no sabrá si no preguntes)

Finalmente, debes probar. Puede usar TDD o cualquier otra cosa que desee, pero esto no garantiza que, al final, haya hecho lo que dijo que haría. Ayuda, pero no garantiza. Entonces necesitas hacer la prueba final. Es por eso que cosas como Verificación y Validación siguen siendo elementos importantes en la mayoría de los enfoques de gestión de proyectos, ya sea el desarrollo de software o la fabricación de excavadoras.

Resumen: necesitas todas las cosas aburridas por adelantado. Utilice cosas como Agile como medio de entrega, pero no puede eliminar el pensamiento, las especificaciones y el diseño arquitectónico anticuados.

[¿Esperaría seriamente construir un edificio de 25 pisos al poner a 1000 trabajadores en el sitio y decirles que formen equipos para hacer algunos trabajos? Sin planes Sin cálculos estructurales. Sin un diseño o visión de cómo debería verse el edificio. Y con solo saber que es un hotel. No, no lo creo.]

rápidamente_ahora
fuente
11
+1. +10 si pudiera. Si no tiene una buena idea de qué es lo que finalmente está construyendo, que solo puede provenir de un trabajo de diseño inicial, incluso si modifica ese diseño más adelante, entonces el paradigma de desarrollo que está siguiendo es "lanzar mierda en la pared y ver qué se pega ".
Ant
55
-1. No me gustan las especificaciones detalladas porque las personas / clientes cambian de opinión todo el tiempo, lo que hace que las especificaciones y los diseños iniciales no tengan sentido, por no hablar de desperdicio. Por lo tanto, en lugar de perder el tiempo "reuniendo requisitos" y demás, debe crear un software de trabajo que le muestre a su cliente lo antes posible, para que pueda obtener comentarios reales sobre el siguiente paso. En lugar de hacer conjeturas y especulaciones. En cuanto a "las especificaciones son el medio de comunicación": prefiero hablar con mis clientes y trabajar de forma iterativa, pero bueno, cada uno con lo suyo, supongo.
Martin Wickman
66
+1. +10 si pudiera +1. Soy un adicto total al software de construcción, es como construir una analogía de construcción porque simplemente lo es. Sí, el software no es físico, sí se hace correctamente, puede ser altamente modular y desacoplado. Pero hacerlo muy modular y desacoplado es muy difícil; eso es lo que toma el tiempo y la planificación. Me he dado cuenta de que siempre habrá dos campos en la ingeniería de software: los que piensan que la planificación es una pérdida de tiempo y los que no. Y sabes, también me di cuenta de que la gente no cambia de campamento, bueno, en realidad no. He trabajado en un entorno altamente planificado y ...
66
Estoy de acuerdo contigo, pero lo que estás describiendo realmente ES ágil. Agile dice "sin gran diseño por adelantado", no "sin diseño". Esto se dijo como respuesta a los enormes y rígidos proyectos de monstruos en cascada de megaempresas de antaño. No es una excusa para no diseñar y encontrar una buena arquitectura para su código. El punto es no pasar semanas o meses haciendo TODO el diseño antes de comenzar a codificar, porque el diseño SERÁ incorrecto, y cuanto más lo notes y lo arregles, mejor. Obtenga comentarios rápidos, repita, mejore, etc.
Sara
55
Kai: veo que Agile se usa como una excusa para no hacer especificaciones, no planificar, simplemente sumergirse. Y eso es simplemente incorrecto.
rapid_now
36

Todavía me sorprende que mucha gente piense que TDD significa escribir pruebas unitarias primero. No, significa escribir pruebas que necesitará antes de escribir el código. La prueba en realidad puede ser una prueba unitaria, una prueba de integración, una prueba de extremo a extremo y, por supuesto, una prueba de rendimiento (bueno, probablemente no escriba una prueba de rendimiento antes del código probado, pero eso no significa que no deba escribirla en absoluto). El tipo necesario de la prueba debe ser visible desde la definición de hecho para la historia del usuario. Si uno de los criterios de aceptación para la historia del usuario dice que la función debe proporcionar el resultado dentro de 500 ms con 50 usuarios concurrentes, la historia del usuario no puede considerarse como completada hasta que tenga una prueba de rendimiento que demuestre que se cumplen estos criterios de aceptación. Una vez que tenga la prueba automática, puede verificar todos los días que está aprobando a medida que agrega otras funciones.

Parece que sus criterios de aceptación no se definieron correctamente y por eso no pudo probar su rendimiento. Aún así, puede suceder que la aplicación funcione mal una vez que la implemente en el entorno real y la use bajo una carga pesada, pero siempre se puede considerar como un incumplimiento de los requisitos (si el requisito no está definido, el desarrollador no lo tiene en cuenta al trabajar en el código) o el equipo de desarrollo (pruebas insuficientes contra los requisitos definidos).

Otra cosa interesante es que los desarrolladores de su equipo se están centrando en la historia de un solo usuario. Agile se trata de comunicación, por lo que los desarrolladores deben comunicar lo que requieren las historias de los usuarios y cómo afecta al resto de la aplicación; la colaboración es imprescindible. La prueba también debería abarcar eso, de modo que si un desarrollador rompe la funcionalidad necesaria para otra historia de usuario, debería ser visible en las pruebas automatizadas. Si aún siente que no es suficiente o no funciona, puede presentar una reunión de arquitectura donde todo el equipo coopera y discute la arquitectura de la aplicación. Por lo general, es suficiente tener esa reunión una vez por semana.

Muchas cosas del proceso en cascada se reemplazan con comunicaciones y pruebas automáticas. ¡Nadie dice que no se puede escribir documentación o diseño de alto nivel! Puedes y muchos equipos usan, por ejemplo, Wiki para eso.

Ladislav Mrnka
fuente
77
+1 excelente respuesta. La historia es el objetivo: es la punta del iceberg, un marcador de posición para una conversación futura, el primer paso en el viaje; ¡No es todo el viaje! Las descripciones de las pruebas son los requisitos, los casos de uso y los criterios de aceptación combinados. El diseño no se ignora, el diseño está limitado al alcance de la historia y las pruebas, pero realiza todo el diseño que necesites . Cualquiera que se saltee el diseño y diga que esa es la forma ágil, o bien no entiende (vaya a leer el libro XP nuevamente), no quiere (¡codificación de cowbow yee-haw!), O simplemente está siendo flojo . Y dando a Agile un mal nombre.
Steven A. Lowe
16

[nuestro producto] era demasiado lento para usar, tenía errores, se volvía laberínticamente complejo y completamente inflexible.

Eso no tiene nada que ver con ágil, es una señal de que los programadores no están haciendo su trabajo correctamente.

Una idea básica de ágil es que el equipo tiene control completo sobre el proceso. Eso significa que deben acordar la cantidad de planificación, documentación, pruebas y cómo manejan la refactorización. Todo ese poder es grandioso, pero también conlleva responsabilidad y es aquí donde probablemente falló su equipo. Aceptaron su libertad, pero descuidaron sus responsabilidades.

Al final, solo se trata de explicar la calidad del código y tratar de acordar una forma de aumentarlo y mantenerlo de esa manera. Las prácticas normales de programación se aplican, de verdad.

Consejo profesional: use su "Definición de hecho" para hacer cumplir esto. Asegúrese de que todos estén de acuerdo y colóquelo visible para todos. Úselo como un guardián estricto para decidir si una historia se completa o no. Incluso es posible agregar requisitos no funcionales (como el rendimiento) a esa lista también.

Martin Wickman
fuente
1
"Aceptaron su libertad, pero descuidaron sus responsabilidades" tal vez debería ser una pancarta en el muro ágil "¿Han aceptado sus responsabilidades junto con su libertad?"
Andy Dent
Gran respuesta, ¿puedo sugerir agregar que cuando usa el DoD como un contrato de esta manera, también se vuelve central en la retrospectiva? ¿Cómo nos ayudó u obstaculizó este DoD para agregar valor a nuestros clientes?
Graham Lee
11

Sí. Tus compañeros de equipo son idiotas. Su proyecto apesta debido a Agile. ¿Sentirse mejor? Bien, sigamos adelante. :PAGS

Creo que usted y su equipo podrán comunicarse de manera más efectiva sobre lo que salió mal si se concentra menos en los nombres de sus Metodologías de capital-M y más sobre por qué el software que escribió fue tan lento y defectuoso. No utilice los términos ágil o cascada en absoluto. Están claramente cargados emocionalmente en su oficina.

Ágil funciona a veces. Esta vez no funcionó para tu equipo. Algunas personas dirán que es porque hiciste mal a Agile. Después de todo, Agile funciona, así que si lo hubieras hecho bien, habría funcionado, ¿verdad? Lo que sea.

No parece que nadie esté en desacuerdo con que hubo un fracaso, pero no vas a ganar amigos, influir en las personas o hacerlo mejor la próxima vez si culpas a una metodología. Eso probablemente tuvo poco que ver con lo que realmente salió mal.

En cambio, concéntrese en precisar las causas más directas de la falla y trabaje con el equipo para asegurarse de que no vuelvan a suceder. Esto requerirá habilidades de las personas.

Hablando de las habilidades de las personas, no debería sorprenderte que tu equipo no apreciara que los hicieras quedar mal haciendo todo su trabajo y haciéndolo mejor de lo que lo hicieron. Al hacer esto "bajo el radar", puede haber dañado algunas relaciones que ahora tendrá que reconstruir para ser un miembro efectivo del equipo.

Creo que la mejor manera de ver una situación como esta es considerar la producción total a largo plazo del equipo en su conjunto. Es posible que haya ahorrado la semana esta vez, pero podría haber mejorado a largo plazo para su empresa al construir un mejor equipo .

Te estoy contando todas estas cosas, pero creo que probablemente ya las conoces y podrías explicárselas a alguien más si no estuvieras tan cerca de esta situación.

PeterAllenWebb
fuente
9

Si desea agregar una cita concisa a sus discusiones, Eisenhower tuvo una buena:

"Los planes no son nada; la planificación lo es todo".

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

Él quiso decir que debe esperar cambiar sus planes y, por lo tanto, no le dé demasiado valor al plan tal como existe, pero al mismo tiempo el proceso de planificación enfocará sus energías de manera crucial. Debe hacer planes antes de poder probarlos y refinarlos.

jhocking
fuente
9

+1 Esta es la mejor descripción de empresa ágil que he leído recientemente.

Todos los que se llevan bien con ágiles señalan que nunca se suponía que significara esto, pero una vez que todos quedan atrapados en las métricas, esto es exactamente lo que obtienes de un equipo que no tiene pasión por la calidad del producto y está obsesionado con pruebe la cobertura por encima de todo lo demás o cumpla con los plazos de entrega semanales independientemente de la esquina en la que hayan pintado a todos los demás porque eso es todo lo que hace que llegue al nivel de gestión semanalmente.

Nunca he visto esto arreglado con nada menos que una reorganización. Si usted es una empresa de grado medio sin nada especial para atraer a personas realmente apasionadas, incluso eso no lo solucionará a menos que la próxima administración cambie las metodologías a veces.

Agile solo parece funcionar bien en organizaciones donde el equipo de desarrollo se preocupa lo suficiente como para hacer un buen producto a pesar del trabajo adicional no acreditado que se requiere. Efectivamente, tienen que preocuparse lo suficiente como para que sea bueno en su propio tiempo, luchar por mejorar (y estar dispuestos a gastar mucho tiempo extra rehaciendo las pruebas en algunos casos de TDD)

Obviamente te importa enviar un buen producto, obviamente les importa pasar por un conjunto de mociones con guión y recibir un cheque de pago para limpiar continuamente el desorden que hacen.

Buscaría un empleo menos irritante en otro lugar, sea ágil o no.

Si está completamente quemado en ágil, hay muchos lugares que aún hacen otras metodologías. Casi cualquier cosa en oferta o contrato, por ejemplo.

Cuenta
fuente
1
Esa es en realidad la peor definición de ágil que leí. Los desarrolladores no necesitan hacer un trabajo extra y sin acreditar. Además, solo los idiotas trabajan en su propio tiempo. El tiempo dedicado a probar el código es un tiempo bien invertido.
Bћовић
No podría estar más de acuerdo, Agile, cuando se convierte en la bestia que a menudo se convierte en niveles de burocracia empresarial, es el peor ágil posible. En un entorno de color de cinta no empresarial, el equipo solo haría esas cosas como historias o antes de comprometerse con las historias. Cuando Agile se convierte en un indicador de métricas corporativas, la flexibilidad suele ser lo primero.
Bill
4

Tiendo a usar una especie de híbrido. El plan general es cascada, pero la ejecución es ágil.

Supongo que si la situación es tan mala como dices, tu equipo no está usando ágilmente, solo está siendo flojo o indisciplinado. Ágil no se trata de no planificar, solo se trata de ser flexible y, bueno, ágil.

Ricardo
fuente
Tiendo a pensar eso también. Estoy seguro de que real ágil no se trata de no planificar, es solo que esa es una interpretación de ello.
Hay un mundo de diferencia entre el capital, "A" ágil y en minúscula, "a" ágil.
Aaronaught
Pssst ... no le digas eso a la gente ágil, ya que así es como casi todas las personas de la cascada lo hacen porque funciona. Todavía creen que TODOS los desarrolladores de cascada crean documentos monolíticos sin escribir ningún código hasta el final y en cada paso todo está mal porque no hay implementación.
Dunk
4

Tenemos los mismos problemas con algunos miembros del personal.

Básicamente, "No sé hasta que lo escriba" es una declaración favorita. Así que fuimos al revés, trabajamos con el cliente para definir los entregables con puntos de cierre. El último es "ahora escribe el código para hacer X".

Si tenemos "escribir diseño / prueba / plan, etc." en el mismo sprint entregable que "hacer el código divertido e interesante", entonces la primera parte nunca sucede ...

PERO si coloco "no puedes hacer ningún código divertido e interesante hasta que hayas dicho lo que vas a construir y el cliente haya cerrado"

  • en primer lugar, obtienes una aceptación gruñona, y algunas lágrimas y tuve que hacer mucho trabajo para rellenar los espacios en blanco y un esfuerzo extra ...
  • entonces obtienes reconocimiento cuando les preguntas "entonces, ¿cómo fue el proceso" que es mejor haber intentado la primera versión en papel?
  • entonces tiene los casos de prueba que los desarrolladores pueden ver, y puede señalar exactamente la expectativa de "lo que significa".
  • entonces los clientes que firman el desarrollo tienen una tasa de rechazo 80% menor ...
  • Además, observa a todos los desarrolladores caminando sosteniendo los documentos de diseño y hablando entre ellos sobre los diseños ... comienzan a entenderlo realmente.
  • Luego, averigua cómo dividir el plan del proyecto en trozos pequeños y hacer un proceso con él.

La parte ágil se produce cuando el cliente cambia del plan y usted puede adaptarse dentro de un ciclo de 2 semanas NO volar por el asiento de sus pantalones y recuperarlo en el camino.

En nuestro caso, el "gran diseño inicial" se dividió en 9 etapas (lanzamientos de producción reales) con un promedio de 5 etapas. Los diseñadores y desarrolladores se mantienen a la par, los diseñadores están 1-3 etapas por delante de los desarrolladores ... demasiado lejos y los descubrimientos en el desarrollo rompen demasiado el diseño, demasiado cerca y ajustan el costo del diseño tanto como han sido. ya implementado "en piedra" dentro del desarrollo. Cada subetapa vale de 2 a 4 sprints para 1 desarrollador.

En proyectos más pequeños, solo tenemos que el mismo desarrollador diseña primero> cerrar sesión> factura> desarrollar> cerrar sesión> factura ... en ciclos.

El problema de nombres de prueba

La prueba tiene muchas caras, formalmente hay alrededor de 7 categorías de pruebas cada una con subsecciones ... una de estas posteriores es "escribir pruebas unitarias automatizadas".

Es un mal nombre tener "prueba de primer desarrollo" simplemente porque los desarrolladores entienden lo que significa "pruebas" en este contexto, ven las pruebas como escribir el código real de la prueba contra la interfaz para la implementación. Cuando no es realmente eso ... puede hacer esto cuando se trata de escribir el código, pero realmente "validar el diseño contra casos de uso e historias de usuarios ANTES de comenzar a escribir el código" ... hecho correctamente, esto elimina muchos de los problemas normalmente descubiertos durante el desarrollo mientras todavía está en la versión mucho más barata de "papel que se puede tirar".

Robin Vessey
fuente
3

Uno de los elementos clave de Agile es la idea de la mejora continua y la idea de que todo el equipo posee el proyecto. Por lo tanto, el enfoque correcto habría sido revisar los problemas con el equipo y hacer que el equipo decidiera cómo corregirlo.

Un miembro del equipo se va solo, abandonando todos los principios de Agile y haciendo las cosas a su manera, puede resultar en que una pequeña cantidad de código funcione bien, pero en realidad no avanza todo el proyecto de una manera positiva.

Dave
fuente
Me parece que avanzar en el proyecto fue precisamente lo que hizo . "Revisar con el equipo" no es en realidad una solución, es simplemente una forma de diferir la solución y difundir la responsabilidad.
Aaronaught
El equipo ya es responsable del resultado. Lo que necesitan es que alguien diga: "Estamos en mal estado, ¿cómo cambiamos nuestra metodología?" Luego lo arreglan.
Dave
2
Tengo la impresión de que lo que este equipo en particular necesita es que sus miembros aprendan a pensar por sí mismos en lugar de seguir ciegamente un proceso que no entienden. Hablar no logrará nada si ya es una cámara de eco.
Aaronaught
2

Una forma de hacer que funcionen puede ser hacer un T-Map que cubra todos los registros de Sprint

T-map

Cada equipo tiene un hilo, cada sprint es un período. Todo se une (que es donde su equipo parece caerse). Fije esto en alguna parte y obtenga imanes para representar los pares / subequipos. Incluso pueden "competir". Pero todos saben dónde están ellos y los otros equipos. Ponga dependencias aquí si hay alguna.

El punto aquí es que transmites el proceso total pero también lo desglosas en sprints. Incluso si solo se pone el primer sprint allí, y los otros períodos están en blanco, esta debería ser una excelente hoja de ruta para terminar el proyecto.

Pureferret
fuente
1

Tiene dos problemas: falta de forma en los requisitos y mala arquitectura.

Requisitos

Necesita un objetivo final general y una hoja de ruta detallada de cómo llegar allí.

En el mundo de las cascadas, el objetivo final es la especificación funcional, y la hoja de ruta de cómo llegar es el plan del proyecto.

En el mundo ágil, una forma es capturarlo en una historia de usuario épica. Luego, la hoja de ruta son las historias detalladas de los usuarios que desarrollan los detalles de la epopeya.

Nunca he estado completamente feliz con esa historia, porque la historia épica nunca captura suficiente carne para transmitir la idea completa. Entonces, lo que he tendido a usar es un documento de requisitos de sistemas de alto nivel junto con una historia de usuario épica o dos. Después de eso, la hoja de ruta son las historias detalladas de los usuarios.

Lo bueno de tener un documento de requisitos del sistema es que se pueden extraer los criterios de aceptación para muchas de las historias de usuarios.

Piense en el documento de requisitos del sistema de alto nivel como una "hoja de corte" que el marketing podría usar para vender el producto a un cliente experto en tecnología.

Arquitectura

Una de las cosas que le ofrece la "hoja de corte" es que pone límites al sistema que está diseñando. Eso le permite tomar decisiones informadas, desde el principio, sobre la arquitectura a utilizar.

Si su equipo hubiera tenido dicho documento desde el principio, no tendría que pasar por la molestia de rediseñar el sistema más adelante.


En realidad, un tercer problema que tienes es una mala comunicación. La comunicación es una calle de doble sentido (o de múltiples vías entre varias personas). Sin embargo, eso es solo una falla humana y requiere (a veces) esfuerzos sobrehumanos para hacerlo bien.

Peter K.
fuente