De historias de usuario, culturas y del arte de narrar historias

“Yo no sé muchas cosas, en verdad,

Digo tan solo lo que he visto.

Y he visto que la cuna del hombre

la mecen con cuentos,

que los gritos de angustia del hombre

los ahogan con cuentos,

que el llanto del hombre

lo taponan con cuentos.

Y que el miedo del hombre

ha inventado todos los cuentos…

Yo sé muy pocas cosas, es verdad,

pero me han dormido con todos los cuentos

y sé todos los cuentos ...”

[León Felipe, Aguaviva.]

La vida es una alegoría, los seres humanos no solo estamos configurados como cuerpos biológicos abastecidos de estímulos y pulsiones, pues nacemos en un entorno social y por tanto nos relacionamos, desde lo más esencial –lo familiar, hasta lo más universal, con nuestros semejantes. Pero además poseemos una visión personal para interpretar nuestra cotidianidad, tenemos ideales y pensamientos, emociones y aversiones que nos hacen actuar  de formas particulares al interpretar nuestra realidad.

En todo esto, la narración de historias juega un papel muy importante  en la construcción de conocimiento. La narrativa es una forma de caracterizar los fenómenos de la experiencia humana. Dice Ivar Jacobson en su libro Casos de Uso 2.0 que “la narración de historias permite a las culturas sobrevivir y progresar; es el camino más simple y más efectivo para pasar el conocimiento de una persona a otra. Es la mejor manera de comunicar lo que un sistema debe hacer y hacer que todo el mundo trabaje en el sistema sobre los mismos objetivos.” [1]

Las historias (de usuario) establecen una manera de organizar y comunicar experiencias. Las personas usan instintivamente la narración de historias para organizar un cúmulo de ideas que consideran disperso; además, gracias a ellas pueden organizar lo que saben acerca de su trabajo y de cómo lo hacen. Al narrar historias, las personas nos invitan de una forma u otra  a investigar sus pensamientos, sus sentimientos y sus intenciones. Finalmente, como oyentes y más tarde como lectores de las historias de usuario, adherimos a los acontecimientos, como una exploración de la experiencia de los usuarios, entendiéndolas mejor y de la forma más completa posible, pero sobre todo, comprendiendo su valor real.

Quienes transitamos a diario por el vasto universo del diseño y construcción de productos de software sabemos que es importante enfocarnos en el valor que estos prestarán a sus dueños, los usuarios, y a otros interesados. El mismo Jacobson dice que “solo se genera valor si el sistema se usa realmente; así, es mejor enfocarse en cómo se usará el sistema que en las largas listas de funciones o características que ofrecerá.” [2] Y agrega más adelante: “es fácil capturar y validar la completitud de las historias y estas, a su vez, facilitan filtrar las formas potenciales de usar el sistema que ofrezcan poco o ningún valor real a los usuarios. Este foco constante en el valor permite asegurar que cada entrega del sistema sea tan pequeña como sea posible, a la vez que tenga valor real para los usuarios del sistema y para los interesados que financian el desarrollo.” [3]

Cuenta las historias, no las escribas

En su libro “Fifty Quick Ideas to Improve your User Stories”, Gojko Adzic & David Evans [4], compilan una serie de conceptos sobre cómo mejorar nuestras historias de usuario o, mejor aun, sobre cómo mejorar el desempeño del equipo ágil usando la técnica de las historias de usuario. Me interesó mucho la primera de esas ideas, muy acorde a mi interés actual sobre las historias y la supervivencia de las culturas. Esta idea es precisamente la del título de esta sección: cuenta historias, no las escribas.

Uno de los errores más comunes de las personas que empiezan a usar prácticas ágiles es creer que las historias de usuario son requisitos livianos. Las historias de usuario no son requisitos, son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, el Equipo de Desarrollo y el Dueño de Producto, pero definitivamente no son requisitos. Este malentendido conduce a situaciones en que las historias sean recolectadas en herramientas de gestión de actividades, con muchos detalles escritos o proporcionados por representantes del negocio.

