Buscar en Gazafatonario IT

jueves, mayo 08, 2014

Cultura Ágil, ese oscuro objeto del deseo

“El ingeniero de software aficionado siempre está a la búsqueda de algo mágico, algún método o herramienta sensacional que prometa convertir el desarrollo de software en algo trivial. Está en el ingeniero de software profesional saber que no existe tal panacea”.

[Grady Booch, Object-Oriented Analysis and Design]
Cultura Ágil, ese oscuro objeto del deseo
Este artículo fue publicado inicialmente en http://goo.gl/IuJIlY
Vivimos en una era de ofertas pero también de riesgo. ¿Qué tipo de productos queremos que usen nuestros clientes? La filosofía ágil está modificando a pasos aumentados el statu quo del desarrollo del software, con nosotros a bordo o sin nuestra participación. El interrogante es cómo y hasta qué punto seremos capaces de dar el salto hacia lo que ya está aquí: la cultura ágil.

El pronóstico que genera más suspicacia alrededor de la transformación hacia ágil es que va a dividir la comunidad de desarrolladores entre quienes tendremos éxito y quienes no lo tendrán, entre personas felices y personas desventuradas, y entre personas que tendrán una vida (o que volverán a tenerla) y personas que no; y que también fragmentará la gama de usuarios del software entre personas satisfechas y personas insatisfechas: será una segregación ágil. Este movimiento ágil que vive la ingeniería de software brinda la promesa de mejorar las vidas de quienes trasegamos por sus laberintos, pero también entraña la amenaza de segregarnos.
¿Pero a qué viene esta evolución hacia ágil? Primero, se trata de abandonar esa visión microscópica ampliamente difundida de la gestión de proyectos clásica de “comando y control”, enfocada en el cumplimiento de tiempos e hitos intermedios que muchas veces no tienen nada que ver con el producto y mucho menos con el cliente, de proyectos que solo son “vistos” a través de herramientas y procesos predictivos, y comenzar a mirarlos con los ojos del cliente, con el lente del Valor del producto para el negocio, y de las entregas continuas de producto con calidad.
Quienes llevamos ya algún tiempo construyendo software, cargamos en nuestro ADN aquel precepto de Deming de que la calidad de los productos depende en gran medida de la calidad de los procesos que se usan para crear y mantener esos productos. También llevamos a cuesta modelos de gestión de proyectos tipo “Comando y Control” y modelos de ejecución de procesos prescriptivos como CMMI, PMI, COBIT y los incontables ISO numeral.
Ninguno de estos modelos habla de las personas y sus interacciones ni de la trama del producto, ni del impacto que el producto debe generar en quien lo usa y de lo confortable y apoyado que debe sentirse este usuario con ese producto; y tampoco habla de la calidad y de la naturaleza del comportamiento de las personas que construimos el producto. De esto también se trata la cultura ágil.
En la práctica, es posible combinar métodos ágiles con Arquitecturas Orientadas a Objeto o Patrones de Diseño y con Principios de Ingeniería como Historias de Usuario o Casos de Uso 2.0 y Test Driven Development (TDD) o Behavior Driven Development (BDD), para crear productos grandiosos, que tengan “alma”, que tengan argumento, es decir, que sean significativos para el usuario, que le digan algo y que en algún momento del tiempo cambien su estilo de vida.
Ahora bien, estos métodos ágiles, con Scrum a la cabeza, 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 deberían 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.
Esto se puede lograr poniendo en práctica algunos de los principios de Lean Software Development, o simplemente Lean. Estos principios, originados en el enfoque de manufactura lean de Toyota, constituyen una filosofía de gestión de procesos ampliamente aceptada en la comunidad ágil y buscan eliminar las entregas tardías tan comunes hoy en los proyectos de software, lo mismo que eliminar cualquier desperdicio, como código y funcionalidad innecesarios, requisitos poco claros, pruebas insuficientes que conducen a una repetición del proceso, al igual que la burocracia y la lentitud en la comunicación interna.
Ser ágil también es aceptar que los proyectos complejos (léase proyectos de TI) están sujetos a cambios, a redefinición de alcance y a oscilaciones en la priorización de los requisitos. Para ser ágiles debemos planificar para el cambio, trabajando a la sombra de un proceso que entienda esto. Ágil también nos puede proporcionar “estimaciones” de costo, o “estimaciones” de tiempo, pero los métodos ágiles son más honestos y nos abastecen con entregables de mejor y mayor valor mucho antes que un proceso “No-ágil”. En breve, ser ágil quiere decir reemplazar la predictibilidad falsa por la eficiencia.
Ser ágil también es acerca del equipo. Los equipos ágiles nos enfocamos en validar continuamente nuestras hipótesis y generar valor lo antes posible. Sabemos que esta es la base para equipos de alto rendimiento que enfrentan alta incertidumbre, como la presente en los proyectos de software. En estos equipos cambiamos la planificación basada en especialidades por un enfoque en la propagación de conocimientos, de experiencia. Además, en los equipos ágiles invocamos continuamente energías innovadoras para encontrar formas mejores de aumentar la productividad y el entusiasmo de los participantes.
Más allá de todo esto es importante entender que los procesos ágiles como Scrum se basan en el empirismo, lo que quiere decir que durante el proyecto aprendemos por Observación en vez de por predicción, es decir, de la experiencia y constantemente nos estamos adaptando para reencausar el proyecto si detectamos variaciones que pueden obstaculizar la consecución de los objetivos trazados.
Finalmente, en el camino hacia ágil hemos aprendido que el compromiso de cambio debe ser colectivo, que la meta de una organización ágil no es el uso del método sino el resultado: mejores equipos, individuos motivados, mayor valor de negocio entregado, moral más elevada, clientes felices, más que satisfechos, y mejores productos.
Esa es nuestra naturaleza, esa es la razón por la que estamos aquí. 
¿Quieres saber más?
Para saber más sobre Lean Software Development, visita el sitio de Mary & Tom Poppendieck: http://www.poppendieck.com/
Para saber más sobre Ágil y Scrum puedes leer estos artículos en mi Gazafatonario:



