Anteriormente, hablé de la noción de "Requisitos ágiles"y este concepto está integrado en la Prueba Nokia. No hay una definición de Requisitos Ágiles que sea comúnmente acordada, por lo que ahora utilizo un concepto estándar que es mejor terminología para lo que se necesita. Para muchas aplicaciones, en particular aplicaciones web, una historia sólo necesita notas y pruebas de aceptación en una tarjeta o nota adhesiva. Para algunas aplicaciones, como las aplicaciones móviles para médicos, a menos que un prototipo totalmente formado sea aceptable para un grupo cuidadosamente seleccionado de médicos de prueba, los usuarios finales se negarán a utilizar la aplicación cuando se instale en el entorno hospitalario. Por eso, antes de cortar una línea de código, hay que acordar una especificación de habilitación completa, con un prototipo que funcione.Por qué no se puede innovar como Apple." PatientKeeper utilizó esta estrategia durante 2003-2008, que es una de las razones por las que fueron el conjunto de equipos Scrum más rápido de toda la empresa que he visto nunca. Yo los llamaba "El futuro de Scrum"en Agile 2005. Algunas personas dijeron que PatientKeeper se parecía más a Kanban que Scrum por lo que también fueron los equipos Kanban más rápidos jamás vistos. Siempre he ejecutado Kanban dentro de Scrum desde 1993 ya que Scrum es la visión de Takeuchi y Nonaka de los equipos lean. Sin embargo, intentamos minimizar el Kanban, como hizo Taiichi Ono y como hace Toyota hoy en día.
En 2007, visité a los abogados de patentes de PatientKeepers porque nuestro director general quería obtener una patente sobre el descubrimiento de una estrategia de información para analizar los pagos de honorarios de los médicos que aumentaría los ingresos de los hospitales en 30% durante el primer mes de uso. Le pedí a la Product Owner que trajera la documentación que tenía para que la revisaran los abogados. Había una especificación ágil de tres páginas. Este es un documento que Product Owners en PatientKeeper utilizar para describir el concepto global de una característica. Las historias de usuario se desarrollan a partir de este documento.
Nuestro objetivo era trabajar con los abogados para entender cuánta documentación se necesitaba para una solicitud de patente. Los abogados señalaron que una solicitud de patente es una "especificación habilitante". Se trata de un término jurídico que describe un documento que permite a la persona media con conocimientos en la materia crear la característica sin tener ninguna discusión con los creadores de la especificación habilitadora.
Los abogados determinaron que nuestra especificación ágil de tres páginas no era una especificación habilitante. Para elaborar un documento que fuera aprobado por la oficina de patentes estadounidense necesitaríamos cinco páginas.
Resulta que una especificación habilitadora es exactamente lo que se necesita para maximizar la eficiencia del proceso de ejecución de una historia de usuario. La eficiencia media del proceso de los equipos que ejecutan historias de usuario es de aproximadamente 20%. Esto significa que una historia que requiere un día ideal de trabajo tarda cinco días naturales en entregarse. Systematic Software Engineering, una empresa del nivel de madurez 5 de CMMI, dispone de numerosos datos que muestra que los equipos que impulsan la eficiencia del proceso de historias a más de 50% duplicarán su velocidad sistemáticamente para cada equipo. (PatientKeeper funcionaba a una velocidad 10 veces superior a la de nuestro socio de cascada en la India).
La definición de "especificación habilitante" forma parte de la ley de patentes de EE.UU., que ha sido ampliamente juzgada por los tribunales, por lo que no sólo es un concepto comúnmente aceptado, sino que usted puede llevar sus requisitos a los tribunales y el juez le dirá si son o no especificaciones habilitantes.
En general, los requisitos NO son especificaciones habilitadoras. En un proyecto reciente de una gran empresa global descubrimos que cientos de páginas de requisitos no eran especificaciones habilitadoras. De media, 60% de lo que había en los documentos era inútil para los desarrolladores. Esto hizo que los presupuestos se duplicaran. Peor aún, 10% de lo que necesitaban los desarrolladores para implantar el software no figuraba en los requisitos.
Las especificaciones de habilitación utilizadas en PatientKeeper proporcionaron una descripción global de un conjunto de características enmarcadas como historias de usuario ligeras con capturas de pantalla, lógica empresarial y estructuras de datos. La especificación de habilitación se utilizó para generar historias de usuario que luego formaron el backlog del producto. El equipo de Product Owner actualizaba periódicamente la descripción global de las características, que era una referencia del estado del sistema y permitía a los desarrolladores ver de dónde procedían las historias de usuario del backlog del producto.
Una historia de usuario tiene que ser una miniespecificación habilitadora para que los equipos ágiles funcionen al máximo rendimiento. Si no lo es, será necesario mantener un diálogo continuo con el Product Owner durante el sprint para averiguar qué significa la historia. Esto reducirá la eficiencia del proceso de la historia y paralizará la velocidad.
Una historia de usuario contiene una plantilla, notas, pruebas de aceptación e implica una conversación con el Product Owner. Por lo tanto, la conversación puede formar parte de la mini-especificación de aceptación si la conversación está clara antes del comienzo de un sprint. Esto puede ser en una tarjeta para una aplicación sencilla y será del orden de no más de 3-5 páginas, incluso para una complicada aplicación de misión crítica y que amenaza la vida como la Plataforma PatientKeeper.
Como señalaron los abogados, una especificación de habilitación para una característica importante no debe tener más de cinco páginas. Así que toda la documentación necesaria, incluida la transcripción de todas las conversaciones, debería ser del orden de 3-5 páginas para una característica moderadamente grande. Esto es lo que entiendo por "Especificación ágil". Ahora creo que "Especificación habilitadora" es mejor terminología.
2-231 Obtención de derechos de patente § 2.07[6]
"Una especificación de patente es habilitante si permite a una persona con conocimientos ordinarios en la materia poner en práctica la invención sin experimentación indebida".
Ver Jay Dratler. Derecho de la Propiedad Intelectual: Propiedad Comercial, Creativa e Industrial, Volumen 1 para las citas.
Spanish 
English 
French