Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta historias de usuario. Mostrar todas las entradas
Mostrando las entradas con la etiqueta historias de usuario. Mostrar todas las entradas

lunes, noviembre 28, 2016

Las historias de usuario como instrumentos de negociación


Hablemos un poco de ese continuum que significa diseñar y construir soluciones de valor para una organización. Las organizaciones hoy día están hechas de software, el software está en todas partes y si de construir software se trata, los equipos ágiles tenemos algo que decir.
De los incontables utensilios que contamos en nuestra mesa de trabajo las historias de usuario están siempre a la vista de quienes transitamos por los senderos de los problemas complejos y las soluciones para ellos. Para nosotros, trabajar en soluciones mejora la comprensión de los problemas. Esta es posiblemente la razón principal por la cual los enfoques iterativo e incremental son mejores que cualquier otro en la actualidad. Y si los combinamos, mucho mejor. Los Agilistas fantásticos:
1.     Construimos de manera iterativa para minimizar el riesgo
2.    Construimos de manera incremental para maximizar el retorno de la inversión (ROI)
3.    ¡Repetimos  1 y 2 hasta la saciedad! O hasta que se esté generando el suficiente valor como para detener nuestro esfuerzo de desarrollo.
En ese camino hemos aprendido que los problemas no son subjetivos. Lo subjetivo es la percepción que tengamos de esos problemas. En general estos se basan en la realidad. Además, los enfoques de pensamiento, nuestro mindset, pueden llegar a redefinir esos problemas por completo.
Ya sabemos que una historia de usuario no es un contrato firmado en piedra, más bien es una carta de intención de algo que el sistema debe hacer y cuyos detalles se abordan durante la conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. También son cartas de negociación entre unos y otros, pero solo habrá una negociación fluida si el usuario está realmente interesado en el éxito del esfuerzo de desarrollo, si está dispuesto a comunicarse de manera efectiva y a trabajar con y como parte del equipo.
Los ingredientes clave de una historia de usuario son: quién es el usuario, qué quiere hacer el usuario y por qué lo necesita. Contrario a lo que mucha gente cree, las personas (usuarios o consumidores finales, expertos con el conocimiento, interesados, patrocinadores y otras personas impactadas por la historia), constituyen lo más importante de una historia de usuario. Esto permite o posibilita la comunicación para que hagamos las cosas correctas y nos ayuda a identificar el valor para priorizar lo que haremos primero y lo que haremos más adelante.
La parte “conversación” de una historia de usuario idealmente es una colaboración entre el usuario y el equipo que construye la solución, es una asociación para entender el problema y trabajar precisamente en una solución que resuelva ese problema y también permite confirmar más adelante que esa solución de hecho resuelve el problema adecuadamente.
Las historias de usuario proporcionan un entorno, un medio para adaptarnos, para buscar oportunidades. Si encontramos un obstáculo que no es posible sortear, siempre podemos buscar otra historia relacionada que nos permita avanzar. Es posible que, al hacerlo, encontremos la solución a la historia que no nos permitía progresar en principio y podemos volver a ella.
Ahora bien, si esa carta de intención, esa necesidad que tiene el usuario, es muy específica, la tarea del equipo es preguntar “¿por qué?” ¿Por qué y para qué se necesita esa historia?; en cambio, si es muy abstracta, preguntaremos “¿cómo?” ¿Cómo lo hace? ¿Cómo quiere o quisiera la solución? Las historias de usuario siempre son sobre “negociación” si queremos un buen balance entre costo y valor.
En general, las historias de usuario nos permiten a los Agilistas fantásticos:
1.     Lograr este balance en pequeños alcances,
2.    Construir la solución, o los incrementos de esta, de tal manera que podamos obtener una efectiva retroalimentación anticipada.
3.    Trabajar en los aspectos de más valor primero para que sean entregados y empiecen a generar ROI lo más pronto posible.
Finalmente, ninguna discusión o exposición sobre historias de usuario estaría completa si no incluimos la palabra “confianza”. Si la confianza es poca en un equipo Scrum, las historias de usuario se convertirán muy pronto en piezas muy concretas de descripciones de problemas que el Dueño de Producto le entregará al equipo de desarrollo y que quizás nadie querrá resolver. Si esto ocurre, seguramente el equipo de desarrollo también va a solicitar, con grado de exigencia, unos criterios de aceptación muy concretos. El resultado: el muy pesado, extenso y falto de humanidad documento de especificación de requisitos funcionales y no funcionales del pasado, el mismo que cargaba consigo el sinsabor de la frustración y la derrota.
Entonces, para que positivamente las historias de usuario sean una herramienta auténtica de negociación entre las áreas de TI y las del negocio y para que sean una representación de los problemas de este último y de las soluciones que puedan proporcionar los primeros, es necesario que en el ambiente haya un alto grado de confianza. El Equipo Scrum en pleno, e incluso los interesados del entorno, tienen que conformar un equipo propiamente dicho, donde el trabajo colaborativo, la adaptación, el mejoramiento continuo y la entrega continua de valor sirvan de pilares y de integradores entre sus miembros para que todo lo anterior sea posible.