Nada más alejado de una buena práctica. Las historias de usuario implican un modelo totalmente diferente, Gojko y David lo llaman “requisitos por colaboración”, un modelo donde la transferencia de conocimiento vía documentos “pesados” se reemplaza por involucramiento y colaboración, al mejor estilo del Manifiesto Ágil. Ya sabemos que la conversación cara a cara es la forma más efectiva de comunicar información y que una buena discusión entre los interesados y el equipo ágil lleva a mejores preguntas/respuestas, opciones e ideas del producto. Cuando los requisitos se escriben, aun si los llamamos historias de usuario, estas discusiones nunca suceden y las mejores ideas se pierden para siempre. Tengo algo de experiencia en esto, pasé dos décadas escribiendo requisitos de software, todo tipo de requisitos, todo tipo de productos de software.

La recomendación es simple, avanzan Adzic y Evans en su libro: intenta contar historias o que te cuenten historias, en vez de escribirlas. Usa tarjetas físicas o un sistema de tiquetes electrónicos, pero solo como recordatorios de esa conversación que tendrás más adelante. No gastes mucho tiempo tratando de descifrar los detalles de las historias con anticipación. Compromete a los interesados del negocio e involucra a los miembros del equipo en una discusión, busca distintas perspectivas de la historia y explora opciones. Esta es la forma de acceder a los beneficios reales de trabajar con historias de usuario.

Beneficios clave de contar historias

Las discusiones permiten a los representantes del negocio, no solo explicar lo que quieren, sino también asegurarse de que los miembros del equipo entiendan esto correctamente. Uno de los mayores problemas en los modelos tradicionales son los malos entendidos entre los distintos roles en el equipo y entre los interesados, entre quienes existen niveles heterogéneos de conocimiento acerca de las necesidades de cada uno, complemento además del ya típico fenómeno del “teléfono roto” [5]. Es un hecho, explicar una historia cara a cara evita caer en vacíos de conocimiento sobre la historia.

El segundo beneficio, apuntan Adzic & Evans, es el análisis más rápido. Cuando el equipo completo se involucra en una discusión, los vacíos funcionales, las inconsistencias y los requisitos no claros se descubren más rápidamente que cuando una sola persona (léase Analista del Negocio o similar), escribe los detalles.

Pero el beneficio más importante de la comunicación cara a cara, comparada con el paso de información vía documentos, es que la primera produce mejores soluciones, mejores productos. Para ser capaz de construir buenas soluciones, las personas necesitan conocer los planes y las oportunidades del negocio, entender el dominio del problema, tener un conocimiento profundo de las restricciones técnicas estar al tanto de las nuevas tecnologías que potencialmente les puedan servir. Involucrar a un grupo de personas en el análisis desde diferentes perspectivas ayuda al equipo a beneficiarse del conocimiento compartido.

Como lograrlo

La excusa más común para llenarnos de documentación es la insistencia del negocio en la aprobación formal, las regulaciones legales o gubernamentales o las dependencias con terceros. Si es necesario “firmar” las historias hazlo a medida que las discutes. Es más, si el alcance final debe ser aprobado por varios interesados en el negocio, involúcralos en las reuniones de Refinamiento, días antes de la reunión de planificación del Sprint donde se van a construir las historias. En cualquier caso, el Dueño de Producto juega un papel muy importante en la consecución de tales aprobaciones. Es una de sus responsabilidades directas.

Como siempre, ensaya distintos acercamientos y en cada retrospectiva analiza como le fue a tu equipo. Como dice el refrán, la experiencia no se improvisa. Hasta allí el tema, recomiendo amplísimamente los libros que usé como referencia

Referencias

[1] [2] [3] Ivar Jacobson et all. Use Case 2.0. Ivar Jacobson International. 2011. Traducción de Luis Antonio Salazar y Carlos Mario Zapata.

[4] Gojko Adzic & David Evans, Fifty Quick Ideas to Improve your User Stories, © 2013 – 2014 Nueri Consulting LLP

[5] Conocido también en algunas culturas o regiones como el fenómeno o el juego del “teléfono descompuesto”

Para saber más de historias de usuario puedes leer mi serie de artículos en este mismo Gazafatonario:

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

http://goo.gl/iJvj7

Escribiendo Historias de Usuario Altamente Efectivas, Parte 1

http://goo.gl/NZv4vj

Escribiendo Historias de Usuario Altamente Efectivas, 2

http://goo.gl/e1DSVh

Escribiendo Historias de Usuario Altamente Efectivas, 3

http://goo.gl/eGHQQU

Escribiendo Historias de Usuario Altamente Efectivas, 4

http://goo.gl/f4sEi2

Antipatrones Scrum: definición de la estructura

Sobre ScrumButs, seres humanos y otros menesteres terrenales de lo Ágil

El cambio es difícil, aceptar el cambio es aún más difícil, pero cambiar una cultura organizacional, arraigada en la estructura de las organizaciones y en el ADN de las personas, es quizás la tarea más compleja que un ser humano, o un grupo de personas, pueden emprender. Pero los cambios son necesarios y con estos vienen los sinsabores de la toma de decisiones erróneas, las que, en el caso de los métodos de desarrollo de software, son el equivalente de errores en la adopción de prácticas y métodos nuevos para la organización.

Durante la transición al enfoque ágil de construcción de software, muchas veces las organizaciones y las personas encargadas del cambio en las organizaciones deciden no seguir la línea descrita por las guías, los expertos o las prácticas documentadas por la industria, y se apartan de ello simplemente para adecuar su “nueva” forma de trabajo a las antiguas costumbres, a lo que es conocido y que costó tanto (tiempo, dinero, personas, recursos) implementar y que de alguna manera ha funcionado en la organización.

El término ScrumBut (ScrumPero) se usa para referirnos a los cambios a Scrum que se hacen para ocultar disfunciones y problemas que un Scrum no modificado revela a la luz del contexto donde suceden los hechos. Un ejemplo típico, de algunos presentados en [1], es: “Usamos Scrum, pero no podemos construir una pieza de funcionalidad en un mes, así que nuestros Sprints tardan 6 semanas” (o más). En este ejemplo, El ScrumBut es el uso de sprints de 6 semanas debido a la inhabilidad de la organización para dividir los requisitos en historias de usuario (o cualquier otra pieza que se use para representar funcionalidad del software) lo suficientemente pequeñas y simples.

El término (ScrumBut) implica que el cambio al método Scrum se debió a problemas en la organización, en vez de a problemas con el propio método Scrum. Pero ojo, no todos los cambios al método Scrum se consideran ScrumButs. Se considera aceptable cambiar las prácticas de Scrum si los cambios se basan en una necesidad real y en un entendimiento profundo de los mecanismos que hacen que Scrum funcione. Este último asunto es lo que constituirá la parte de “Excepción” del antipatrón.

Personas y sus interacciones sobre el mismísimo proceso Scrum y las herramientas que proporciona

Estamos de acuerdo en que Ágil es más acerca de las personas y sus interacciones, la comunicación cara a cara y la cultura, que acerca de los procesos, las prácticas y las herramientas, aunque nunca debemos cansarnos de repetir esto. Sí, las prácticas de Scrum son importantes y nos proporcionan guías inteligentes que nos ayudan a mejorar nuestra productividad y la calidad de lo que hacemos, pero son los principios – la parte difícil – los que hacen que Ágil sea sostenible en el largo plazo y los que nos permiten maximizar los beneficios que el método nos ofrece.

Así que cuando decimos que una mala práctica, un ScrumBut, es este de los sprints demasiado extensos, no vamos a arremeter contra la práctica en sí, lo que nos interesa es ir a los principios ágiles, esos del mismísimo Manifiesto Ágil y mirar que podemos hacer. ¡Eureka! Hay un principio que dice: “Entregamos software funcional frecuentemente…” [2], esto es lo que nos interesa. La entrega de productos, de alto valor para el cliente/usuario, priorizado por este, es lo que nos va a permitir obtener una mejor y más objetiva retroalimentación del estado de las cosas, nos hablará del grado de satisfacción del usuario, de su felicidad y de la calidad de ese producto.

Y esta entrega de software debemos hacerla desde el inicio del proyecto y manera frecuente, ¿cómo nos suena ‘cada 2 semanas’? De esta forma, si nos equivocamos, lo hacemos rápido, en 2 semanas, y barato, mucho más económico que si hubiésemos invertido meses de trabajo y muchas personas en esa porción del producto y del proyecto. Si nos equivocamos, todavía hay tiempo para reaccionar, decidir sobre acciones que nos hagan volver al “camino correcto”, que mejoren el estado de salud del producto/proyecto y de todos los interesados en el mismo.

Estudio a fondo de un Antipatrón: la estructura y el contenido

