¿Por qué fallan las implementaciones de Scrum?

Respuesta: porque desconocemos los valores y principios del Manifiesto Ágil punto

El Manifiesto por el Desarrollo Ágil de Software

La razón que expuse es apenas una de las muchas por las cuales podemos fracasar al intentar Scrum. Para hacerle frente, entonces es necesario conocer de qué se trata exactamente el Manifiesto Ágil. Este lo encontramos en http://www.agilemanifesto.org/iso/es/. Sin embargo, lo copiaremos aquí para explicar mejor el asunto que nos ocupa:

Estamos descubriendo formas mejores de desarrollar

software tanto por nuestra propia experiencia como

ayudando a terceros. A través de este trabajo hemos

aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha,

valoramos más los de la izquierda.

Estos son los valores. Le siguen una docena de principios que pueden encontrar en la página que mencioné antes. Este texto parece inofensivo pero encierra una enorme carga emocional; sin embargo, lo más importante es que nos enseña justamente cómo debemos enfrentar los proyectos de construcción de software actuales. Y como leerlo es más fácil que entenderlo, en la sección de Referencia enumero algunos de los artículos de mi Gazafatonario IT que intentan explicar de una u otra forma la razón de ser de este manifiesto.

Algunas recomendaciones para tener éxito al implementar Scrum

• No piense en herramientas antes que en el proceso y no piense en el proceso antes que en las personas y sus interacciones. ¿Cómo va a lograr que las persones interactúen entre sí? “La gente tiene que trabajar cara a cara” dice el mismísimo Jeff Sutherland, y para todos Scrum debe ser una forma de hacer, una forma de ser, una forma de vida. Esto es, valorar el valor “Personas e interacciones sobre procesos y herramientas” del Manifiesto Ágil.
• Necesitamos herramientas, sí, pero no permitamos que estas nos dicten el proceso e indiquen el camino a seguir, lo último que queremos son productos de software costosos antes de lograr que Scrum funcione o antes de lograr los primeros resultados exitosos con el método. Además, necesitamos un proceso para gestionar toda una operación, desde la concepción de los productos hasta la puesta en funcionamiento de los mismos a cabal satisfacción de los usuarios/clientes; y el núcleo de ese proceso debe ser precisamente Scrum, tal y como dice la Guía, no es necesario “inventar” nada más.
• Tampoco es necesario eliminar o agregar nada más a Scrum como marco de gestión. Por ejemplo, decir que hacemos Scrum pero no tenemos Dueño de Producto o usar el patrón proxy del Dueño de Producto, es algo común en las implementaciones deslucidas de Scrum. Uno de los principios del Manifiesto Ágil lo dice claramente: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Esto apunta a resolver la mayor causa de fracaso en los proyectos tradicionales: “falta de involucramiento del usuario” [7]. 
• No piense que Scrum le va a solucionar todos sus problemas, incluidos los personales. Scrum no es una bala de plata [4], de hecho, Scrum por sí solo no es suficiente, debe acompañarse de un conjunto de prácticas y otros métodos preferiblemente ágiles. Eso sí, no intente implementarlos todos de una sola vez y mucho menos intente hacerlo solo, hágase acompañar de expertos, de personas que hayan recorrido el camino y que quizás hayan cometido uno o dos errores críticos; con seguridad, serán ellos quienes lo sacarán del aprieto en el que posiblemente se va a encontrar más de una vez.

• No piense en las certificaciones. Si cree que les hacen falta, estas llegarán a su debido tiempo. Cuando tenga la suficiente experiencia y madurez para darse cuenta que no las necesita. Sí, certificarse nos trae beneficios a nosotros como individuos y a las organizaciones para las que trabajamos o representamos. La certificación verifica que nuestro nivel de pericia y conocimiento es consistente con los estándares de la profesión en un área específica, pero, también a veces, las certificaciones atribuyen competencias donde usualmente no las hay, a quienes usualmente no las tienen.
• Uno de los aspectos que hacen “mágico” a Scrum es que podemos implementarlo usando Scrum. La gran ventaja es que no tenemos que definir un proceso porque ya está definido [8]. Podemos tener una Lista de elementos a implementar (el backlog) y los separamos en sprints de 2 semanas para ir implementando gradualmente en unos pocos meses. Esto permitirá que las personas se sientan cómodas y a gusto con el cambio y se logren mejores resultados más rápidamente.

En cada Sprint de implementación de Scrum realice las ceremonias orgánicas de Scrum:

1. Planee cada sprint de la implementación
2. Haga reuniones diarias
3. Al final de cada sprint revise los resultados
4. Antes del siguiente sprint, haga una retrospectiva de lo que fue bien y lo que fue mal durante el sprint actual de implementación 