sábado, noviembre 26, 2016

User Story Mapping - Una introducción


El User Story Map es una herramienta que permite generar una representación visual del producto completo. Ofrece una vista general de todas las funcionalidades que lo componen (the big picture) de punta a punta. 

Permite identificar Historias de Usuario faltantes en el Backlog, planificar Releases (entregas) dividiéndolo en porciones (Slicing) y visualizar cómo se distribuyen las funcionalidades de acuerdo a las diferentes áreas del sistema.

Son diferentes a los backlogs típicos de historias de usuario en cuanto: 

  • Hacen visible el flujo de trabajo o la cadena de valor
  • Muestran las relaciones entre historias más grandes y sus historias hijas
  • Ayudan a confirmar la completitud del backlog
  • Proporcionan un contexto útil para la priorización
  • Permiten planear entregas (releases) en porciones valuadas y completas de funcionalidad

En esta presentación, basada en el trabajo de Jeff patton, hago una breve introducción al tema de User Story Mapping. La pueden descargar de:


miércoles, noviembre 02, 2016

Planear sprints en horas y no por puntos


Hace algunos días nuestro amigo Carlos Jaramillo nos preguntaba a algunos colegas si estábamos de acuerdo con el legendario Mike Cohn cuando dice que los sprints deberían planearse con horas y no con puntos. Carlos se refirió específicamente al artículo Why Sprints Should Be Planned with Hours, Not Points (Por qué los sprints deberían planearse con horas, no con puntos).

Como lo dice Cohn al inicio de su artículo, para mí y creo que para muchos de los que hemos leído su libro Agile Estimating and planning (Estimación y Planificación Ágil) fue una sorpresa cuando vimos el título ya que sabemos que él es un gran referente y promotor de los puntos de historia y de su uso. Pero pasemos a la que fue mi respuesta entonces:

¡Estoy de acuerdo!

En particular, estoy de acuerdo con Mike cuando dice que “los puntos (de historia) son demasiado imprecisos para ser útiles en el corto plazo”, es decir, en un sprint de menos de un mes. También me gustaría destacar aquello de que la velocidad, aunque ligeramente, puede variar de sprint a sprint.

Además de lo que dice Cohn en su artículo algunas otras razones me llevan a pensar así:

No hay una correlación directa entre puntos de historia y el esfuerzo de implementación de la historia de usuario. Es decir, no existe tal regla o ley que señale que si un punto de historia toma H horas implementarse, N puntos de historia tomarán N x H horas implementarse (por ejemplo: si la implementación de una historia de un (1) punto toma 25 horas, entonces la implementación de una historia de 2 puntos tomará 50 horas, no).

Es probable, eso sí, que al final, después de muchos sprints, el promedio muestre tendencia hacia esos números, pero nada evita, en el escenario propuesto, que una historia de 2 puntos le tome al equipo 15 horas y otra también de 2 puntos le tome 35 horas para implementarla o cualquier otro número, incluso podríamos tener una historia de 2 puntos cuya implementación tome 10 horas o menos. En cualquier caso, eso apenas sería la tendencia natural.

Además, aun con ritmo sostenido y con entrega de valor constante en cada sprint, no es lo mismo un equipo en el primer sprint del proyecto que en el séptimo o en el décimo noveno. No es lo mismo un equipo en abril que en septiembre o en diciembre. No es lo mismo un equipo si el proyecto va bien desde varios puntos de vista, como el valor entregado, la calidad, el consumo de presupuesto, etcétera, o si va regular o mal; y no es lo mismo si el equipo y aun la organización a la que pertenece han estado mejorando continuamente o si su crecimiento personal y profesional se ha estancado por acción del proyecto.