La Presentación

En este enlace puedes descargar la presentación basada en el artículo:



domingo, marzo 30, 2014

Lanzamiento de Agiles 2014: “Lo mítico, lo estético, lo simbólico”

La imagen es de Jorge Johnson.
La imagen es de Jorge Johnson.
El 27 de marzo ocurrió un hecho histórico para quienes hacemos parte del ecosistema ágil, se trata del lanzamiento de las 7as jornadas latinoamericanas de metodologías ágiles, Ágiles 2014.
En la Universidad EAFIT de Medellín nos reunimos representantes de la Industria, de la Academia, de las organizaciones sin ánimo de lucro del sector productivo (de software) y los entusiastas de las metodologías ágiles, miembros de la Comunidad Ágiles Colombia. En el ciberespacio, nos acompañaban desde distintos puntos, participantes de las distintas comunidades latinoamericanas con quienes llevamos adelante este proyecto.
Bajo el lema de “Sea protagonista del cambio en el mundo del trabajo”, Luis Mulato, presidente de la Conferencia, nos empezaba explicando cómo “narradores, protagonistas y testigos de historias de cambio nos han transmitido sus vivencias y ahora somos responsables de difundir su legado: Sí podemos cambiar el mundo”.
Me vino a la mente aquel fabuloso ensayo de Tobias Mayer en su libro The People’s Scrum, donde relata una imagen, la de “una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente que fomenta la escucha, la comunicación abierta y la colaboración a mansalva.” Tobias se refería a un ambiente parecido al de una plaza o al del patio de la escuela, “donde la innovación y las ideas disruptivas eran una parte natural de cada interacción”.
Mulato nos contó la historia de Ágiles, desde la Pampa argentina hasta el café colombiano, hoy, y nos explicó como nuestra visión es la de “fortalecer a Colombia como un país comprometido con el uso de metodologías ágiles e integrar a la región, expandiendo los conocimientos y experiencias de las comunidades predecesoras en Centroamérica y México.”
La imagen es de Claudia Sandoval.
La imagen es de Claudia Sandoval.

Nos mostró cómo personalidades de la talla de Mary y Tom Poppendieck, Janeth Gregory y Jurgen Appelo, James Patton y Diana Larsen, entre otros, han participado en ediciones anteriores y que esperábamos contar con reconocidos expertos de la misma talla que ellos. Y hablamos de los beneficios de que la industria se sumara a la Conferencia:
  • Conocer las tendencias
  • Conocer experiencias en el medio
  • Ver la aplicabilidad del modelo
  • Compartir los resultados
  • Experimentar la felicidad de las personas
  • Percibir y dejarse contagiar de la energía renovadora que trae la cultura ágil, volver a amar los lunes en la oficina