Se me ocurre que podríamos usar, para empezar, este algoritmo general de la implementación de Scrum:

Figura 1: Algoritmo general de la implementación de Scrum usando Scrum

Esta es una primerísima versión del algoritmo a “mano alzada”, escucho opiniones al respecto.

Otras Recomendaciones a tener en cuenta para asegurar el éxito en una implementación de Scrum

• Todo el equipo debe tener un pensamiento Ágil.
• Debe haber un alto grado de cohesión en el equipo, incluyendo a los usuarios.
• Centrado en el usuario
• Transparente, es decir, todos deben conocer el estado del proyecto en cualquier momento
• Debe predominar la Cultura de la Calidad
• Debe haber retroalimentación continua de todos los participantes
• Manejo de riesgos conjunto
• Se requiere disciplina
• El equipo debe tener un experto en métodos ágiles en general y en Scrum en particular para hacer coaching y acompañamiento continuo.
• Participe o, al menos, manténgase en contacto con otras personas que estén usando Scrum: la Comunidad Ágiles Colombia [9] es un buen ejemplo de ello; la de Ágiles Latinoamérica [10] también.

Finalmente, cuando tenga la suficiente experiencia y cuente con equipos maduros, quizás antes, atrévase a adicionar sus propios valores al Manifiesto Ágil y póngalos en práctica. Ya en la comunidad Ágiles estamos discutiendo algunos de esos nuevos valores y principios:

Experiencia efectiva sobre certificaciones retóricas

Innovación continua sobre mantenimiento de productos

Satisfacción del Cliente sobre margen de utilidad

Felicidad de las personas sobre inapetencia profesional

¿Se animan con otros? Pueden dejarme sus comentarios o ir al foro de la comunidad Ágiles Colombia y participar de la discusión. Lo encuentran en:

https://groups.google.com/forum/#!topic/agiles-colombia/Cd3QJRnHYEo

Referencias

Scrum – Lo Fundamental

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

Scrum Orgánico para Iniciantes

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

Vademescrum, Sección I: El Scrum Master 1

http://www.gazafatonarioit.com/2013/06/vademescrum-seccion-i-el-scrum-master-1.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

Planificación del Sprint: el primer paso para producir el máximo efecto

http://www.gazafatonarioit.com/2013/09/planificacion-del-sprint-el-primer-paso.html

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

http://www.gazafatonarioit.com/2013/09/gerentes-de-proyectos-de-software-una.html

Chaos Report. Standish Group. www.standishgroup.com/‎

La Guía de Scrum. http://www.scrum.org/scrum-guides‎

Ágiles Colombia. http://agilescolombia.org/

Ágiles Latinoamérica. http://www.agiles.org/‎

Planificación del Sprint: el primer paso para producir el máximo efecto

“Es un mal plan aquel que no admite modificación”

Publio Sirio, siglo I a.C.

Presentación

Ya sabemos que “el trabajo a realizar durante el Sprint se planifica en la Reunión de Planificación de Sprint.” [1] Es durante esta reunión a la que asiste el Equipo Scrum en pleno que se responden estas dos cuestiones:

• ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
• ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento? [2]

Durante la reunión se propone un Objetivo a alcanzar en el sprint que inicia y se discuten los elementos de la Lista de Producto que, una vez terminados, dan como resultado el logro del objetivo propuesto.

Durante la primera parte de la reunión el Dueño de Producto propone los elementos de la Lista de Producto que quiere ver terminados hacia el final del sprint. En la práctica, el Equipo de Desarrollo realiza todas las preguntas necesarias al Dueño de Producto con el fin de clarificar aspectos de los elementos de la Lista de Producto, por ejemplo, de las historias de usuario seleccionadas para el sprint. Esta parte de la reunión es un evento típico de recolección de información, se establecen los criterios de aceptación de las historias de usuario, los pormenores funcionales y no funcionales de las mismas y todo lo que haga falta para que el equipo pase luego a decidir cómo se conseguirá terminar el trabajo del sprint.

En principio, el equipo debe estimar el esfuerzo necesario que le tomará terminar cada historia de usuario según lo establecido en la Definición de Terminado. Para ello, el equipo debe poner de manifiesto su experiencia en el ciclo de vida del desarrollo del software, desde el análisis, pasando por el diseño, la implementación, las pruebas, la documentación, hasta el despliegue del producto funcional. La estimación puede hacerla entonces usando técnicas ágiles como Planning Poker, que permite fijar los puntos de historia de cada una de las historias de usuario y que servirán luego para calcular la Velocidad del equipo y evaluar aspectos de productividad y calidad.

Al final de la reunión el equipo tiene definidos:

• Un Objetivo del Sprint y
• Una Lista de Pendientes del Sprint

Además del número total de puntos de historia que se construirán en el sprint que comienza. El objetivo del sprint es una corta descripción, una o dos frases, de lo que el equipo planea alcanzar durante el Sprint. Por ejemplo, si estamos construyendo un sistema de publicación en línea, este bien puede ser el objetivo de un Sprint:

• Implementar la creación básica de blogs, adición básica y publicación de entadas a los blogs y publicación de comentarios a esas entradas.
• Implementar la gestión básica de usuarios, el ingreso a la aplicación y el recordatorio de contraseñas.

Es una meta que debe estar visible a todos los miembros del equipo y de los demás interesados y cuyo significado debe entenderse a cabalidad. Por ejemplo, “adición básica de entradas a los blogs” quiere decir que se permitirán entradas con texto y una imagen en algún formato conocido; y no quiere decir que se permitirán todos los formatos de imágenes usados hoy, ni que se permitirá inserción de videos o de documentos, tampoco que habrá revisión ortográfica. Es precisamente el contexto lo que debe ser acordado y entendido por todo el Equipo Scrum.

Algunas malas prácticas en la reunión de Planificación y cómo evitarlas

A la reunión de Planificación del Sprint asiste el equipo Scrum en pleno, incluyendo el Scrum Master y el Dueño de Producto, responsable de direccionar el trabajo del Equipo de Desarrollo. Incluso es posible que asistan algunos interesados que apoyen al Dueño de Producto en la clarificación de los elementos de la Pila de Producto. El Equipo debe planear muy bien la reunión, el Scrum Master debe velar porque se haga en el bloque de tiempo establecido por las reglas de Scrum, por ejemplo, 4 horas para un Sprint de 2 semanas. El Dueño de Producto debe estar preparado para responder las cuestiones que surjan de la selección de elementos de la Lista de Producto que serán seleccionados para el sprint.

El Equipo de Desarrollo debe estar completo, ser multifuncional, preparado física y anímicamente para enfrentar un nuevo sprint, los sprints anteriores son cosas del pasado, las acciones de mejoramiento se tomaron y se llevaron a la Lista de Producto para su implementación efectiva, de acuerdo con la prioridad del Dueño de Producto y del Equipo en general. El Equipo está conformado por personas, no por súper héroes que trabajan 16 o más horas al día o con capacidades por encima del promedio (esto último apenas es una ganancia pero no debe tomarse como fundamento para sobrecargar al equipo con tareas que van más allá de su esfuerzo normal).

Aun así debemos tener cuidado: una reunión de planificación mal ejecutada terminará con un mal plan, con elementos de la Lista de Producto pobremente entendidos (por ejemplo, requisitos incompletos o ambiguos), con sobrecarga de trabajo para el equipo, con “sprints individuales”, es decir, iteraciones planeadas para cada miembro del equipo en vez de una sola para todo el equipo; sin la definición de “terminado” o sin el objetivo del sprint claro. Por ello tengamos en cuenta lo siguiente.

Esto es lo que hemos aprendido de las reuniones de planificación del sprint:

No empiece sin el Dueño de Producto. El Dueño del Producto está ausente o remoto. En Ágil/Scrum promulgamos y valoramos más la interacción entre las personas que los procesos y las herramientas. “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara” [3], dice uno de los principios del Manifiesto Ágil. Así que es primordial que el Dueño de Producto esté disponible y presencial durante toda la reunión.

Además, el Dueño de Producto debe estar cuando se realice la estimación y la planeación de tareas. En ocasiones, el Dueño de Producto ayuda a bajar la tensión y las expectativas que se hace el Equipo cuando de construir un incremento del producto. El Dueño de Producto quizás insista en hacer las cosas de otra manera, sencilla o más liviana, pero de valor para el negocio. O al contrario, el Equipo de Desarrollo o el Scrum Master pueden motivar al Dueño de Producto a disminuir su interés en ciertos aspectos del producto pero a fijarse en otras características de mucho más valor y rendimiento para la organización. Recordemos “la simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.” [4]

No permita que el Dueño de Producto sea quien decida sobre la cantidad de trabajo que el equipo debe realizar. En otras palabras, que el Dueño de Producto proponga (imponga) la cantidad de elementos de la Lista de Producto a construir durante el sprint, sin tener en cuenta la Velocidad del equipo o el esfuerzo total que el equipo puede acometer durante la iteración. A medida que el Dueño de Producto propone elementos de la lista, el equipo estima su implementación y resta el estimado del tiempo total efectivo del sprint. Recordemos que “los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.” [5]