Todos esos factores que acabo de mencionar impactan positiva o negativamente la motivación del equipo y por consiguiente, el rendimiento de los miembros del equipo. Lo que finalmente se traduce en número de horas de esfuerzo necesarias para implementar una historia, o sea, para llevarla de ‘Propuesta’ o ‘En proceso’ a ‘Terminada’.

La misma calidad y el tamaño de las historias de usuario también afectan de una forma u otra el esfuerzo requerido para su implementación. Me refiero a la calidad con que son comunicadas al equipo por el Dueño de Producto o por quien corresponda, así también perturba de manera distinta una historia de 2 puntos que una de 5 o una de 8.

Y todo esto para concluir que en cada Planificación de Sprint se debe hacer el ejercicio de, precisamente, planear por horas de esfuerzo, de eso se trata esta ceremonia inicial de Scrum después de todo. La gran diferencia con la planificación de los métodos tradicionalistas es que no vamos a planear seis meses de trabajo o un año o dos, no, se trata solo de adelantarnos a lo que va a pasar en las próximas 2 semanas de trabajo, quizás tres.

Nuestros equipos deben o deberían tener el conocimiento y la experiencia para decirle al Dueño de Producto y al mismo Scrum Master, al final de la Planificación, cómo intentarán hacer su trabajo en el sprint que comienza y eso incluye contarnos el número de horas de esfuerzo que tomará implementar una historia de usuario en particular. Se trata es de dilucidar cuando nos tomará el diseño, la programación, las pruebas, la integración, la documentación y cualquier otra actividad concerniente a la construcción de la historia. Después de todo, para eso fue que precisamente se conformó el equipo.

¡Pero hay más!

Usamos Puntos de Historia para estimar el backlog y el esfuerzo a mediano y largo plazo porque son o representan un valor abstracto. También sabemos que es posible usar otros métodos abstractos de estimación como 'tallas de camisetas', días ideales, colores, tamaño de los planetas o, incluso como dice mi amigo Jorge Abad en sus Lecciones Aprendidas, podemos usar la técnica del ‘ojo de buen cubero’, estimar con Garrapatandamandapispuntos o con cualquier otra medida cuyas convenciones sean bien conocidas por todo el equipo.

El precepto fundamental aquí es que todos estos métodos producen estimados y los estimados, sobre todo en software, están condenados al error. Casi 50 años de experiencias después de aquella remota conferencia de la OTAN en Garmisch en la que de alguna manera se dio vida a la Ingeniería de Software nos han demostrado eso.

En cualquier caso para estos escenarios de mediano/largo plazo, si un usuario o cliente está exigiendo estimar en horas un proyecto Ágil, todavía no ha entendido el enfoque y necesita guía en ese sentido. Las horas son algo concreto sí, pero solo para lo que he explicado arriba, estimar un sprint corto o muy corto, de muy pocos días a dos semanas.

Pero igual que con los puntos, estimar con horas no nos eximirá del error inherente a las estimaciones. Así que en vez de salir corriendo detrás de las horas, deberíamos enfocarnos en habilitar y empoderar nuestros equipos para que hagan un mejor trabajo.
----------
¿Ustedes qué creen? ¿Cómo estiman los sprints? Déjenmelo saber en el foro.


----------
Más sobre Planificación en:



El artículo de referencia de Mike Cohn lo pueden encontrar en:

miércoles, julio 13, 2016

SCRUM CARD GAME – Un juego para experimentar Scrum


SCRUM CARD GAME es un juego simple que permite a los jugadores experimentar el trabajo en sprints de Scrum discutir muchas cuestiones y temas que suceden en la vida real mientras trabajan en un equipo Scrum. La discusión sobre la mesa  de juego será muy cercana a la experiencia real del trabajo en un equipo Scrum. Este juego usualmente se juega durante un entrenamiento o taller. Los participantes ya deben conocer y entender el marco de trabajo Scrum o pueden aprenderlo mientras participan del juego. También puede servir como método para hacer que un equipo experimentado reflexione sobre sus rituales y reglas establecidas de Scrum.

El eje del juego es que cada equipo (de 4 a 6 personas) es un centro de desarrollo competitivo contratado para llevar una nueva aplicación al mercado. El equipo más productivo gana.