Después, un momento especial, bueno, una suma de momentos, las charlas ignite, las conferencias relámpago, donde en solo 5 minutos, con 20 diapositivas que avanzan automáticamente, diversos conferencistas nos deleitaron con temas tan diversos como las de Jorge Johnson con sus “Girasoles, falanges y estimación relativa” en la que nos decía que todos somos geómetras y que nuestro cerebro “necesita buscar una cohesión o patrón geométrico”, nos habló de la filotaxis, naturaleza autoorganizada y la proporción dorada y cómo todo esto tiene relación con la estimación de proyectos ágiles de software. Al final, nos lanzó su hipótesis, la está estudiando a fondo me dijo, obteniendo las bases teóricas: “Nuestro cerebro tiene grandes habilidades para hacer estimación relativa con la secuencia Fibonacci.” Siendo fan de la archipopular progresión, yo no lo dudo. Esperaremos con ansias los resultados de su investigación.
Jaime García nos habló de la necesidad de un “Agilector 4000” en su “Selección Ágil de la Tecnología” y nos dejó a todos con la expectativa hasta octubre, fecha en la que ocurrirá el evento. Adrian Moya nos habló de “Desarrollo Guiado por Comportamiento” o BDD. Entre otros. La lista completa de participantes y temas y presentaciones la pueden encontrar aquí. Desde el exterior, vía Internet, nos acompañaron Diego Fontdevila con su “Arquitecturas y Organizaciones”, Martín Salias con su “Como escala la naturaleza” y Ricardo Colusso, entrevistando a Carlos Churba sobre “Principios para Estimular la Creatividad”. Al final, Verónica Vera nos deleitó con su “Futuro netamente humano”. En ese instante, el ambiente era mágico y quienes fuimos artífices y probablemente los participantes de esta fiesta de apertura nos dejamos contagiar de la felicidad, esa que tanto hemos vuelto a buscar y que estamos encontrando vía la cultura ágil.
En el cierre de la velada hablé de cómo es que seguimos viviendo en un momento histórico, pleno de ciencia y tecnología, pero también lleno de dilemas y conflictos humanos. Mientras lo decía, pensaba de nuevo en ese ensayo de Tobias, en su imagen renovada de la oficina del futuro, y en el mecanismo que teníamos para lograrlo. Tobias dice que “ese mecanismo no se llama Scrum. No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión.” Más adelante expone finalmente que “hay solo una persona, un método, una cosa que puede hacer realidad esta visión. .” Por eso el gran reto, dije entonces, el nuestro, es que junto al cálculo y a la técnica, junto al método y a la teoría, hagamos convivir lo mítico, lo estético, lo simbólico.”
¡Nos vemos en octubre!

martes, marzo 04, 2014

Algunas Notas Sobre Gestión del Producto en Scrum

"Si puedes soñarlo, puedes hacerlo". Walt Disney.
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
Quienes venimos de enfoques tradicionales de desarrollo de software caracterizados por proponer y hasta exigir una diversidad de artefactos, encontramos la Lista de Producto (Product Backlog) de Scrum como algo tan hermosamente simple que raya en lo poético. Quizás a esa simplicidad se deba su inmensa popularidad entre los practicantes ágiles.
La Lista de Producto es un inventario priorizado del trabajo pendiente necesario para traer el producto a la vida. El Dueño de Producto es el responsable de la Lista de Producto y de su contenido. Nadie tiene una visión del producto que va más allá del producto en sí, como el Dueño de Producto.

Sus elementos pueden incluir:
  • Una exploración de las necesidades del usuario
  • Opciones técnicas variadas
  • Una descripción tanto de requisitos funcionales como no funcionales
  • El trabajo necesario para lanzar el producto

También puede contener otros elementos como:
  • Configuración del entorno
  • Defectos del producto. 

