¿Cómo reportar el desempeño de un proyecto de desarrollo de software?

Me gusta Agile específicamente por esto: el seguimiento y los informes sobre el rendimiento son intuitivos, detallados y también se basan en los resultados reales del equipo.

Algunos antecedentes:

en ágil, se divide un proyecto en "historias", pequeñas piezas de trabajo que, si se implementan de forma independiente, tendrían sentido para un cliente. Por ejemplo, para el sitio PM.SE, podría decir "Publicar una pregunta (título y contenido)" es una historia; poder editar (por el autor original) es una historia; agregar etiquetas es una historia; etcétera.

Las historias se estiman en una unidad de tamaño vaga (puntos de historia) que son relativas . Una historia de dos puntos es aproximadamente la mitad del trabajo de una de cuatro puntos. Al tener un ejemplo icónico y estandarizado para una historia de uno o dos puntos, puede estimar fácilmente todo lo relacionado con eso.

En ágil/scrum típico, realiza un seguimiento de su "velocidad" (número de puntos de historia por día). Su "registro de productos" es la lista de todas las historias durante la vida del producto; en cualquier momento, puede decir "tenemos X puntos de historias para hacer para este proyecto, de los cuales hemos completado Y puntos". Esa es tu actuación.

Más allá de las prácticas ágiles estándar, puede hacer cosas divertidas, como:

• Presupuesto (por ejemplo, solo hacemos hasta 20-30 puntos por iteración de dos semanas)
• Estadísticas (en los últimos diez sprints, nuestra velocidad ha aumentado de 30 a 40 puntos por sprint constantemente)
• Valor ganado: personalmente me gusta mucho esta parte. Realice un seguimiento de los "puntos esperados realizados hoy" frente al valor de "puntos reales realizados hoy". Te dice si vas por delante o por detrás.
• Planificación del producto: llevas dos semanas en un proyecto de ocho semanas. Has completado 20 puntos hasta ahora (10 puntos por semana); todo el proyecto se divide en 160 puntos de la historia . No hay forma de que lo logres.

Por otro lado, algunas personas consideran que los puntos son insuficientes y requieren que los desarrolladores dividan aún más las historias en tareas y realicen un seguimiento de las tareas tarea por tarea y las calculen en horas. Lo que sea que te dé la visibilidad que necesitas.

La mejor métrica para mostrar el progreso de un proyecto de desarrollo de software es el software en funcionamiento . Supongamos que informa el estado semanal o mensualmente a sus clientes o patrocinadores/partes interesadas del proyecto. Puede informar que el 22 % de las funciones especificadas se han completado (o, más probablemente, el 13 % de las funciones están completas, otro 4 % se ha iniciado y otro 5 % tiene entre un 50 % y un 90 % de finalización). Pero, ¿qué significan realmente esos números? En realidad, esos números no significan casi nada para un cliente. Incluso para una característica que cree que está "terminada", el cliente puede haber tenido una expectativa diferente, y entonces su "terminada" es algo diferente a "terminada".

Por otro lado, si tiene una demostración de un software en funcionamiento en un día y hora establecidos, el cliente/parte interesada puede ver exactamente lo que se hace o deja de hacer, en qué medida lo que se ha hecho cumple con sus expectativas. Este es el corazón de la filosofía de desarrollo ágil de software. Pero incluso si no está "haciendo ágil", aún puede "informar el progreso" de esta manera.

Si bien no estoy en absoluto en desacuerdo con las cenizas, tengo una opinión ligeramente diferente sobre las métricas más valiosas y tiendo a informar lo siguiente:

• Tiempo de entrega : también se usa de forma predictiva como "su espera desde este punto es de aproximadamente N días". Este es el tiempo promedio en días hábiles desde la solicitud del cliente hasta la entrega de una clase específica de servicio.
• Tiempo de ciclo : Realmente lo mismo que el tiempo de entrega, pero con un punto de partida diferente para la medición. Este es el tiempo promedio en días hábiles desde que el equipo lo acepta como "listo" hasta la entrega para una clase de servicio específica. La diferencia entre el tiempo de Lead y Cycle es el tiempo que pasa sentado en un backlog siendo ignorado.
• Rendimiento : cuántos elementos de trabajo se entregan en promedio en un período de tiempo determinado para una clase de servicio determinada. Esto es esencialmente velocidad.

A muchas personas les gustan las mediciones del ciclo y del tiempo de entrega tanto como el rendimiento porque le indican explícitamente qué tan reactivo es su equipo/organización. Tiendo a evitar la velocidad de las historias porque incluye la estimación de los equipos y, por lo tanto, los equipos la engañan fácilmente, especialmente si se espera que muestren una mejora progresiva.

Para la segunda parte de su pregunta, depende completamente del contexto del equipo. No puedo imaginar ejecutar un proyecto distribuido o grande sin algún tipo de soporte de herramientas electrónicas, y personalmente he tenido un buen éxito con el seguimiento de elementos de trabajo de Rally y Team Foundation de Microsoft. Para proyectos pequeños, toma menos de 5 minutos capturarlo de una pared de tarjetas todos los días, lo que permite graficar fácilmente con Excel o en papel grande visible.

Le sugiero que realice un seguimiento de las siguientes métricas: - velocidad: cantidad de puntos de la historia que su equipo entrega durante una iteración - cantidad de defectos escapados: defectos que se escaparon de sus esfuerzos de control de calidad y que el cliente encontró después de la liberación - tiempo para corregir el defecto: tiempo promedio para arreglar un defecto

Recopilamos esas métricas utilizando http://www.programeter.com creado por nosotros mismos para realizar un seguimiento del rendimiento y la calidad de nuestros esfuerzos de desarrollo de productos.

No estoy de acuerdo con la tesis de que Agile es excepcional al depender del seguimiento y la generación de informes sobre los resultados reales del equipo.

Puedo imaginar equipos no ágiles informando sobre el progreso del trabajo real, y he visto equipos ágiles informando ficción (95% del trabajo completado y 1 de cada 5 historias completadas durante la revisión), todo es cuestión de reglas y responsabilidad personal.

Lo que realmente puede ayudar en esta área es el concepto ágil Definición de Hecho : en pocas palabras, un conjunto de condiciones que deben cumplirse para tratar el trabajo como realmente, realmente completado que se puede informar y completar de inmediato. Creo que esta es una de las cosas más importantes que deben definirse antes de comenzar cualquier medida de rendimiento. Solo entonces existe la posibilidad de que la medición sea objetiva e informativa.