process - methodologies - agile methodology wiki

Ágil en pequeños bocados: la mayor parte del dinero (12)

¿Qué aspecto único del desarrollo ágil deberíamos implementar primero para mejorar nuestro proceso de desarrollo, y por qué?

Estoy en una situación que me requiere "ajustar" mi proceso, en lugar de volver a diseñarlo, y "ágil" parece ser el mantra del día. Si podemos hacer un solo cambio que mejore algo: calidad, tiempo de comercialización, documentación, transparencia, etc. , ¿cuál será el impacto más visible y positivo?

Si elegimos correctamente, podremos hacer una segunda elección. :-)

Actualización: ¿Cuál es su SDLC actual?
Medio ambiente: esencialmente "reinicio". Un pequeño puñado de desarrolladores; productos heredados con 10 ^ 5-10 ^ 6 LOC y decenas de miles desplegados en todo el mundo; los productos son fuertemente interdependientes; características significativas añadidas a lo largo de los años, incluidas muchas operaciones únicas, sin refactorización; Horarios apretados; QA superficial; no hay autopsias o "gurú del proceso".

Proceso típico:

Crear diseño / espec. Revisión por todos los interesados.
Codifique una o más características / correcciones.
Revise el diseño / especificación para dar cuenta de las sorpresas.
Características de prueba, defectos de registro.
Prioriza las tareas nuevas y restantes.
Revise el diseño / especificación / cronograma.
Regrese al paso 2 según sea necesario.
Lanzamiento para beta, registro de comentarios.
Regrese al paso 2 según sea necesario.
Lanzamiento oficial.

¡Gracias por tantas sugerencias útiles y puntos de vista!

Agile es ahora la palabra de moda, pero tenga en cuenta que NO es una bala de plata ; no arreglará tu proceso de desarrollo así como así. Es posible que desee leer el excelente artículo de Steve Yegge sobre el desarrollo ágil para equilibrar la exageración.

La "selección de cerezas" en algunos aspectos del desarrollo ágil puede ser difícil si no captas el núcleo de Agile. Agile es más que nada una forma de pensar : ser flexible, aceptar que las cosas cambiarán, escribir el código en iteraciones cortas enfocadas en obtener una o pocas características completas . Lo opuesto a obtener una especificación única, completa y monolítica, escribir todo el código, la documentación y luego enviarlo.

Si quiere demostrar que Agile Development funciona, probablemente votaría por usar el sprint para mostrar lo que significa "liberar temprano, liberar a menudo".

Comience con la prueba unitaria si todavía no lo hace. Si está realizando pruebas unitarias, cambie al desarrollo impulsado por pruebas. Estos son fáciles de agregar a los procesos existentes y pagarán dividendos inmediatos. Cuando esté listo para enfrentar los cambios en el proceso, incluya el desarrollo iterativo. Si su proceso actual ya es iterativo, comience a realizar entregas frecuentes de sus iteraciones a los clientes para obtener comentarios.

Si tuviera que resumir la forma "ágil", diría que entreguen valor empresarial de alta calidad desde el principio y con frecuencia. Las prácticas anteriores te ayudarán a recorrer un largo camino a lo largo de ese camino.

[EDITAR] Creo que lo que sugiero es adoptar un enfoque ágil para adoptar métodos ágiles y comenzar con cosas fáciles que brinden mucho valor de inmediato.

Cree un equipo interfuncional con programadores, probadores, redactores técnicos y posiblemente personas de ventas / servicios todos juntos. Haga que se den cuenta de que el concepto de "hecho", es decir, algo por terminar, es algo que está escrito, probado, documentado, instalado, implementado y listo para ser utilizado por el cliente.

Es importante porque a menos que todos los miembros de varias áreas funcionales se reúnan y se centren en el objetivo único de obtener algo para el cliente, no puede implementar ningún otro aspecto del marco Ágil.

Creo que los dos aspectos más valiosos y fáciles de implementar de Agile son

stand-ups diarios: realice una breve reunión diaria con el equipo para revisar el estado. Usa las 3 preguntas. Evite la diafonía, la charla y la perra. Mantenlo rápido y en el punto.
Iteraciones en cajas de tiempo: dividir el proyecto en ciclos de dos o tres semanas te obliga a trabajar para lograr objetivos manejables en plazos razonables

Pruebas automatizadas que se ejecutan en una compilación automatizada.

Totalmente depende de su proceso existente, pero le diré que una de las mejores movidas que hicimos fue obtener el concepto de la acumulación de elementos y una pregunta diaria de 3 (¿en qué trabajó desde la última vez que nos vimos? para trabajar en el día de hoy? ¿Cuáles son los obstáculos que le impiden avanzar?) reunirse por la mañana para ver dónde estamos y qué podemos hacer para avanzar hacia nuestro punto final de ciclo de iteración corta.

Es bueno poder ver el trabajo pendiente acumulado del trabajo por hacer y en lo que se está trabajando ahora y lo que lo convertirá en la próxima iteración. Es bueno poder tener una idea de dónde están los desarrolladores individuales y ayudarlos a eliminar cualquier impedimento para seguir adelante. Evita que los desarrolladores se vuelvan oscuros .

De todos modos, ese es mi pensamiento. Funcionó para nosotros

Yo trataría de ir con el desarrollo impulsado por prueba. Esto te dará muchas cosas:

