agile - ventajas - son metodologías ágiles de procesos

Lista de mejores prácticas ágiles (9)

"Agile" o "Agile Software Development" no es un método único. Es un término general que abarca solo una colección de "valores" que puede optar por mantener. Dos métodos diferentes pueden ser "ágiles" y, sin embargo, entrar en conflicto entre sí cuando se trata de prácticas que debe o no debe hacer.

No existe una definición clara de "ágil", por lo que no es posible hacer una lista definitiva de "prácticas ágiles".

Hay una lista definitiva de las Prácticas de programación extremas básicas (es decir, las cosas que debe hacer para cumplir con la definición básica de "hacer XP").

También hay una cantidad mínima de cosas que debes hacer para hacer Scrum (aunque no es tan útil porque no dice absolutamente nada sobre prácticas de ingeniería específicas ).

Estoy tratando de definir qué prácticas ágiles vamos a utilizar y tengo dificultades para definir la lista de las mejores prácticas ágiles. Me gustaría que mi lista fuera más desde un punto de vista técnico (el ángulo de visión del ingeniero), y debería definir cómo los ingenieros de SW deberían abordar el desarrollo. La lista debe estar relacionada con la gestión lo menos posible.

Si importa, estamos programando en c ++.

Es bastante fácil encontrar muchas mejores prácticas, y esta es la lista que logré formar hasta ahora:

Refactorización
Pequeños ciclos de liberación.
Codificacion estandar
Propiedad colectiva
Metáfora del sistema
Juego de cepillado
Todo el equipo
Reuniones diarias de scrum
Programación de pares
Test Driven Design
Desarrollo impulsado por el comportamiento.
Integración continua
Revisiones de código y diseño.
Partes interesadas activas
Documento tarde
Uso extensivo de patrones de diseño.

Ya estamos usando algunas de las prácticas de la lista. Algunos no los vamos a usar.

¿Hay buenas prácticas ágiles que podría agregar a la lista?

PS Puedo agregar una pequeña descripción de las prácticas, si así lo solicita.

EDITAR

Como dije, ya estamos usando algunas prácticas ágiles (principalmente las prácticas que demuestran ser las mejores):

Integración continua - esta es una muy buena práctica. Obtener información rápida sobre los últimos registros es muy útil. Tener un tiempo de inactividad porque alguien rompió una construcción puede ser muy frustrante, especialmente si dura más tiempo.
Metáfora del sistema: ayuda poco, porque tener nombres de funciones y clases descriptivas ayuda a entender mejor el código
Código estándar: creamos el estándar de codificación antes de ingresar a la codificación. Usar el estilo de código uniforme es bueno, porque cualquiera puede tomar el código de otro y trabajar en él como si fuera suyo.
TDD: antes de comenzar la codificación, configuramos el entorno para crear fácilmente pruebas unitarias, pero solo hasta hace poco comenzamos a adoptar los principios de TDD. Personalmente lo probé hace varios años, y no me fue tan bien, pero ahora me encanta. Desafortunadamente, no todos los miembros del equipo lo están haciendo, solo medio equipo.
Reuniones diarias de scrum: probamos reuniones diarias y no fueron tan bien. Al igual que en mi trabajo anterior, las reuniones diarias generalmente se convierten en discusiones de más de 30 minutos. Supongo que nos perdimos un buen scrum master (o líder, ¿cómo se llama?)
Refactorización: hicimos refactorización, pero solo si alguien del equipo crea una solicitud de cambio. No lo hicimos a propósito: "Vamos a sentarnos ahora y reducir nuestra deuda técnica".
Pequeños ciclos de lanzamiento: ahora mismo tenemos enormes ciclos de lanzamiento (6 meses), y para el próximo lanzamiento planeamos dividir el ciclo en 4-6 lanzamientos internos.
Revisiones de código y diseño: hicimos la revisión inicial de diseño (como hace 5 años) y algunas revisiones de diseño de algunos subcomponentes menores durante este período. Hicimos revisiones de código de algunas clases.
Documento tarde - lo hicimos para este lanzamiento. Solo la documentación requerida significa escribir documentación cada vez más divertida. Los desarrolladores lo aman :)
Uso de patrones de diseño: ya estamos usando patrones de diseño donde sea apropiado.

