Historias de Usuario: un nuevo orden en los requisitos del software

Las Historias de Usuario no requieren almacenarse en
documentos pesados o especiales

VademeScrum, Sección 2: Las Historias de Usuario 1

Estoy escribiendo un artículo sobre Scrum sin Historias de Usuario, pero entonces noté que quizás muchos de mis lectores no sabrían que es una historia de usuario y por qué se usan en Scrum. Así es que tomé la decisión de cambiar el curso del destino y escribir primero sobre este asunto. En el desarrollo ágil, la historia de usuario es un sustituto más ligero para lo que han sido nuestros medios tradicionales de especificar requisitos de software: documentos de especificaciones de requisitos de software, especificaciones de casos de uso y similares.

Ejemplo 1: La historia de usuario “Leer un libro”

Pensemos en una historia de usuario como una manera de dejar un legado, algo que trascienda más allá del tiempo, por ejemplo, de un proyecto y que permita que las culturas sobrevivan. Para ello, las historias tienen que ser simples, cortas, fáciles de entender y de aceptar y de franca recordación sin que tengan que escribirse todos sus detalles. Ese es el gran poder de las historias de usuario. Veamos, por ejemplo, la siguiente historia de un caso no software pero que ilustra perfectamente la estructura y comportamiento de una historia de usuario:

Como: crítico literario

Quiero: leer un libro

Para: escribir una reseña sobre el libro

Estos tres elementos conforman el núcleo de toda historia de usuario. En el primero (Como) se establece quién es el usuario o grupo de usuarios que “intervienen” en la historia, típicamente es un rol de usuario, en el desarrollo de software este elemento responde a la pregunta “quién usará la funcionalidad” descrita por esta historia. El segundo elemento (Qué) es la actividad, el eje de la historia, qué hace el usuario en la historia. Y el tercer elemento (Para) es el propósito de la historia, la meta que quiere alcanzar el usuario al ejecutar la historia. Todos, en conjunto, describen una finalidad, más que un requisito.

Definición

En resumen, una Historia de Usuario es una corta declaración de intención que describe algo que el sistema necesita hacer para el usuario. Se describe desde el punto de vista de quien usará la funcionalidad, es decir, su usuario. Pero ya que definimos qué es una historia de usuario, dejemos claro también qué no es: no es una especificación detallada de requisitos de software, algo que el sistema debe hacer, es más bien, un contrato negociable de intención que indica que el sistema necesita hacer algo más o menos así.

Algunas características de las historias de usuario son:

• Son cortas y fáciles de leer, entendibles por los desarrolladores, interesados y usuarios
• Representan incrementos pequeños de funcionalidad valorada, que puede ser desarrollada en un período de días o semanas
• Son relativamente fáciles de estimar porque el esfuerzo de implementar la funcionalidad puede determinarse rápidamente
• No se llevan en documentos grandes o pesados, sino más bien en listas organizadas que pueden ordenarse más fácilmente y reordenarse a medida que se descubre nueva información
• No se detallan al principio del proyecto, sino que se elaboran sobre una base JIT – evitando así especificidad demasiado pronto, retardos en el desarrollo, inventario de requisitos y una declaración sobre-restringida de la solución.
• Necesitan poco o ningún mantenimiento y se pueden desechar con seguridad después de la implementación
• Las historias de usuario, y el código que se crea rápidamente a continuación, sirven como insumo para la documentación, la cual también es elaborada de manera incremental.

Ejemplo 2: La historia de usuario “Ingresar a la red social”

Un aspecto que viene con la simplicidad y el tamaño relativamente pequeño de las historias de usuario es que, por lo general, representan funcionalidades parciales, es decir, no indican funciones o procedimientos complejos y grandes que el sistema debe hacer. Por ejemplo, podríamos tener una historia llamada “Ingreso Básico a la Red” para especificar la entrada a una red social en Internet. El usuario es un “miembro de la red” y lo que hace más habitualmente este miembro es compartir enlaces con sus contactos. La historia luciría más o menos así:

Como: miembro de la red social

Quiero: ingresar a la red

Para: compartir un enlace

La “Narración” de las Historias de Usuario

Pero y ¿dónde están los detalles de la historia de usuario? ¿Cómo sabemos que efectivamente la historia descrita en el ejemplo anterior es simple y representa una funcionalidad parcial? ¿Cómo ingresa el usuario a la red? Estos pormenores se dan durante la Conversación y se especifican en los Criterios de Aceptación de la Historia. La Conversación representa una discusión entre el equipo, el usuario, el propietario del producto y los otros interesados, que es necesaria para determinar el comportamiento más detallado requerido para implementar la intención.

En el ejemplo citado, la conversación puede responder a preguntas como:

• ¿Qué información necesita el usuario proporcionar al sistema para ingresar?
• ¿Es obligatoria toda la información o puede ser parcial, esto es, hay datos opcionales?
• ¿Qué ocurre cuando la información está incorrecta o incompleta?

Encontrar respuestas  a estas y a otras cuestiones relacionadas delimita la funcionalidad de la historia. Por ejemplo, en una primera entrega del software o salida a producción del mismo, podemos acordar con los usuarios tener solo la funcionalidad básica de ingreso, de allí el nombre de la historia establecido en la sección anterior. O sea, solo se solicitará un nombre de usuario y una contraseña con algunas características. A continuación, el sistema validará que el par nombre de usuario + contraseña coincidan y permitirá el ingreso del usuario, nada más. En caso contrario mostrará un mensaje advirtiendo la imposibilidad de ingreso a la red.

Entre tanto, los criterios de aceptación, llamados también Confirmación, representan las condiciones de satisfacción que se aplicarán para determinar si la historia cumple o no la intención así como los requisitos más detallados. Es precisamente la Prueba de Aceptación del usuario, que muestra cómo el usuario confirmará que la historia se ha implementado a su entera satisfacción. Los flujos alternativos en la actividad, los límites de aceptación y otras clarificaciones deberían capturarse junto con la historia. Muchos de estos se pueden convertir en casos de pruebas de aceptación u otros casos de pruebas funcionales, para la historia.

En la historia “Ingreso Básico a la Red”, estos criterios de aceptación podrían incluir:

• El nombre de usuario es la dirección de correo electrónico del usuario.
• La contraseña debe contener letras y números.
• La contraseña debe ser de al menos 8 caracteres y máximo de 32.
• El usuario ya debe estar registrado en la red social.
• Si la contraseña no coincide con el nombre de usuario, el sistema mostrará el mensaje “Combinación incorrecta de correo electrónico/contraseña”.
• Entre otros.

Notamos de inmediato que en esta historia “Ingreso Básico a la Red” no se estableció nada acerca de olvido de la contraseña o del nombre de usuario, o qué ocurre luego de mostrar el mensaje sobre datos incorrectos, o de cambio de contraseña o de otras funcionalidades adicionales al ingreso como “No cerrar sesión”, restablecer la contraseña, usar el número de teléfono móvil en vez del correo electrónico para ingresar o si la cuenta se bloquea al hacer varios intentos de ingreso fallidos y qué se debe hacer para restablecer el acceso, entre muchas otras cosas que giran alrededor del ingreso a la red. Estos detalles pueden hacer parte de otras historias a construirse más adelante para la versión actual del producto o para otras versiones sucesivas del producto.

Lo que hicimos con este ejemplo fue encontrar la historia de mayor valor para el negocio, es decir, esa funcionalidad o parte de la funcionalidad que será usada la mayor parte del tiempo por los usuarios y que, por consiguiente, permite obtener el máximo valor de negocio o el retorno de inversión más rápidamente posible. Recordemos que cuando se trata de desarrollo de software, las prácticas ágiles lo son porque permiten entrega rápida de valor. Hablaremos de este asunto en otra oportunidad porque me parece vital a la hora de acoger los principios o pilares ágiles.

Ejemplo 3: La historia de usuario “Quiero publicar una entrada básica de blog”

Veamos un ejemplo completo de una historia de usuario relacionada con la creación de blogs y la publicación de entradas al blog.

Carta:

Como Bloguero (<rol de usuario>) quiero ser capaz de publicar entradas en un blog (<lo que hago con el sistema>) para aumentar mi credibilidad y posicionarme como experto en el área de mi interés (<valor del negocio que recibo>).

Conversación:

P1. ¿Cuál es su área de interés? (El equipo al Bloguero)

R1. El área de mi interés es la literatura contemporánea hispanoamericana

P2. ¿Cuál es el público esperado?

R2. El público esperado es el compuesto por jóvenes y adultos

P3. ¿Cuál es la frecuencia de publicación?

R3. El objetivo es publicar una entrada quincenal

(Sigue…)

En el caso de Scrum, esta conversación se da típicamente durante la planeación del sprint, al principio del mismo, y durante el sprint.

Confirmación (criterios de aceptación): 

El contenido de las entradas debe ser texto principalmente

El sistema debe permitir entradas de hasta tres mil palabras

Cada entrada debe llevar un título de hasta 256 caracteres

Cada entrada debe publicarse en una página separada

(Sigue…)

Este esquema estructural de la historia de usuario es lo que se conoce como la “Aliteración Carta, Conversación, Confirmación”, propuesta por Ron Jeffries, uno de los co-creadores de eXtreme Programming o XP.

¿Cuándo se usan las historias de usuario?