Todo este preámbulo, necesario por demás, para llegar al meollo del asunto. Vamos a intentar definir una primera versión de Antipatrón con el ejemplo que hemos venido mencionando a lo largo de este estudio. Es precisamente lo que me interesa porque en todo este recorrido de consulta sobre el tema he encontrado que la gran mayoría de los autores sobre mencionan el antipatrón, el scrumbut o la práctica dañina, algunos dan un paso más y mencionan una o dos recomendaciones de como curar la enfermedad. Pero en general, todos se quedan en el camino, no van más allá de mencionar una lista de prácticas incorrectas. Ahora que recuerdo, eso mismo hice yo en el primer artículo (acercamiento) de esta serie sobre antipatrones Scrum [3].

Pero muchas veces ayuda conocer el porqué del por qué, el problema detrás del problema, la causa raíz y con ello en la superficie, es un poco más liviano encontrar el camino de salida. Así que vamos al fondo de las cosas. Hagamos un acercamiento más detallado a un antipatrón, mejor dicho, entremos al núcleo de una mala práctica común.

Nombre del Antipatrón: ‘Sprint demasiado extenso’

Recomendación de Scrum: Realizar sprints de 2 semanas (o menos). Más específicamente, para equipos de menos de 5 personas, sprints de 2 semanas están bien: si el equipo es de 5 personas o más, es posible hacer sprints de menos de 2 semanas. En definitiva, los sprints no deberían tardar más de 3 a 4 semanas. Este último lapso, quizás solo para equipos pequeños de 3 personas.

Contexto: Experimentación temprana con Scrum, legado Cascada de ciclos de producción extensos, clientes/usuarios reacios a participar en intervalos cortos.

Esta situación es bastante común cuando el equipo venía trabajando con Cascada o con RUP o WaterRUP o similares. También, cuando el equipo intenta hacer/entregar muchas funcionalidades o funcionalidades muy grandes o complejas, o cuando el equipo es muy pequeño (1 o 2 personas) y para entregar Valor extienden los sprints

Solución (este es el antipatrón): Establecer sprints de 4 semanas o aún más largos.

Consecuencias: en vez de un trabajo más extensos para los sprints, las tareas planeadas tienden a no finalizarse al final del sprint, posiblemente porque las primeras semanas no son usadas los suficientemente eficientes y se establecen tareas muy largas en los sprints. Disminuyendo consecuentemente el compromiso del equipo a entregar elementos al final del sprint. El ciclo de retroalimentación llega a ser tan extenso que parte del trabajo podría no llegar a necesitarse más.

La productividad no es la misma al inicio del sprint (normalmente más baja), que al final del mismo. Algo similar ocurre con el “paso sostenido” que debería mantener el equipo durante todo el proyecto: en este caso, al principio del sprint, los miembros del equipo inician con el ritmo que quisieran tener durante todo el sprint y, por extensión, durante todo el proyecto; sin embargo, hacia la segunda parte del sprint y sobre todo hacia el final del mismo, el equipo regularmente trabaja más de la cuenta, tratando de alcanzar el objetivo del sprint. Lamentablemente, muchas veces es demasiado tarde.

Excepciones: Si el equipo de desarrollo debe sincronizarse con trabajo externo que tiene un ritmo más lento (por ejemplo, desarrollo de hardware), sprints más prolongados podrían justificarse. En este caso, se debe prestar especial atención a la “Definición de Preparado”. [4]

Hasta allí esta versión. ¡Funciona para mí!

Terminemos con una sugerencia

Ya he dicho en otras ocasiones que debemos empezar con “Scrum al Natural”, Scrum orgánico si se quiere. Cuando sea hora de hacer alguna adaptación, motivada por el hábitat organizacional, debemos evaluar estos cambios a las prácticas Scrum en su contexto, con el fin de separar los cambios dañinos de los necesarios o benéficos requeridos por ese hábitat organizacional y evitar así una crisis mayúscula en el mediano o en el largo plazo.

Ágiles, nos vemos en la Red.

Referencias

[1] Un breve artículo: ‘ScrumButs and Modifying Scrum’, lo encuentran en

https://www.scrum.org/ScrumBut

[2] http://www.agilemanifesto.org/iso/es/principles.html.

El principio completo dice:

“Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.”

¡Nunca está de más darse una pasadita por el Manifiesto Ágil!

[3] http://goo.gl/tFAvlN

El primer artículo de esta serie sobre Antipatrones Ágiles/Scrum, donde hago una introducción al asunto que nos ocupa. La dirección completa es:

http://www.gazafatonarioit.com/2014/11/antipatrones-scrum-primer-acercamiento.html

