Cuando Alistair Cockburn dice algo como:
"La 'especificación ágil' no existe. La frase es un engaño".
Este es exactamente el tipo de debate que tuvimos en la reunión del Manifiesto Ágil en 2001. Significa que hay algo realmente interesante de lo que hablar. Primero, lea por qué Alistair dice que sigue utilizando casos de uso.
En PatientKeeper tenemos "Especificaciones Ágiles" que son similares a los casos de uso de Alistair para nuevas funcionalidades. Exigimos que especifiquen claramente la experiencia del usuario con capturas de pantalla detalladas, flujo de trabajo, lógica de negocio y descripciones de datos. Queremos la especificación justa y un diálogo con los desarrolladores para determinar cuánto documentar. Para cosas sencillas, puede bastar con una historia de usuario.
Problema: Va a implementar más de mil historias de usuario a lo largo de muchos años en momentos aleatorios. Se requiere una gran precisión en las capturas de pantalla, el flujo y la lógica empresarial, ya que un error podría matar a un paciente. O un médico podría llamarlo "basura" y negarse a utilizarlo.
Fuerzas: Los usuarios médicos requieren un ajuste exacto a su flujo de trabajo, su inferencia a partir de datos clínicos, en un tiempo mínimo mientras están de pie frente a un paciente enfermo utilizando su iPhone para todos los datos clínicos. Los Developers no tienen ni idea de cómo debe ser esto para un médico. Tampoco los Product Owner, aunque sean médicos. Un grupo cuidadosamente seleccionado de líderes del pensamiento médico debe utilizar prototipos de trabajo para determinar exactamente cómo debe verse y sentirse para el médico mientras se llega a un consenso y los desarrolladores mucho exactamente crear su enfoque elegido o los médicos pueden negarse a utilizar el producto. Los médicos no utilizarán el ratón. La mayoría de las cosas deben requerir un clic y cualquier cosa que requiera más de tres clics nunca se utilizará, ya que interferirá en la conversación con el paciente. Cualquier corrupción de datos es una amenaza para la vida. La falta de facilidad de uso es una amenaza para la vida.
Por ejemplo, una pequeña parte de los datos clínicos son resultados de laboratorio. Hay docenas de pruebas de laboratorio, cada una de las cuales produce un complejo conjunto de datos con múltiples valores y rangos normales. Estos resultados interactúan entre sí. Se necesitan alertas automáticas para condiciones críticas basadas en una relación compleja entre múltiples resultados de laboratorio. Estas alertas son actualizadas periódicamente por juntas clínicas que determinan las mejores prácticas. Todas las pruebas de laboratorio se grafican de forma diferente según las especificaciones exactas que se enseñan en las facultades de medicina. A menudo se necesitan nuevas pruebas de laboratorio. Se basan en datos de investigación desarrollados en laboratorios. El desarrollador debe ser capaz de revisar rápidamente todas las implementaciones anteriores de todos los resultados de laboratorio para encajar este nuevo resultado en el flujo de trabajo del médico de la manera correcta. La implementación física del producto actual no es suficiente para este propósito.
Solución: El Product Owner crea un documento justo a tiempo llamado Pruebas de laboratorio. Crece con el tiempo a medida que hay más pruebas de laboratorio y que los datos de investigación influyen en los resultados de las pruebas de laboratorio. El Product Owner realiza análisis de alto nivel de capturas de pantalla, flujos de trabajo, estructuras de datos, lógica de negocio y lo presenta como un caso de uso muy ligero para dar soporte a historias de usuario implementadas en un momento dado. El Product Owner ha probado un prototipo totalmente funcional de esta implementación en un grupo de médicos líderes de opinión antes de que cualquier historia para estos esté lista para entrar en un Sprint. El Developers se niega a desarrollar cualquier historia que no alcance este estado "listo". De hecho, se les dice que se tomen el día libre si el Sprint Backlog no está "listo".
Resultado: A lo largo de ocho años y miles de historias, la especificación global ha crecido hasta alcanzar casi treinta páginas. Un desarrollador puede capturar en su mente en menos de cinco minutos toda la historia de la implementación de todos los resultados de laboratorio que es esencial para la implementación de un nuevo análisis de sangre para el tratamiento de pacientes diabéticos.
Los Product Owners son extremadamente disciplinados en este entorno. Saben que los desarrolladores se tomarán el día libre si su "Especificación Ágil" no está lista para la creación de historias de usuario en un Sprint.
El equipo también es muy disciplinado y alcanza una velocidad 10 veces superior a la de sus competidores en cascada, lo que hizo que los ingresos se cuadruplicaran en 2007.
Nombre para esta cosa: En juego.
Necesidad de esta cosa: Absolutamente esencial o se arriesgará a matar pacientes O peor aún, los médicos se negarán a usarlo declarando que es "una porquería" o tiene demasiadas alertas o no alerta de una condición crítica en esta prueba de laboratorio en el contexto de ciertos datos en otras múltiples pruebas de laboratorio. O no rellena automáticamente las notas clínicas correctas, o el desarrollador tiene tan poca idea de cómo tratar a los pacientes que deberían fusilarle, o .....
La mejor formación para desarrolladores: Enviarlos a una operación en la que se abre al paciente en la camilla y el cirujano empieza a gritarle a él y al personal quirúrgico haciendo gestos amenazadores para golpearles con instrumentos quirúrgicos por proporcionar datos erróneos que le llevan a tomar la decisión de abortar la operación y volver a intentarlo en otra fecha cuando le proporcionen los datos correctos y los instrumentos adecuados en el momento oportuno, cuando los resultados de laboratorio del paciente estén exactamente en la constelación correcta para que se lleve a cabo la operación.
Jeff Sutherland
Spanish 
English 
French