Buscar en Gazafatonario IT

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

miércoles, marzo 29, 2017

Guía Supernumeraria para un Dueño de Producto Virtuoso


El Dueño de Producto es un nuevo rol para muchas, en realidad para la gran mayoría de las compañías. Y de estas, un gran conjunto no lo entiende o simplemente no ha tenido las mejores experiencias con sus responsabilidades. En términos generales, el Dueño de Producto es un ilustre olvidado.
Mientras que la promesa de un equipo de TI es diseñar y construir el mejor producto o servicio que el negocio necesita, una solución con Valor, dadas las restricciones de tiempo, presupuesto, tecnología, entre otras, la promesa de un Dueño de Producto es trabajar con el equipo en la priorización y negociación de características del producto, lograr no solo que el equipo de desarrollo aprenda del negocio sino de lo que significa Valor para el negocio.
La proposición de valor del Dueño de Producto también incluye mantener al equipo motivado y contribuir desde su posición a que se cumplan los compromisos con los usuarios o consumidores que él mismo representa. También, mientras la organización confía en la mentalidad Ágil del equipo y del Scrum Master para mantener la alineación con las áreas de TI, delega en el Dueño de Producto la responsabilidad de mejorar los tiempos de salida al mercado a la vez que optimizar el retorno de la inversión.
El Dueño de Producto es precisamente el dueño de la visión del producto, el plan del negocio, las ganancias, el plan de entregas y de un backlog de producto cuidadosamente refinado y priorizado con precisión para que el equipo pueda trabajar sin tropiezos. Mientras el trabajo del equipo es construir correctamente el producto, el Dueño de Producto debe entregar el producto correcto. ¡Es un juego de palabras, pero es verdad!
El Dueño de Producto es o será el encargado de devolver el encanto que muchos usuarios, socios y empleados perdieron en el pasado a raíz de las soluciones de TI disfuncionales que estábamos produciendo. Eran soluciones con muy poco o ningún sentido de la calidad, tardaban años en llegar al mercado y carecían de la innovación necesaria para resolver problemas reales del negocio. Las cosas así, la responsabilidad moral de un Dueño de Producto es una carga pesada que todos en la Organización tenemos obligación de ayudar a soportar mediante el apoyo incondicional a su trabajo.
Scrum en particular y el enfoque Ágil en general proporcionan las herramientas suficientes para que el Dueño de Producto cumpla con sus responsabilidades de manera decidida y franca, para conectar efectivamente los deseos y necesidades de los usuarios y el negocio con el equipo de desarrollo, de forma dinámica y receptiva.
En su libro “Agile Product Management with Scrum”, Roman Pichler describe ampliamente las principales actividades que un Dueño de Producto de talante realiza:
Definir y manejar la Visión del Producto

Una visión efectiva del producto responde o debería responder a las siguientes cuestiones:
  • ¿Quién comprará o usará el producto? ¿Quién es el consumidor o usuario final?
  • ¿Qué necesidades cubrirá el producto? ¿Qué valor agrega el producto al usuario o a la organización?
  • ¿Cuáles son los atributos críticos del producto para que este sea exitoso?
  • ¿Cómo y qué tantas ganancias tendrá la compañía con el producto?
Entre otras no menos importantes. En resumen, la visión debería comunicar la esencia del futuro producto de una manera concisa y describir un objetivo compartido que conduzca la creación del producto pero que sea lo suficientemente amplio como para facilitar la creatividad del equipo que lo desarrollará.
Un aspecto importante a considerar aquí es el conocido como el Mínimo Producto Viable (MVP) o, a veces, el Mínimo Producto Mercadeable. Este es un producto con la mínima funcionalidad que cubra algunas de las necesidades básicas de los usuarios y genere valor a la organización. Un Dueño de Producto hábil sabe que el producto debe estar en funcionamiento muy pronto y que este debe entregarse en pequeños incrementos en cortos lapsos de tiempo. Esto reduce la incertidumbre y aumenta el aprendizaje no solo sobre el producto sino sobre los hábitos de consumo de sus usuarios finales.
Para saber más sobre cómo crear la Visión del Producto, pueden ver este Webinar sobre Inception Ágil que facilité con mi gran amigo Jorge Abad:
Es prácticamente imposible, por no decir menos, establecer una visión del producto apropiada sin tener en cuenta el factor humano. En otras palabras, definir una correcta visión del producto es un acto puramente humano.
Trabajar con el backlog de Producto

Este artefacto hermosamente simple sufre muchas veces de la falta de atención apropiada tanto por parte del Dueño de Producto como del mismo equipo de desarrollo.
Para quienes no están familiarizados con la herramienta, es una lista priorizada de los elementos necesarios para darle vida al producto. Estos elementos incluyen la exploración de las necesidades de los usuarios, pero también puede incluir una descripción de opciones técnicas y de requisitos funcionales y no funcionales, así como el trabajo necesario para poner a punto los distintos ambientes de trabajo.
Uno de los aspectos más importantes que debe estar en el radar del Dueño de Producto es este del Valor de cada uno de los elementos del backlog. El valor es un factor común de priorización de sus elementos. El Dueño de Producto sabe que debe entregar primero los elementos de mayor valor. Al agregar nuevos elementos, el Dueño de Producto no solo revisa o establece el valor de estos nuevos elementos sino que reexamina el valor de los existentes.
También hemos aprendido que un Dueño de Producto experimentado va adelante del equipo en cuanto al conocimiento detallado que tiene de los elementos del producto. Quizás uno o dos sprints más allá del actual y está continuamente practicando refinamiento al producto.
Para profundizar más en estos asuntos pueden leer mis artículos:
Sobre gestión del producto en general, en el que abordo cuáles son los atributos (DEEP) de un buen backlog de producto:
Sobre refinamiento del producto en particular:
Planear las entregas

En su libro Agile Estimating and Planning, el gran Mike Cohn escribió que “Planificar... es una búsqueda de valor”. Otra vez emerge el Valor como factor determinante a la hora de planear las entregas de un producto. También hemos aprendido que este plan de entregas no puede ir encadenado a las aristas de tiempo, costo y alcance de manera fija e inquebrantable. Es posible adherirse a una de ellas, quizás a dos, pero no a las tres en simultáneo.
Otra vez: la meta principal de todo Dueño de Producto es entregar el producto correcto. De allí que la planificación de esta entrega de producto, en pequeñas entregas incrementales es una tarea fundamental de todo Dueño de Producto hábil. Sobre este asunto en particular pueden leer mi artículo:
En donde agrego el atributo de Valor a las ya ampliamente difundidas bases de Ágil y propongo El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor.
Colaborar con las Reuniones del Sprint

¡Scrum!

Las reuniones son oportunidades de Conversación cara a cara y, en el caso específico de Scrum, son momentos propicios para la inspección y adaptación, pilares fundamentales de la mentalidad Ágil. Y el Dueño de Producto hace parte del equipo Scrum, así que bienvenido su aporte estratégico y táctico al equipo durante estas conversaciones.
Para saber más sobre los distintos eventos en Scrum pueden ir a mi Gazafatonario:

En conclusión, el Dueño de Producto es uno de los ejes fundamentales sobre los cuales avanzan los equipos Scrum como un todo hacia la búsqueda de un objetivo común: la generación de valor a la vez que responder al cambio de manera eficiente. En particular, el Dueño de Producto se constituye en una arista esencial para la correcta gestión ágil del producto pero sobre todo para entregar productos cuyos componentes generen resonancia entre ellos e impacten el modus vivendi de sus consumidores, nosotros la humanidad.

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:

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, octubre 28, 2015

El enfoque Iterativo e Incremental, ¡una vez más!


El enfoque Iterativo e Incremental, ¡una vez más!
Mucho se habla de esto, de hecho iba a titular este artículo: “Todavía otra lección más sobre el enfoque iterativo e incremental para construir productos (de software)” pero entonces pensé en cambiar ligeramente la dirección del tema… Pero no tanto.
Iterativo e incremental son de esos principios que pueden resultar artificiosos para quienes intentan aplicarlos por primera vez. Su interpretación se  presta a confusiones y a desacuerdos y finalmente los productos que surgen de los así llamados ‘proyectos iterativos e incrementales’ terminan siendo una colcha de retazos, pedazos de funcionalidades que no se integran bien entre sí y que terminan ocasionando más problemas al usuario de los que intentan resolver.
En breve, ‘iterativo’ quiere decir ‘en períodos cortos de tiempo’. El término clave es ‘cortos’. ¡De menos de un mes, gritamos a los cuatro vientos los agilistas! Durante este período se diseña y se construye, en el sentido extenso de la expresión ‘diseñar y construir’, una parte del producto que llamamos ‘incremento’. Pero no es cualquier parte del producto la que se construye. Sin embargo no voy a detenerme mucho en ello. Pueden consultar más sobre ‘Iterativo e Incremental’ aquí, gracias a Javier Garzás, o en cualquiera de estos lugares:
O algunos de los míos:
Entre muchos otros. Y no puedo terminar esta breve presentación del tema sin referirme a esa imagen que ya se está convirtiendo en icónica y que ilustra muy bien este par de conceptos: se trata de la imagen de Henrik Kniberg, actualizada:

Pero a dónde verdaderamente quiero llegar esta vez es a este asunto del ‘Incremento de Valor’, ¿qué quiere decir eso realmente? Así que empecemos de nuevo:

El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor

Resuelta la trama de ‘Iterativo e Incremental’, lo que queda es entender qué significa ‘producto de Valor para el cliente o usuario’, qué significa ‘Desarrollo de producto dirigido por el Valor’. Vamos a ver si lo logramos entender:
En este enfoque, conocido también como ‘desarrollo guiado por el valor’ o VDD, por sus siglas en inglés, el cliente o usuario juega un papel primordial:
  • Es el cliente o usuario del producto quien determina o establece su valor, no el equipo de desarrollo
  • Es el usuario o cliente quien solicita el producto, o esa porción del producto, es decir, fue ese usuario o cliente quien priorizó el desarrollo de ese incremento en ese momento del tiempo (del proyecto)
  • El incremento resuelve un problema pequeño o parte de un problema grande al usuario
  • Le permite obtener retorno de la inversión que está haciendo (ROI): reduce los costos para el negocio o aumenta las ganancias… ¡o ambas cosas a la vez! En últimas, al entregar el producto hay o se genera una compensación para el usuario, además de la satisfacción aumentada y de la felicidad recargada, no solo de él como receptor de un objeto de valor, sino de todo el equipo de desarrollo y, por qué no, de todos los demás interesados, dado el logro de objetivos.

Foto de FreeDigitalPhoto.Net
  • Varias o muchas personas se benefician de inmediato con el producto (con su uso), ya sea porque lo están usando directamente (usuarios, clientes) o porque otros lo usan (patrocinadores, otros interesados, alta gerencia, etcétera)
  • El producto está diseñado para humanos, sus componentes hacen resonancia unos con otros e impactan el modus vivendi de las personas, aunque solo para mejorarlo
Human-driven development o HDD –Desarrollo de Software Para Personas. Foto de FreeDigitalPhoto.Net 
  • El riesgo del proyecto, inherente a cualquier tentativa de construcción de software, se reduce dramáticamente luego de las primeras entregas. Si hemos de fallar, que sea rápido, en porciones pequeñas y muy barato. A partir de allí, el ascenso hacia el logro de los objetivos es vertiginoso y siempre positivo.
  • El crecimiento del producto es orgánico, se parte de un mínimo producto viable o ‘mercadeable’ (MVP por sus siglas en inglés) y el producto completo va creciendo alrededor de este MVP, en entregas sucesivas y constantes. Y ya que llegamos a este apartado, olvidémonos del “viable” en el MVP, la V ahora es por Valor, como en Mínimo Producto de Valor. Recordemos que este MVP es el primer objeto con el que el cliente o usuario podrá interactuar, así que el impacto a conseguir debe ser máximo, debemos hacer que se convierta en un objeto de deseo. A propósito de deseo, entonces en vez de llamarlo MVP, nombrémoslo MDP, por las siglas en inglés de Mínimo Producto Deseable. Es un juego de palabras, apenas para mi Gazafatonario, pero ayudan a entender lo que queremos realmente con esta generación de valor desde las primeras de cambio.
  • Se disminuye considerablemente la incertidumbre, tanto la del proyecto como un todo, como la del producto que se empieza a usar. Esto ocurre porque con cada entrega el equipo conoce mejor a su usuario y aprende mucho más rápido de sus necesidades y ambiciones. A la postre, el equipo construye el software para aprender y medir el impacto del uso real del producto. Después de todo, el proceso de creación de conocimiento se acelera si ellos entregan rápido un conjunto mínimo de elementos del producto priorizados por los objetivos que el cliente quiere alcanzar.
No son las únicas condiciones, si acaso algunas de las más importantes. En cualquier caso, la próxima vez que te soliciten un plan de trabajo para un proyecto, ya sea a mediano o a largo plazo, ten el coraje de responder: ¿quieres un plan a mediano/largo plazo o Valor en términos cortos?
Nota: este artículo se publicó originalmente en Pulse de LinkedIn en el siguiente enlace: https://www.linkedin.com/pulse/iterativo-e-incremental-luis-antonio-salazar-caraballo