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

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)

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

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.

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

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.

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.

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

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.

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

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.

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

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.

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.