¿Cómo se ve una buena "definición de hecho" para un equipo maduro?

Al mirar ejemplos de definiciones de hecho en varias fuentes, generalmente incluyen puntos como

• código completado
• pruebas unitarias ejecutadas
• código revisado por pares o emparejado
• código registrado
• documentación actualizada
• ...

En nuestro equipo, tenemos una lista similar, pero nadie la mira porque esos puntos parecen tan evidentemente obvios que a nadie se le ocurriría omitir ninguno de estos pasos. Entonces nos preguntamos si esa es principalmente una herramienta para los equipos que hacen la transición a un proceso ágil y si no deberíamos deshacernos de él.

Por otro lado, mucha literatura afirma que todos los equipos de alto rendimiento tienen una fuerte definición de hecho. Este tipo de indicios de que podríamos perder la oportunidad de mejorar aquí.

Entonces, ¿cuáles son ejemplos de definiciones sólidas de hecho de un equipo maduro? ¿Qué tipo de puntos incluyen típicamente?

Las pautas están ahí para todos. En un equipo maduro, como mencionaste, todos lo están haciendo, por lo que no significa que no haya lugar para ello. Supongamos que se une un nuevo miembro, que no ha estado expuesto a esta metodología antes. Tener la estructura en su lugar, sería vital para él. No tendría que molestar a otros miembros, o no "olvidaría" una entrega.

En mi opinión, enumere todo, incluso lo obvio. Tal vez, tenga una "lista corta de trucos" para los que no sean obvios si ayuda a aquellos que desean una lista más corta, pero considere el caso de los nuevos miembros.

Es un proceso iterativo, cada vez que ve algo que puede mejorar, agréguelo en la definición de hecho. En horas extras, desarrollará una lista que sea relevante para su empresa. Anann ya ha mencionado algunos que valen la pena.

El hecho de que los puntos sean evidentemente obvios no significa que las personas siempre los lleven a cabo. Tomemos otros dos ejemplos: pilotos y cirujanos. Una cabina de un avión comercial o una sala de operaciones tiene varias personas, con una buena cantidad de educación y experiencia entre ellas. Sin embargo, las cosas siguen yendo mal: los pasos se realizan fuera de orden, algo se olvida, algo se hace incorrectamente. He visto varias fuentes en el sitio que un gran número (hasta el 70%) de los incidentes de aeronaves atribuidos a un error del piloto podrían haberse evitado con una lista de verificación . Según los investigadores , hasta el 29% de las demandas por negligencia en los Países Bajos podrían haberse evitado con el uso de una lista de verificación.. Aunque estas personas han sido entrenadas y, en retrospectiva, probablemente identificarían fácilmente lo que hicieron mal, sucedió algo que les hizo fallar. Todavía no lo he leído, pero se supone que el Manifiesto de la Lista de verificación es relevante. Está escrito desde una profesión médica, pero las ventajas de hacer visible una lista de verificación o un diagrama de flujo como recordatorio de qué hacer son aplicables a cualquier profesión.

Entonces, el primer paso sería crear una lista de cosas que son parte de su definición de hecho y hacerla visible. No importa cuán obvia sea esa tarea, si necesita estar completa para que la historia se considere realizada, debe estar en esa lista. La lista debe estar en algún lugar visible para el equipo. Tenga en cuenta que no tiene que ser nada elegante o formal , tal vez solo una serie de preguntas que todos deben hacerse antes de que una historia pueda llamarse hecha.

El segundo paso es decidir qué pasa en esa lista de verificación para su definición de hecho. Todo lo que necesita hacer para completar una tarea debe ser específico, inequívoco, aceptable y realista. También debe estar dentro de un contexto de tiempo para considerarlo hecho. Por ejemplo, no necesita incluir "modificar código" o "modificar diseño" en una definición de hecho; si no necesita cambiar un producto de trabajo, no hay necesidad de la historia.

Sospecharía que una buena lista de verificación para servir como base para una definición de hecho sería:

• ¿Se han actualizado todas las pruebas de unidad, integración, sistema y aceptación asociadas?
• ¿Se ha transformado el producto de trabajo en su forma liberable? Por ejemplo, código creado, documentación en formato de archivo exportable, etc.
• ¿Todos los productos de trabajo asociados han sido revisados ​​por pares? Los ejemplos de productos de trabajo incluyen código fuente (producción y prueba), comentarios, documentos de diseño, procedimientos de prueba y manuales de usuario.
• ¿Se han ejecutado y aprobado todas las pruebas asociadas (en todos los niveles de prueba)?
• ¿Se ha fusionado el código en el repositorio de integración?

Por supuesto, tendrá que encontrar una buena definición de hecho que incluya cualquier otra actividad que su equipo y su cliente consideren agregar valor. Si está en la lista de verificación, debe ser algo que debe hacerse para agregar valor a alguien (el equipo, el cliente, el usuario). Al enumerar claramente lo que haces, también puedes identificar y eliminar actividades extrañas para mejorar el proceso.

Esto realmente suena como si fueras un tipo con suerte:

En nuestro equipo, tenemos una lista similar, pero nadie la mira porque esos puntos parecen tan obvios

Su equipo ya está "maduro" ;-). ¡Pero siempre hay margen de mejora!

A su pregunta:

Entonces, ¿cuáles son ejemplos de definiciones sólidas de hecho de un equipo maduro? ¿Qué tipo de puntos incluyen típicamente?

En la parte superior de su lista, puede agregar:

Varias métricas de calidad del código: - Inestabilidad, abstracción - LOC vs DLOC (documentado) - etc.

La regla general podría ser que la métrica no debería empeorar con su confirmación. Además, podría formular un "hecho: con excelencia" si alguien realmente mejora las métricas. Aunque esto (las métricas mejoran) generalmente no forma parte de las fases de desarrollo (nuevas características) sino de las fases de refactorización.

En una de mis compañías anteriores teníamos una definición de "hecho" que decía que sus métricas deben mantenerse por debajo de ciertos umbrales, si sube, aún no ha terminado. (La complejidad ciclomática nunca debe superar los 15, a menos que tenga una muy, muy buena excusa, como cálculos complicados).

Lo mismo ocurre con las infracciones de tipo Checkstyle, especialmente si tiene un conjunto de reglas personalizado para verificar el estilo de código de su equipo. Si infringe el estándar de codificación, aún no ha terminado.

Entonces no solo podría ejecutar UnitTest, sino que también podría medir la cobertura del código. Si al menos el 50% están cubiertos, no ha terminado. Aunque esta es una especie de definición escamosa de hecho, ya que debe hacerse pruebas para los métodos básicos / principales / críticos, y no necesariamente para el 100% de su código base.

Ah, sí ... y si tiene (debería) un servidor CI con integración de sucursal automatizada ... solo habrá terminado si su confirmación en la sucursal DEV se fusionó con la sucursal LIVE actual y tampoco causa errores. (Pruebas unitarias, etc.)

hmmm ... eso es todo lo que recuerdo bien de compañías / proyectos anteriores, que no se ha mencionado en su lista.

Espero que te haya dado algunas ideas ;-)

Salud,

anann

En un entorno TDD / BDD, la definición de "hecho" (técnicamente "Código completo", ya que la definición de Matt "realmente" hecho "es correcta) es bastante simple:

• Todas las pruebas automatizadas pasan (esas pruebas automáticas deben incluir otras nuevas escritas para la historia en cuestión para verificar que la funcionalidad o el comportamiento requerido exista y funcione)
• Revisión de código aprobada (al menos un desarrollador senior en el equipo se contenta con permitir que su trabajo se convierta en parte de la base de código, y que no haya "engañado" o "pirateado" su historia)
• Comprometerse con éxito (incluido el bot de compilación que pasa todas las pruebas automatizadas, las métricas de cobertura de código, las verificaciones de estilo de policía, etc.)

En este punto, puedes seguir adelante. Estos tres puntos son críticos, pero son todos los que el codificador promedio del equipo debe tener en cuenta. Escrito o no escrito, son inviolables en un entorno TDD. La documentación, cuando los codificadores son los que hacen la documentación, es un punto adicional. En mi último equipo Agile, la documentación fue manejada por los BA / QA; sabían lo que el cliente quería, habían ejecutado los UAT y, por lo tanto, estaban en mejores condiciones para documentar la nueva característica de una manera que fuera significativa para el cliente, por lo que la documentación no formaba parte de la definición de "hecho" del codificador, aunque era parte de la definición del equipo.