Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Valor. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Valor. Mostrar todas las entradas

martes, diciembre 13, 2016

El Scrum Master extraordinario


En esta presentación hablo sobre que ser Scrum Master es principalmente acerca de liderazgo y coaching. No es un rol de gestión. No eres un gerente de proyectos ni de personas. Además, ser Scrum Master o Coach ágil definitivamente no es acerca de reforzar los procesos. 
Un Scrum Master extraordinario quiere o querrá que su equipo sea parte de esta carrera evolutiva – por ejemplo, haciéndolos partícipes de entrevistas con los usuarios o haciendo experimentos.
Si quieres llegar a ser un Scrum Master extraordinario enfoca tu energía en construir un entorno grandioso para tu equipo, probablemente así no tendrás que pasarte la vida, tu fantástica vida como Scrum Master, removiendo impedimentos. 
Además del trabajo de referencia, esta presentación está basada en mis artículos:
Puedes ver o descargar la presentación en el siguiente enlace:


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:


martes, noviembre 08, 2016

Más de cómo ser un Scrum Master extraordinario

Créditos de la foto: Dean Potter's solo walk at Taft Point in Yosemite by Photographer Jeff Cunningham.
Entender que Scrum no es una metodología sino un marco de trabajo (framework) que propone unos pocos lineamientos ayuda. No existen reglas que apliquen a todos y cada uno de los escenarios posibles donde se usa, solo algunas prácticas que han funcionado en algunas organizaciones con anterioridad.
Como Scrum Master o Coach ágil necesitas determinar o encontrar por tu cuenta lo que funciona para la Organización con la que estás involucrado. Si lo logras, lo conviertes en un destino, no en un proceso. De eso se trata el empirismo.
Ser Scrum Master o Coach ágil es principalmente acerca de liderazgo y coaching. No es un rol de gestión. No eres un gerente de proyectos ni de personas. Además, ser Scrum Master o Coach ágil definitivamente no es acerca de reforzar los procesos.
Scrum no está diseñado para Contadores. Algunas métricas son útiles para entender la salud de un equipo Scrum pero por lo general insistir en “cumplir con distintas KPI” (como por ejemplo ‘compromisos versus velocidad’) no ayuda. Si eres un Scrum Master excepcional seguro mantendrás a tu equipo libre de esta clase de presión.
Scrum no tiene mucho que decir sobre el proceso que habilita al Dueño de Producto a llenar el Backlog con historias de usuario de valor, usables y factibles. El descubrimiento del producto basado en Lean UX, Design Thinking o Lean Startup puede ayudar a esta causa. Un Scrum Master extraordinario quiere o querrá que su equipo sea parte de esta carrera evolutiva – por ejemplo, haciéndolos partícipes de entrevistas con los usuarios o haciendo experimentos.
La comunicación del equipo con los interesados no debería ser únicamente a través de un guardián o “proxy” (por ejemplo, solo a través del Dueño de Producto). Hacerlo así hiere de gravedad la transparencia y afecta negativamente el desempeño del equipo. Las revisiones de Sprint son una buena forma de presentar el valor entregado por el equipo durante el Sprint que está finalizando pero también es una buena manera de estar en contacto cercano con los interesados.
Si quieres llegar a ser un Scrum Master extraordinario enfoca tu energía en construir un entorno grandioso para tu equipo, probablemente así no tendrás que pasarte la vida, tu fantástica vida como Scrum Master, removiendo impedimentos.
De esta manera encontrarás ese balance del que habla mi amigo Johhny Ordoñez* y que requiere la Agilidad Moderna para seguir evolucionando y seguir transformándonos en mejores personas cada día, ese balance a nivel personal, de equipo, de grupo, de organización y de sociedad.
-----
Más sobre cómo ir de Scrum Master bueno a Scrum Master grandioso en http://www.gazafatonarioit.com/2015/05/de-scrum-master-bueno-scrum-master.html

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 16, 2016

Purga ágil de producto

Nuestro backlog del producto puede no tener una “buena salud”. Es decir, puede contener elementos que lo oscurezcan o que disminuyan su transparencia. Por lo general estos elementos tienden a ir hasta el fondo del backlog y muchas veces no son detectados hasta que es muy tarde en el proyecto, trayendo como consecuencia la extensión innecesaria del esfuerzo de desarrollo y la desmotivación del equipo debido a la gran capacidad energética que sus miembros invierten en estos elementos de poco o ningún valor para el producto y para el negocio.
Una de las técnicas que podemos aplicar al backlog y, por consiguiente, al producto, es esta de la purga del producto. Los detalles de cómo hacerlo lo encuentran en mi artículo en Pulse de LinkedIn:

miércoles, junio 01, 2016

Los Pilares de Scrum

Los Pilares de Scrum. Clic en la imagen para ampliar.

Sin ninguna duda, para que Scrum sea eficiente y efectivo, cada uno de estos pilares debe estar en pie, deben promoverse desde las personas y los equipos hasta toda la organización y deben apoyarse sin restricciones. Sin uno o más de estos pilares, cualquier implementación de Scrum está condenada a un cataclismo anunciado.

Déjame saber en el foro como te ha ido con la puesta en macha de estos pilares mientras implementas Scrum en tu organización.

Puedes descargar el PDF de la imagen en alta resolución haciendo clic aquí.

O me la solicitas a mi correo: lucho.salazar@gmail.com.



martes, abril 26, 2016

Del triángulo de hierro al triángulo ágil (modificado)


Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!


Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:
  • Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
  • Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
  • Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.


Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:


Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:



Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil