Ajedrez - antoniomartel.com

Archivos de Autor: antoniomartel

El Dueño del Producto

El Dueño del Producto (Product Owner) es el responsable de gestionar la Lista o Pila del Producto (Product Backlog) con la lista de funcionalidades que deberá tener el producto. La gestión de esa Pila del Producto implica que es también el responsable de que el producto final tenga el mayor valor posible y para ello deberá obtener el máximo valor del trabajo del Equipo de Desarrollo.

Para gestionar esa Pila del Producto deberá:

  • Expresar claramente los elementos de la Lista para que queden claros para todos y que esa Lista muestre  en qué estará trabajando el equipo en los próximos Sprints.
  • Asegurarse de que el Equipo de desarrollo entiende los elementos de la Lista con el detalle suficiente. El Dueño del Producto conoce bien su producto y lo que se quiere conseguir con él, por tanto es el responsable de que cada funcionalidad a implementar está bien detallada y explicada para el Equipo de Desarrollo.
  • Ordenar los elementos de la Lista de Producto para obtener los objetivos que tiene el producto lo antes posible, priorizando para ello los de más valor para el producto en el mercado o en su organización.
  • Optimizar el valor del trabajo del Equipo de Desarrollo. Para ello deberá hacer que mediante la Pila del Producto debidamente ordenada y priorizada el Equipo de Desarrollo trabaje en las funcionalidades de más valor en cada momento, evitando trabajo redundante o inútil en tareas de poco valor añadido.

Es además la única persona responsable de gestionar esa Lista de Producto. Eso implica que puede estar representando a varias personas o a un comité de Interesados (Stakeholders) en el producto en la empresa cliente que nos contrata o de la propia empresa que desarrolla el producto pero es sólo el Dueño del Producto el único responsable de expresar, detallar, optimizar y priorizar la Pila del Producto. Los Interesados en el producto pueden querer cambiar la Lista, añadir nuevas funcionalidades o darles otra prioridad pero deberán hablar primero con el Dueño del Producto para expresarle sus deseos y sólo él podrá cambiarla.

El rol del Dueño del Producto es un rol fundamental en todo proyecto (se llame como se llame según la metodología) por lo que toda la organización que contrata el desarrollo del producto debe respetar sus decisiones. Él es quién decide qué va a hacerse con el producto y que funcionalidades tendrá por lo que tiene un peso muy grande en que el producto final sea un éxito o no.

No se permite acceder al Equipo de Desarrollo para pedirle que realice funcionalidades distintas a las indicadas en la Lista de Producto. El Equipo de Desarrollo deberá actuar siempre en función de lo que diga el Product Owner y no cualquier otro Interesado en el producto.

El equipo de trabajo Scrum

En un proyecto gestionado con Scrum el equipo de trabajo estará formado por tres perfiles: el Dueño del Producto (Product Owner), el Scrum Master y el Equipo de Desarrollo (Development Team).

Ninguno de esos perfiles es el de jefe de proyectos o rol similar ya que estos equipos Scrum son autoorganizados. Esto quiere decir que ellos mismos deciden cómo llevar a cabo el trabajo y se reparten las tareas ¿Quién mejor que el Dueño del Producto para saber lo que hay que hacer y lo que se quiere conseguir? ¿Y quién mejor que el Equipo de Desarrollo para saber cómo hay que las tareas? Ellos dividirán las funcionalidades en tareas más pequeñas, las priorizarán y se las asignarán a si mismos. Ellos mismos se organizan el trabajo cada dos o tres semanas, lo que dure el Sprint.

Los equipos de trabajo también son multifuncionales. Esto significa que dentro del mismo equipo de trabajo encontraremos todos los perfiles necesarios para hacer el trabajo. Si hay que analizar algo lo hará algún miembro del equipo de trabajo. Si hay que realizar una tarea de administración de base de datos lo hará algún otro miembro del equipo (como en DevOps).