El Dueño del Producto no está listo para el Sprint. O la Lista de Producto no está lista. Muy bien, estamos todos los que somos para la reunión pero a las primeras de cambio el Dueño de Producto nos empieza a decir que no tiene las respuestas, que desconoce tal o cual característica, que debe consultar dentro de tres o más días con alguien más, incluso externo a la organización, que no está seguro si las cosas son así o de otra forma, en fin, esa serie de respuestas que finalmente nos llenan de requisitos incompletos y, por consiguiente, de supuestos. Nuestro cerebro tiende a llenar los vacíos con conjeturas que le pueden hacer mucho daño al proyecto.

En el caso de las consultas para más tarde o para días posteriores, le debemos aclarar al Dueño de Producto (y por “debemos” quiero decir el Scrum Master), que dado que el sprint tiene una duración muy corta (2 semanas, por ejemplo), no es posible esperar tanto tiempo por sus respuestas y pasamos así al siguiente elemento de la lista. Precisamente, para evitar estas anomalías, recurrimos a prácticas de refinamiento de la Lista de Producto que consisten en que, en medio del sprint actual, nos reunimos con el Dueño de Producto para agregar detalles, lo mismo que priorizar y estimar los elementos de la lista de los próximos dos sprints. Así cuando llegue el momento de la planificación, el Dueño de Producto esté lo suficientemente preparado como para iniciar la nueva iteración sin contratiempos.

Planear un esfuerzo total que sobrepasa los límites del Equipo, por ejemplo, planear tareas del ciclo de vida del software en tiempos de reunión de Revisión o de Retrospectiva. Si el equipo es de 5 personas y estamos haciendo sprints de 2 semanas, debemos restar 15 horas de esfuerzo total por estas 2 reuniones (10 por la reunión de revisión y 5 por la de retrospectiva), además unas 12  horas de esfuerzo por reuniones diarias y 20 horas por la reunión de Planificación del Sprint, esta de la que estamos hablando. Es decir, unas 47 horas menos, con lo que el esfuerzo real sería de 353 horas para ese equipo de 5 personas.

Incluso deberíamos planear jornadas efectivas de menos de 8 horas, por ejemplo 6 o 7, máximo. Con 7 horas, por ejemplo, el esfuerzo total del equipo de 5 personas sería de unas 300 horas. Algo realista y que, a la larga, contribuye a aumentar la productividad, la energía de las personas del equipo, la motivación y, como  consecuencia, mejora la calidad de los productos que construyen. “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.” [6]

Otras cosas que no debemos hacer antes, durante o después de la reunión de Planificación del sprint

• La reunión tarda más de lo debido. El Scrum Master debe estar atento a ello. Puede ser un indicativo de falta de productividad o de que estamos sobre-planificando el sprint.
• Cada miembro del equipo planea su “sprint individual”. O se hace una planeación para alguien en particular, “alguien adicional”.
• No planear de manera colaborativa. Va de la mano con la anterior práctica errónea.
• No planear la reunión con anticipación. Vale para todo el Equipo Scrum. Si hicimos Refinamiento deberíamos tener el suficiente apresto para realizar una reunión dinámica y efectiva.
• No definir un Objetivo del Sprint. ¿Entonces hacia dónde vamos? El Objetivo es la brújula que nos orienta.
• Planear tareas de 8 horas o más para un miembro del equipo. Se deben planear 2, 3 o más tareas cuya suma de esfuerzos individuales sume el tiempo total de esfuerzo diario de cada miembro del equipo.
• Permitir que alguien, por ejemplo el Dueño de Producto o el Scrum Master, incluso alguien externo, asigne las tareas al resto del equipo.
• Ausencia física del Scrum Master en la reunión de planificación. Puede estar virtual pero seguramente el valor de su participación será mucho menor.

Referencias

[1], [2] La Guía de Scrum. http://www.scrumguides.org/download.html

[3], [4], [5], [6]  El Manifiesto Ágil. http://www.agilemanifesto.org/iso/es

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

“En los próximos treinta años, sin hacer ningún  ruido, un día dejaremos de ser los seres más brillantes de la tierra”. James McAclear.

Imagen de Mark Garlick/Science Photo Library

Hace poco, durante la sesión de preguntas y respuestas de una conferencia sobre transición al universo ágil y a Scrum que facilité con todas mis ganas, alguien del público censuró arduamente algunos de mis puntos de vista… Esta es su historia.

La pregunta

-         “Lucho, quiero referirme específicamente al asunto de la Gerencia del Proyecto en este mundo ágil que planteas” – comenzó diciendo con firmeza. “Afirmas que nosotros no necesitamos un Gerente de Proyectos si estamos empleando una metodología Ágil, específicamente si empleamos Scrum”