[4] Un artículo sobre este asunto de la Definición de Preparado fue publicado hace poco por el amigo y colega Johnny Ordoñez, se los recomiendo ampliamente:

‘La Definición de “Ready” es tan importante como la Definición de “Done”’

Lo encuentran en: http://johnnyordonez.wordpress.com/2014/12/12/la-definicion-de-ready/

Antipatrones Scrum: primer acercamiento

“Scrum es como el ajedrez. O lo juegas como lo dictan sus reglas, o no lo juegas. Scrum y el ajedrez no fallan ni aciertan. O los juegas, o no.” Ken Schwaber [1]

Presentación, o de la relación que tiene Bruce Lee con un arquitecto de apellido Alexander, una banda de los cuatro, Chuck Norris y Kent Beck

Las llaman ‘malas prácticas’, a mí me gusta llamarlas ‘prácticas fuera de contexto’; en el entorno ágil, algunos incluso hablan con humor de ‘Scrum Norris’, refiriéndose a aquel actor de Hollywood, Chuck Norris, quien apareciera por primera vez en 1972 en una película del legendario Bruce Lee, La Furia del Dragón, y que se hiciera popular por allá en los años 80 con películas de acción como Ojo por Ojo, Perdidos en Acción y Fuerza Delta y donde, a pesar de la incesante acción, no sufría ni un rasguño, ni siquiera se espelucaba. Los más técnicos y aventajados penetran la barrera científica y las llaman ‘Antipatrones’. Pero para usar este último término, primero definamos qué es un patrón, en nuestro contexto.

Quizás todos recordamos los súperarchipopulares ‘patrones de diseño’ [2] de los también súperarchifamosos ‘banda de los cuatro’ (Gang of Four), compuesta por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, quienes a su vez basaron su investigación en el trabajo de un Arquitecto (no de software), Christopher Alexander, quien por allá a finales de los 70, dio origen al tema como un concepto arquitectónico. Lo curioso de este asunto es que no fueron Gamma y su banda quienes primero tomaron ese concepto de Alexander: fueron los mismísimos Kent Beck y Ward Cunningham quienes en 1987 comenzaron a experimentar con la idea de aplicar patrones a la programación de computadores y presentaron sus resultados en el OOPSLA de ese año.

Toda esta historia, que siempre me ha parecido fascinante, porque es en la que se basarán los antropólogos de la TI en el futuro para descubrir al resto del universo de donde proviene la inteligencia artificial: las máquinas que piensan, los robots que hablan mejor que los humanos y los computadores ópticos, toda esta historia, simplemente para entender que un ‘patrón’ es una solución reusable a un problema común y recurrente dentro de un contexto. Pero ojo, un patrón no es una solución terminada, en cambio, es una descripción de cómo solucionar un problema.

Finalmente, hay patrones de Análisis (Fowler), patrones de diseño (Gamma et all), patrones de programación (Beck), patrones de pruebas (Binder), etcétera. Por supuesto, están los patrones en los métodos y en las prácticas y en los procesos. Pero de todo esto hablaremos en otra oportunidad. Lo que me ocupa esta vez son precisamente los Antipatrones Ágiles, en general, y los de Scrum, en particular.

Antipatrones Scrum: una primerísima aproximación pragmática

Un Antipatrón es, entonces, la antítesis de una solución a un problema recurrente. En el caso de los métodos y prácticas (ágiles), son actividades, procedimientos o rutinas, usos o hábitos, que personas dentro de una organización o entorno adquieren o ejecutan, con la idea de que son la forma ‘correcta’ de hacer las cosas. Estas malas prácticas se dan por múltiples razones. Aquí algunas de las respuestas más frecuentes que escucho en mi trasegar ágil:

• Siempre lo hemos hecho así
• Nuestras condiciones son únicas, entonces debemos hacerlo de esta manera (¡la madre de todas las entelequias!)
• Hay temor al cambio (la más natural de todas estas especulaciones, el miedo es algo inherente al ser humano. Es quizás este miedo el que infunde los demás motivos expuestos aquí. No en vano León Felipe dice: “el miedo del hombre…ha inventado todos los cuentos.” [3])
• La teoría, lo que dicen los libros y los manuales (léase Guías) no nos aplica
• Tenemos regulaciones que nos impiden hacerlo de otra forma
• No hemos tenido entrenamiento ni acompañamiento (de expertos en la materia)

