Actualización en 17 Sep 2008: Tenga en cuenta que este es un post muy antiguo en los primeros días de PatientKeeper antes de que aprendiéramos cómo eliminar el "QA Sprint" o "Sprint de estabilización" antes de ir a la plena producción en un sistema hospitalario. El Sprint de estabilización implicaba plenamente a equipos interfuncionales. En 2003, un nuevo director general preguntó por qué la definición de DONE no podía ser al menos cuatro grandes hospitales del sistema en vivo sin problemas pendientes al final de cada Sprint mensual. Nos tomó dos años de trabajo para lograr esto y a partir de 1995, PatientKeeper va en vivo al final de cada Sprint sin tiempo extra para QA, regresión o pruebas de rendimiento. Además, el Sprint de esta publicación fue una emergencia que nos enseñó dolorosamente que nunca se debe hacer un Sprint de más de un mes. Este Sprint representa un modo de fracaso que nunca hemos vuelto a hacer.
La buena noticia acerca de esta publicación es que muestra cómo PatientKeeper temprano implementado el mejor sistema de seguimiento Scrum que he visto nunca. Todavía tiene ventajas significativas sobre cualquier herramienta Scrum en el mercado. Se ha migrado a Jira como el sistema de almacenamiento subyacente para todas las tareas. Los errores son simplemente otra tarea de desarrollo en este sistema.
Recientemente se ha publicado una pregunta en el lista objeto-tecnología preguntando cómo manejar los errores durante un sprint SCRUM. Hemos refinado el arte de la gestión de proyectos SCRUM en PatientKeeper durante el último par de años para manejar múltiples sprints simultáneos con miles de tareas simultáneas, integrando el seguimiento de errores con el seguimiento del proyecto de desarrollo. El requisito para el sistema de gestión de proyectos fue de menos de 60 segundos por día por desarrollador para actualizar, y menos de 10 minutos por día para el director del proyecto para hacer informes completos con tablas y gráficos.
Para cumplir este requisito, los desarrolladores no podían utilizar otro programa que el sistema de seguimiento de fallos que ya utilizaban. Sólo añadimos unos pocos datos para incluir las tareas de desarrollo junto con los fallos: clase (tarea de desarrollo o fallo), estimación inicial, tiempo invertido y porcentaje completado. Nuestro equipo ya utilizaba un sistema de seguimiento de errores de código abierto. GNATS. Mejoramos GNATS con estos datos y la posibilidad de volcarlos en una hoja de cálculo Excel automáticamente, todos los días, para el gestor de proyectos.
El Burndown Chart anterior se publicó en: Sutherland, Jeff. Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies. Cutter IT Journal 14:12:5-11, diciembre de 2001. Si desea una copia, envíame un correo electrónico.
El gráfico representa un Sprint bastante largo necesario para entregar la versión 6 del producto móvil PatientKeeper para resultados clínicos. La planificación de este proyecto comenzó en abril (mientras otra versión estaba en curso) y los elementos de desarrollo se introdujeron en GNATS, que incluía estimaciones iniciales. Las estimaciones iniciales se congelan y no pueden modificarse una vez introducidas. Esto nos permite evaluar la precisión de la estimación en una fecha posterior. Se puede ver cómo aumenta la cartera de proyectos pendientes a medida que se introducen nuevos elementos. El Sprint se inició en junio y se produjo un rápido aumento del backlog a medida que el marketing de producto añadía nuevas tareas y los desarrolladores descubrían que sus estimaciones iniciales eran demasiado cortas o que faltaban tareas. En la parte inicial de un Sprint, el reto consiste en completar el backlog y empezar a hacer volar la curva de backlog hacia la fecha de entrega. En este caso, la entrega se detuvo el 20 de agosto.
A medida que se encuentran errores, se introducen en el mismo sistema. Es posible introducir estimaciones para arreglar los fallos, pero solemos hacer un seguimiento por recuento. Los datos volcados al gestor de proyectos permiten ver los datos de múltiples maneras. También muestra la entrada y salida de errores por día, de modo que se puede ver cuántos errores se están encontrando y solucionando a medida que se avanza.Esta métrica es una de las informaciones más críticas para evaluar la estabilidad del código, así como el éxito del proyecto. En el Sprint de desarrollo que finalizó el 20 de agosto, en este gráfico la atención se centra en los días acumulados restantes para las tareas inacabadas, lo que incluye a los probadores que trabajan con los desarrolladores para eliminar errores. El 20 de agosto, pasamos a un sprint de estabilización para asegurarnos de que el sistema estaba totalmente listo para la producción y ponerlo en marcha en un gran sistema hospitalario. Los equipos pasaron entonces a centrarse totalmente en el recuento de errores restantes día a día, incluidas las entradas y salidas.
Las pruebas continúan durante el ciclo de desarrollo y las tareas no deben completarse hasta que se hayan eliminado los errores de alta prioridad. Si se encuentran errores después de que la tarea se haya registrado como finalizada, puede reabrirse o el desarrollador propietario puede corregir el error mientras trabaja en otras tareas. En cualquier caso, este esfuerzo se refleja en una curva de backlog ascendente o descendente. Al final de cada día, cada desarrollador revisa las tareas y errores en los que está trabajando en la misma interfaz de usuario GNATS, y actualiza la base de datos en menos de 60 segundos.
Este es el mejor sistema de gestión de proyectos que he visto o experimentado. El tiempo necesario para actualizar e informar de las estadísticas de gestión de proyectos se ha reducido en al menos dos órdenes de magnitud con respecto a otros enfoques que he visto. Además, la Curva de Backlog refleja miles de estimaciones individuales que se actualizan diariamente. Este microcoste del esfuerzo del proyecto produce estimaciones más precisas de la finalización del proyecto que otros enfoques. Muy recomendable.
Spanish 
English 
French