Dado su carácter de simplicidad y tamaño (pequeño), la poca información explícita que contienen, las historias de usuario se usan o son beneficiosas cuando hay requisitos cambiantes, lo que ocurre la mayor parte del tiempo, pero y más importante, cuando los usuarios o representantes de estos están disponibles sin protocolo para que el equipo de desarrollo resuelva todas las inquietudes que se le presenten mientras convierten la historia en funcionalidad. En Scrum, por ejemplo, ese representante de los usuarios e interesados en el producto es precisamente el Dueño del Producto.

En otros artículos proporcionaré más ejemplos, buenas prácticas para identificar y documentar historias de usuario y hablaré de los principales atributos de toda historia de usuario, agrupados bajo las siglas INVEST.

Otros artículos de esta serie:

Sobre los atributos INVEST de las historias de usuario:

Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)
http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_19.html

Vademescrum, Sección I: El Scrum Master 1

El Vademescrum

No se trata de un lapsus calami ni de ninguna charada. Simplemente usé un procedimiento morfológico para crear una nueva palabra cuyo significado se hará evidente en breve. Usando el formato de la Academia de la Lengua, podemos decir que Vademescrum proviene de Vademécum (obra de referencia que contiene las nociones más importantes de una materia, ya sea ciencia o arte) y de Scrum (marco de trabajo liviano y adaptativo para desarrollo iterativo e incremental de software). El Vademescrum es, por lo tanto, una especie de marco referencial de Scrum y de sus componentes.

Vademescrum, Sección I: El Scrum Master 1

Entrando en materia, el Scrum Master es quien inspira los valores y las prácticas de Scrum en todo el equipo Scrum y, junto con otros Scrum Masters, en la organización. Es quien debe llevar al equipo a jugar Scrum Extremo y que lo haga a su máxima capacidad. El SM es como el médico que prescribe una receta o régimen a su paciente (el equipo Scrum) y se asegura de su cumplimiento y, aunque el SM no tiene autoridad sobre el equipo, sí tiene autoridad sobre el proceso Scrum que se sigue, por ejemplo, puede tomar la decisión de cambiar la duración de los sprints.

El SM también busca en las entrañas del proyecto y del equipo para encontrar los motivos por los que algo salió mal, por ejemplo, si no se entregó software potencialmente distribuible, probado y funcionando, al final de un sprint, o si el equipo no logró la velocidad esperada, o simplemente el por qué no se alcanzó la definición de Hecho (Done), o que los miembros del equipo no estén “anclados” en roles específicos. El Scrum Master también sirve como un escudo insalvable del equipo de interferencias externas, por ejemplo, cuando un interesado quiere modificar el alcance o la duración de un sprint, o ambos.

La guía de Scrum dice además que:

“El Scrum Master es el responsable de asegurar que Scrum es entendido y llevado a cabo. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder servil, al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones, para maximizar el valor creado por el Equipo Scrum.”

Ahora bien, cuando un Scrum Master se une a un equipo, debe recordar que está allí para servir a:

1. El Dueño de Producto
2. El Equipo de Desarrollo
3. La Organización

Para ello el SM debe tener en cuenta no solo el nivel de madurez en Scrum del equipo y de la organización, sino la capacidad de los miembros del equipo para obrar bajo el manto del espíritu Scrum. Esto quiere decir que el SM debe interactuar con cada persona en el equipo tanto como sea posible y promover la interacción entre ellos ya que, como recordarán, “valoramos individuos e interacciones sobre procesos y herramientas”.

En principio, no es buena idea que el SM haga cambios profundos en la Forma de Trabajo del equipo porque esto podría disminuir considerablemente su velocidad; en cambio, el SM debe considerar acompañar y guiar al equipo hacia el éxito constante. También debe lograr que haya confianza entre todos los miembros del equipo y que ellos tengan confianza en su SM, tal y como un paciente confía en su médico de cabecera.

Otras indicaciones que debe tener en cuenta el Scrum Master son:

• Soportar activamente el proceso de adopción, adaptación y mejoramiento de prácticas ágiles en la organización.
• Entender lo bueno y las mejoras que el equipo está buscando.
• Tratar de establecer una comunicación abierta con el Dueño del Producto.
• Interactuar con otros SM e identificar los desafíos que enfrentan.
• Constantemente inspeccionar, ser transparente y adaptar, es decir, promover los pilares de Scrum.
• Entrenar al equipo, entrenarlo y luego entrenarlo más. Cuando esté cansado de entrenar al equipo, entrenarlo en algo más. Ser el mentor que todos esperan que sea.
• Promover la comunicación abierta.
• Resaltar cuando el equipo alcance hitos de adaptación y mejoramiento.
• Preguntarle al Dueño del Producto por 2 o 3 cosas que él/ella piense que no están bien, dañadas o que no están funcionando o simplemente con las que no está feliz.
• Hacer lo anterior, pero con el Equipo de Desarrollo.
• Mostrar a todos como planea corregir estos aspectos con la mayor brevedad.
• Entender la cultura y el contexto del equipo.
• Identificar oportunidades de mejora y facilitar y fomentar el mejoramiento.
• Promover la retrospectiva al final del Sprint e, incluso, durante el Sprint.
• Finalmente, pero no menos importante, hacer que el equipo tenga acceso rápido a una buena máquina de bebidas de café, esto también resuelve muchos asuntos.

