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

“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

Sobre el cambio a ágil, temores infundados y penas frívolas

“Las masas humanas más peligrosas son aquellas en cuyas venas ha sido inyectado el veneno del miedo... del miedo al cambio.”

[Octavio Paz (1914-1998) Poeta y ensayista mexicano]

Todavía me encuentro con muchas personas que creen que ‘saltar al ecosistema ágil’ es como en las películas donde después de un ataque al gobierno, a veces por parte de alienígenas, a veces por parte de un gobierno enemigo, se dan a la búsqueda de los jóvenes y niños ‘genios’ de las universidades para que les resuelvan el misterio o le decodifiquen el mensaje cósmico. Lo bueno de esas historias es que siempre hay alguien que lo logra, a veces solo, a veces en compañía de alguien que para lograrlo viola un sinnúmero de leyes y comete muchos delitos en simultáneo. Otros son más facilistas y quieren usar la máquina del tiempo para ir al momento justo antes de que los modelos y enfoques tradicionales salieran a la luz pública y borrarlos de la historia. ¡Eso ya no es posible! Al menos no con una máquina.

Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas. También es cuestión de pensar un poco, de entender cuáles son los problemas mayores de las organizaciones y de las personas cuando intentan dar el salto a una nueva forma de ver e interpretar el mundo. Hay dolores superficiales, pero también hay enfermedades crónicas cuyos síntomas no son tan evidentes; para completar el cuadro clínico, hay penas que traspasan lo físico y se quedan en lo puramente espiritual, son difíciles de detectar y mucho más de erradicar, de sanar.

Conocer los miedos no solo de los interesados sino también de los patrocinadores, de quienes toman las decisiones, por ejemplo, es un buen comienzo. He encontrado que muchos de ellos/ellas temen no alcanzar el éxito en el proyecto de transformación y quienes no, imaginan o sospechan que pueden perder su lugar en la organización una vez se dé el cambio, asunto que está bastante alejado de la realidad a no ser que la persona no se adapte al nuevo entorno. En este último caso, tendríamos que preguntarnos si en realidad ya estamos en el punto que queremos.

Quizás entonces el entrenamiento y el soporte no ha sido el adecuado. A veces nos quedamos en las áreas de tecnología, cuando ‘Ágil’ es un asunto de toda la organización. El papel del Scrum Master es fundamental en este aspecto y no nos digamos mentiras (al menos no entre nosotros), los buenos Scrum Masters, los verdaderamente buenos, son difíciles de encontrar: ellas o ellos necesitan tener lo que llamamos comúnmente ‘don de gentes’ y también habilidades en lo ágil y también conocimiento técnico y todo esto junto es muy difícil de encontrar en una sola persona.

Algunas otras dificultades ya son ‘clásicas’: cambiar de un enfoque de ‘comando y control’ tradicional a un enfoque de autoorganización, al mejor estilo Scrum, es una tarea espinosa por no decir algo indecible. Este es un aspecto que impacta a los mandos medios de una compañía, por ejemplo, a la habitual oficina de proyectos o PMO que llaman en algunos entornos. Es precisamente en esta oficina donde comienza el cuestionamiento de lo que puede ser y no es: ¿entonces qué hago con todos los gerentes de proyecto que tengo? He escuchado decir. Encontrar una justificación válida para esto es arduo, imposible dirán algunos. Pero en general, todas las personas tienden a sentir miedo, por aquello de los equipos multifuncionales, donde el poder de la especialización de una persona se pierde. En este mismo orden de ideas, abandonar la falsa seguridad que dan los planes a mediano y, sobre todo, a largo plazo, que nunca han funcionado, en pro de planes a corto plazo, es algo que enciende las alarmas de más personas en la organización de las que quisiéramos contar. Miedo al cambio, natural por demás, es el tema de fondo.

Algunos otros obstáculos que he encontrado:

• Conseguir que las áreas del negocio y la alta dirección se involucren efectivamente
• Lograr la confianza y la autonomía que requieren los equipos ágiles y, sobre todo, el equipo de transformación
• Qué hacer con la jerarquía existente en las organizaciones donde el escalafón de las personas es algo ‘valioso’, es una pregunta que deberíamos responder al iniciar el cambio
• Crear, preparar y promover un equipo ‘colonizador’ o mejor aún, un equipo ‘conquistador’, punta de lanza, que se atreva a hacer las cosas, a ir más allá de donde nadie en la compañía ha llegado. Este es un asunto vital.
• Desaprender los hábitos del desarrollo en cascada, del comando y control, del esperar a que me digan qué hacer, del llenar documentos por llenar y todos esos aspectos que aborda el manifiesto ágil en toda su extensión. Sobre este asunto, los invito a leer: ‘Respuesta al cambio sobre seguir al plan: no planearás’, aquí mismo en este Gazafatonario.
• No intentar cambiar a las personas que no quieren cambiar. La naturaleza humana evade el cambio o se resiste a este cuando alguien intenta cambiarla. Cuando la dejan en paz, cambia por sí misma… ¡si quiere!
• Finalmente, pero no menos importante, cambiar la cultura de la compañía, en ágil todo es acerca de la cultura. Pero sobre esto pueden leer mi artículo: ‘Cultura ágil: ese oscuro objeto del deseo’, aquí mismo en mi Gazafatonario.
• Más allá de todo, recordar que ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Cambia... Hay un gran chance de que el nuevo día sea radiante.

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.

