En un borrador reciente de "The Scrum Papers" documento el uso del sistema de seguimiento de errores GNATS en mi empresa PatientKeeper para gestionar una implementación compleja de Scrum. En mi curso Scrum Tuning utilizo un número de complejidad que es igual a (número de equipos) x (número de versiones por año) x (número de productos) x (número de kits o ramas de versiones separadas para soportar plataformas de proveedores). PatientKeeper tiene un número de complejidad de 3240 que es mayor que cualquier otra empresa Scrum que he visto a excepción de un proyecto de British Telecom de más de 1000 personas.
El apoyo a este nivel de complejidad en PatientKeeper requiere un "All-At-Once-Scrum" utilizando un sistema totalmente automatizado. Estoy desaprobando el término Tipo C Scrum utilizado en mi documento Agile 2005 como Scrum Trainers siento que confunde a la gente. Sólo hay un Scrum y algunos incluso afirmarían que un Scrum que multihilo Sprints a través de múltiples equipos no es realmente Scrum en absoluto. Permítanme señalar que Mary y Tom Poppendieck han documentado el All-At-Once-Scrum en su reciente libro sobre la implementación del desarrollo lean de software como una de las implementaciones Agile de mayor rendimiento en el planeta, Ken Schwaber ha comentado que es un "monstruo competitivo", y al menos cinco empresas han discutido conmigo su implementación de este patito feo. Una de ellas incluso publicó un artículo sobre su implantación en la Conferencia Internacional de Hawai sobre Sistemas de Software en enero de 2007. Esta implantación Scrum requiere la participación total y absoluta de la alta dirección y un MetaScrum dirigido por un Jefe Product Owner que dirija la estrategia de producto de la empresa, por no hablar del despliegue en directo al final de cada Sprint. Pero estoy divagando...
Muy pocas empresas que utilizan Scrum son empresas de plataforma. Estas empresas tienden a utilizar equipos de arquitectura por capas, ya que las API de varias capas de software son productos utilizados por docenas de socios tecnológicos y, por lo tanto, son características que deben ser soportadas incluso con más cuidado que una característica típica orientada al usuario en una aplicación web. Las empresas con las que he trabajado son Google, Palm y PatientKeeper. Amazon está utilizando Scrum para abordar características de plataforma similares. Para soportar adecuadamente la complejidad de estas implementaciones se necesitan herramientas avanzadas. Una de las ventajas de las herramientas necesarias es que admiten equipos escalables, distribuidos y subcontratados como efecto secundario trivial, aunque importante.
Las herramientas implantadas en PatientKeeper tenían un requisito clave establecido por el equipo de desarrollo en los primeros días de la empresa. Un desarrollador tenía que tardar menos de 60 segundos al día en utilizarla y el ScrumMaster tenía que tardar menos de 10 minutos al día en proporcionar a la empresa un informe de burndown actualizado y cualquier otro informe que un directivo pudiera solicitar bajo demanda.
La solución fue añadir cinco elementos de datos a un sistema de seguimiento de errores de código abierto, junto con pequeñas mejoras en la interfaz de usuario y la capacidad de hacer volcados nocturnos de datos para su importación en hojas de cálculo Excel. Aunque he recomendado regularmente la actualización del sistema GNATS PatientKeeper a una solución de código abierto más reciente, se ha convertido en una misión tan crítica para PatientKeeper como un sistema de contabilidad en línea a un banco. Si se cae la empresa se cae. Por lo tanto, el equipo de desarrollo se ha negado a pensar siquiera en actualizarlo.
Algunas de las muchas características que me gustaría tener en un nuevo sistema son una mejor interfaz de usuario y una conexión automática a un sistema de control de versiones. Trac era de interés porque es un sistema de seguimiento de errores basado en wiki que puede ser ampliado para soportar un "All-At-Once-Scrum" y tiene un enlace directo a Subversion. Dado que el sistema de gestión de configuración de código Subversion es una actualización fácil de CVS, recomiendo que a PatientKeeper también. Sin embargo, la naturaleza de nuestra compleja gestión de las ramas de código para apoyar un All-At-Once-Scrum es aún más misión crítica que el sistema de información en tiempo real Scrum. "Ay", dice la ingeniería, "¡ni se te ocurra!".
Confío en que llegará el día en que PatientKeeper decida actualizar. Tendrán que hacerlo como los grandes bancos que solía trabajar con la ejecución de sistemas en línea dual en paralelo durante varias semanas para asegurarse de que todo funciona a la perfección antes de cortar más. Para aquellos de ustedes que aún no han ido completamente sin papel, sin tarjeta, y sin no hay más opciones.
Nota: En 2008 PatientKeeper se actualizó a Jira y Subversion.
Las primeras versiones de Trac no soportaban fácilmente Scrum. Sin embargo, la última versión de Trac tiene más flexibilidad y una empresa londinense ha desarrollado un plugin Scrum de código abierto, el primero de varios requisitos para la herramienta que necesito.
Consulte el blog de Daan para conocer las últimas actualizaciones del plugin Trac Scrum.
Spanish 
English 
French