Contraindicaciones

Esta es la primera entrega de este Vademescrum, volveré con más. Mientras tanto es importante tener claro que un SM hace mucho más de lo que enumeré aquí. Una persona debe preguntarse, ¿cómo me llegó la idea de convertirme en Scrum Master? Y también, ¿dónde consigo la experiencia necesaria y suficiente para hacerlo bien? ¿Dónde y cómo puedo aprender más? Asimismo debe cuestionarse quién le enseña.

Es un hecho, en estos días parece que Scrum Masters con toda esa experiencia son concebidos en cursos de 2 días y un examen de selección múltiple. Al final, caen en el olvido sin que nadie en el equipo se haga cargo. Es toda una experiencia misteriosa que se puede dominar sin antes pasar por las etapas clásicas de aprendiz –> practicante –> practicante -> experto –> entrenador -> mentor y sin que se extienda el manto ágil de Scrum sobre el equipo y la organización.

Lecturas Adicionales

Scrum Fundamental lo encuentran en este mismo Gazafatonario, en:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

La lista de verificación de Scrum la encuentran en:

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

La mitología es un conjunto de mitos relativamente cohesionados: relatos que forman parte de una determinada cultura. Los mitos son relatos basados en la tradición y en la leyenda, creados para explicar el universo, el origen del mundo, los fenómenos naturales y cualquier cosa para la que no haya una explicación simple [1]. En el bestiario mitológico de la humanidad encontramos seres fantásticos que nos hacen soñar o morir de miedo: el Dragón, el Fénix, el Grifo, el Kraken, el Cancerbero, la Hidra, el Minotauro, la Escila, el Pegaso y la Sirena, para citar algunos de los más arraigados en nuestros temores y pesadillas.

Se trata de esa necesidad inherente al ser humano de aferrarse a lo desconocido y a lo sobrehumano para entender mejor la realidad que lo rodea, o simplemente para escaparse de esta. En el caso de los métodos de software, por ejemplo, estas aprehensiones tienen su origen en la falta de conocimiento teórico-práctico sobre algo específico, en el miedo o rechazo al cambio o en la fobia a equivocarse de quienes practicamos el desarrollo de software. Lo que haré a continuación es mencionar brevemente algunos de estos arquetipos quiméricos que pululan en el universo de los métodos ágiles en general y de Scrum en particular.

Ágil no necesita documentación

¡Esta es la madre de todas las entelequias! Su origen está en ese valor expuesto en el Manifiesto Ágil que reza: “valoramos software funcionando sobre documentación extensiva” [2]. En ninguna parte del manifiesto dice que no se hace documentación, esta debe elaborarse justo cuando se necesita y solamente la suficiente y necesaria y en los formatos más adecuados, que llegue al público interesado, que entregue valor a la organización. Y siendo consecuentes con el primer valor del manifiesto, esta documentación no se requiere producir con herramientas sofisticadas.

Ágil significa “no hay un plan”

De hecho, ágil no soporta el desarrollo sin planeación. Los métodos ágiles usan planeación y estimación continua para maximizar el ROI. En realidad, ágil es sobre manejo de alcance. La planeación continua permite redireccionar el compás del proyecto de acuerdo con el entorno cambiante del mismo; también, asegura un foco consistente en las prioridades del negocio teniendo en cuenta las restricciones impuestas al proyecto. Además, la planeación constante posibilita tomar mejores decisiones y comunicarlas más efectivamente. Plan sí hay, solo que es dinámico y flexible.

Podemos rastrear el origen de este mito a otro  valor del Manifiesto Ágil que invoca: “valorar la respuesta ante el cambio sobre seguir un plan” [2]. Otra vez, se trata de un malentendido nocivo para la industria del software. Este artículo es un intento más por remediar esa situación.

Ágil es la solución tipo “bala de plata” a todos los problemas de la ingeniería de software (Existe una solución tipo bala de plata)

De todos los monstruos que llenan las pesadillas de nuestro folclor, ninguno más terrorífico que los llamados licántropos. Para ellos buscamos balas de plata que mágicamente los hacen desaparecer para siempre.

La industria del software tiene muchos problemas, aquellos que precisamente se quisieron arbitrar con el manifiesto ágil. Sin embargo, ningún método actual, por sí solo o combinado, es capaz de enfrentar la enorme cantidad de variables que se mezclan en el ambiente de los proyectos de software, dada la magnitud y complejidad de la mayoría de estos. Los métodos ágiles no son la excepción. Si bien su modelo iterativo y adaptativo de gestión posibilita en gran medida la resolución de muchos impedimentos, siempre habrá que poner de manifiesto nuestro sentido común para afrontar escenarios hostiles.

Es decir, además de recurrir a balas de plata, estacas de madera, ajos o apelaciones a la mediación divina (léase procesos y herramientas, documentación detallada, contratos y acuerdos de servicio, planes, etc.), necesitamos encontrar mecanismos que nos permitan interactuar mejor entre nosotros, construir productos de software por incrementos, colaborar íntimamente con los usuarios y reaccionar hábilmente ante los cambios que se presentan todo el tiempo durante un proyecto. Esto es lo que dice realmente el manifiesto ágil.

Ágil no necesita diseño previo

Este quizás es un derivado del primer mito. En la realidad, la pieza funcional de software que se entrega en cada iteración requiere de diseño, el suficiente y necesario para construir un producto con calidad. Se trata de un diseño funcional, tan robusto pero tan flexible como se requiera para que todos los cortes del software se puedan integrar en uno solo. Si pensamos en “diseñar a medida que avanzamos”, seguramente fallaremos en el intento y nuestro producto nunca verá la luz del día. El ciclo convencional del software no desaparece porque lo hagamos ágil: análisis, diseño, implementación, pruebas y despliegue. ¡Algunas cosas no cambian!

Ágil siempre usa “Historias de Usuario"

Esta leyenda también desciende de la primera. Es que la “no documentación” es el más arraigado de todos los mitos alrededor de los métodos ágiles. Tanto las organizaciones como los individuos necesitamos de conocimiento explícito, o sea, de aquel que tenemos y del que somos plenamente conscientes cuando lo ejecutamos, que está estructurado y muchas veces esquematizado para facilitar su difusión. Esas son las claves: estructurado y esquematizado, es decir, documentado. Otra cosa es el formato que usamos para documentar, quizás ese es el que debe cambiar, pero ese es un problema diferente.

Y en cuanto a las historias de usuario, rutinarias en los métodos ágiles, hay que decir que ágil no siempre las usa. Hay que usarlas sí, y solo sí, son apropiadas. Existen otros instrumentos, unos más efectivos que otros, como los prototipos, los tableros de historias, los simuladores. ¿Alguien ha intentado “porciones de caso de uso”? Estas últimas son tan livianas como las historias de usuario y tienen el poder de los casos de uso. Y otro error muy común es creer que las historias de usuario siempre son elaboradas por el Dueño de Producto.

Scrum siempre Funciona

Ya tenemos claro que ágil no es una bala de plata y Scrum es ágil, conclusión…

Primero debemos saber cuándo implementar Scrum en la organización. Y luego debemos saber cuándo usar Scrum en un proyecto. ¿Está preparado nuestro cliente/usuario? ¿Habrá un dueño de producto? Más importante aún, ¿está dispuesto nuestro equipo para entregar software probado y funcionando que sea potencialmente distribuible cada periodo corto de tiempo – 2 semanas –? ¿Están claros los valores y principios del manifiesto ágil? Este artículo es un síntoma de que no lo están. ¿El equipo es autogestionado y experto? ¿Nuestro usuario está dispuesto a involucrarse al 100%?

Entre otras, estas son algunas de las cuestiones que debemos responder y establecer antes de intentar Scrum en nuestros proyectos. Se requiere de cierta capacidad y de cierta madurez para enfrentar el reto.

Scrum Master igual a Gerente de Proyecto

Scrum Master es un rol de gestión, sí, pero no es un gerente como lo conocemos en los proyectos tradicionales, mucho menos un gerente tipo PMI o algo parecido. “El Scrum Master es un líder servil, al servicio del Equipo Scrum.” [3] Un SM es un facilitador, es alguien que se sitúa en algún lugar entre el equipo de desarrollo y el cliente. También puede verse como un “guardián de Scrum”, un custodio, alguien que vigila que el proceso se esté llevando a cabo como lo indica la guía de Scrum.

El SM puede venir de una PMO, es cierto, pero también puede llegar desde el equipo de Analistas o de cualquier otro miembro de la organización que tenga las habilidades y la empatía requerida. El SM tampoco es un desarrollador líder o arquitecto, también hay que decirlo.

Podemos hacer Scrum sin un Dueño de Producto o con muchos dueños de producto

Cuando no tenemos un dueño de producto que está fuera del equipo o, mejor, fuera de la jerarquía del equipo, perdemos algo precioso e inherente a ágil: la noción del cliente. Perdemos a la persona que nos puede ayudar a entender lo que realmente quiere el cliente. “El dueño de producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” [4] El dueño de producto es quien establece los criterios reales de aceptación del producto, esto no lo puede hacer otro rol en el equipo o en la organización. Es un hecho, sin este personaje, el equipo no sabrá que hacer.