Ágil Necesita Ser Tanto Iterativo como Incremental

Noviembre 11 de 2014, por Mike Cohn

Este artículo se publicó originalmente en el boletín mensual de Mike Cohn. Si te gusta lo que estás leyendo, suscríbete para que este contenido te llegue directamente a tu buzón semanas antes de que sea publicado en el blog, aquí.

Scrum, como todos los procesos ágiles, es tanto iterativo como incremental. Puesto que estas palabras se usan frecuentemente sin definición, permítanme definirlas.

Un proceso iterativo es uno que permite progresar a través de refinamiento sucesivo. Un equipo de desarrollo hace un primer corte del sistema sabiendo que está incompleto o frágil en algunas áreas (quizás en muchas). El equipo luego refina iterativamente esas áreas hasta que el producto es satisfactorio. Con cada iteración, el software se mejora mediante la adición de mayor detalle.

Por ejemplo, en una primera iteración, una pantalla de búsqueda podría codificarse para soportar solamente el tipo más simple de búsqueda. La segunda iteración podría agregar criterios adicionales de búsqueda. Finalmente, una tercera iteración puede agregar manejo de errores.

Una buena analogía es la escultura. Primero, el escultor selecciona una piedra de un tamaño apropiado. A continuación, el escultor talla la forma general de la piedra. En este punto, uno quizás pueda distinguir la cabeza y el torso y hasta pueda descifrar que el trabajo finalizado será un cuerpo humano en vez de un pájaro. Luego, el escultor refina su trabajo adicionando detalles. Sin embargo, es poco probable que el escultor dé por completada un área hasta que el trabajo entero esté terminado.

Por su parte, un proceso incremental es uno en el que el software se construye y entrega por piezas. Cada pieza, o incremento, representa un subconjunto completo de funcionalidad. El incremento puede ser pequeño o grande, quizás algo que vaya desde una pantalla de ingreso al sistema hasta un conjunto altamente flexible de pantallas de administración de datos.

Cada incremento se codifica y se prueba completamente y la expectativa común es que el trabajo de una iteración no necesitará volver a revisarse. Un escultor incremental elegirá una parte de su trabajo y se enfocará completamente en esta hasta que esté finalizada. Él/ella puede seleccionar pequeños incrementos (primero la nariz, luego los ojos, después la boca y así sucesivamente) o incrementos grandes (cabeza, torso, piernas y luego los brazos). Sin embargo, independientemente del tamaño del incremento, el escultor incremental intentará finalizar el trabajo de ese incremento tan completamente como le sea posible.

Scrum y ágil usan un enfoque tanto incremental como iterativo. Iterativo en el sentido de que planean que el trabajo de una iteración sea mejorado en las iteraciones subsiguientes. Incremental porque el trabajo terminado se entrega durante todo el proyecto.

Para ilustrar mejor las diferencias entre iterativo e incremental, consideremos la construcción de un sitio Web pero no de manera incremental. Para hacer esto, el equipo construiría un poco de cada parte del sitio –manejo de perfiles, búsqueda, anuncios, etc. Luego el equipo revisaría todas las partes, mejorando cada una de ellas.

Más adelante el equipo revisaría todas las partes nuevamente, haciendo otras mejoras. En este enfoque puramente iterativo, se consigue mejorar un poco el sitio completo.

Ahora, consideremos desarrollar el mismo sitio con un proceso puramente incremental pero no iterativo. Si un sitio de citas fuera construido incrementalmente, el equipo construiría y perfeccionaría la administración de perfiles antes de empezar cualquier otra parte del sitio. El equipo luego construiría y perfeccionaría otra área, digamos las búsquedas, antes de moverse a una tercera área. Cada área funcional se perfeccionaría antes de iniciar el área siguiente.

Ni iterativo ni incremental son grandiosos por sí solos. Pero juntos –como están en Scrum– son fantásticos.

Nota del traductor (¡ese soy yo!):

Traducido del artículo original de Mike Cohn: ‘Agile Needs to Be Both Iterative and Incremental’, que pueden encontrar en este enlace:

http://www.mountaingoatsoftware.com/blog/agile-needs-to-be-both-iterative-and-incremental

Publicado con permiso del autor.