Por ejemplo, si necesitamos que se realicen frecuentemente este tipo de tareas de base de datos en el trabajo diario tendremos que contar con alguien con formación de DBA en el equipo. De esta forma el equipo de trabajo puede también autoorganizarse al no depender de otro departamento que tendrá sus propias prioridades y por el que habría que esperar a que realice la tarea. Mientras espera el equipo de desarrollo tendría que dedicarse a otras cosas, quizás menos importantes, hasta que se lleve a cabo la tarea por otro departamento o área de negocio.

Este modelo de equipos de trabajo de Scrum mejora la flexibilidad y la productividad al no estar tan encorsetado y tener un equipo más creativo e independiente.

Al realizar entregas iterativas e incrementales, es decir, realizar una entrega del producto cada vez mayor al finalizar cada Sprint, el equipo de trabajo obtiene feedback de la opinión de los usuarios y los interesados de forma frecuente. Este feedback le permitirá priorizar las próximas tareas y corregir la línea a seguir si es necesario. Estas entregas incrementales son de producto «Terminado» y probado. De esta forma siempre hay disponible una versión plenamente funcional del producto lista para ser usada.

Teoría de Scrum

Scrum es un marco de trabajo basado en el control de procesos empírico y por tanto no basado en predicciones o suposiciones. Esto quiere decir que el conocimiento procede de la experiencia, la observación de los hechos y de tomar decisiones basándose en lo que se
conoce. Las decisiones se toman en base a los resultados que se están viendo en el proyecto y no en base a planificaciones a largo plazo y a fechas de entrega supuestas al principio del proyecto.

Si en un proyecto tenemos que decidir si eliminamos o no una característica nueva de un producto o si es necesario dedicar más esfuerzo al desarrollo de una parte del proyecto para llegar a cumplir los límites establecidos, esta decisión la tomaremos basándonos en los datos sobre el esfuerzo que ya nos ha costado construir esta característica o similares o en los datos reales del tiempo que nos ha llevado construir las tareas ya realizadas. No nos basamos en un diagrama de Gantt con la predicción realizada al inicio del proyecto con lo que supuestamente iba a costarnos realizar estas tareas y con los límites que tenemos para cumplir la planificación, sean estos ya reales o no.

Todos los proyectos intentarán ser lo más previsibles posible y predecir cuando estarán acabadas las cosas pero, si con el objetivo de mejorar la previsibilidad usamos diagramas de Gantt, estimaciones y fechas de entrega a largo plazo con la información que teníamos al empezar el proyecto, podríamos estar teniendo el efecto contrario y volver al proyecto más imprevisible de lo que debería.

Si en lugar de trabajar y trabajar para que los planes sean exactos, asumimos que esos planes pueden estar equivocados y que son sólo eso, planes, podemos tomar las decisiones basándonos en los datos reales que vamos conociendo del proyecto para intentar ser lo más previsibles posible con los que tenemos actualmente.

Para mejorar la predictibilidad del proyecto y poder prever más fácilmente cuando vamos a acabar un conjunto de tareas o todo el proyecto, Scrum se basa en tres pilares:

Transparencia

Scrum entrega de forma iterativa pequeños incrementos del producto de forma que va añadiendo nuevas funcionalidades o características al producto final. La lista de cosas pendientes de terminar es pública, la lista de cosas terminadas y su estado es pública también. Se comparte además un lenguaje común entre todos los participantes en el proyectos de forma que sea claro y transparente para todo el mundo en qué estado está todo.

Cuando se dice que algo está ‘terminado’ debe significar lo mismo para todo el mundo y que no se barren dejabo de la alfombra con tal de hacer una marca en su casillero funcionalidades hechas pero que no han sido lo suficientemente probadas o no son prácticas. Las cosas están en estado ‘Hecho’ o ‘Terminado’ de forma transparente para todo los usuarios de Scrum sin ocultar nada a ninguno. Por eso se habla de tener una definición de ‘Hecho’ o de cuando algo puede decirse que está terminado.

Inspección