Aunque aun no sabía en qué iba a terminar aquello, no quería hacer parte de lo que venía a continuación. Empecé a pensar que el asunto podía convertirse en un ejercicio de semántica, en vez de uno de fondo, empezando con la definición de “nosotros” y la de “Gerente de Proyectos”.

-          Por ejemplo, – prosiguió ella, con un tono que rayaba en lo trascendental – dices que el Scrum Master es quien facilita las reuniones Diarias, la reunión de Planificación del Sprint, la Retrospectiva; es quien le da un empujoncito al Dueño del Producto para que sus historias estén a tiempo para la Planificación del Sprint; y es a quién acuden los miembros del Equipo cuando tienen problemas que no pueden resolver.

En un instante calculé muchas de las preguntas que podían resultar de aquel soliloquio y con preocupación noté que la referencia inicial al Scrum Master haría que entráramos a un terreno escabroso, a una discusión que podría exacerbar los ánimos de Ella y de algunos de los asistentes.

-          No tienes que llamar a esa persona un Gerente de Proyecto si no quieres – aseveró Ella con una modulación culminante, aunque con las mejillas rojizas, - y, en Scrum, esa persona es el Scrum Master.

Otra vez el Scrum Master. Sin duda, lo que venía era equipararlo con el Gerente de Proyectos tradicional.

-          Aun así, mucho de este trabajo se parece a la clase de cosas que hacen los Gerentes de Proyectos. – Ahí estuvo, no me equivoqué, pero antes de que pudiera pensar en algo más, siguió diciendo - El hecho de que un Gerente de Proyectos asociado con tipos diferentes de proyectos haga cosas que no son consistentes con Scrum no elimina la necesidad de que alguien haga esas cosas que parecen tan espantosas en los proyectos Scrum.

En cierto sentido tenía razón. Pero ¿y la pregunta?

-          Mi punto es, aunque no se llame Gerente de Proyectos, sí hay gerencia de proyectos en los proyectos Scrum. ¿Qué nos puedes decir al respecto? – Se sentó más tranquila que cuando se levantó para hacer el cuestionamiento. Es como si hubiese aliviado setenta y cinco minutos de ansiedad de un solo tirón, el mismo tiempo que tardó mi intervención.

La respuesta

Mi punto en cambio – pensé - es que embrollarse mucho con el vocabulario e insistir en que alguien que llena el rol de Scrum Master absoluta y positivamente no hace nada que se parezca al trabajo de gerencia de proyectos, no es un uso constructivo del tiempo. Es más lucrativo averiguar lo que se necesita hacer para que el proyecto sea exitoso… ¡Y hacerlo!

Sin embargo, quise iniciar mi respuesta dándole parcialmente la razón. Le dije que tal y como concebimos el proceso, un proyecto Scrum está inmerso dentro de un conjunto de actividades relacionadas que requieren habilidades más clásicas de un Gerente de Proyectos, como la negociación contractual, la puesta en marcha de la operación o la misma selección del equipo. En Scrum, el equipo se autoorganiza, pero no es capaz de autoseleccionarse, hay restricciones de disponibilidad de las personas, de habilidades necesarias y de motivación, entre otras, que deben tomarse en cuenta. Sí, es cierto que quien se pone en los zapatos del Scrum Master bien puede hacer estas cosas, en cuyo caso llamarlo Gerente de Proyectos (así como Scrum Master) tiene mucho sentido.

Mientras yo hablaba, miraba cómo la expresión de su rostro cambiaba; el tono rojizo que tenía durante su intervención se había disipado y sus mejillas volvieron a su color habitual. Incluso sonrió, asintió con la cabeza y le susurró algo que nunca sabremos a su compañero de la izquierda, aunque tuve la ligera desesperanza de que decía: – sí, ¡yo tenía razón! – En parte la tenía… pero solo si hubiésemos estado hablando de proyectos tratados con métodos tradicionales, no ágiles.

Mientras hacía la pausa para continuar, pensaba que esa pregunta ponía de manifiesto una vez más algo común en los procesos de transformación hacia lo ágil y era que, aun cuando creyeran que ya habían llegado al final del camino (¡somos ágiles, somos Scrum!), muchos todavía tenían un largo camino por recorrer antes de que realmente entendieran lo que significaba hacer Scrum y “ser ágil”. Imaginé a Ken Schwaber o a Jeff Sutherland interviniendo en la discusión, pero solo para argumentar que  ninguno de los roles en Scrum eran eufemismos para “Gerente de Proyectos”, y finalmente pensé que ninguno de ellos ni ninguno de los otros 15 personajes que firmaron el Manifiesto Ágil, entrarían alguna vez en una discusión como esta.

Pero – justo en este instante tuve la idea completa – quienes tratamos de aplicar Scrum adhiriéndonos a sus reglas tan íntimamente como podamos, sabemos que es el Equipo el que toma las decisiones y que el Dueño del Producto es el “familiar” más inmediato que los Equipos Scrum tienen a un(a) Gerente de Proyectos. – Ya estaba dicho, sentía que debía deshacer de raíz ese arraigo de las personas de quedarse en la mitad del proceso de renovación hacia la filosofía ágil.

La guía de Scrum dice textualmente: “El Dueño de Producto es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo.” Y más adelante, en el mismo apartado sobre el Dueño del Producto, complementa: “toda la organización debe respetar sus decisiones.” Les recomiendo además el artículo “Scrum: Cediendo el mando y control AL EQUIPO” de mi colega Jorge Abad y con quien he abordado estos asuntos en la Comunidad Ágiles Colombia. Bien dice él que el “rol de la gerencia de proyectos queda inoperante y se convierte en un reto profesional pasar de gerente de proyectos a Scrum Master” [1]. Jorge se refiere a los Proyectos/Equipos Scrum. Le decía precisamente sobre esta aseveración que, aunque estuviera claro que el gerente de proyectos de hoy puede ser un Scrum Master, el trámite de ir de un punto a otro no es algo lineal y mucho menos algo que se pueda lograr durante el sueño.

En este punto de mi parlamento, no solo la expresión corporal de mi interlocutora, sino la de muchos en el auditorio, era de desconcierto. Así que debía anticiparme a sus preguntas.

La pregunta entonces es – continué – ¿cómo lograr esa metamorfosis? ¿Cómo hacer que ese cambio no se quede en un mero “regateo”, que no se quede en una evolución trunca o, dicho de otra forma, en una mera mutación involutiva? No queremos que el resultado sea algo así como “gerenscrummaster de proyectos”… como lo que sucede en La Mosca, aquella película de 1986, dirigida por David Cronenberg, con Jeff Golblum y Geena Davis.

Y la respuesta a esa pregunta es: dejarse abrazar por los valores y principios del Manifiesto Ágil, por los pilares de Scrum de Transparencia, Inspección y Adaptación, ese trípode que se constituye precisamente en el soporte de los Equipos Scrum, autoorganizados, esos que según la misma Guía de Scrum “eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo.” Además, “tienen todas las competencias necesarias para llevar a cabo el trabajo sin depender de otras personas que no son parte del equipo.”

Me pareció que no había nada más que decir. Así que me propuse cerrar el tema diciéndoles que, de hecho, la conversión de los gerentes de proyecto actuales hacia otros roles era un factor de resistencia al cambio durante el proceso de renovación hacia “ser ágil” y esa resistencia normalmente redundaba en una crisis organizacional. Pero no había nada que hacer, buena parte, sino todas las responsabilidades del gerente se distribuyen en estos nuevos roles que hoy estamos jugando en Scrum. Por ejemplo, la visión y las guías del proyecto están a cargo del Dueño del Producto, el Equipo automaneja la organización diaria del flujo del proyecto, mientras que la facilitación y el entrenamiento son responsabilidad del Scrum Master.

Conclusión

Estoy seguro que a mi interpelante no le gustó esta respuesta, pero que le vamos a hacer. A algunos les sabe cruda la verdad. Lo que ocurre es que las organizaciones no se mueven rápida y fácilmente a Ágil/Scrum y tienen malos momentos consiguiendo velocidad y experiencia en los nuevos roles. El cambio es duro. Ágil no es una construcción de conveniencia; demanda un cambio radical del pensamiento tradicional acerca del desarrollo. Si una persona no puede verdaderamente adoptar los valores y principios del Manifiesto, entonces en mi opinión ellos son ADNS – Ágil De Nombre Solamente. ¿Eres tú un ADNS?

Lo otro que me inquieta son los certificados. Cuando escucho o leo a gente con CSM y CSPO, PSM o similares, y combinados con PMP o algo así, haciéndome preguntas o expresándose como lo hizo el personaje de esta historia, me pregunto si fueron al entrenamiento y obtuvieron las certificaciones simplemente para llenar sus Hojas de Vida. No parecen comprometidos con el pensamiento ágil o con los valores y principios del Manifiesto Ágil.

He tenido la colosal fortuna de trabajar con personas/colegas supremamente inteligentes, en proyectos de software extremadamente complejos; y ellos siempre me tienen en cuenta para resolver problemas comunes y no tan comunes pero peculiares en esta clase de proyectos; también quieren conocer mi opinión sobre ideas técnicas que los mantuvieran enfocados en los objetivos primordiales, es decir, los entregables del proyecto. Soy parte del equipo, no una figura de autoridad. Lo que hecho, en la práctica, es contribuir al éxito del proyecto y al triunfo del equipo, a la satisfacción del usuario. No importa nada más.

