Metodologías comunes para escribir comentarios "post-mortem" [cerrado]

7

Recientemente, agregamos una característica relativamente grande a nuestro producto que involucraba a todo el departamento de R & D (con todos los diferentes equipos dentro de él).

Esta característica incluía el desarrollo de IU, el desarrollo del lado del servidor y las grandes migraciones de esquemas SQL (y otras cosas en las que yo mismo no estaba involucrado).

El proceso de desarrollo de esta función fue caótico: los equipos de aplicaciones para clientes y servidores de aplicaciones frontales no se sincronizaron, las migraciones de SQL rompieron la base de datos y las especificaciones del producto fueron incompletas, lo que significó que con cada paso de la forma encontramos nuevos problemas con la definición inicial. , requiriendo cambios en los conceptos centrales en los que los desarrolladores han confiado.

En definitiva, una característica que se planeó lanzar dentro de los 10 a 14 días, tomó aproximadamente 24 días (intensivos) de desarrollo.

Se me pidió que escribiera un informe de 'Lo que salió mal' (por parte de mi equipo, cada equipo escribe un informe de este tipo desde su punto de vista).

¿Cuáles son las metodologías comunes para escribir dichos informes, específicamente en el campo del desarrollo de software?
Además, ¿existe algún nombre formal para dichos informes?

EDITAR & RESPUESTA:
Aparentemente, tal informe / proceso de revisión se conoce comúnmente como 'Proyecto Post-Mortem' (también existen otros nombres).
Después de resolver esto, encontré estos dos recursos que describen metodologías sugeridas para recopilar los datos necesarios, organizarlos, analizarlos y formular soluciones para los problemas descubiertos (así como información general sobre estas revisiones y sus propósitos):

'Un proceso definido para el proyecto Post Mortem' -
enlace

'Revisiones post mortem: Propósito y enfoques en la ingeniería de software' - enlace

    
pregunta Tudmotu 01.03.2014 - 21:08

1 respuesta

4

Habiendo hecho esto muchas veces, este es el formato que he usado con éxito en el pasado. El orden en que se presentan estos encabezados también marcará la diferencia en la forma en que la administración recibe el informe. Siempre que sea posible, déjalos con un buen sabor de boca.

Esto no debería tener que ser dicho, pero ... mantenga su idioma como profesional a lo largo del informe.

¿Qué pasó?

Describe lo que pasó, tanto lo bueno como lo malo. Dar detalles sobre cada incidente. No eches la culpa. Mantener las opiniones fuera de él. Imagínate a ti mismo como un reportero que cuenta la historia de lo ocurrido.

¿Qué salió mal?

Esta es la parte difícil. Admita lo que usted, su equipo u otros equipos hicieron mal. ¡Mantén la culpa fuera de esto! Solo establece los hechos. "Nosotros (mi equipo) hicimos cambios de última hora en la base de datos que causaron retrasos en todo el grupo de desarrollo en X días".

¿Qué salió bien?

Parte del relato de esta historia debe incluir dónde tu equipo u otros equipos hicieron lo correcto. Comunicación de retrasos, cambios, etc. "Agregamos significativamente más columnas a las tablas X, Y y Z. Estas columnas nos permitirán rastrear algo ."

¿Cómo mejoramos el proceso?

Aquí es donde comienzas a mostrar algunas opiniones. Se le preguntó qué sucedió y qué se podría hacer para solucionarlo. Indique sus opiniones apoyadas con hechos. "Cuando hicimos el cambio de ruptura de la base de datos, deberíamos haber implementado estos cambios en una base de datos de desarrollo separada".

    
respondido por el Adam Zuckerman 01.03.2014 - 23:18

Lea otras preguntas en las etiquetas