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

Creo (y es posible que 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 hacerlo mal. Es por eso que muchos lo saltan, cualquier excusa servirá: "Oh, lo hacemos ágil, así que no necesitamos hacer eso". Érase una vez, antes de ser ágil, era "oh, soy realmente inteligente y sé cómo resolver esto, por lo que no necesitamos hacerlo". Las palabras han cambiado un poco, pero la canción es esencialmente la misma.

Esto es, por supuesto, todo toro: tienes que saber lo que debes 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, dibuje una arquitectura. Esta es la parte de "obtener el panorama general correcto". No hay una solución mágica aquí, ninguna manera correcta, y ninguna metodología que lo ayude. Las arquitecturas son la SÍNTESIS de una solución, y provienen de genios inspirados en parte y conocimientos adquiridos en parte.

En cada uno de estos pasos habrá una iteración: encontrará cosas incorrectas o faltantes y las arreglará. Eso es depuración. Simplemente se hace 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 de todos para resolver cualquier problema: haga estos errores y todo lo que sigue será incorrecto. Estos pasos son como los cimientos de un edificio: haz que se equivoquen y tienes 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), tendrá tareas. Normalmente muchos de ellos.

Agrupa las tareas como quieras, asignalas como quieras. Use la metodología de la semana que desee o que le funcione. Y realice esas tareas, sabiendo a dónde se dirige y qué necesita lograr.

En el camino habrá fallas, errores, problemas encontrados con la especificación y la arquitectura. Esto apunta a cosas como: "Bueno, entonces toda esa planificación fue una pérdida de tiempo". Que también es toro. Solo significaba que tenías MENOS errores para lidiar más tarde. A medida que encuentre problemas con el tema de los primeros días de alto nivel, corríjalos.

(Y en 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: "¿Es mi implementación? roto, o se rompe la especificación? "Porque si un problema se puede solucionar de forma rápida y económica cambiando la especificación, entonces eso es lo que debe hacer. A veces esto funciona con un cliente, a veces no. Pero no lo hará. saber si no preguntas.)

Finalmente - debes probar. Puedes usar TDD o cualquier otra cosa que desees, pero esto no es garantía de que al final, hiciste lo que dijiste que harías. Ayuda, pero no garantiza. Así que tienes que 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 para la gestión de proyectos, ya sea el desarrollo de software o la creació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, la especificación y el diseño arquitectónico pasados de moda.

[¿Esperas seriamente construir un edificio de 25 pisos al colocar a 1000 trabajadores en el sitio y pedirles 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 creía.]

Todavía me sorprende que muchas personas piensen que TDD significa escribir primero las pruebas unitarias. No, significa escribir las pruebas que necesitará antes de escribir el código. En realidad, la prueba puede ser una prueba unitaria, una prueba de integración, una prueba de extremo a extremo y, por supuesto, una prueba de rendimiento (probablemente no escribirá la prueba de rendimiento antes del código probado, pero eso no significa que no deba escribirlo 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 simultáneos, la historia del usuario no se puede considerar como completada hasta que tenga una prueba de rendimiento que demuestre que se cumple con los criterios de aceptación. Una vez que tenga la prueba automática, puede verificar todos los días que está pasando a medida que agrega otras funciones.

Parece que su criterio de aceptación no se definió correctamente y, por lo tanto, 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 puede considerarse como una falla de 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 requisitos definidos).

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

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

  

[nuestro producto era] demasiado lento para usar,   Buggy, volviéndose laberínticamente complejo.   y completamente inflexible.

Eso no tiene nada que ver con Agile, 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 tratan la refactorización. Todo ese poder es genial, pero también viene con responsabilidad y es probablemente donde tu equipo falló. Aceptaron su libertad, pero descuidaron sus responsabilidades.

Al final, solo se trata de explicar la calidad del código y tratar de llegar a un acuerdo sobre la manera de aumentarlo y mantenerlo de esa manera. Las prácticas normales de programación se aplican, en realidad.

Consejo profesional: use su "Definición de Hecho" para hacer cumplir esto. Asegúrate de que todos estén de acuerdo y ponlo visible para todos. Úselo como un controlador 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.

Sí. Tus compañeros de equipo son idiotas. Su proyecto apestó debido a Agile. ¿Sentirse mejor? Está bien, sigamos adelante. : P

Creo que usted y su equipo podrán comunicarse de manera más efectiva sobre lo que salió mal si se concentran 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 con errores. No utilice los términos Agile o waterfall en absoluto. Están claramente cargados emocionalmente en su oficina.

El ágil funciona a veces. No funcionó para tu equipo esta vez. 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 suena como si alguien estuviera en desacuerdo porque hubo un fracaso, pero no vas a ganar amigos, influenciar a la gente ni a 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 su lugar, concéntrese en detectar las causas más directas de la falla y trabaje con el equipo para asegurarse de que no vuelvan a ocurrir. Esto requerirá habilidades de las personas.

Hablando de las habilidades de las personas, no debería sorprenderse de que su equipo no apreciara que se vieran mal haciendo todo su trabajo y haciéndolo mejor que ellos. Al hacer esto "bajo el radar", es posible que haya dañado algunas relaciones que ahora deberá 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 como un todo. Es posible que haya guardado la semana esta vez, pero que a la larga le haya ido mejor a su empresa al crear un mejor equipo .

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

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

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

enlace

Quiso decir que deberías esperar cambiar tus planes y, por lo tanto, no le pongas demasiado valor al plan tal como existe, pero al mismo tiempo el proceso de planificación enfocará tus energías de una manera crucial. Debe hacer planes antes de poder probarlos y refinarlos.