Otro pilar básico de Scrum, lo que se ha entregado y el estado en el que están las cosas se puede inspeccionar por los interesados en el proyecto o el dueño del producto (Product Owner) de forma que compruebe que está en perfecto funcionamiento y que el estado es real. Esto se hace en parte con la reunión de demo, con la transparencia de los entregables que se entregan de forma iterativa para que puedan ser probados y con las revisiones de lo que queda por hacer.  Estas revisiones no deben realizarse de forma tan frecuente que la inspección ralentice el trabajo.

Adaptación

Si en las revisiones de la inspección se comprueba que el producto, el plazo para construir o la nueva característica que se está construyendo se desvían de límites
aceptables, o que el producto resultante no será aprobado, deben hacerse cambios para intentar volver a límites dentro de lo aceptable. Estos ajustes deberán hacerse cuanto antes para evitar mayores desviaciones sobre lo que quede por realizar.

Adaptaciones o ajustes como estos son los que hacen que Scrum no sea predecible y no puedan darse largos plazos de predicción porque siempre se está adaptando el producto para mejorarlo y evitar mayores desviaciones sobre el producto ideal con el presupuesto que tenemos.

Para poder realizar estas inspecciones y sus correspondientes adaptaciones Scrum prescribe cuatro eventos o sucesos dentro de cada Sprint. Estos eventos son descritos con más detalle en otros post de este blog:

  • Reunión de Planificación del Sprint (Sprint Planning Meeting)
  • Scrum Diario (Daily Scrum)
  • Revisión del Sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)

Curso práctico Scrum – Agile 101

Publico en esta entrada los posibles contenidos que tendría el curso sobre Scrum/Agile 101. Los que me conocen o han leído mi libro saben que no será un curso de Scrum para seguir al pie de la letra, para eso ya están las guías de Scrum que publican Scrum.org o Scrum Alliance.

Será una guía práctica que te permite saber cómo implementar el Scrum que ya conoces de oídas o del que incluse ya tienes un certificado pero no sabes muy bien cómo llevarlo al día a día de tus proyectos.

El contenido estarían divididos en unidades y capítulos como los que pongo a continuación. Sólo falta que ustedes voten por añadir o incluir nuevos capítulos (aún faltan algunos):

  • Introducción y fundamentos de Scrum
  • Descripción reuniones, artefactos, participantes y roles de Scrum (con cheat list o hoja de resumen)
    • Tres capítulos: El rol de Product Owner, El rol de Scrum Master, El rol de los interesados o stakeholders.
    • Tres capítulos: El product backlog, el sprint backlog y la gráfica burndown
  • Cómo implantar Scrum en tus proyectos (con checklist para comprobar que se está haciendo lo importante)
  • Sección cómo… o qué hacer cuando… con Errores y dudas más habituales.
    • Capítulos Buenas prácticas del software (todo no es Scrum en un proyecto).
  • Qué certificación Scrum elegir
  • Scrum ventajas e inconvenientes
  • Estimaciones ágiles en tus proyectos
  • Lecciones aprendidas
  • Kanban
  • Entender y cómo usar la gráfica burndown.
Será un curso fácil de seguir en el que cada capítulo o unidad contaría con:
  • Uno PDF con texto explicando el contenido de la unidad
  • Otro PDF con texto y contenidos adicionales que no son estrictamente temario pero que ayudarán a completar y entender la información del temario.
  • Un vídeo en el que explico de viva voz los contenidos de la unidad siguiendo gráficas o slides de presentaciones.
  • Un ejemplo práctico basado en un caso real en el que pongo en contexto el contenido de la unidad.
  • Una batería de tests de 10 preguntas sobre la unidad y un ejercicio propuesto sobre el contenido de la unidad. En el siguiente paso a estos tests se darían las soluciones o claves al ejercicio propuesto.
