Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Scrum Diario. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Scrum Diario. Mostrar todas las entradas

sábado, julio 30, 2016

Un vistazo a la guía de Scrum

¿Hace cuánto leíste por última vez la guía de Scrum? Es bien sabido que a medida que tu experiencia y conocimientos crecen, tu forma de ver (leer) algo cambia respecto a la vez anterior. Quizás aprendas algo más, quizás seas capaz de visualizar o entender algo que antes no habías percibido o entendido.

Aprovechando la revisión de la que fue objeto la guía por parte de sus autores y de que había que traducir esa actualización, realicé una revisión exhaustiva tanto de la versión en inglés como de la versión en español en la que tuve la oportunidad de trabajar por primera vez en 2013. (Para conocer los cambios introducidos a la guía, ve a: http://www.gazafatonarioit.com/2016/07/revision-la-guia-de-scrum.html)

Con tres años más de experiencia y conocimiento en Scrum y temas relacionados, me tomé la libertad de actualizar la Gramática y redacción del documento y también algunos asuntos de fondo que me hacían ruido desde hacía mucho tiempo respecto a la versión original de la guía en inglés.

Con todo esto, aproveché también para “repasar” lo que dice la guía, para mirarla más a fondo y decidí traer aquí una lista, arbitraria por demás, pero de todo mi gusto, de algunos puntos que quiero resaltar. Son los siguientes:
“Scrum no es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas”.
Es impresionante la cantidad de personas, equipos y organizaciones que solo “aprenden” o quieren aprender Scrum, como si con eso fuera suficiente para hacer todo el trabajado que se les viene por delante. La lista de proceso, técnicas, marcos de trabajo y prácticas que podemos y deberíamos usar con Scrum es extensísima, no voy a elaborarla aquí, pero lo que sí es cierto, lamentándolo mucho por quienes no lo han visto, es que Scrum solo no es suficiente.
“Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar”.
Scrum se basa en la teoría empírica  de control de procesos. Esto quiere decir básicamente que aprendemos de la experiencia. Scrum nos permite visualizar la eficacia las prácticas que usamos las personas, los equipos y las organizaciones y nos permite inspeccionarlas continuamente y adaptarlas y adaptarnos de acuerdo con los distintos escenarios circundantes.
“El Dueño de Producto es la única persona responsable de gestionar la Lista del Producto”.
Todavía me encuentro con muchos equipos y organizaciones que no terminan de integrar al negocio, vía el Dueño de Producto, en sus equipos. Y muchos menos son los Dueños de Producto que realmente actúan como tal. El muy comentado pero pocas veces entendido “backlog” de producto sigue siendo gestionado por el equipo y muchas veces solo por el Scrum Master o por alguien más que no es ninguno de los roles propuestos en la guía.
“El Scrum Master es el responsable de asegurar que Scrum se entienda y se adopte. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum”.
Usar Scrum no nos hace ágiles, eso lo tenemos claro muchos. Pero muchos no tienen claro que si vamos a usar Scrum como marco de trabajo ágil, debemos ajustarnos a las reglas enumeradas en la guía. Estas reglas condensan la experiencia de muchos años de trabajo, sobre todo en proyectos de software, de los autores y de muchos otros en la industria. Conjuguemos esta observación con la del primer punto más arriba.
“La Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint de un mes. Para Sprints más cortos el evento es usualmente más corto”.
En las versiones anteriores es español aquí decía que el tiempo de las reuniones era proporcional a estas ocho horas para sprints más cortos. En ninguna parte de la guía original en inglés dice así, de tal forma que la actualicé en este sentido.
“Al finalizar la Planificación del Sprint, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”.
¿Cuántos de los equipos en los que has trabajado, en los que eres Scrum Master, miembro del Equipo o Dueño de Producto, hacen esto? De hecho, muchos quieren terminar lo más rápido posible la planificación para ponerse a trabajar pero nadie es capaz de explicar cómo van a trabajar para lograr la meta trazada del Sprint.
“El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas”.
Es más, muchas veces los equipos no establecen un objetivo más allá de aquel que indica el número de historias de usuario a construir en el sprint. La meta del Sprint debería ser algo más de Valor para el Dueño de Producto y, por ende, para el negocio. Dejaré este asunto de la meta del sprint para otro artículo pero además de pensar en las características o funcionalidades a implementar siempre es bueno pensar en las razones para llevar a cabo la iteración. Bien sabemos que metas efectivas nos sirven para probar o demostrar que nuestras ideas funcionan, para fomentar el trabajo en equipo, para reducir o eliminar un riesgo específico o para proporcionar mayor valor entregado al negocio.
 “El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint”.
La expresión clave aquí es “a menudo”. Hacer otras cosas después de la reunión diaria puede hacernos perder foco y, por consiguiente, productividad y puede alejarnos de la consecución del objetivo del sprint. Por ejemplo, en la reunión diaria no hablamos de las soluciones a los impedimentos, entonces es buena idea tener reuniones específicas sobre estos asuntos justo después de aquella.
“El Scrum Master se asegura de que se cumpla la regla de que solo los miembros del Equipo de Desarrollo participan en el Scrum Diario”.
Sigo viendo mucho de comando y control en la reunión diaria. ¡El seguimiento diario, dicen algunos! Esta es una reunión de coordinación, de planificación, es precisamente “una reunión clave de inspección y adaptación”. Cualquier otra cosa que se requiera hacer con el equipo, debe ser en otra reunión especial, no en esta.
“Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint. Basándose en esto y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor”.
La Revisión de Sprint no es solo para hacer la demostración del incremento de producto terminado. Y puesto que a esta reunión asisten o pueden asistir interesados clave en el producto, es una oportunidad única para discutir lo que viene a continuación en el proyecto.
“Una Lista de Producto nunca está completa. Mientras el producto exista, su Lista de Producto también existe”.
“Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente”. ¿Hace falta decir algo más?
“Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor”.
El valor para el negocio. Noten además que hablamos de “los elementos de la lista”, no son solo historias de usuario, como muchos erróneamente creen y manifiestan.
“Scrum no reconoce subequipos en los equipos de desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla”.
No existe tal cosa como “ellos y nosotros”, somos un único equipo indivisible, somos una unidad morfológica (orgánica) y funcional y actuamos como tal. Valoramos las habilidades y fortalezas de cada uno de los miembros de esta unidad, pero hacia el mundo exterior somos El Equipo.


Y bueno, como dice mi amigo y colega Jorge Abad, hasta aquí estas reflexiones, viscerales por demás, sobre la guía de Scrum. Los invito a que la descarguen y vuelvan a leerla y a que nos cuenten en el foro cuáles son sus puntos favoritos de la guía, con cuál no están de acuerdo, cuál cambiarían, etcétera.

También pueden descargar la guía de:

Guía de Scrum en español

jueves, enero 14, 2016

Nexus, el exoesqueleto de desarrollo a escala con Scrum


Scrum es un marco de trabajo para desarrollar sistemas complejos. Como dice la Guía Oficial, es liviano, fácil de entender, pero quizás, después de un tiempo, con el acompañamiento adecuado, hayas sido capaz de llegar a dominarlo y tú y tu organización se encuentren en el camino de las entregas frecuentes de software con valor, del mejoramiento continuo vía retrospectivas, con equipos autoorganizados, donde las decisiones frecuentes de adaptación se basan en el conocimiento ganado vía la inspección y la experiencia. Después de todo, la autoorganización y el empirismo constituyen la doble hélice del DNA de Scrum.
Pero ¿cómo ha sido tu experiencia al querer dar el siguiente paso: escalar Scrum? Quizás has intentado SAFe, LeSS o el soberbio modelo de Spotify, para mencionar solo algunos de los ejemplares que prometen llevar con éxito la agilidad a toda la organización. ¿Cómo ha sido tu experiencia al intentar que múltiples equipos trabajen en un producto? O Quizás múltiples equipos trabajando en productos individuales o en una suite de productos integrados. ¿Qué tal toda la organización tratando de adoptar Scrum y otras prácticas ágiles? ¿Acaso has intentado una transformación organizacional de 180º hacia Ágil? Una que sea sostenible, es decir, un cambio que sea capaz de conservarse y reproducirse sin necesidad de apoyo o intervención externa.
Nexus™ – Un Exoesqueleto para 3-9 Equipos Scrum.
De eso se trata Nexus, “un marco de trabajo que consiste en roles, eventos, artefactos y técnicas que vinculan y entrelazan el trabajo de aproximadamente tres a nueve equipos de Scrum que trabajan en una sola Lista de Producto para construir un Incremento Integrado que cumpla un objetivo”.
Para entender Nexus, primero debemos entender de qué se trata el desarrollo de software a escala con Scrum: cualquier implementación de Scrum donde múltiples Equipos Scrum construyen un producto o un conjunto de características de un producto en uno o más Sprints o, también, cualquier implementación de Scrum donde múltiples Equipos Scrum construyen múltiples productos relacionados o conjuntos de características de productos en uno o más Sprints.
En el caso de múltiples equipos construyendo un producto, este tiene una Lista de Producto manejada por un Dueño de Producto y los equipos en conjunto crean un Incremento Integrado en cada Sprint por lo menos. Este Incremento se convierte en el foco y objetivo de todos los equipos dejando de lado el énfasis en el incremento individual que produce cada equipo en un Sprint.
Es precisamente la integración del trabajo (o la ausencia de esta), uno de los mayores obstáculos que encuentran las organizaciones al escalar Scrum o al tratar de implementar Scrum a gran escala. Para sobrepasar este impedimento, Nexus aumenta Scrum de manera orgánica, es el siguiente paso natural. Si has entendido y estás practicando Scrum, Nexus te parecerá más que familiar. Este nuevo marco de trabajo adiciona un nuevo rol, el Equipo de Integración Nexus, responsable de asegurar que se produzca el Incremento Integrado, es decir,  el trabajo combinado de un Nexus que adhiere a la definición de “Terminado”.
Además, Nexus adiciona un conjunto de eventos que, en general, extienden los eventos de Scrum o los reemplazan, lo mismo que un artefacto adicional:
Construido sobre los principios, valores y fundamentos de Scrum, el marco de trabajo Nexus:
  • Crea rutas de comunicación
  • Extiende y profundiza los mecanismos de inspección y adaptación
  • Fomenta la transparencia continuada
  • Depende de la inteligencia hacia arriba, en este caso, del Equipo de Integración Nexus hacia los equipos individuales que forman el Nexus.
Con mis grandes amigos Leonardo Agudelo y Jorge Abad tuve la oportunidad de traducir al español la Guía de Nexus, la misma que ya está publicada y disponible para descarga inmediata en:
Nota: este artículo se publicó por primera vez en diciembre de 2015 en Pulse de LinkedIn:
https://www.linkedin.com/pulse/nexus-el-exoesqueleto-de-desarrollo-escala-con-scrum-luis-antonio
------------------------------
Actualización 20150406:
Esta noche estuve hablando de Nexus con amigos de la Comunidad Ágiles Colombia en Medellín. Aquí está la presentación:

------------------------------
Actualización 20151007 (Ágiles 2016):
Hoy estuve hablando de Nexus con amigos de la Comunidad Ágiles Latinoamérica en Quito, durante las Jornadas Ágiles Latinoaméricanas - Ágiles 2016, una experiencia gratificante. 
Aquí está la presentación actualizada:


jueves, junio 11, 2015

Mañana empiezo un nuevo proyecto: ¿qué metodología ágil me pongo? (V1.6.0)


El ecosistema ágil está formado por un conjunto de organismos “vivos” llamados “marcos de trabajo 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 marcos de trabajo 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 marcos de trabajo y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, los marcos de trabajo más usados, como ScrumeXtreme Programming (XP), KanbanLean; y algunas de las técnicas necesarias en un primer esfuerzo por implementar la Cultura Ágil en una Organización: User Story MappingProduct Vision BoardUser PersonaUser 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 presentación, actualizada, la hice durante el Primer Agile Open Space en la ciudad de Pasto, Colombia, el 6 de junio de 2015.
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 marcos de trabajo o prácticas 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.

Esta es la presentación completa y el enlace para descargar:


jueves, noviembre 27, 2014

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.


martes, julio 01, 2014

Respuesta al cambio sobre seguir un plan: ¡no planearás!

“El plan no es nada, la planificación lo es todo”. Eisenhower
Imagen cortesía de Vichaya Kiatying-Angs / FreeDigitalPhotos.net
Basado en hechos históricos

Natalia es gerente de proyectos de una importante compañía proveedora de servicios de tecnología. Es la encargada de la operación en uno de los clientes más grandes de la empresa: un conglomerado de telefonía móvil. Hacia el final de esta mañana la llamó el director de mercadeo de esa organización bastante alarmado:

         - Natalia, hablas con Juan Pérez de Móviles del Sur* - ¿tienes un momento?
         - Hola Juan, ¿en qué te puedo ayudar?

Lo que siguió fue toda una perorata que inquietó a Natalia. El cliente le contó cómo durante la mañana se enteró de la Promoción Rumbo al Mundial Brasil 2014 que su más encarnizado competidor sacaría a la luz la noche de ese día. Pérez sabía que de no responder efectiva y rápidamente no solo dejaría de ganar cientos o miles de clientes, sino que perdería muchos otros, lo que podría golpear severamente sus márgenes de ganancia durante el primer semestre del año. Para suerte de Natalia, el señor Pérez había hecho su tarea, ya sabía que debía actualizar las herramientas de software de mercadeo y ventas para soportar una promoción agresiva que debería estar al aire en la TV y en las redes sociales dos horas antes que la de su competidor.

Mientras Pérez hablaba, Natalia revisaba rápidamente el proceso de control de cambio de la compañía y concluyó que podría entregarle una propuesta de trabajo que incluyera el impacto de la actualización del software en costo y presupuesto a su cliente pero solo hasta el día siguiente. Era inaudito, mientras Juan Pérez estaba buscando una respuesta ágil y eficiente que concluyera con un resultado de valor en las próximas 8 horas, Natalia se enfrentaba a la disyuntiva de seguir un proceso clásico de estimación a priori y modificación del plan de trabajo, previo análisis de impacto y de costos, que redundaría en una pérdida tanto para su compañía como para la de su cliente, o simplemente responderle firme y positivamente que cumpliría la meta establecida para las siguientes horas.

El Manifiesto por el Desarrollo Ágil de Software (aka: la solución del proveedor)

Por suerte para Natalia, ella también había hecho su tarea. En los últimos tiempos había empezado un proceso de transformación en sus equipos que incluía una forma de ver el mundo de manera distinta a como lo venían haciendo en la compañía. Se trataba de todo un ecosistema basado en una cadena de valores y principios que rompían con los esquemas tradicionales de hacer software. Todo empezaba con el así llamado Manifiesto por el Desarrollo Ágil de Software o, simplemente, Manifiesto Ágil, el cual le daría la clave para ganar ese día:

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.
El Manifiesto Ágil por el Desarrollo de Software. Fuente: http://www.agilemanifesto.org/iso/es.

Este pedazo de esfuerzo mental, fruto de la colaboración de 17 personajes reconocidos en la industria del software en 2001, serviría a Natalia como pilar fundamental para encontrar una solución de valor para su cliente. Los Valores y Principios Ágiles enfatizan en la importancia de colaboración e interacción en el desarrollo de software y, de otro lado, el trabajo creativo involucra comúnmente alguna forma de colaboración y puede entenderse como una interacción entre un individuo y un contexto sociocultural.

Los proyectos tradicionales están plagados de equipos conducidos-por-gerentes, organizados en una estructura jerárquica con múltiples capas de autoridad. Esta gerencia es del estilo de “comando y control” y los roles se basan en tareas funcionales que, en el caso del software, son los programadores, los diseñadores, los analistas, etc. El trabajo se delega a los miembros del equipo por sus jefes. Las prácticas en estos equipos incluyen copiosa documentación, especificaciones previas y planeación detallada. Las líneas de comunicación son indirectas entre las distintas capas de la jerarquía organizacional y el empoderamiento es algo invisible para la mayoría de los participantes, lo mismo que el estado general del proyecto.
Imagen cortesía de Salvatore Vuono / FreeDigitalPhotos.net
El primero de los valores “Individuos y sus interacciones”, le indicaba a Natalia que necesitaba un equipo cooperativo, multi-funcional y auto-suficiente, experto, altamente productivo y creativo que se comunicara con su cliente y trabajara con él el resto de la tarde, no solo en la extracción de conocimiento típica de los proyectos actuales, sino en todo el ciclo de producción que le permitiera a Móviles del Sur poner en funcionamiento una solución automatizada que soportara su ambicioso programa de retención y captura de clientes con motivo del evento mundialista de los próximos meses. Recordó así uno de los Principios que acompañaban a esos valores ágiles:

Principio Ágil # 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

Natalia sabía que la filosofía ágil tiene la habilidad de amplificar la productividad de los equipos de software hasta una escala de gran magnitud, a través del empoderamiento de las personas, fomentando un entorno orientado-al-equipo y enfocándose en la transparencia del proyecto y en los resultados. Estos proyectos pasaron de ser dirigidos-por-el-plan a estar enfocados en el producto, uno priorizado por y de valor para el cliente. Estos equipos se identifican a sí mismos como una unidad social dentro de la organización de la cual hacen parte y a quienes se les confía la ejecución del trabajo y se les proporciona el entorno y el apoyo que necesitan, para mantenerlos motivados, como invoca otro de los principios del Manifiesto Ágil, y para aumentar su apego emocional a la empresa.

Si bien se trata de un conjunto de Valores, el último de estos, pero no por eso menos importante, no devalúa la planificación, en la práctica solo se adhiere al plan. La planificación es valiosa en sí misma; y dado que el plan nos asiste en la tarea de reconocer cuándo las cosas han cambiado, también nos ayuda a entender las implicaciones del cambio, cómo tenemos que ajustarnos y cuál es el costo probable. Lo importante es que, a medida que hacemos planes, entendamos que el plan puede cambiar. La planificación es una actividad continua que incluye:
  • Reuniones de planificación de iteración
  • Reuniones diarias
  • Reuniones de revisión
  • Retrospectivas
  • Evaluación de riesgos

Planificación clásica versus planificación ágil y un mito que se niega a desaparecer
Imagen cortesía de hin255 / FreeDigitalPhotos.net
Cada una de esas ceremonias sirve para no solo para planear sino también para inspeccionar el estado del proyecto y crear mecanismos de adaptación en caso de ser necesario. El grueso de los practicantes de la industria y quienes la miran desde los tejados, cree que los equipos ágiles son desorganizados, informales, que no documentan y sobre todo que no planean. Todo eso se debe en parte a la mala lectura que le dan al mismísimo Manifiesto Ágil. Pero no es así. Contrario a lo que ocurre en los modelos tradicionales de planificación, donde se planea al comienzo, se elaboran planes de 2, 3 o más niveles, y se hace seguimiento a ese plan durante el resto del proyecto, un seguimiento que raya en el acoso, los equipos ágiles planean todos los días.

En parte eso se debe a que los equipos ágiles saben que los cambios hacen parte inherente, son constituyente primario del ADN, del ciclo de vida del software. Los cambios pueden ocurrir en cualquier momento, desde las etapas iniciales del proyecto, aun cuando apenas se están conociendo las necesidades del usuario, hasta las fases tardías del proyecto, quizás cuando estamos a punto de salir a producción. Si son bien manejados, los cambios brindan muchos beneficios a los usuarios, el primero de ellos, ventaja competitiva. Los cambios son una herramienta invaluable para crear productos inmejorables. Era precisamente lo que necesitaba Juan Pérez ese día. Otro de los principios ágiles llevó a Natalia a esa conclusión:

Principio Ágil # 2: Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

En cambio, los enfoques tradicionales de gerencia de proyectos presentan los cambios como un monstruo con el que hay luchar a sangre y fuego. Los procedimientos rigurosos de control de cambio, típicos de estos enfoques, causan la pérdida de oportunidad que los clientes tienen para ganar más mercado y para crear mejores productos. En general, a medida que el tiempo avanza, la habilidad de hacer cambios disminuye y cuesta más. Esto es lo que enfrentan los procesos ágiles, aunque sin dejar de planear. Los métodos ágiles promueven planes más livianos y de alto nivel a largo plazo, mientras que atienden la elaboración de agendas bien detalladas a corto plazo, las de la iteración actual, que solo tarda unos pocos días o muy pocas semanas. En Scrum, por ejemplo, las iteraciones tardan máximo 4 semanas y con frecuencia mucho menos que eso.

Al principio de los proyectos ágiles se planean las entregas o salidas a producción tempranas, beneficio primario que nos traen los procesos ágiles. Estas salidas a producción pueden ser cada tres meses, pero hoy contamos con la tecnología y plataformas lo suficientemente maduras como para hacer continuous delivery o entregas continuas. Amazon, por ejemplo, la vendedora al detal más grande del mundo, sale a producción cada 11,6 segundos, algo absolutamente asombroso si tenemos en cuenta la cantidad de clientes recurrentes simultáneos que tiene su sitio Web cada segundo. Natalia sabía todo eso, entonces no dudó que podía tener un producto funcionando para antes de las 8 de la noche de ese día, meta principal de su cliente.

Resultado final

Mientras hacia un recorrido por los acontecimientos de la hora, Natalia convocó a un equipo idóneo, uno que sabía capaz de elaborar un producto que generara resonancia no solo en su cliente sino en sus usuarios, uno que haga que la gente experimente distintas reacciones de gozo al usarlo, sin hablar de los ingresos en que redundaría su uso. No se trataba solo de actualizar un pedazo de software existente, sino de producir algo no ordinario que tuviera la capacidad de atraer a una audiencia cada vez mayor. Otro de los principios ágiles fue el último consejo que le dio al equipo antes de despedirlo hacia lo que seguramente sería un éxito total:

Principio Ágil # 10: La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

¿Quieres saber más?

Sobre otros mitos y leyendas relacionadas con los métodos ágiles puedes leer:
Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum: http://goo.gl/PIfZpx

Sobre planificación ágil, estos 2 artículos:
Planificación del Sprint: el primer paso para producir el máximo efecto: http://goo.gl/9TO7FF
Compendio Sobre el Scrum Diario: http://goo.gl/GG7id1

Sobre cultura ágil y transformación a ágil, estos 2 artículos:
Cultura ágil: ese oscuro objeto del deseo: http://goo.gl/IuJIlY
Sí, usted está listo para implementar un proyecto ágil: http://goo.gl/19Hcnz