Quizás esta última sea la razón cardinal de que las organizaciones se desvíen de las prácticas propuestas en Scrum por distintos motivos y de que las implementaciones prácticas de Scrum rara vez sigan los ideales de los libros de texto y mucho menos de sus autores. Es probable que algunos de esos porqués estén bien respaldados y sean sensatos, como lo hemos abordado en algunos ambientes, sin embargo, la gran mayoría de las veces las organizaciones no alcanzan a distinguir netamente las secuelas que se derivan de tomar esas desviaciones y se sienten tentadas a ajustar, a ‘acomodar’ Scrum y otras prácticas ágiles para ellas.

He estado allí: muy tarde se dan cuenta estas organizaciones que han caído en un sinfín de malas prácticas o en unos hábitos inadecuados para las personas, para los equipos y para la organización misma. Los resultados infaustos empiezan a aparecer cuando tratamos de ir un poco más allá: ‘bueno, ya que hacemos Scrum, agreguemos TDD y refactoring’ o ‘ya que hemos gestionado dos o tres proyectos con Scrum, llevemos esto a nivel corporativo’. Personas quemadas, clientes/usuarios que no ven la diferencia con métodos anteriores (léase Cascada, WaterRUP, etc.) o modelos de calidad como CMMI, COBIT, PMI y familiares.

Ahora bien, es cierto que en un lapso de tiempo relativamente breve, desde el ascenso de los arquetipos, poéticos por demás, del Manifiesto Ágil, muchas organizaciones se han afiliado a alguna forma de trabajo ágil. Pero lo que realmente está sucediendo cuando alguien dice “somos ágiles”, es “estamos usando algunas prácticas o ideas de Scrum y de otros métodos o prácticas ágiles”, algo que se conoce ordinariamente como ScrumBut (en español, ScrumPero –algo así como: ‘sí, usamos Scrum pero…’, donde este ‘pero’, quiere decir muchas veces: no tenemos Dueño de Producto, o no hacemos reuniones diarias, o el Scrum Master es el mismo Arquitecto de software o el gerente del proyecto, o no tenemos ‘definición de terminado’, entre muchas otras cosas y, con frecuencia, un compuesto de varias de estas).

Primera lista no exhaustiva, incompleta, de antipatrones Scrum

Hasta aquí la perorata, a manera de introducción. Lo que sigue es una lista de esas prácticas fuera de contexto, o antipatrones.

1. “Nuestro Scrum Diario tarda 30 minutos o más, hablamos mucho de todo”, emparentado con “no hacemos Reunión Diaria porque no le vemos sentido”. Ya sé, tus tareas tardan 20, 30 o más horas y cada día que se reúnen, tus actividades siguen “en progreso”. Por eso no tiene sentido reunirse cada día.
2. “Hablamos con el Dueño de Producto cada 2 o 3 semanas, durante la reunión de planificación”
3. “Nuestro Sprint 0 es de nunca acabar, estamos detallando todos los requisitos”, también conocido como el ‘contraataque de la Cascada’
4. “No sabemos donde está el Backlog del Producto”, o del ‘extraño caso del backlog de producto misterioso’
5. “No tenemos definición de terminado”, familiar de “nuestro ‘trabajo en progreso’ es ilimitado”
6. “No hacemos retrospectiva porque todo funciona muy bien con Scrum” o “nuestras retrospectivas son una oda a la autolaceración”. Me sé muchas otras con nuestra reunión favorita de regresión y análisis. Una, a propósito de Scrum Norris: ‘Cuck Norris no necesita Revisiones ni Retrospectivas. No hay espacio para el mejoramiento en los procesos de Chuck Norris’.
7. “Nuestros Scrum Masters están en piloto automático”. A estos los ascendieron en esta década a zombis. ¡Estamos llenos de Scrum Masters zombis! Necesitamos un proyecto ‘Alice’ que acabe con esa disfunción.
8. “Sí, hacemos sprints de 2 semanas, pero no entregamos valor al negocio”. Estos son los del enfoque iterativo e insustancial. El producto resultante es una colcha de retazos
9. “Nuestros equipos son elásticos: sus miembros entran a y salen del equipo en cualquier momento del sprint y en cualquier sprint”
10. “En la organización cambiamos el modelo de gestión del PMI por Scrum, pero el resto del proceso lo dejamos tal cual estamos certificados CMMI”