+1 Esta es la mejor descripción de agile empresarial que he leído recientemente.

Todos los que se llevan bien con Agile 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 obtiene de un equipo que no tiene pasión por la calidad del producto y tampoco está obsesionado con la cobertura de las pruebas por encima de todo o con el cumplimiento de sus plazos de entrega semanales, independientemente del rincón en el que hayan convencido a todos los demás, porque eso es todo lo que hace que el nivel de gestión sea semanal.

Nunca he visto esto arreglado con nada menos que una reorganización. Si usted es una empresa de nivel medio que no tiene nada especial para atraer personas realmente apasionadas, entonces 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 en las que el equipo de desarrollo se preocupa lo suficiente como para hacer un buen producto a pesar del trabajo adicional no acreditado que se requiere. De hecho, tienen que preocuparse lo suficiente como para que sea bueno en su propio tiempo, luchar por mejorar (y estar dispuestos a quemar un montón de tiempo adicional para hacer pruebas en algunos casos de TDD)

Obviamente, te importa enviar un buen producto, obviamente les importa pasar por un conjunto de movimientos programados y recibir un cheque de pago para limpiar continuamente el desorden que producen.

Buscaría un empleo menos irritante en otros lugares, sea ágil o no.

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

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

Mi conjetura es que si la situación es tan mala como dices, tu equipo realmente no está usando ágil, simplemente está siendo perezoso o indisciplinado. Agile no se trata de no planear, solo se trata de ser flexible y, bueno, ágil.

Tenemos los mismos problemas con algunos empleados.

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

Si tenemos "escribir diseño / prueba / plan, etc." en el mismo sprint de entrega que "haz 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 se haya desconectado", entonces

• En primer lugar, obtienes quejas, y unas cuantas lágrimas y tuve que hacer un montón de trabajo en los espacios en blanco y un esfuerzo extra ...
• luego obtienes un reconocimiento sorprendente cuando les preguntas "entonces, ¿cómo fue el proceso" que es mejor haber intentado la primera versión en papel?
• luego tienes los casos de prueba que los desarrolladores pueden ver, y puedes apuntar exactamente a la expectativa de "lo que significa".
• luego los clientes firman el desarrollo tiene una tasa de rechazo del 80% menos ...
• además, observas a todos los desarrolladores caminando por ahí sosteniendo los documentos de diseño y hablando entre ellos sobre los diseños ... realmente comienzan a entenderlo.
• Luego, averigua cómo dividir el plan del proyecto en partes del tamaño de un bocado y hacer un proceso a partir de él.

La parte ágil se produce cuando el cliente cambia del plan y usted puede adaptarse dentro de un ciclo de 2 semanas. NO vuele en el asiento de su pantalón ni lo invente en el camino.

En nuestro caso, el "gran diseño por adelantado" se dividió en 9 etapas (versiones de producción reales) con un promedio de 5 subestadios. Los diseñadores y desarrolladores se mantienen a la par los unos con los otros, los diseñadores están 1-3 subalternos por delante de los desarrolladores ... demasiado lejos y los descubrimientos en el desarrollo rompen demasiado el diseño, demasiado cerca y ajustes para el costo de diseño a tanto como han sido Ya implementado "en piedra" en desarrollo. Cada subestación tiene un valor de 2 a 4 sprints para 1 desarrollador.

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

El problema de nomenclatura de prueba

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

Es un mal nombre tener "desarrollo primero de la prueba" simplemente porque los desarrolladores entienden lo que significa "pruebas" en este contexto que ven las pruebas mientras escriben el código real de la prueba contra la interfaz para la implementación. Cuando realmente no es 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 usuario ANTES de comenzar a escribir el código" ... hecho correctamente, esto elimina muchos de los problemas que normalmente se descubren durante el desarrollo, mientras que todavía está en la versión mucho más barata del "papel que se puede tirar".

Uno de los elementos clave de Agile es la idea de la mejora continua y la idea de que todo el equipo es el propietario del proyecto. Entonces, el enfoque correcto habría sido revisar los problemas con el equipo y hacer que el equipo decida cómo corregirlo.

Un miembro del equipo que se retira solo, abandona todos los principios de Agile y hace las cosas a su manera puede dar como resultado que una pequeña cantidad de código funcione bien, pero en realidad no hace que todo el proyecto avance de manera positiva. / p>     

Una forma de hacer que funcionen puede ser para hacer un T-Map que cubra todo tu back-log de sprint

Cadaequipotieneunhilo,cadasprintesunperíodo.Todoseune(queesdondetuequipoparececaer).Fijeestoenalgunaparteyobtengaimanespararepresentarlospares/subequipos.Inclusopueden"correr". Pero todos saben dónde están ellos y los otros equipos. Ponga las dependencias aquí si hay alguna.

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

Tiene dos problemas: no hay suficiente forma en los requisitos y arquitectura deficiente.

Requisitos

Necesitas un objetivo final general y una hoja de ruta detallada para llegar allí.

En el mundo de las cataratas, el objetivo final es la especificación funcional, y la hoja de ruta para llegar allí 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 completan los detalles de la épica.

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

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

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 con conocimientos técnicos.

Arquitectura

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

Si su equipo hubiera tenido un documento de este tipo desde el principio, no tendría que volver a diseñar el sistema más tarde.

En realidad, un tercer problema que tiene es una mala comunicación. La comunicación es una calle de doble sentido (o multidireccional entre varias personas). Sin embargo, eso es solo un fallo humano y requiere (a veces) esfuerzos sobrehumanos para hacerlo bien.