Con Ágil/Scrum simplemente lo estamos haciendo más frecuentemente, con mayor calidad y, sobre todo, con mayor entusiasmo y felicidad.

Referencias

Scrum:Cediendo el mando y control AL EQUIPO

El Manifiesto Ágil del Desarrollo de Software

La Guía de Scrum

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

Historias de Usuario Altamente Efectivas 4

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

Cualidad :: Valiosa (y Valuada)

Las Historias de Usuario deben tener Valor para los usuarios

Veamos esta situación:

Historia de Poco Valor

Como: Lector del blog

Quiero: ver la lista de temas tratados en el blog

Para: buscar las entradas que más se acomoden a mis intereses personales

Es mejor escribir esta historia desde el punto de vista del Bloguero:

Historia de Mucho Valor

Como: Bloguero

Quiero: mostrar a los lectores los nuevos temas tratados en mi blog

Para: que ellos continúen más propensos a leer más entradas del blog

Con esta historia tenemos una perspectiva más clara del valor real de la historia. La implementación de esta podría llevar a más lectores a leer más entradas del blog con lo que se incrementaría el tráfico en el sitio Web y posicionarían al bloguero como experto en los temas de su dominio. Mientras que ambas historias son pequeñas, negociables, independientes, y pueden tener los demás atributos de las buenas historias de usuario, el valor de la segunda es mucho más alto para el negocio que el valor de la primera.

Al negociar la funcionalidad de una historia también tenemos en cuenta su valor para el negocio. Una visión que siempre debemos tener los equipos ágiles es encontrar ese 20% de la funcionalidad que se usa el 80% de las veces o ese 20% del producto que tiene el 80% del valor para el negocio, recordemos que la filosofía ágil se basa en entregar valor al usuario. Esto quiere decir que si tenemos una funcionalidad como la siguiente:

Como: Bloguero

Quiero: ingresar a mi blog con usuario y contraseña

Para: mantener la seguridad y confiabilidad de la información del blog

Criterios de Aceptación:

• Debo ser capaz de cambiar la contraseña cuando lo desee
• El sistema debe enviarme un correo electrónico para confirmar el cambio de contraseña
• El usuario puede ser un nombre seleccionado por mí o una dirección de correo electrónico
• El sistema debe bloquear la cuenta cuando haga tres intentos fallidos consecutivos
• El sistema debe permitir que ingrese automáticamente si uso el mismo computador o dispositivo
• Si olvidé la contraseña, el sistema debe preguntarme por la dirección de correo asociada a mi cuenta o por mi nombre de usuario y enviarme un enlace para establecer una nueva contraseña
• [Siguen…]

Esta es, a todas luces, una historia que se puede dividir en varias historias dado el alto número de criterios de confirmación que tiene. Con los usuarios buscamos lo que proporcione mayor valor para el negocio y lo que se vaya a usar más, por ejemplo: “el sistema debe permitir establecer una nueva contraseña cuando lo desee”, y salir en la primera iteración o entrega con esta funcionalidad. Las demás se van adicionando a medida que avanzan las iteraciones o las entregas. Y como antes, algunos de estos criterios quizás nunca lleguen a implementarse, por ejemplo, el de bloquear la cuenta después de varios intentos errados.

Finalmente, quien mejor conoce el valor de una historia de usuario es precisamente el usuario, personificado en alguien como el Dueño del Producto, que habla como una sola voz ante el equipo de desarrollo y que representa los intereses del negocio. Es a esta persona a quien debemos apoyar para que los esfuerzos de desarrollo sean conducidos efectiva y eficientemente.

A estas alturas solo hace falta recordar que el Valor es el atributo más importante en el modelo INVEST. Cada historia de usuario debe proporcionar algún valor, el mayor posible, al usuario, al cliente o a cualquier interesado en el producto. Con esto en mente, debemos entonces reorientar nuestras estructuras de descomposición funcional del software de un enfoque horizontal a uno vertical, esto es, para el usuario o interesado no tiene prácticamente ningún valor si cierta funcionalidad requiere de uno o varios procedimientos almacenados, o de uno o varios componentes en las capas intermedias de la solución.

El usuario necesita de la funcionalidad que le permite interactuar con el sistema, es lo que tiene valor para él/ella. Entonces debemos crear historias que atraviesen la arquitectura para poder presentar valor al usuario y obtener así la mejor retroalimentación en el menor tiempo posible. Esto es consistente con los modelos de gestión ágiles como Scrum, donde el Dueño de Producto es quien orienta los esfuerzos del equipo de desarrollo y prioriza las historias de usuario teniendo en cuenta su valor para el negocio. Y normalmente el Dueño de Producto no conoce de los aspectos puramente técnicos que subyacen a una historia de usuario (procedimientos almacenados, clases, componentes, Web services, etcétera).