Suplemento

1. “Nuestros Scrum Masters están asignados a 4, 9 y hasta 17 proyectos simultáneamente”, mejor conocido el Pulpo Ágil
2. Nuestros clientes aceptan que usemos Scrum pero los proyectos son tiempo fijo-costo fijo-alcance fijo y el cronograma lo debemos entregar el primer día”

Por ahora solo la lista, pero mi análisis irá mucho más allá. Cuál es el contexto donde típicamente ocurre la mala práctica, cuál es la recomendación de Scrum/Ágil para cada eliminar el antipatrón de la faz de la tierra (bueno, al menos, del entorno donde se presenta), cuáles son las consecuencias de insistir en el mal-uso de la práctica, cuál es la solución (al menos, parcial) y, quién sabe, quizás alguna que otra excepción en la que el uso del antipatrón se justifique. ¿Es esto último posible? Yo no lo sé de cierto, lo supongo.

Colofón

Finalmente, quiero referirme a la frase inicial que usé para abrir este primer incremento sobre el tema: tiene razón Schwaber al hacer la analogía de Scrum con el Ajedrez. Las reglas de este juego son pocas y bastante simples, sin embargo, las estrategias existentes para jugarlo son diversas. Y hay un momento en el juego de la ‘Torre’ y el ‘Alfil’, llamado el ‘juego medio’ por los estudiosos, que se parece mucho a cuando los equipos de construcción de software juegan al diseño y a la programación usando las maniobras de Scrum: es cuando se requiere de creatividad, innovación, anticipación; es cuando precisamente nos damos cuenta que el desarrollo de software, como el Ajedrez, es jugado por personas, no por procesos ni herramientas.

Volveré con más antipatrones… ¡pronto! Mientras tanto, cuéntame cuáles malas prácticas o antítesis de excelencia, te has encontrado al ingresar a este apasionante pero complejo universo del desarrollo de software con métodos y prácticas ágiles.

Referencias

[1] Blog de Ken Schwaber: abril 7 de 2011:

https://kenschwaber.wordpress.com/2011/04/07/scrum-fails/

[2] Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. ISBN 0-201-63361-2.

[3] Felipe Camino Galicia de la Rosa, conocido como León Felipe (Tábara, Zamora, 11 de abril de 1884 - Ciudad de México, 18 de septiembre de 1968), fue un poeta español. Este es su poema “Sé todos los cuentos”:

Yo no sé muchas cosas, es verdad.

Digo tan sólo lo que he visto.

Y he visto:

que la cuna del hombre la mecen con cuentos…

Que los gritos de angustia del hombre los ahogan con cuentos…

Que el llanto del hombre lo taponan con cuentos…

Que los huesos del hombre los entierran con cuentos…

Y que el miedo del hombre…

ha inventado todos los cuentos.

Yo sé muy pocas cosas, es verdad.

Pero me han dormido con todos los cuentos…

Y sé todos los cuentos.

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Ecosistema de Métodos y Prácticas Ágiles (Parcial)

El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “métodos y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de métodos y prácticas ágiles, según sus necesidades.

Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.

Pero, ¿cuáles son esos métodos y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, las metodologías más usadas, como Scrum, eXtreme Programming (XP), Kanban, Lean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story Mapping, Product Vision Board, User Persona, User Stories, TDD, BDD, para mencionar solo algunas.

Y lo más importante, ¿para qué sirve cada uno de estos especímenes ágiles? ¿Alguno de ellos es adecuado para el proyecto que inicio mañana? ¿Varios de estos? ¿Son complementarios? ¿Qué problemas puedo encontrar si elijo mal? Y en el fondo, ¿cuáles son las razones por las que debo permitir el nacimiento y expansión de un nuevo ecosistema aun si el actual me está rindiendo beneficios? Y hablando de utilidades, ¿cuáles puedo obtener al implementar la “agilidad” en mi Organización?

Finalmente, sabemos que los ecosistemas están gobernados principalmente por eventos estocásticos (azar), por las reacciones que estos eventos ocasionan en sus componentes y por las respuestas de los organismos a las condiciones que los rodean. ¿Cómo controlar estos eventos y sobrevivir en el intento? Una mirada Darwiniana nos ayudará a entender cómo, mediante la inspección y la adaptación, nos iremos adecuando a los cambios que ocurren en todo proceso de evolución y entenderemos que la cultura ágil es el siguiente paso en la evolución de la inteligencia.

