23 votos

Lista de prácticas óptimas ágiles

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 vista del ingeniero), y que definiera cómo los ingenieros de SW deberían enfocar el desarrollo. La lista debería estar relacionada con la gestión lo menos posible.

Si importa, estamos programando en c++.

Es bastante fácil encontrar muchas buenas prácticas, y esta es la lista que he logrado formar hasta ahora:

  1. Refactorización
  2. Pequeños ciclos de liberación
  3. Norma de codificación
  4. Propiedad colectiva
  5. Metáfora del sistema
  6. Juego de planificación
  7. Todo el equipo
  8. Reuniones diarias de Scrum
  9. Programación de pares
  10. Diseño impulsado por pruebas
  11. Desarrollo impulsado por el comportamiento
  12. Integración continua
  13. Revisiones del código y del diseño
  14. Interesados activos
  15. Documento tardío
  16. Uso extensivo de patrones de diseño

Ya estamos utilizando algunas de las prácticas de la lista. Algunas no las vamos a usar.

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

PS Puedo añadir una pequeña descripción de las prácticas, si se solicita.

EDITAR

Como dije, ya estamos usando algunas prácticas ágiles (sobre todo las que resultan ser las mejores):

  1. La integración continua - esta es una muy buena práctica. Obtener la retroalimentación rápida de los últimos check-ins es muy útil. Tener un tiempo de inactividad porque alguien rompió una construcción puede ser muy frustrante, especialmente si dura más tiempo.
  2. Metáfora del sistema - ayuda poco, porque tener nombres descriptivos de clases y funciones ayuda a entender mejor el código
  3. Estándar de codificación - creamos el estándar de codificación antes de entrar en la codificación. Usar un estilo de código uniforme es bueno, porque cualquiera puede tomar el código de otro y trabajar en él como si fuera propio.
  4. TDD - antes de empezar a codificar, establecimos el entorno para crear fácilmente pruebas unitarias, pero sólo hasta hace poco empezamos a adoptar los principios de TDD. Yo personalmente lo intenté hace varios años, y no salió muy bien, pero ahora me encanta. Desafortunadamente, no todos los miembros del equipo lo están haciendo, sólo la mitad del equipo.
  5. Reuniones diarias de Scrum. Intentamos reuniones diarias y no salieron muy bien. Al igual que en mi trabajo anterior, las reuniones diarias se convierten en discusiones de más de 30 minutos. Supongo que nos perdimos al buen maestro de scrum (o líder, ¿cómo se llama?)
  6. Refactorización - hicimos la refactorización, pero sólo si alguien del equipo crea una solicitud de cambio. No lo hicimos como a propósito: "Sentémonos ahora, y reduzcamos nuestra profundidad técnica".
  7. Pequeños ciclos de liberación - ahora mismo tenemos enormes ciclos de liberación (6 meses), y para la próxima liberación estamos planeando romper el ciclo en 4-6 liberaciones internas.
  8. Revisiones de código y diseño - hicimos la revisión inicial de diseño (como hace 5 años), y pocas revisiones de diseño de algunos subcomponentes menores durante este período. Hicimos revisiones de código de algunas clases
  9. Documento tardío lo hicimos para este lanzamiento. Sólo la documentación requerida significa escribir la documentación menos y más divertida codificación. A los desarrolladores les encanta :)
  10. Uso de patrones de diseño - ya estamos usando patrones de diseño cuando es apropiado.

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

18voto

Justin Niessner Puntos 144953

Primero, ve a leer el Doce principios de software ágil .

En segundo lugar, averigua a partir de lo que sabes cómo lograr los principios que son más importantes para ti.

La gente comete constantemente el error de esperar que el desarrollo ágil sea una bala de plata o un conjunto riguroso de procesos a los que hay que adherirse y que harán que su desarrollo de software sea exitoso.

No es lo que se supone que debe ser. El hecho de que ya tengas una lista de 15 "Mejores Prácticas" me asusta un poco. No te lo tomes demasiado en serio y no lo pienses demasiado. Si encuentras que te has perdido algo... lo coges en la siguiente iteración.

12voto

BЈовић Puntos 28674