Debido a la estructura de nuestra organización, no podemos utilizar otras prácticas, pero como puede ver, la lista es larga y no puede seleccionar todo. Además, ahora solo somos 4 desarrolladores de SW, cada uno de los cuales mantiene aproximadamente 80 kLOC y trabaja en nuevas cosas. Por lo tanto, no podemos hacer, por ejemplo, la programación de pares, o la propiedad colectiva.

Algunas otras ideas para agregar, aunque algunas pueden estar implícitas de otras prácticas que tenga:

Recuerde que cada uno puede personalizarse a su manera y este es un aspecto importante, ya que no es necesariamente una buena idea que sea demasiado religioso acerca de seguir una práctica si no es útil para su situación.

Sprint Reviews es diferente de Sprint Retrospectives, al menos en mi opinión. La Revisión es donde lo que se terminó en el sprint se muestra a otros, generalmente partes interesadas, para obtener comentarios y actualizar la cartera de productos con nuevos elementos que pueden surgir al ver el producto. La Retrospectiva es donde el equipo se reúne para discutir qué salió bien y qué se puede mejorar para el próximo sprint que es ligeramente diferente a mi mente.

Creo que tu lista es bastante completa. Podría agregar "un alcance claro y fijo para cada iteración", ya que con frecuencia he visto problemas en la práctica, aunque se podría argumentar que es solo una parte de los "pequeños ciclos de lanzamiento".

Además, enumeraría "pequeños ciclos de lanzamiento" y "refactorización" como puntos separados, son bastante independientes.

En cualquier caso, no me preocuparía demasiado por "perder" parte de ágil. Una propiedad importante de los métodos ágiles es que no son todo o nada: puede comenzar con una parte que funcione bien para usted y luego aumentarla. Algunas prácticas dependen unas de otras (p. Ej., Refactorización y propiedad colectiva del código), pero la mayoría se puede usar de forma independiente.

Estoy en el medio de leer "Triunfar con Agile" ahora mismo. En el capítulo 2, Mike Cohn ofrece una grave advertencia contra el establecimiento de "mejores prácticas" de cualquier tipo:

"Cuando la transición a Scrum ... recopilar las mejores prácticas es peligroso. Como las sirenas que nos cantan desde las rocas, las mejores prácticas nos tientan a relajarnos y detener el esfuerzo de mejora continua que es esencial para Scrum ... Aunque los miembros del equipo siempre deben mirar para compartir entre sí sus buenas formas de trabajo recién descubiertas, deben resistir la tentación de codificarlos en un conjunto de mejores prácticas ... "

Continúa citando a Taiichi Ohno, de Toyota:

"... hay algo que se llama trabajo estándar, pero los estándares deben cambiarse constantemente. En cambio, si consideras el estándar como" lo mejor que puedes hacer ", todo está terminado ... [si establecemos algo como] lo mejor posible, la motivación para kaizen [mejora continua incremental] desaparecerá ".

Atribución: Triunfar con Agile: Desarrollo de software con Scrum, Mike Cohn, 2010

Hacer una lista de las mejores prácticas parece como BDUF para una transición ágil. Si quieres ser ágil, trata de llegar de una manera ágil.

¿Cuál es el peor problema con tu proceso actual? ¿Qué puedes cambiar para abordar ese problema? Pruébalo y ve cómo funciona.

Enjuague y repita.

Y hacer todo esto en equipo.

EDITAR:

Algunas cosas son difíciles de incluir con sensatez en los comentarios, así que ampliaré algunos de los comentarios aquí:

Creo que el problema es que algunas personas se niegan a escribir pruebas unitarias, pero en mi opinión, las pruebas unitarias proporcionan una red segura más grande. No estoy seguro de qué se puede hacer al respecto.

La mala cobertura de la prueba es realmente una solución afirmada negativamente y no un problema real.

Si tiene una mala cobertura de prueba, entonces es probable que esté entregando software con errores o donde sea difícil y lento realizar cambios sin introducir errores. Estos son problemas.

Si las personas se niegan a escribir pruebas, o bien no creen que haya un problema, no creen que las pruebas unitarias de resolución lo resuelvan, o no les importa.