La idea es que el contenido del curso pueda completarse con unas 40 o 50 horas de trabajo de forma que puedas terminarlo en 4 o 5 semanas si le dedicas unas 10 horas a la semana (1 hora diaria y un par horas más el fin  de semana podría ser un ejemplo).
Al final del curso habría un test con preguntas abiertas y cerradas junto a un ejercicio práctico que corregiría personalmente. Este test sería diferente para cada alumno y si se suspende se tendría derecho a otro intento (con otro examen diferente). Se entregaría a los aprobados un PDF con mi firma y un logo del curso que podría descargarse desde mi web con un enlace como el siguiente https:antoniomartel.comcertificadosmanuel-echevarria-agile101.pdf para que puedas entregar el link a cualquier empleador o jefe tuyo y pueda comprobar por el mismo que el PDF es original.
El contenido del curso está aún abierto. Si te gusta lo que vas leyendo del curso y te animas a contestar unas preguntas para saber qué te puede interesar y qué no, pásate por el enlace a la encuesta del curso Scrum – Agile 101 y me ayudarás a saber qué puede ser más interesante para los alumnos del curso.

Blueprint… o como quiera que se llame esto en 2017

He estado estos últimos meses ocupado intentando dar forma a un montón de ideas sobre qué hacer con el blog, posibles cursos de formación de las que ya te hablaba hace algún tiempo en la entrada Curso de Scrum Agile 101 y otras ideas sobre aplicaciones en la nube o coaching/mentoring online a través de Skype o algún otro sistema de vídeo conferencia.

Estas ideas se resumen en estos puntos que podrían convertirse en gérmenes de nuevos proyectos si veo el interés suficiente:

  • Web de formación online para la venta de cursos online sobre Agile, gestión de proyectos, gestión de recursos humanos, Lean Management o gestión a secas. Crearía una nueva web que podría llamarse Blueprint en la que mediante pago por Paypal recibirías enlaces a los contenidos que cree sobre estos temas. Veo aún pocas respuestas al cuestionario online para conocer más sobre el posible interés de los asistentes a los cursos ¿Se animan ahora a contestarlo haciendo clic en el cuestionario sobre formación online?
  • Web de asesoramiento online a través de sistema de vídeoconferencia como Skype o algún otro. Podría ser un complemento a la solución anterior en la que alguien o alguna empresa decide pagar por formación o asesoramiento más especializado al que se incluye en un curso genérico. En este formato se podrían resolver dudas o tratar problemas específicos que alguien podría tener cuando está implantando Scrum o tratando de llevar una gestión ágil de sus proyectos o empresas.
  • Nuevos libros que tengan el denominador común ‘Buenas prácticas en…’, por ejemplo, Buenas prácticas en el desarrollo de software o Buenas práctica en la gestión. Este último libro podría ser una segunda parte del libro Gestión práctica de proyectos con Scrum pero tener una visión más global a toda la gestión (recursos humanos, lean management, etc.) y no sólo a la gestión de proyectos software.
  • Aplicación en la nube para vender en formato de pago por uso a distribuidores o vendedores de productos en tiendas comerciales. Muchos de ellos aún usan un bloc de notas para tomar el pedido que le hacen sus clientes y que luego van de vuelta a su almacén a dejar la nota para preparar el pedido y llevar después la factura junto al pedido que se entrega al cliente. Ya existen sistemas similares pero con éste trataría de apostar por sencillez y economía en el presupuesto. Consistiría en una aplicación web que, desde el móvil, permita al vendedor tomar nota del pedido y que cuando llegue al almacén esté ya preparado y anotado en el sistema backend (también web). Habría que tener muchas cosas en cuenta como por ejemplo la integración con el sistema de contabilidad o de ventas que ya tengan o el sistema de impresión de albaranes o facturas (podrían ser simples pdfs).
Como ven muchas ideas para llevar a cabo y poco tiempo. 2017 se me va a quedar corto para todo esto. Ya estoy dando forma a algún curso de Scrum y haciendo sondeos con algunas empresas con comerciales o vendedores en la calle que puedan estar interesados. Si me dejan su opinión en los comentarios a esta entrada me ayudarán a saber cuáles son los sistemas en los que la gente podría tener más interés.
La idea de llamar a todos estos proyectos/empresa/startup como Blueprint viene de que en inglés los bocetos o esbozos de un nuevo edificios o el diseño ingeniería de un nuevo producto se hacía con tinta azul por lo que a esos dibujos se les llamaba blueprints.
Referencias:

Suscríbete