archivo

Archivo de la etiqueta: product owner

Una de las principales ventajas que tenemos si trabajamos con pilas de producto, además de tener un registro de todo lo que está pendiente por hacer (hasta el momento e independientemente de que se hagan todas o no, ya que seguirán apareciendo nuevas historias de usuario y otras se descartarán por la propia evolución del producto), es que el product owner o los responsables funcionales tienen todo un inventario de tareas que poder elegir, sobre las cuales deberán aplicar una prioridad, conociendo de antemano (puede ser pactado en función de las necesidades del sprint) cuál es la capacidad de trabajo máxima que se puede asumir en el sprint.

Independientemente de que después se afine el número de jornadas de cada historia, es fundamental (al menos lo pienso así) que cuando los usuarios están priorizando (o repriorizando) sepan cuánto peso va a tener cada una. De esta forma, tienes una lista de la compra (las historias de usuario), un presupuesto y se deberán quedar con lo que realmente les resulta más prioritario o más adecuado en este momento.

De esta forma los usuarios son conscientes realmente de la cantidad de trabajo que se puede asumir en un sprint y ellos mismos son responsables de elegir lo que se va a hacer.

Se requerirá algo de tiempo para que entren en la dinámica de los sprints y de que no deberían haber cambios mientras se está ejecutando, si bien, no debemos cerrar la puerta a excepciones debidamente justificados, aunque de esta manera perdamos pureza si aplicamos prácticas de Scrum (os recuerdo que las prácticas y metodologías son útiles pero no debemos olvidar que una de las bases del agilismo es la adaptación al cambio y a los contextos).

Desarrollamos software para satisfacer unas expectativas que un conjunto de personas tienen sobre un determinado sistema o producto. Para llegar a ese objetivo es absolutamente necesario ir incorporando en cada iteración el mayor valor posible en relación a la inversión realizada.

Para eso es importante que antes de cada sprint se haya generado la materia prima necesaria (definición de historias de usuario con el nivel de detalle suficiente y otros elementos necesarios para realizar el desarrollo) para que la priorización de las tareas por parte del product owner le permita seleccionar soluciones que permitan incrementar ese valor.

Sin embargo, esa materia prima no siempre llega o implica a trabajar con materia prima relacionada con historias de usuario menos prioritarias. ¿Cuál es la consecuencia de esto? El desarrollo se paraliza o bien no estamos sacando todo el partido posible a la inversión.

Esta es una realidad en el desarrollo de software independientemente de la metodología o enfoque que utilicemos, lo que rompe el carácter idílico o teórico de cualquier planteamiento.

Si no se define adecuadamente el alcance de una serie de historias de usuario porque el product owner no consigue encontrar una solución satisfactoria (hay que tener en cuenta que él puede ser el responsable de la línea de desarrollo del producto, pero puede haber decisiones estratégicas que tenga que consultar con terceros, como por ejemplo, sus jefes y entrar las mismas en un período de espera que no se corresponde con el ritmo que necesita el proyecto), el proyecto se termina resintiendo, puede entrar en una situación de bloqueo, con las consecuencias negativas indicadas en el párrafo anterior y que si se mantienen en el tiempo puede dar lugar a que fracase.

Para sacar el máximo rendimiento a una sesión en la que se está trabajando con el product owner en la definición de historias de usuario o requisitos, lo mejor es centrarnos en unos temas concretos y que tanto él como nosotros no terminemos saturados con un exceso de información.

Si se tienen estudiados y trabajados con anterioridad a la sesión, mucho mejor, ya que se partirá con una base que permitirá ser mucho más efectivo, aún cuando se descarte la solución o soluciones que se hayan pensado. No se trata de acertar a la primera, se trata de ir trabajando en la definición.

El exceso de información es difícil de procesar durante y después (sobre todo cuando se trata de aspectos de negocio o técnicos que tienen una cierta complejidad) y aunque pueda permitir delimitar el alcance de una serie de historias de usuario, nos daremos cuenta después de que hay una gran cantidad de detalles que se nos han escapado y es en esos detalles donde se encuentra realmente la clave para cumplir o no las expectativas del usuario.

¿Dónde está el límite? Cuando ya llevas trabajando un tiempo con el product owner y con tu equipo, sabrás donde tienes que poner el listón.

También es importante tener en cuenta la frecuencia con que podemos reunirnos con el product owner. Si está poco accesible y el proyecto tiene un ritmo medio o alto, es normal y casi necesario que pese a que no sea la mejor solución, tratar de aprovechar las sesiones para obtener toda la materia prima posible.