En este punto llegamos al no menos peliagudo asunto de los requisitos técnicos o no funcionales, del software. Dos estrategias se usan habitualmente: la primera de ellas es que estas condiciones técnicas hagan parte de los criterios de aceptación de la historia, como en:

Como: Editor

Quiero: establecer el período de expiración de la contraseña

Para: que los blogueros se vean forzados a cambiar sus contraseñas periódicamente.

Criterios de Aceptación:

• La contraseña se debe poder cambiar antes de finalizar el período de expiración
• Ninguna persona distinta a su creador debe tener acceso a la contraseña

El segundo criterio, relacionado con el acceso a la contraseña, es una restricción típica de seguridad que bien puede ser establecida por un usuario, en este caso, por el Editor; también puede ser un Administrador de la Aplicación. Este enfoque de incluir las características no funcionales de una historia como parte de esta tiene la ventaja de permitir al mismo usuario reconocer su valor y al equipo completo de negociar su implementación.

La segunda táctica es crear historias independientes para cada propiedad o condición técnica, o para un grupo de estas, como en:

Como: Bloguero

Quiero: que mis entradas de blog soporten hasta 10 mil comentarios cada una

Para: mantenerme en contacto con el mayor número de personas posible

Criterios de Aceptación:

• Cada comentario debe contener hasta 500 palabras o 4000 caracteres

En este ejemplo, tanto la acción expuesta en la historia de usuario, como el criterio de confirmación son requisitos no funcionales que se pueden implementar. Este segundo enfoque ayuda a independizar las historias de usuario y a aplicar criterios a un grupo de funcionalidades (este no es el caso en el ejemplo); sin embargo, estas historias tienen la desventaja de que los usuarios o interesados (el Dueño del Producto) no le vean ningún valor y son difíciles de negociar con ellos/ellas.

En la práctica se usa una combinación de las dos estrategias. Ahora bien, hay que decir es que no existe tal cosa como la historia del desarrollador o la del arquitecto del software, ni mucho menos la del Dueño del Producto, como en:

Historias de Poco o Ningún Valor

Como: Desarrollador

Quiero: matricular mi aplicación en Jenkins

Para: tener integración continua automatizada

Como: Arquitecto

Quiero: que las transacciones de la aplicación se tarden menos de 1 segundo

Para: poner en producción una solución de alto desempeño

Como: Analista de Pruebas

Quiero: automatizar los casos de prueba de la aplicación

Para: hacer pruebas de regresión de manera eficiente y efectiva

Como: Desarrollador

Quiero: implementar el procedimiento almacenado spAdicionarComentario

Para: que la aplicación tenga la capacidad de añadir comentarios a las entradas de blogs

Simplemente estas historias no deberían existir, de hecho, no son historias de usuario del todo, ningún usuario final las usa. Para el usuario no es importante, por ejemplo, donde se registran los errores de una aplicación, quizás ni le interese si se registran en alguna herramienta; tampoco es de valor conocer el número de inconformidades que tiene el código fuente frente a las buenas prácticas de programación. El usuario da por hecho que el equipo de desarrollo sabe, precisamente, construir productos de software y que le va a entregar el mejor posible y el de mayor valor.

Conclusiones Finales

Es un hecho, sin importar que tanto trabajemos como equipo de desarrollo en poner a punto el ambiente de pruebas, en tener los mejores servidores de integración continua disponibles, en usar las mejores prácticas de escritura de código fuente, en crear componentes reutilizables de alta calidad o procedimientos almacenados optimizados, el Bloguero de nuestro sistema de publicaciones no puede crear una entrada de blog con el reporte que genera el analizador de código estático de nuestro entorno de desarrollo al compilar el código fuente, ni con las docenas o cientos de procedimientos almacenados implementados sobre el motor de la base de datos, ni con la implementación del algoritmo Blowfish para encriptar las contraseñas.

Simplemente necesita de una interfaz de usuario que pueda utilizar para realizar todas sus operaciones.

Artículos Relacionados

El artículo donde presento las Historias de Usuario, a manera de introducción: Historias de Usuario: un nuevo orden en los requisitos del software, lo encuentran en:

http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

La primera parte de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 1. Lo encuentran en:

http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

La parte 2 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Independiente. Lo encuentran en:

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

La parte 3 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Negociable. Lo encuentran en:

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Referencias

• INVEST in Good Stories, and SMART Tasks:

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

• A User Story Primer, by Dean Leffingwell with Pete Behrens
• User Stories Applied, by Mike Cohn