Ahora bien, el dueño del producto es uno solo, no un equipo o comité de dueños de productos. El dueño de producto es una sola voz y representa los intereses del cliente, es decir, de todos los interesados en el producto. Más de un dueño de producto puede “adicionar ruido” al proyecto, es decir, sumar variables que pueden llevar el proyecto a la devastación. Finalmente, este mito tiene sus orígenes en que ninguna persona por sí sola tiene el conocimiento completo de lo que quiere la organización, pero ello no es necesario, solo es suficiente con que tenga contacto con las personas apropiadas.

Scrum no funciona con CMMI u otros modelos de procesos y viceversa

He visto anuncios en la Web sobre “la gran pelea” entre Scrum y CMMI, seminarios virtuales, tertulias presenciales, diplomados para expertos, como si se tratara del campeonato de combate definitivo, la última de las grandes contiendas entre dos “gigantes” del deporte. Esta leyenda urbana tiene sus raíces en la creencia de que CMMI es predictivo mientras que Scrum es adaptativo. Pero lo que hay que saber realmente es que CMMI es un modelo de mejoramiento de procesos, nos indica qué buenas prácticas dan ventaja a nuestra organización, en tanto que Scrum aporta precisamente el cómo implementar esas prácticas.

En la realidad es posible integrar estos dos mundos y ponerlos a funcionar en beneficio de nuestros clientes y de nosotros mismos: a la vez que CMMI permite describir todos los procesos de la organización y su interacción, Scrum regula el procedimiento a seguir en el mero proceso de desarrollo. Quizás el detalle más oscuro en este análisis es aquel de las estadísticas inherentes a toda organización de alta madurez, pero la cultura ágil de alguna manera impuesta por Scrum sirve de fundamento sistemático a los requisitos de un proceso de control estadístico impuesto por CMMI. Las cosas así, es totalmente viable convivir con Scrum y CMMI en un mismo plano.

Scrum produce equipos de súper héroes, tipo los Vengadores o la Liga de la Justicia

Necesitamos expertos, es cierto. Pero estos no se hacen solos. Scrum no es una caneca de desechos biológicos o químicos y donde podamos caer y levantarnos con poderes extrasensoriales que permitan leer la mente de los usuarios o con una memoria prodigiosa que nos faculte a escribir solo las líneas de código correctas o realizar diseños perfectos en cuestión de segundos.

Si seguimos Scrum, si asistimos a las ceremonias propuestas por el marco de trabajo, seremos capaces de entender los obstáculos que evitan mejorar nuestro desempeño. Y sin la habilidad o deseo de remover esos impedimentos, apenas si podremos tener mayor visibilidad de los problemas. Y esto simplemente redundará en el aumento de nuestra frustración, lo que a su vez dejará notar nuestro comportamiento negativo y menos productivo. Ya lo he repetido, Scrum no es la solución definitiva, pero ayuda a ser mejores cada vez. La transparencia y la predictibilidad son los beneficios inmediatos.

¡El plan de mejoramiento personal y profesional lo ejecutamos de nuestra cuenta!

Más Mitos y Leyendas

Otros mitos, no menos perjudiciales, son:

• Estamos haciendo Scrum, así que no necesitamos otras prácticas ágiles como TDD, Refactoring, Pair Programming, etcétera
• Ágil es menos disciplinado y más fácil
• Podemos lograr agilidad sin cambio organizacional e individual
• Ágil es igual a Scrum
• Con Scrum podemos hacer cambio en cualquier momento

La lista realmente podría ser interminable.

Conclusiones

Scrum es una idea sencillamente empaquetada y de esta manera podemos transferirla rápidamente de una persona a otra y de un equipo a otro. Con todo y ello, es innegable la gran cantidad de concepciones erróneas que tenemos al respecto. Para sacar estos monstruos y mitos de nuestras mentes es necesario tener acompañamiento, no basta con aprender por sí solo, necesitamos entrenamiento de personas que hayan usado exitosamente el método. Las organizaciones, por su parte, deben concebir un buen plan de implantación del método: configurar el proceso, hacer proyectos piloto, medir, analizar los resultados, ajustar, entrenar a los equipos e institucionalizar.

¡Así lo estamos haciendo!

Referencias Web/Bibliográficas

[1] Colaboradores de Wikipedia. Mitología [en línea]. Wikipedia, La enciclopedia libre, 2013 [fecha de consulta: 11 de junio del 2013]. Disponible en http://es.wikipedia.org/w/index.php?title=Mitolog%C3%ADa&oldid=67124850

[2] El Manifiesto Ágil de Software: http://www.agilemanifesto.org/iso/es/

[3] La Guía de Scrum: http://www.scrum.org/Scrum-Guides

[4] La Guía de Scrum: http://www.scrum.org/Scrum-Guides