La Lista de Producto reemplaza los artefactos tradicionales de requisitos, tales como las especificaciones de requisitos del software. Mientras que el Dueño de Producto se compromete a manejar la Lista de Producto, el Scrum Master, el equipo y los interesados contribuyen a esta tarea. Juntos, descubren la funcionalidad del producto. Además, la Lista de Producto es también una herramienta para proporcionar transparencia durante el proyecto.
Sobre la Priorización
La priorización de la Lista puede hacerse de muchas formas, pero es algo que siempre se hace con el Dueño de Producto a bordo, liderando la priorización. Por ejemplo, es posible crear temas que contienen una lista de historias. Cada uno de estos temas tiene un “costo de retardo” asociado. Esto permite conocer el impacto de no implementar un tema si antes implementamos otro.
En este apartado debemos tener en cuenta que si se nos dificulta la priorización de la Lista de Elementos del Producto, puede estar sucediendo que:
  1. Los elementos, por ejemplo las historias de usuario, son muy grandes para priorizar
  2. No hay ningún valor de negocio asociado al Elemento de la Lista de Producto.
En el primer caso podemos dividir las historias en historias más pequeñas y relacionadas. En el segundo caso, podemos desechar estas historias “sin valor” y encontrar otras que sí reflejen valor del negocio o Retorno de la Inversión. Recuerda, si el Dueño de Producto no es capaz de escribir estas historias, el Scrum Master está a su servicio para ayudarle. No pretendas en el primer intento que un usuario tenga las habilidades y experiencia necesarias para escribir historias de usuario que cumplan con los atributos INVEST. Además, por lo general, no es posible cambiar de Dueño de Producto, es alguien sin quien el proyecto no puede vivir.

Sobre los defectos del producto
Si te estás preguntando como encargarte de esas anomalías que surgen o pueden surgir luego de la salida a producción del software y no sabes si decidirte por usar historias y priorizarlas en la Lista de Producto junto con las nuevas características, y si no estás buscando dogmas, puedes simplemente pensar en trabajar con el Dueño de Producto para clasificar y priorizar esos defectos en producción, luego los puedes tratar como historias de usuario a incluirlos en una entrega específica.
Al igual que en enfoques clásicos de mantenimiento de productos, si el defecto causa un alto impacto en los usuarios, este debe escalarse y resolverse como un ajuste en producción sin pasar por la cadencia normal de Scrum. Lo que sí puedes hacer es manejar la reparación del software usando un proceso Kanban, el cual permite un enfoque más liviano de gestión. Eso sí, no olvides que un error en producción representa valor negativo para el negocio así que dedica un esfuerzo mayor a evitarlos o a reducirlos al mínimo más que a corregirlos.
Cuando hagas esto piensa que:
  • Si una parte del producto tiene desperfectos, todavía no está Terminada.
  • Cualquier trabajo que necesite hacerse, necesita priorizarse.
  • Cualquier actividad que realice el equipo, toma tiempo.
  • El tiempo consumido en una cosa, no puede consumirse en otras cosas.