Lo mejor que puede hacer al respecto es reunirse con su equipo y decidir cuáles son los problemas y ponerse de acuerdo sobre las cosas para tratar de mejorar.

Si tienes miembros del equipo que no están interesados en mejorar, ese es un problema mayor. Aún debe tratar de abordarlo como un equipo completo, pero es difícil y es posible que necesite ayuda de la gerencia.

Como ya mencioné, ya estamos utilizando con éxito algunas prácticas ágiles, pero quizás haya nuevas y mejores formas de hacer las cosas. Lo que estoy tratando de hacer es volver a evaluar cómo estamos haciendo las cosas.

Bueno. Básicamente, eso es lo que sugiero que haga, pero hágalo en equipo y céntrese en resolver los problemas identificados en lugar de intentar hacer una gran lista de las mejores prácticas.

Primero, lee los doce principios del software ágil .

Segundo, averigüe a partir de lo que sabe cómo lograr los principios que son más importantes para usted.

Las personas constantemente cometen el error de esperar que el desarrollo Agile sea un Silver Bullet o un conjunto riguroso de procesos que debe cumplir para que su desarrollo de software sea exitoso.

Eso no es lo que debe ser. El hecho de que ya tenga una lista de 15 "Mejores Prácticas" me asusta un poco. No lo tomes demasiado en serio y no lo pienses demasiado. Si encuentras que te perdiste algo ... obténlo en la próxima iteración.

Un par de cosas que son realmente importantes que puedes agregar son:

Equipos autogestionados - refiriéndose a "Las mejores arquitecturas, requisitos y diseños surgen de los equipos autoorganizados"
Retrospectivas - refiriéndose a "A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta y ajusta su comportamiento en consecuencia"
Soluciones de diseño simple que minimizan el trabajo realizado.

Scrums cada período de tiempo dado (diario, semanal, etc.) y los sprints que se producen como resultado.

No es oscuro, pero vale la pena un enlace a una explicación de todos modos.

Este texto resume todas las mejores prácticas ágiles (con enlaces):
Requerimientos
- Visión del producto / Declaración de la visión
- Pila de Producto
- Historias de usuarios
- Casos de uso
- Escenarios de uso
- Personas
- Planeando Poker
Priorización de requisitos
Diseño
- Spikes arquitectónicos / Soluciones Spike
- Diseño impulsado por dominio
- Diseño emergente / Diseño evolutivo
- Tarjetas CRC
- Diseño por Contrato
- Metáfora del sistema
Construcción
- Estilo de codificación / Pautas de codificación / Norma de codificación
- Test Driven Development
- Desarrollo guiado por el comportamiento
- Programación de pares / emparejamiento
- Refactorización
- Propiedad del código colectivo
- Construcciones diarias / Construcciones automatizadas / Construcciones de diez minutos
- Integración continua
- Revisiones de código / Peer Reviews
- Software Metrics / Code Metrics & Analysis
- Control de fuente / Control de versión
- Seguimiento de problemas / Seguimiento de errores
- Gestión de la configuración
- Entrega frecuente / lanzamientos frecuentes
Pruebas - Pruebas unitarias
- Prueba de humo / Prueba de verificación de construcción
- Pruebas de integración
- Pruebas del sistema
- Prueba exploratoria
- Automatización de Pruebas
- Test de prueba / Criterios de aceptación / Pruebas de aceptación
Proceso
- Timeboxing / Sprints fijos / Longitud de iteración fija
- Planeación de lanzamiento
- Planificación de la iteración / Planificación del juego / Sprint Planning
- Sprint Backlog
- Tablero de tareas
- Definición de Hecho / Hecho Hecho
- Reunión diaria de pie / Scrum diario
- velocidad
- Sprint Review / demostración de iteración
- Mapeo de flujo de valor
- Análisis de la causa raíz / 5 por qué
- Grabar gráficos / quemar gráficos
- Grandes Gráficos Visibles / Radiadores de Información
- Retrospectiva / Taller de reflexión.
Organización
- Equipo pequeño
- Equipo multidisciplinar
- Equipo autoorganizado / Equipo Scrum
- Equipo colocado / Sentados juntos / Área de trabajo común
- Cliente en el sitio / Propietario del producto
- Scrum Master
- Marcha sostenible
- Mover a la gente alrededor
- Scrum of Scrums