Nota:

Esta fue la presentación que hice durante el marco de las VII Jornadas Latinoamericanas de Metodologías Ágiles - Ágiles 2014, en Medellín, Colombia. Del 23 al 25 de octubre de 2014.

Nivel: Principiante

Título: Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo?

Resumen:

Uno de los impedimentos más grandes a la hora de implementar Ágil se origina en el desconocimiento que tienen las personas sobre lo que harán a continuación. ¿Por cuál de los métodos empiezo? ¿Uno solo es suficiente? La respuesta corta a esta última pregunta es “no”. Entonces, ¿qué debo saber para dar el salto de aquí hasta ágil? ¿De qué me “agarro” para no caer en el abismo? Estos son los asuntos que abordaré en esta sesión introductoria.

Con definiciones simples y ejemplificadas, basado en hechos históricos de los cuales he sido protagonista, le contaré a la audiencia de qué se trata toda esta jerigonza ágil, a manera de Gazafatonario.

La presentación completa la pueden descargar aquí:

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo? de Luis Antonio Salazar Caraballo

#Agiles2014: Ágil es algo que eres, CMMI es algo que usas

ser ágil significa reemplazar la predictibilidad falsa por la eficiencia

Con una actualización debido al cambio de audiencia, presenté en #Agiles2014 mi disertación sobre Ágil y CMMI. Como en la versión 1.0, durante la SEPG LA 2014 en Manizales, mi asunto principal era que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización. Los líderes de los procesos actuales deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos como CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se habló en el resto de #Agiles2014.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Para descargar la presentación

Puedes descargar las memorias de esta conferencia de: http://goo.gl/rhNMcf

Por qué usar métodos + prácticas ágiles

Anualmente, la consultora VersionOne.com publica un estudio sobre el uso de metodologías y prácticas ágiles. Este año, el estudio llegó a su octava edición. El estudio dice, por ejemplo, que Scrum es el método más ampliamente usado en el ecosistema ágil y así ha sido en los últimos 8 años, mismos en los cuales se ha incrementado su uso desde un 40% hasta el 55% de este año. Además, otros sabores de Scrum, combinados con métodos o prácticas como XP y Kanban también son bastante usados. Es un hecho, Scrum está aquí para quedarse.

Fuente: VersionOne.com. 8th Annual State of Agile Survey

Pero quiero referirme es a las principales razones por las cuales se usa Ágil. El estudio dice en esta sección que los 3 motivos primordiales que dieron los participantes de la encuesta son:

• Acelera la salida del producto al mercado: 23%
• Maneja más fácilmente los cambios en las prioridades: 16% y
• Mejora la alineación del negocio y de la IT: 15%

Fuente: VersionOne.com. 8th Annual State of Agile Survey

El 75% de los encuestados considera que es muy importante o de la más alta importancia el que los métodos ágiles aceleren la salida del producto al mercado. Este es el principal beneficio de usar prácticas y metodologías ágiles. Las salidas “tempranas” se logran construyendo el producto de manera orgánica, en iteraciones cortas de 4 semanas o menos, con preferencia al tiempo más corto posible. Y si bien es cierto que es posible no salir a producción al final de cada iteración, siempre debemos planear para que haya entregas a Operación cada muy pocas iteraciones.

Los equipos ágiles no congelan las prioridades ni las firman con sangre. Es el usuario (por ejemplo, el Dueño de Producto en Scrum), quien establece qué quiere ver primero y qué quiere ver más adelante. En consistencia con el aspecto anterior, es el usuario quien tiene la última palabra en el orden de prioridad conque el mercado llega al mercado o a los usuarios finales. Se trata además, de software con valor, recordemos que en Ágil todo es acerca de entrega de valor al negocio.

En ese mismo orden de ideas, la alineación de la IT con los objetivos del negocio siempre ha sido uno de los pilares de los métodos ágiles, de hecho, tiene sus cimientos en aquel valor del Manifiesto Ágil de Colaboración con el cliente sobre la negociación contractual. Recordemos también que los desarrolladores y el negocio trabajamos juntos cotidianamente durante todo el proyecto, o así reza uno de los principios del Manifiesto. El 65% de los encuestados respondió que esta razón es muy importante o de la más alta importancia para ellos a la hora de hace uso de las metodologías ágiles.

El estudio completo lo encuentran en versionone.com.