Los Atributos DEEP de la Lista de Producto
Dice Mike Cohn que una Lista de Producto efectiva tiene estas cuatro propiedades: detallada apropiadamente, estimada, emergente y priorizada. De allí el acrónimo DEEP.
Detallada Apropiadamente
Los Elementos de la Lista de Producto en la parte superior se describen en mayor detalle que los que están en la parte inferior de la Lista. A medida que bajamos en la lista, los elementos están menos detallados. Esto tiene sentido: son elementos que se convertirán en software apenas varias iteraciones más adelante o quizás nunca, si el usuario nota que no los necesita o si se acaba el presupuesto del proyecto. De hecho, es posible que el Dueño de Producto cambie la prioridad de alguno de estos, en cuyo caso solo debe llenar los vacíos de ese elemento para que quede “preparado” para construirse.
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle
Esta técnica asegura que la Lista de Producto se mantenga concisa y que los elementos a implementarse en el siguiente sprint son trabajables. Una consecuencia de este enfoque es que los requisitos se descubren, se descomponen y se refinan a lo largo de todo el proyecto. Es otra de las razones por las cuales el Dueño de Producto debe trabajar con el Equipo de Desarrollo cotidianamente durante todo el proyecto, o más o menos así reza uno de los Principios Ágiles.
Estimada
La estimación de los Elementos de la Lista de Producto usualmente se expresa en puntos de historia o en “días ideales”. Conocer el tamaño de los elementos ayuda a priorizar y a planificar las entregas a producción. Recordemos que otras estimaciones más detalladas a nivel de tareas se realizan durante la Reunión de Planificación del Sprint; y también, estas tareas y sus estimados se capturan en la Lista de Pendientes del Sprint.
Un día ideal es una abstracción del número de horas diarias en las que normalmente esperas que un miembro del equipo sea productivo, restando tiempo para asistir a reuniones, ir al baño, tomar un café o simplemente hacer una pausa laboral.
Emergente
La Lista de Producto tiene una cualidad orgánica. Evoluciona y su contenido cambia frecuentemente. Nuevos elementos se descubren y adicionan a la Lista basados en retroalimentación del usuario, principalmente. Los elementos existentes se modifican, re-priorizan, refinan o se remueven permanentemente.
Priorizada
Todos los elementos en la Lista de Producto se ordenan según su valor e trascendencia para la Organización. Los elementos más importantes y de más alta prioridad se implementan primero. Estos pueden encontrarse al principio de la lista, como indico en la Figura 1. Luego de que un elemento esté “Terminado”, se elimina de la Lista de Producto.
Finalmente
La Lista de Producto existe por un propósito más grande: construir un producto que impacte a los usuarios, que haga resonancia en ellos/ellas y que cambie en algo sus estilos de vida.
El producto debe construirse de manera orgánica, es decir, tan pronto como sea posible, debemos tener una versión que los usuarios puedan usar, el producto mínimo viable. A partir de este producto parcial, coherente y de valor, se construye el producto completo.
Al construirlo, piensa que estás componiendo una pieza musical grandiosa, la sinfonía definitiva, una que será recordada por siempre. Una obra así despliega patrones, trayectorias e incita a las personas a estar a su alrededor.
¿Quieres saber más?
Te recomiendo ampliamente este artículo de Jeff Sutherland:
Enabling Specifications: The Key to Building Agile Systems
El libro de Roman Pichler, Agile Management with Scrum, Creating Products That Customers Love. Addinson-Wesley, 2010.
Sobre Historias de Usuario, mi serie de artículos:
Historias de Usuario: un nuevo orden en los requisitos del software
Historias de Usuario Altamente Efectivas, Parte 1
Historias de Usuario Altamente Efectivas, 2
Historias de Usuario Altamente Efectivas, 3
Historias de Usuario Altamente Efectivas, 4

lunes, enero 27, 2014

Compendio Sobre el Scrum Diario

Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero?
Respuesta: ¡Un día a la vez!
[Frederick P. Brooks, Jr. The Mythical Man-Month. Pp. 153.]
Se ha llamado Reunión Diaria, Scrum Diario, Reunión de Pie, Reunión Diaria de Pie y de algunas otras formas equivalentes, en todos los idiomas. Esta no es solo una reunión de pie. Este ritual, que bien puede implementarse en proyectos de todo tipo, ágiles y no ágiles, tiene una importancia que muchas veces pasa desapercibida para el común de los mortales.

Brooks, en su ya antiquísimo libro The Mythical Man-Month, y del que me he permitido extraer la frase inicial, dice que pequeñas demoras incrementales en distintos frentes del proyecto eventualmente se acumulan para producir un enorme retraso. Se requiere entonces atención permanente para alcanzar metas individuales pequeñas o parciales en todos los niveles del proyecto. [1]

Hace ya 40 años Brooks ponía de manifiesto la necesidad de una sesión como esta. Es una reunión de planificación, no de seguimiento como erróneamente creen algunos. También es una ceremonia de sincronización del equipo, para que sus miembros se enteren de los avances del Sprint de todo el equipo y de las dificultades existentes, cuya exposición se hace para que cada participante se postule en pro de su solución.

Así que si eres un Scrum Master o haces parte de un Equipo Scrum, sigue estos consejos que he tomado de aquí y de allá, incluida mi propia experiencia facilitándolas y ayudando a terceros a facilitarlas.

Algunos Patrones de Comportamiento Durante el Scrum Diario

Sé riguroso con la agenda. No permitas discusiones y mantente firme en las 3 preguntas. De esta forma, terminarás antes de 15 minutos. Como Scrum Master es tu trabajo hacer que esto pase. Si comienza una discusión, detenla y pide a los involucrados que la aplacen hasta después de la reunión, pero asegúrate de que se lleve a cabo. Sin embargo, permite que los miembros del equipo brinden ideas rápidas sobre la solución a problemas comunes.