Los materiales para el juego incluyen:
  • Un juego de cartas de Historias, Eventos, Problemas y Soluciones. Estas son las cartas de Oportunidad. Estas se encuentran en el manual oficial del juego del que comento más abajo.
  • Dos dados de seis lados (para cada equipo)
  • Rotafolio
  • Marcadores

Podrán imaginar ustedes que los sucesos del juego ocurren durante los sprints, se pueden jugar hasta tres sprints aunque es posible jugar 4 o más. Los sprints son de tres días de duración y durante cada día cada uno de los miembros del equipo trabaja en el sprint. En cada Sprint los equipos realizar Planificación, Revisión y Retrospectiva y durante la ejecución del sprint se experimentan conceptos como impedimentos o bloqueos, definición de Terminado, trabajo, Tablero de tareas, Backlog, entre muchos otros.

Al final del juego es posible hacer un análisis de temas tan importantes para los equipos ágiles como:
  • Esfuerzo planeado versus Real
  • Variaciones en la velocidad
  • Horas Estimadas versus Tamaño (Estimado Original)
  • Riesgos mayores que sucedieron (Técnicos, Personas, Eventos No Planeados)
  • ¿Cuáles son los tipos de riesgos más difíciles de tomar?
  • ¿Podemos proyectar eventos malos?
  • Entre otros

El autor del juego es Timofey Yevgrashyn, un agilista de Europa del Este, Gerente Ágil con experiencia en consultoría, coaching y entrenamiento. Timofey  tiene experiencia en el lanzamiento y liderazgo de transformaciones Ágiles/Lean que conducen a alinear las entregas con los objetivos del negocio. Hasta este año (2016) ha ayudado a más de 50 equipos de más de 10 países y ha completado cerca de 3000 horas de entrenamiento Ágil a más de 4000 personas. ¡Eso es estar en el campo de batalla!