Obtendrá una muy buena cobertura de prueba de unidad (no estoy diciendo que la cobertura de prueba de unidad sea importante).
Los desarrolladores tendrán más confianza de que el código realmente funciona (consulte * más adelante para obtener más información)
Podrá refactorizar el código más fácilmente (porque tiene las pruebas).

[*] - Kent Beck en esta área menciona diagramas de Influencia. En los diagramas de influencia, una flecha entre nodos significa que un aumento en el primer nodo implica un aumento en el segundo nodo. Una flecha con un círculo significa que un aumento en el primer nodo implica una disminución en el segundo nodo.

-----> [Stress] <--o-- / --o--> [RunTests]

Mientras más estrés sientas, menos pruebas harás. Mientras menos pruebas hagas, más errores cometerás. Cuantos más errores hagas, más estrés sentirás. Repetir...

¿Cómo resolver este círculo que lleva a los desarrolladores estresados a no confiar en su propio código después de un tiempo?

El primer desarrollo de prueba cambia el diagrama de influencia:

[TestFirst] <--o-- / --o--> [Stress]

Cuanto más pruebas el primer desarrollo, menos estrés sientes. Cuanto menos estrés sientas, más pruebas desarrollarás primero.

Esto lleva a un mejor código de prueba desarrollado por desarrolladores que confían en su código.

Edificio iterativo

Cuando pasamos a tener construcciones de manera constante (en nuestro caso, semanalmente o dos veces por semana) vimos la mayor mejora.

Cuando se producía cada construcción, nos reuníamos con el equipo de desarrollo, el equipo de control de calidad y el equipo de gestión del producto y creábamos una lista del trabajo que se incluía en la nueva construcción.

Luego, todos ayudaron a responder la pregunta de qué debería incluirse en la próxima compilación.

Desde entonces, hemos agregado muchas otras características del desarrollo Ágil (incluido el intento de implementar un scrum al pie de la letra), pero nada nos ha dado tanto "por el dinero" como la construcción iterativa.

Desarrollo iterativo. Trabaje en pequeñas iteraciones (digamos 2 semanas), tenga la aplicación ''lista'' para el final de cada iteración, es decir, sus probadores deberían estar felices de entregar los resultados a sus clientes.

Este es el núcleo. Puedes construir sobre esto.

Soy un gran admirador de mix-and-match, y un cambio incremental del proceso de desarrollo. Estoy de acuerdo en que el desarrollo iterativo debe ser su primer objetivo, pero creo que puede abordarlo en pasos aún más pequeños.

Según mi experiencia, recomendaría el siguiente orden: elija el primero que no haga:

Corrige errores primero. Desearía no tener que decir eso. Este es el llamado de cordura, y también se requiere tener ciclos más cortos.
Pasos pequeños. Entrenar el hábito de implementar el cambio más pequeño que sea un paso visible hacia la siguiente característica, luego compilar y probar. Divide todas tus tareas en <1h unidades antes de comenzar a codificar. Apunte a un código funcional, construible al menos cada 15 minutos. Esto no requiere mucho cambio de infraestructura, excepto tal vez arreglar la construcción incremental y tener máquinas rápidas.

¡Sí! Comience asegurándose de que los desarrolladores tengan máquinas rápidas. ¿Cuánto mejor consejo podría obtener?

Construye todo a diario Configure un doble clic con compilaciones completas desde el control de origen hasta el medio de instalación, idealmente en una PC separada. Este es el primer paso para las construcciones frecuentes, pero ya ayudan bastante por sí solos. Para nosotros, fue un paso crucial para obtener resultados de construcción confiables y reproducibles.
Comience a escribir Pruebas unitarias. No se preocupe por la cobertura todavía, no haga cumplir "escribir pruebas primero", pero ponga el marco en su lugar. Escribir pruebas para nuevos códigos y cambios. Luego ejecútelos con sus compilaciones diarias.
Ciclos cortos. Ahora es el momento, tienes todas las herramientas para hacer lanzamientos semanales o semanales en dos versiones: la base de código está en un estado de entrega muchas veces al día, haciendo que la compilación esté a doble clic y, al menos, algo esté funcionando .

Además de todos los buenos consejos que ya proporcioné y con los que estoy de acuerdo, sugiero fortalecer el control de calidad con pruebas automáticas y repetibles. Invertir en automatización le permitirá tener más confianza al cambiar el código ya implementado.

Cree suites de regresión para las nuevas características al mismo tiempo que las implementa.

QA puede usar pruebas exploratorias como alternativa para encontrar agujeros en su proceso de desarrollo.

Consulte el "Manual de procedimientos prácticos" concreto sobre GESTIÓN del desarrollo impulsado por prueba y / o ágil. .

Mi recomendación es comenzar con TDD primero. Es muy fácil de hacer y tiene un profundo impacto en la calidad.

Hay varias partes de esto.

Todos deben obtener las herramientas (JUnit o lo que sea, esto puede ser difícil en algunas culturas).
Los gerentes deben exigir que se realicen las pruebas. Nunca deben (NUNCA) eludir las pruebas unitarias. Tan pronto como alguien dice "esas pruebas no importan, envíelas de todos modos" ha deshecho todo lo bueno de TDD.
Tienes que administrar por caso de prueba: cuántos escritos, cuántos pasaron. Debe definir la funcionalidad a través de casos de prueba: la característica [X] tiene [n] casos de prueba, algunos de los cuales están terminados, algunos están en proceso.