Este texto resume todas las mejores prácticas ágiles (con enlaces) :
Requisitos
- Visión del producto / Declaración de la visión
- Retraso de productos
- Historias de usuarios
- Casos de uso
- Escenarios de uso
- Personas
- Planeando el póker
Priorización de los requisitos
Diseño
- Picos arquitectónicos / Soluciones de picos
- Diseño impulsado por el dominio
- Diseño emergente / Diseño evolutivo
- Tarjetas de la CRC
- Diseño por contrato
- Metáfora del sistema
Construcción
- Estilo de codificación / Directrices de codificación / Estándar de codificación
- Desarrollo impulsado por pruebas
- Desarrollo impulsado por el comportamiento
- Programación de pares / Emparejamiento
- Refactorización
- Propiedad colectiva del código
- Construcciones diarias / Construcciones automatizadas / Construcciones de diez minutos
- Integración continua
- Revisiones de códigos / Revisiones de pares
- Métrica de software / Métrica de código y análisis
- Control de la fuente / Control de la versión
- Rastreo de problemas / Rastreo de bichos
- Gestión de la configuración
- Entrega frecuente / Liberaciones frecuentes
Prueba - Prueba de la unidad
- Prueba de humo / Prueba de verificación de construcción
- Pruebas de integración
- Pruebas del sistema
- Pruebas exploratorias
- Automatización de pruebas
- Pruebas de Cuento / Criterios de Aceptación / Pruebas de Aceptación
Proceso
- Timeboxing / Sprints fijos / Longitud de Iteración fija
- Planificación de la liberación
- Planeación de Iteración / Juego de Planeación / Planeación de Sprint
- Atraso en el Sprint
- Junta de tareas
- Definición de Hecho / Hecho Hecho
- Reunión de pie diaria / Scrum diario
- Velocidad
- Revisión de Sprint / Demostración de Iteración
- Mapeo de la corriente de valor
- Análisis de la causa root / 5 porqués
- Quemar los gráficos / Quemar los gráficos
- Grandes gráficos visibles / Radiadores de información
- Retrospectiva / Taller de reflexión
Organización
- Equipo pequeño
- Equipo multifuncional
- Equipo de auto-organización / Equipo de Scrum
- Equipo Colocado / Sentados juntos / Espacio de trabajo común
- Cliente in situ / Propietario del producto
- Scrum Master
- Ritmo sostenible
- Mover a la gente
- Scrum de Scrums

12voto

Greg Gauthier Puntos 478

Estoy en medio de la lectura de "Succeeding with Agile" ahora mismo. En el capítulo 2, Mike Cohn ofrece una terrible advertencia contra el establecimiento de "mejores prácticas" de cualquier tipo:

"Cuando se hace la transición a Scrum... recoger 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 el Scrum... Aunque los miembros del equipo siempre deben buscar compartir entre sí sus recién descubiertas buenas formas de trabajo, deben resistir el impulso de codificarlas en un conjunto de mejores prácticas..."

Continúa citando a Taiichi Ohno, de Toyota:

"...hay algo llamado trabajo estándar, pero los estándares deben ser cambiados constantemente. En cambio, si piensas que el estándar es lo mejor que puedes hacer, se acabó... ...si establecemos algo como] la mejor manera posible, la motivación para kaizen [mejora incremental continua] desaparecerá."

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

4voto

sjt Puntos 1419

Un par de cosas que son realmente importantes y que podrías añadir son:

  1. Equipos Autogestionados - refiriéndose a "Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados"

  2. Retrospectivas - refiriéndose a "A intervalos regulares, el equipo reflexiona sobre cómo para ser más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia"

  3. Soluciones de diseño simple que minimizan el trabajo realizado

4voto

Don Roby Puntos 24965

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

¿Cuál es el peor problema de su proceso actual? ¿Qué puede cambiar para resolver ese problema? Inténtelo y vea cómo funciona.

Enjuague y repita.

Y hacer todo esto como un equipo.

EDITAR:

Algunas cosas son difíciles de poner sensatamente en los comentarios, así que ampliaré algunos de los comentarios aquí:

Creo que el problema es que algunas personas se niegan a escribir pruebas de unidad, pero en mi opinión, las pruebas de unidad están proporcionando una mayor red de seguridad. No estoy seguro de qué se puede hacer al respecto.

La cobertura deficiente de las pruebas es en realidad una solución declarada negativamente y no un problema real.

Si la cobertura de las pruebas es mala, es probable que esté entregando software con errores o en el que es difícil y lleva mucho tiempo hacer cambios sin introducir errores. Estos son problemas.

Si la gente se niega a escribir pruebas, o bien no creen que haya un problema, o no creen que escribir pruebas de unidad lo solucionará, o no les importa.

Lo mejor que puedes hacer es reunirte con tu equipo y decidir cuáles son los problemas y acordar 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 así, deberías tratar de abordarlo como un equipo completo, pero es difícil y puede que necesites algo de ayuda en la gestión.

Como ya he mencionado, ya estamos utilizando con éxito algunas prácticas ágiles, pero tal vez hay nuevas y mejores formas de hacer las cosas. Lo que intento hacer es reevaluar cómo estamos haciendo las cosas.

Bien. Eso es básicamente lo que sugiero que hagan, pero háganlo en equipo y concéntrense en resolver los problemas identificados en lugar de intentar hacer una gran lista de las mejores prácticas.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X