Esta circunstancia no es deseable ya que el nivel de implicación del product owner debe ser alto y como poco debe ajustarse a lo que el proyecto necesita.

Otro aspecto a tener en cuenta es el nivel de madurez de las historias de usuario con la que estás trabajando.

Cuando se trabaja en un módulo o en un subsistema nuevo y no se sabe por dónde empezar (ni usuarios, ni nosotros), no es malo poner sobre la mesa, las ideas generales que se tienen del mismo y en sesiones posteriores tratar de ir profundizando en aspectos concretos.

Es importante partir de esa visión general, aunque se tarde más de lo que nos gustaría en tenerla, ya que sirve como esquema para usuarios y desarrolladores, de lo contrario se corre el riesgo de que empecemos a desarrollar demasiado pronto y cuando hayamos completado un buen número de historias, el usuario se de cuenta de que las piezas no encajan y que eso no es lo que quiere o cómo lo quiere.

No hace falta, no es necesario, no es ágil, la especificación detallada porque cuando empecemos a desarrollar surgirán inevitablemente cambios, pero tampoco es bueno empezar casi a ciegas.

El retrabajo es volver a trabajar sobre un determinado desarrollo o la realización de nuevo de una serie de tareas (que puede ser de mayor o menor entidad) y que ha podido ser perfectamente evitable.

Tiene un impacto importante en los proyectos porque es tiempo perdido, esfuerzo que no ha proporcionado ningún valor al proyecto.

En el desarrollo de software estamos acostumbrados a hacer y a rehacer, la diferencia con el retrabajo es la diferencia entre la intención y la negligencia. Se ha podido desarrollar una funcionalidad con intención, de manera meditada y después el usuario descartarla porque una vez desarrollada no le termina de ver utilidad en el sistema.

Se ha ido con una idea concreta y se ha fallado, la negligencia es cuando sin esa reflexión necesaria u obviando soluciones más claras y probables se decide tirar hacia adelante.

Es cierto que entre intención y negligencia hay toda una escala de grises y que cada caso concreto merece su análisis. No obstante, las situaciones extremas son fácilmente identificables y cuando se mete la pata resulta complicado disfrazarlo.

El retrabajo puede ser motivado por el product owner pero también por los desarrolladores.

¿Se quiere mejorar la productividad en los desarrollos? No solo basta con simplificar o eliminar tareas que aportan un valor escaso o nulo con respecto a la inversión necesaria para realizarlas, también es muy importante evitar, en la medida de lo posible, el retrabajo.

No resulta positivo que los desarrolladores intervengan en exceso en la definición de las historias de usuario, más allá de dar salida a las especificaciones de usuario con prototipos (pantallazos) que permitan facilitar la comprensión al usuario del efecto que tiene la definición que ha realizado.

No debemos olvidar que el producto no es para los desarrolladores sino para los usuarios.

El otro extremo, en los que los desarrolladores son meros ejecutores de las historias de usuario tampoco es el mejor modelo, ya que los desarrolladores pueden detectar funcionalidades que no terminan de encajar en el sistema y/o que tienen una complejidad que está muy por encima de los beneficios o valor que va a proporcionar a los usuarios.

Alistair Cockburn lo resume bien en la siguiente reflexión (traducción libre): “Un proyecto sufre cuando los desarrolladores no mencionan los problemas que descubren. El proyecto pierde la interacción creativa de programadores ofreciendo sus conocimientos para perfeccionar las peticiones de los clientes”.

La mejor solución es la doble dirección, es decir, desarrolladores y usuarios realizando y conociendo sus responsabilidades y funciones, colaborando, ofreciendo conocimiento y abriendo debates cuando sea necesario.

Existen multitud de variables que pueden echar al traste un proyecto. Una de ellas, tal vez una de las más importantes, es la falta de implicación por parte de la persona designada por el área usuaria para realizar este trabajo.

A veces, no falla la implicación y sí la actitud, cuando el responsable funcional entra en una espiral de ordeno y mando, en la que no se deja aconsejar.

El problema se hace más grande cuando, además de lo anterior, el responsable funcional no asume sus errores de manera que explícita o implícitamente hace que los mismos recaigan sobre el equipo de desarrollo.

Innumerables proyectos han fracasado por estos motivos.

Lo mejor es que desde un principio quede claro cuál es el rol del responsable funcional: definir la línea de desarrollo del producto, estableciendo prioridades y seleccionando las tareas que se hacen en cada momento, es el responsable de coordinar el área usuaria para obtener información adicional en el caso de que sea necesario (que lo será en muchos casos) y es el interfaz de comunicación entre esos usuarios y el equipo de desarrollo (lo cual no quiere decir que los usuarios sean un elemento aislado y que los desarrolladores no puedan comprobar directamente cuáles son sus sensaciones).

Teniendo muy claro que sus decisiones producen un impacto en el proyecto, es decir, si se equivoca a la hora de definir una historia de usuario o si se equivoca en las prioridades, hay repercusiones, en el sentido de que el proyecto tiene un presupuesto limitado y en cada iteración va menguando.

No se trata de que no se pueda equivocar, ya que para eso está el enfoque iterativo incremental y el feedback, sino de que las decisiones que tome las haga con intención, disminuyendo las tentativas orientadas al prueba y error.

Desde un principio hay que definir las reglas del juego y es muy probable, sobre todo para responsables funcionales sin experiencia en la participación en proyectos de desarrollo de software, que haya que ir realizando recordatorios puntuales de las mismas.

Una cosa es que desde un principio queden claras las reglas y otra que el responsable funcional las quiera cumplir. Si pasa de ellas y no se consigue normalizar la situación, no quedará otra que escalar el problema porque de lo contrario el proyecto y el producto serán los principales perjudicados.

Con el objeto de mantener un equilibrio en el proyecto es fundamental gestionar las expectativas, de manera que el responsable funcional no se lleve sorpresas. También, por nuestra parte, es importante que no nos intercambiemos los papeles, es decir, él responsable funcional debe elegir los objetivos de nuestra iteración y él no debe meterse (salvo que requiera alguna aclaración) en el esfuerzo estimado para cada una.

Es muy complicado ambas cosas, que el desarrollador no se meta a product owner y que el product owner no discuta la duración seleccionada para cada tarea, en su afán de tratar de que se asuma la mayor cantidad de trabajo posible, olvidando o ignorando que el cumplimiento de los compromisos se ve muy perjudicado cuando la capacidad del equipo de proyecto está sobresaturada.

Lo primero se resuelve aceptando cuál es el verdadero rol del equipo de desarrollo (una cosa es aconsejar y otra definir la línea de desarrollo) y la segunda con mucho diálogo y con la consolidación de una relación de confianza.

Es más difícil solucionar lo segundo que lo primero, de hecho, será complicado que con relativa frecuencia no se nos pidan explicaciones por tal o cual estimación, aceptemos que esto será así, dando las explicaciones que sean oportunas.

Otra circunstancia que puede darse es que tengamos en la pila de producto historias de usuario suficientes para completar la capacidad de trabajo del sprint, pero que muchas de ellas no se consideren prioritarias o lo sean bastante menos que otras que todavía no se han terminado de definir por completo, pero sobre las que se sabe que durante el período de ejecución del sprint van a terminar de completarse y que va a haber tiempo para abordar algunas de ellas.

No se trata en este caso, no tanto de no poder esperar sino de tratar de conseguir siempre el mayor valor posible del producto con respecto a la cantidad de esfuerzo invertido. Lo fácil sería tomar la decisión de trabajar sobre las historias de usuario que están definidas, incluso en muchos casos será la decisión acertada, pero no podemos cerrarnos a la posibilidad de que en determinadas circunstancias lo aconsejable sea dejar la pila de sprint abierta con una capacidad reservada para la realización de estas tareas.

En este caso, hay que anticiparnos con el objetivo de no desperdiciar capacidad de trabajo, de manera que si finalmente no da tiempo de definir algunas historias de usuario, se opte por trabajar con las que están definidos.

¿Y por qué no se han tenido definidas esas historias de usuario antes? Pues porque no siempre se puede, por mucha voluntad que le ponga el product owner o el equipo de desarrollo. Lo mismo uno y otros han tenido que dedicar su esfuerzo en otros objetivos del proyecto que hasta ahora han sido más prioritarios o el product owner ha tenido que consultar con terceros determinadas decisiones que le trascienden y cuya resolución se mueve en unos tiempos distintos al del proyecto y sus sprints.

Tener la pila abierta de esa manera es poco ortodoxo, lo sé, pero cada proyecto tiene sus propias circunstancias y en base a ello tanto el product owner como nosotros tenemos que tomar decisiones, con fundamento, con intención, evitando la arbitrariedad, siempre pensando en lo que más conviene al proyecto y al producto y con la mente abierta a hacer excepciones puntuales o no tan puntuales sobre la estrategia que venimos aplicando.