Actualización 20200220

Puedes ver y descargar la presentación asociada a este artículo aquí.

Scrum Orgánico para Iniciantes

Advertencia: al final de este artículo podrás empezar a usar Scrum en tus proyectos.

Marco de Trabajo Scrum

Presentación

Cuando publiqué la lista de chequeo de Scrum, asumí que mis lectores ya conocían este marco de trabajo (para software o productos y servicios de otro tipo) o que estarían familiarizados con el concepto de prácticas y técnicas ágiles y que conocían el suficientemente expuesto manifiesto ágil. Pensé que  no hacía falta abordar los aspectos más básicos del asunto. Me equivoqué. Acaso para algunos de nosotros esta sea la primera vez con Scrum, el primer contacto con un marco de trabajo ágil, la primera incursión en esta forma de construir productos de software. Así es que decidí volver a lo fundamental. Aquí vamos otra vez.

Scrum es un marco de trabajo liviano e iterativo de gestión de proyectos que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente. “Scrum es un marco de trabajo con el cual podemos afrontar problemas complejos y adaptativos y con el cual podemos emplear distintos procesos y técnicas, así como también podemos optimizar nuestra predictibilidad y tener un mejor control de los riesgos”[i].

Métodos Ágiles

Pero Scrum no es el único método ágil que podemos encontrar. Algunos otros marcos de trabajo ágil son:

·         Adaptive Software Development (ASD)

·         Crystal Clear

·         Kanban
·         Extreme Programming (XP)
·         Dynamic System Development Method (DSDM)

·         Feature Driven Development (FDD)

·         Lean Software Development (LSD)

·         Open Unified Process (OpenUP)

·         Essential unified process (ESSUP)

·         Agile Unified Process (AUP)

·         Use Case 2.0

La Filosofía Ágil

Todos estos métodos tienen sus cimientos en lo que se conoce como Filosofía Ágil:

·         Usted no puede predecir o planear con absoluta certeza lo que va a entregar, cuándo lo entregará y cuánto será su costo.

·         Empiece con planes iniciales alrededor de las estimaciones, fechas y alcance, pero enfóquese en la revisión continua de estas restricciones a medida que avanza.

·         La meta es entregar el mejor software posible, dadas estas restricciones, pero ningún método con el enfoque de receta de cocina mejorará lo que es “mejor”.

Scrum

Scrum define explícitamente tres roles, cuatro ceremonias y cuatro artefactos principales. El Dueño del Producto, el Equipo de Desarrollo y el Scrum Master son quienes tienen bajo su responsabilidad entregar software probado y funcionando cada cuatro semanas o menos. Todos ellos forman el Equipo Scrum que, además de las actividades regulares de desarrollo de software, realiza cuatro ritos durante cada iteración que en Scrum se llama Sprint: Planificación del Sprint, Reunión Diaria, Revisión del Sprint y Retrospectiva. Durante estas ceremonias, el equipo actualiza la Lista (Backlog) del Producto, la Lista de Pendientes (Backlog) del Sprint y la Lista de Impedimentos; y al final entrega un incremento del producto potencialmente distribuible.

Actores en Scrum

El Dueño del Producto es la persona encargada de maximizar el valor del producto elaborado por el equipo de desarrollo. Es quien define y prioriza los ítems de la bitácora de producto y quien proporciona al equipo todo el conocimiento del negocio necesario para que este sea transformado en software. Entre tanto, el Equipo de Desarrollo es el responsable de construir el producto, teniendo en cuenta las necesidades y prioridades del dueño del producto. En Scrum no existen roles especializados, es simplemente el equipo, comprometido todo con el éxito del proyecto.

Finalmente, el Scrum Master es un servidor, es quien vela porque se ejecute el proceso como está definido y que se lleven a cabo cada una de las ceremonias Scrum como está consignado en la Guía de Scrum. También es el encargado de introducir nuevas prácticas al proceso y al proyecto, acompañando de cerca su implantación y monitoreando los resultados. Es importante aclarar que el Scrum Master no es un gerente, aunque bien podríamos decir que hace parte de y reporta al área de manejo de la organización, por ejemplo, a la oficina de proyectos. Contando el SM, el equipo Scrum no debe superar las 9 personas.

Ceremonias y Artefactos Scrum

En un proyecto gestionado bajo el manto de Scrum, todo ocurre en el marco de un Sprint: este es una iteración de un tiempo máximo de 4 semanas. La industria del software está gritando a cielo abierto que este tiempo sea de solo 2 semanas o de menor duración. Al principio del Sprint se realiza la Planificación del Sprint. En esta reunión, el dueño del producto asiste con la Lista del Producto actualizada y priorizada, de acuerdo con las necesidades del negocio. Junto con el equipo de trabajo, se seleccionan algunos de los elementos de la lista, usualmente los de mayor valor para el negocio, para ser desarrollados durante la iteración.