Las decisiones importantes del proyecto no se deberían tomar durante la Reunión Diaria. Esta es una reunión de estatus, un punto de comunicación, no es para resolver problemas. Esta es una característica importante de la Reunión de Pie.

Si promueves discusiones detalladas, a medida que la reunión avanza y llega el turno de los últimos participantes, quizás el tiempo se habrá acabado y algunos asistentes quedarán sin sincronizar con el resto del grupo, así que no permitas los conflictos o diálogos extensos para buscar soluciones o discutir procedimientos; en cambio, fomenta una o más reuniones en grupos pequeños con las personas necesarias para tomar decisiones específicas. De esta forma, los demás podrán regresar a sus tareas regulares del sprint.

La facilitación de un Scrum Master experimentado es clave hasta que todo el equipo sea un Equipo Scrum maduro y hábil. Asegúrate de que los miembros del equipo asistan a la reunión con una buena idea de lo que harán a continuación, pero también permita una discusión rápida entre los miembros del equipo para tomar decisiones sobre colaborar en una tarea o una serie de tareas.

Proporciona algunos recordatorios estratégicos rápidos que son necesarios como: “estamos cerca del final del sprint, enfoquémonos en asegurar que tengamos un producto potencialmente distribuible que entregar”. Esto es algo que se puede incorporar con el pasar de los sprints, a medida que el equipo se envuelve en la cultura ágil.

Algunas otras ideas:

Usa una especie de testigo, al mejor estilo de las carreras atléticas de relevos, para evitar que los participantes hablen unos sobre otros y asegúrate de que el orden de intervención sea estricto, por ejemplo, en el sentido de las manecillas del reloj.

No realices estas reuniones al final del día, la gente ya está cansada y quiere irse a casa. En ese momento, el interés de las personas ya es otro. Una buena alternativa a hacerla en la mañana, es llevarla a cabo justo después del almuerzo, las personas tienen energía, están felices y vienen de un corto descanso.

Además, como Scrum Master:

Sirve como fuente de inspiración del trabajo en equipo, después de todo, eso eres: un líder al servicio del equipo y de la organización.

Facilita la reunión y haz que se mantenga breve y al punto.

Establece que las tarjetas (o notas adhesivas) de tareas se muevan antes o después de la reunión, pero no durante la misma, llega a un acuerdo de trabajo con el equipo. Haz lo mismo con las horas faltantes del Sprint, con el burn-down chart o cualquier otro mecanismo que estés usando con el equipo para monitorear el avance del proyecto.

Impulsa el que los Cerdos respondan las 3 Preguntas al Equipo Completo, no a ti como Scrum Master o a alguna otra persona en particular.

No permitas que las Gallinas (ninguna Gallina) los interrumpa a menos que sea esencial, en la práctica casi nunca lo es.

Finalmente, observa atentamente y resuelve estos asuntos:

Algunas personas no escuchan cuando otros hablan

Algunas personas dan información vaga o insuficiente, o no dicen nada, lo cual es su prerrogativa. Sin embargo, estos casos deben tratarse con cautela, de manera personalizada.

Algunas personas censuran cuando alguien no tiene un buen avance o comete algún error

Algunas personas postergan discusiones o la comunicación entre ellas durante el día hasta la Reunión Diaria

¿Quieres saber más?

La descripción completa sobre el Scrum Diario la encuentras en “La Guía de Scrum", a cuya última versión en español puedes llegar a través de:


Sobre la reunión diaria, este artículo de Jason Yip es todo un tratado alrededor del tema y expone una serie de patrones que bien podemos implementar: “It's Not Just Standing Up: Patterns for Daily Standup Meetings”:

Sobre Scrum y cultura ágil puedes leer estos artículos en mi Gazafatonario:





Scrum Orgánico para Iniciantes


En particular, sobre el rol y responsabilidades del Scrum Master, facilitador del Scrum Diario:



Referencias

[1] The Mythical Man-Month by Frederick P. Brooks, Jr., Addison Wesley Pub. Co., 1975, 25th Anniversary edition, 2000.

lunes, enero 13, 2014

Sí, usted está listo para implementar un proyecto ágil

En caso de duda, pregunte a un experto.
Además de conocer, entender y adoptar los valores y principios del manifiesto por el desarrollo ágil de software, piense que no se trata de un solo proyecto, se trata de toda una transformación organizacional que implica cultura, filosofía, enfoques, técnicas, métodos y, lo más importante, personas.

La evolución hacia ágil es importante, igual que establecer cuáles serán los factores clave de éxito y, entre aquella y estos, la selección de equipos y proyectos pilotos se convierte en algo vital en todo esfuerzo de mejoramiento ágil.
Sobre la evolución a ágil
Si viene de una metodología en cascada, de un enfoque tradicional de comando y control tipo PMI, de un modelo de calidad riguroso tipo CMMI, o de una combinación de todos, entonces esto le interesa:
  1. Debe definir un proceso de mejoramiento continuo que lo lleve del enfoque actual a una estrategia ágil. No intente hacerlo tipo “Big Bang”, es decir, de la noche a la mañana. Seguramente durante mucho tiempo tendrá que convivir con los dos universos de proyectos.
  2. La implementación del proceso ágil empieza con la interiorización de los valores y principios ágiles (El Manifiesto Ágil) y es única y adaptada a todas las especificaciones que se ajusten a las metas organizacionales.
  3. Debe ser una transformación progresiva a través del enfoque ágil, el cual integra paso a paso las prácticas ágiles requeridas. Por ejemplo, empiece con Scrum y algunas prácticas adicionales (Kanban, Story Mapping, Impact Mapping, Planning Poker, User Stories) y luego siga con algunas de estas: TDD, BDD, Pair Programming, Refactoring, entre otras.
  4. Si tiene que tomar elementos del proceso actual, use prácticas de Lean para hacerlos más livianos y eliminar lo que podría constituirse en desperdicio.
  5. Implemente los conceptos de Valor, Software de Valor para el negocio, Definición de Terminado, Definición de Listo y Criterios de Aceptación. Haga que todas las personas en la organización los adopten y los conviertan en tema cotidiano de conversación.
  6. Despójese y remueva de la organización los vicios y las comodidades actuales. Si quiere nuevos y mejores resultados, cuéntele a todos, debe empezar a hacer las cosas de una manera diferente.
  7. Tenga el coraje para decir que implementar Ágil no es fácil. Hacer software es una tarea compleja y, aunque las prácticas ágiles son livianas y fáciles de entender, son extremadamente difíciles de llegar a dominar… ¡o algo así reza en la guía de Scrum!

Sobre los factores clave de éxito
  1. Los miembros del equipo deberían estar dedicados 100%y trabajar fuera de su rol funcional actual.
  2. La administración debe estar dispuesta a seguir adelante con el enfoque, sin importar los errores que se cometan.
  3. El Dueño de Producto es parte del equipo.
  4. Un Scrum Master debe estar presente y ser capaz de trabajar con el nuevo proceso.
  5. Defina una estrategia de trabajo con todas personas y recursos de apoyo.
  6. No sea impaciente, el éxito quizás no se logra en el primer intento.
  7. Empiece con unas pocas métricas para medir la realidad de los proyectos y de la organización, no a las personas.

Sobre los proyectos piloto
Uno o más proyectos pilotos son importantes. Algunas de las características que debe tener un piloto son las siguientes:
Duración: ni muy corta ni muy larga. De 3 a 9 meses, con una media de 6 meses es un buen tiempo para un proyecto piloto. Recordemos que aunque los resultados parciales de los Sprints nos van a permitir afinar el proceso y las técnicas, también necesitamos el resultado final de cada proyecto piloto para tomar decisiones importantes y mirar aspectos a reforzar. Más de 9 meses es mucho tiempo para ello. Importante aquí es explicar bien a la organización que los métodos ágiles no solo son para proyectos pequeños como estos pilotos, sino para cualquier tipo de proyecto.
Complejidad: ni muy fáciles ni muy complejos. Deben ser mediamente importantes pero definitivamente no críticos para la organización. Hay que recordar que estamos en un proceso de aprendizaje y que podemos cometer errores. Si estos errores son en proyectos críticos, podemos echar al canasto de la basura todo el esfuerzo de implementación ágil debido a la mala imagen ante la organización, al retiro de nuestros patrocinadores, etc. La organización puede ver esto como que Ágil no funciona. Importante es que el proyecto, aunque no corporativo, tenga visibilidad organizacional, que sea conocido por la alta gerencia.
Tamaño: un solo equipo de desarrollo, como dice la guía de Scrum, de entre 3 y 9 personas. 5 o 6 personas es un tamaño adecuado. Adicionemos el Dueño de Producto y el Scrum Master y estamos listos. Por supuesto, esto debemos conjugarlo con la complejidad y duración del proyecto. El equipo debe estar físicamente en una sola ubicación. Un coach de más experiencia puede apoyar ciertas tareas y ser un soporte para el Scrum Master.
Personas: Los miembros del equipo deben:
  • Tener empatía y ser abiertas
  • Tener coraje para aceptar y conducir el cambio
  • Tener auto-disciplina que se traduzca en disciplina de equipo
  • Confiar en ellas mismas y en el resto del grupo

Como siempre, debe ser un equipo multi-funcional empoderado, con los recursos y autoridad necesaria para alcanzar las metas del negocio. Aspectos como la visión de las personas, colaboración, responsabilidad y productividad se conjugarán bien en un proyecto piloto y mantendrán elevada la energía del grupo.
Muy importante es conseguir Orientación vía entrenamiento o acompañamiento para los Scrum Master y adicionar a esto dedicación, para lograr que el proyecto funcione sin importar lo que pase. No se comprometa más allá de lo posible, explique a la organización que al principio el equipo ágil recién formado perderá el balón varias veces, pero se embarcará en una estrategia de mejoramiento continuo.
Cuando el equipo alcanza un buen paso/velocidad, invite a los ejecutivos a las ceremonias, especialmente a la Revisión. Observe Transparencia todo el tiempo, teniendo todos los artefactos (tablero Scrum, burndown chart, burndown de entrega, lista de impedimentos, Meta del Sprint, Definición de Terminado, etc.) a la vista de todos en el área de trabajo del equipo Scrum. Programe la agenda para que los interesados “vayan a ver” la actividad y guíelos a través del proceso, los artefactos y las actividades del Sprint. Haga que se “involucren” y busque su retroalimentación.
Otros aspectos a tener en cuenta
Más allá de todo lo anterior, considere lo siguiente:
  • Asegúrese de que los líderes hayan entendido y recibido bien los valores y principios del manifiesto ágil. Sí, ya sé que lo dije antes, lo repito dada la relevancia y lo que significa para una iniciativa de mejoramiento ágil que se conozca el Manifiesto.
  • Para un mejoramiento más rápido, considere involucrar un buen coach.
  • Enfóquese primero en la calidad.
  • Limite la cantidad de trabajo-en-proceso.
  • Mantenga la inspección y adaptación. Los procesos ágiles como Scrum se basan en el empirismo, donde se aprende por observación. La inspección y adaptación son los medios mediante los cuales podemos mantener el proceso de mejoramiento encausado y los proyectos piloto en el camino correcto.
  • Conozca cómo medir el avance (Tarea, Historia, Sprint, Release). En cualquier caso recuerde: el software funcionando es la medida principal de progreso.
  • Asegúrese de que el Dueño de Producto esté empoderado para tomar decisiones por el equipo.
  • Madure el enfoque de manejo de código fuente y de las pruebas.
  • Estudie o trate de reconocer cuando está convirtiendo los sprints en “cascadas disfrazadas”. Este es uno de los errores más frecuentes cuando la transición se hace desde los métodos clásicos de ejecución de proyectos.
  • Mantenga comunicación constante con los equipos piloto y con la organización y conserve su compromiso con la transparencia.
  • Finalmente, la organización necesita comprar el proceso. No tener retroalimentación del negocio (o del Cliente) es una falla. Asegúrese de tener los interesados y Dueños de Producto correctos que puedan gestionar el backlog de producto y compartir su visión.

¿Quiere saber más?
Puede visitar estos enlaces:
El Manifiesto por el desarrollo ágil de software:

Scrum Orgánico para Iniciantes

Lista de Chequeo Scrum

Scrum – Lo Fundamental

Vademescrum, Sección I: El Scrum Master 1

Nueva Versión de la Guía Oficial de Scrum

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

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

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