Timofey se basó en su trabajo pragmático y en sus entrenamientos para diseñar este fabuloso juego, además de otros que pueden encontrar en su blog que escribe desde 2009 en lengua Rusa “The Improved Methods” (http://tim.com.ua). Conocí el juego y lo he jugado con algunos equipos mixtos de personas con mediana, poca o ninguna experiencia en Scrum y los resultados han sido grandioso. Por eso hablé con Tomofey para que trabajáramos juntos en la versión del juego en español y el resultado ya está aquí.

Mientras él termina de implementar un sitio exclusivo para el juego, pueden encontrar la versión en español su sitio actual:

En la sección Переводы. No se preocupen, si no saben ruso, se trata de la sección Translations (Traducciones).

O directamente en: http://bit.ly/ScrumCardGameES

Descarguen el juego con las tarjetas coloridas imprimibles y no dejen de contarme en el foro, más abajo, sus experiencias con el mismo.

domingo, junio 26, 2016

¡El tamaño sí importa!


Vamos al grano. Si la mayoría de tus historias de usuario llegan a “Terminado” apenas unas pocas horas antes de la Revisión del Sprint, todavía pueden ser más pequeñas. Tu equipo debería tener historias tan pequeñas que las puedas finalizar durante las primeras horas o días del Sprint, dependiendo de la duración de este. Así te aseguras desde las primeras de cambio que el equipo está siendo productivo, está enfocado y que van a entregar valor al final de la iteración. ¡Después de todo, finalizar una tarea aumenta la moral del equipo!
Aunque el objetivo de un Sprint no debe medirse en número de historias de usuario a terminar (implementar), sino al cumplimiento de un objetivo específico, siempre es mejor “prometer” o planear terminar varias historias pequeñas o muy pequeñas que muy pocas historias medianas o grandes.
Es evidente: si tienes 10 historias en tu lista de pendientes del sprint (alias el backlog del sprint), y no terminas 2, es mucho mejor que si solo tienes 4 y terminas 2. En ambos casos fallaste en el mismo número de historias, pero en el primer escenario tuviste un acierto del 80% mientras que en el segundo apenas llegaste a la mitad de la promesa del sprint. El resultado es menos alentador si las historias terminadas son dos de 3 puntos y dejaste sin terminar o aun a punto de terminar dos historias de 13. Solo cumpliste con 6 de los treinta puntos que prometiste.
Hablando de puntos, una buena medida, algo que me ha funcionado casi siempre, es implementar historias cuyo puntaje no sobrepase entre una décima parte y una sexta parte de la velocidad del equipo. Es decir, si la velocidad del equipo de desarrollo es 30 puntos por Sprint, las historias a implementar no deberían ser más grandes de 3 a 5 puntos. Historias de ½, 1 y 2 puntos siempre son bienvenidas en este escenario.
Ahora bien, el tamaño de las historias es un concepto relativo. Un equipo de 7 o 9 personas no ve igual una historia de usuario en un sprint de 3 o 4 semanas que un equipo de 3 o 5 personas en un sprint de 1 o 2 semanas. Pero algo en lo que todos estamos de acuerdo es que, una vez terminadas, las historias deben proporcionar valor al negocio. Las cosas así, otro indicador de “pequeño” es Pareto.
El objetivo siempre es encontrar ese 20% de la historia (de funcionalidades que se van implementar vía esa historia) que genere o entregue el 80% del valor total de la misma. A partir de allí, la división se hace de manera orgánica, adicionando historias al backlog de producto que complementen la historia de “más valor”.
También ayuda el nivel de entendimiento de toda la historia y qué tan rápido llegamos a entenderla por completo. Un índice de que quizás la historia no es pequeña es que no la hemos terminado de entender, quizás no están claros algunos de los criterios de aceptación o hay nubes en la conversación (la c de conversación de la historia) relacionadas con los requisitos funcionales o no funcionales a implementar.
El Principio de Sweepnoise, de mi amigo Leonardo Agudelo, ilustra muy bien este punto:


Finalmente, no solo la S de INVEST indica que la historia es pequeña (Sucinta). Un indicativo de que quizás no lo es tanto, es que  algunas partes de la misma (o toda la historia) no sean negociables o que no haya consenso en su estimación o que tengamos dudas acerca de si es posible conducirla a través de un proceso que nos asegure la calidad del producto terminado o de que incluso tenga dependencias con otra(s) historia(s).

Comparte conmigo y con los demás lectores del blog lo que piensas sobre este asunto del tamaño, ¿importa? ¿No importa? ¿Qué haces habitualmente para dividir tus historias de usuario? Cuéntanos tus heurísticas.
---------------------------------------------------------------------------------------------------------------
Para saber más sobre historias de usuario, puedes leer mi artículo introductorio:
Historias de Usuario: un nuevo orden en los requisitos del software:
http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Para saber más de los criterios INVEST de las historias de usuario puedes leer mi serie de artículos sobre el asunto.
La serie de artículos "Escribiendo Historias de Usuario Altamente Efectivas":
Escribiendo Historias de Usuario Altamente Efectivas, 1 - Introducción
Escribiendo Historias de Usuario Altamente Efectivas, 2 - Independiente
Escribiendo Historias de Usuario Altamente Efectivas, 3 - Negociable
Escribiendo Historias de Usuario Altamente Efectivas, 4 - Valiosa (y Valuada)

Y este otro:

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


También puedes visitar el blog Lecciones Aprendidas de mi amigo Jorge Abad:
Video de explicación: Cómo se construyen historias de usuario
Ejemplo: Una historia de usuario - Listado de Morosos
Ejemplo de historia de usuario : Ingreso al sistema
http://www.lecciones-aprendidas.info/2015/03/ejemplo-de-historias-de-usuario-ingreso.html

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 “métodos y prácticas ágiles” (biocenosis) y el medio físico donde se relacionan, llamados Organizaciones (biotopo). Estas últimas están conformadas por personas y estas personas usan distintas clases de biocenosis, es decir, de métodos y prácticas ágiles, según sus necesidades.
Como todo ecosistema, el ágil tiene barreras que a veces impiden su normal evolución. Barreras físicas, como la falta de entornos adecuados dentro de las Organizaciones para albergar equipos que respiren “agilidad”. Barreras culturales y hasta emocionales, arraigos y miedos que se dan entre las personas, quienes experimentan temores muchas veces infundados debido a la falta de información o de acompañamiento efectivo por parte de expertos, de conocedores de ese ecosistema ágil en formación.
Pero, ¿cuáles son esos métodos y prácticas ágiles? ¿Para qué sirve cada uno de ellos? En esta sesión exploraremos, a manera de introducción, las metodologías más usadas, como 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 métodos empiezo? ¿Uno solo es suficiente? La respuesta corta a esta última pregunta es “no”. Entonces, ¿qué debo saber para dar el salto de aquí hasta ágil? ¿De qué me “agarro” para no caer en el abismo? Estos son los asuntos que abordaré en esta sesión introductoria.
Con definiciones simples y ejemplificadas, basado en hechos históricos de los cuales he sido protagonista, le contaré a la audiencia de qué se trata toda esta jerigonza ágil, a manera de Gazafatonario.

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


viernes, abril 17, 2015

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

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

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

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

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

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

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

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.

lunes, abril 13, 2015

Los trinomios cuadrados perfectos no son ágiles… o del principio de la simplicidad

“La perfección no se logra cuando no hay nada más que añadir, sino cuando no hay nada  más que quitar” [Antoine de Saint Exupéry]
En el último conversatorio sobre Scrum que facilitamos en la Comunidad de Ágiles Colombia en Medellín, hablamos de lo que significa ser ágil y llegamos necesariamente a los valores y principios del Manifiesto ágil.  Uno de los principios llamó especialmente la atención: “La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

Luego me encontré un artículo* de alguien que decía que había vivido gran parte de o toda su vida sin usar el trinomio cuadrado perfecto y muchas otras cosas complejas que le enseñaron en la escuela. A pesas de mi fascinación por el Álgebra, tuve que ceder un espacio en mi mente para estar de acuerdo con este pensamiento.

La tarea que me quedó fue entonces definir qué significaba #simplicidad y qué era eso de ‘maximizar’ el trabajo no realizado. Aquí algunas pistas:

Simplicidad es:

  • Tener un equipo totalmente horizontal, sin títulos ni especialidades adheridas a la frente de  cada miembro, sin protocolos que seguir para comunicarse unos con otros, incluyendo al usuario, donde cada uno sea responsable de sincronizarse con los demás y que nadie le rinda cuentas a nadie. Son equipos altamente productivos.
  • Usar un framework que te permita adaptarte a los continuos cambios del entorno, que te permita inspeccionar tu situación y la de tu equipo y con el que puedas modificar tu comportamiento basado en la experiencia que vas adquiriendo. Un framework que no sea una fuente de artes adivinatorias, sino más bien que evolucione contigo.
  • Priorizar las características del producto y construir solo aquellas que entreguen valor al usuario y al negocio. Según algunos estudios más del 65% del software que se construye se deja de usar muy pronto o nunca llega a instalarse, así que ¿por qué no construir solo lo que el usuario verdaderamente necesita y que genere un alto valor para la organización? Construye solo necesario para obtener rápida retroalimentación.
  • No realizar estimaciones a mediano/largo plazo ni prometer una fecha fija de entrega. No componer planes súper elaborados sino planificar continuamente: planificar las entregas/salidas a producción, planificar las iteraciones o sprints, planificar cada día de trabajo. A la larga, los planes no son nada, pero la planificación lo es todo.
  • Usar herramientas simples, como tableros de tareas simples que estén a la vista de todos, tarjetas simples con lo que quiere el usuario (las historias de usuario: como <<usuario>> quiero <<hacer algo>> para <<obtener algún valor>>): no hagas nada a menos que su valor esté plenamente establecido. Elaborar la documentación suficiente para cubrir las necesidades de la organización.
    "Pero no más simples"
  • No usar trinomios cuadrados perfectos todo el tiempo. Einstein lo dijo, las cosas deberían hacerse lo más simple posible… para construir algo, una funcionalidad por ejemplo, usa la técnica de reusar-comprar-hacer. Consulta primero si ya la tienes o la tiene alguien cercano a ti. ¿No? Búscala entonces en el mercado. ¿No la encontraste? Fabrícala, pero hazlo de manera simple, sin artificios exagerados, no vuelvas el software más complejo de lo que es por naturaleza.
  • Aprender continuamente. Si conoces muchas cosas, encontrarás respuestas cada vez más simples a problemas cada vez más complejos, como los que surgen en la construcción de productos de software. Así que nunca pares de aprender. Y conviértete en maestro, pero recuerda, no se trata solo de decir las cosas, porque tu aprendiz las olvida; tampoco se trata solo de enseñar, porque quizás solo logres que él/ella las recuerde; involúcralo y verás que también aprende.

¿Qué más se les ocurre que es #simplicidad? Háganmelo saber por este medio o por cualquiera de los medios habituales de comunicación.


*El artículo al que me refiero lo encuentran haciendo clic aquí.