Con estos elementos seleccionados se conforma lo que se llama la Lista de Pendientes del Sprint, el trabajo del sprint. A continuación, el equipo de desarrollo define cómo hará el desarrollo y estima el esfuerzo necesario para cada uno de los elementos seleccionados, teniendo en cuenta que el esfuerzo máximo es el definido para el sprint, ni un minuto más. Con estas premisas, el Equipo en pleno elabora la Definición de Terminado y se asegura que todo el mundo la entienda y la comparta. Esta “definición de Terminado” se convierte en una especie de “contrato” del sprint, define las cláusulas sine qua non el incremento del producto no satisface a su dueño ni a la organización.

Con la definición de Terminado en la mente de los miembros del equipo Scrum, este inicia el ciclo de vida del software. Todos los días, a la misma hora y en el mismo lugar, de pie y durante 15 minutos máximo, el equipo se congrega en la Reunión Diaria. En esta sesión, cada integrante del equipo responde tres preguntas: ¿qué hice ayer? ¿Qué haré hoy? Y ¿Qué problemas tengo? Solo tres y nada más que tres. Esta reunión no es para saludarse ni para hablar de asuntos que no estén relacionados con el proyecto o con las personas que lo ejecutan. Tampoco es para resolver los problemas expuestos.

De la reunión diaria sale actualizada la Lista de Impedimentos, la cual es tratada fuera de la reunión, por cada uno de los responsables de solucionarlos. En Scrum, el equipo es autogestionado, multidisciplinario y debería tener la capacidad de resolver sus propios problemas sin la ayuda de alguien externo. Hacia el final de la iteración, se realiza la Revisión del Sprint. En esta sesión, el equipo Scrum y los interesados realizan un escrutinio de lo que se hizo en el sprint y ajustan la lista del producto si fuese necesario. En definitiva, el dueño del Producto verifica que se haya cumplido la Definición de Terminado.

Justo a continuación de la revisión, se hace una Retrospectiva del Sprint: ¿Qué hicimos mal que no repetiremos? ¿Por qué no se alcanzó la Definición de Terminado? ¿Qué hicimos bien que podemos mejorar? ¿Qué hicimos bien que seguiremos haciendo tal cual? Estas son algunas de las cuestiones que, con ayuda del Scrum Master, se responden en esta reunión. En esta sesión también deberíamos separar unos instantes para realizar una introspectiva: ¿Cómo está nuestro estado de ánimo? ¿Seguimos? ¿Paramos? Si seguimos, ¿qué acciones de mejoramiento podemos introducir a partir del siguiente Sprint?

Conclusión

Estos son, grosso modo, los elementos que subyacen el método Scrum. Todas las ceremonias tardan un tiempo fijo definido en el libro de reglas de Scrum o Guía de Scrum. No hay que saber nada más para comenzar a usar el marco de trabajo. Y para usarlo hay que ser ágil, porque Ágil es algo que eres, no algo que haces. Una vez que puedes diferenciar esto, entonces convertirse en ágil será algo fácil. Extrapolando, una organización no puede forzar la filosofía ágil en su cultura, sino que debe permitir que su cultura evolucione hacia un estado ágil. Ágil es un estado de la mente, es una forma de pensar y de ver las cosas.

Se me olvidaba decirles, la retrospectiva siempre debe hacerse al final de cada sprint, a menos que el equipo esté bien ocupado. En cuyo caso, se deberían hacer dos.

Lecturas Adicionales

Mi artículo de Scrum Fundamental lo encuentran en este mismo Gazafatonario, en: http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf#zoom=100.

La lista de verificación de Scrum que desató esta serie de artículos  la encuentran en: http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Otros sitios que pueden visitar para aprender más de Scrum y libros que pueden leer son:

http://www.scrum.org/scrumguides

http://www.scrumalliance.org

http://www.mountaingoatsoftware.com/

http://scrum.jeffsutherland.com/

http://www.controlchaos.com/

http://americalatina.pmi.org/latam/CertificationsAndCredentials/PMI-ACP/PMI-ACPExamPreparation/MaterialsAndResourcesInAgile.aspx

Essential Scrum: A Practical Guide to the Most Popular Agile Process. Mike Cohn.

Succeeding with Agile: Software Development Using Scrum. Mike Cohn.

Agile Project Management with Scrum (Microsoft Professional). Ken Schwaber.

Agile Product Management with Scrum: Creating Products that Customers Love. Roman Pichler.

Professional Scrum Development with Microsoft® Visual Studio® 2012. Richard Hundhausen.

User Stories Applied: For Agile Software Development. Mike Cohn.

---

[i] La Guía de Scrum. © 1991-2011 Ken Schwaber y Jeff Sutherland, Todos los Derechos Reservados.