En cualquier enfoque ágil un pilar fundamental es realizar entregas (releases) frecuentes al cliente, es decir, poner en producción nuevas versiones del producto. El trabajo de desarrollo es organizado en iteraciones (sprints) cuya duración no debería ser superior a un mes (la frecuencia recomendada por XP o Scrum). Cuando el producto ya está en producción (se ha hecho al menos una entrega al cliente) las siguientes entregas podrían coincidir con las iteraciones, es decir, cada versión resultante de la iteración podría ser puesta en producción. Sin embargo, cuando se trata de la primera entrega del producto, o cuando se trata de una reforma de envergadura, probablemente no será suficiente con un mes de trabajo para conseguir un nivel operacional mínimo para ponerla en producción. Así pues, para respetar el hecho de que cada iteración (sprint) no debería extenderse más allá de un mes, en el caso de entregas que no puedan desarrollarse en una sola iteración, éstas requerirán ser abordadas en una serie de iteraciones.
La primera entrega del producto podría coincidir con la idea tradicional de proyecto de desarrollo. Pero una vez que el producto está en producción el objetivo será conseguir una siguiente entrega a través de una o más iteraciones. Estas siguientes entregas podrían llamarse "proyectos" pero parece más natural llamarlas entregas, o simplemente versiones cuando coinciden con ser el resultado de una sola iteración.
Hay una situación particular en la cual el concepto de proyecto resulta adecuado en el contexto de desarrollo iterativo e incremental. Esta es cuando se hace un cambio de envergadura en el producto, el cual obliga a organizar una serie de unidades de trabajo en varias iteraciones, quizás incluso dedicando recursos específicos para dicho cambio. Así, durante sucesivas iteraciones, de forma exclusiva o en conjunto con otros cambios, se lleva a cabo el trabajo asociado al proyecto. Los cambio asociados al proyecto podrían incluirse en las posibles entregas que se realicen durante la duración del proyecto o pueden hacerse disponibles sólo en la entrega que coincide con el término del proyecto. En el ámbito ágil este concepto de proyecto coincide con el término theme, el cual se refiere a un conjunto de Historias de Usuario relacionadas en cuanto a la funcionalidad o características que involucran.
Según lo explicado, queda en evidencia que cuando se utiliza un enfoque iterativo e incremental, el foco se centra en el producto más que en un determinado proyecto asociado al producto. Este matiz es similar al que se puede establecer al diferenciar un Product Manager respecto de un Project Manager. El trabajo del Product Manager está más orientado a los clientes del producto y dicho trabajo persiste mientras existe el producto. Por contraparte, la duración del trabajo del Project Manager es la duración del proyecto y su interés se centra en la gestión exitosa del proyecto, la cual debe estar alineada con la visión del producto pero restringida a unos plazos, alcance y costos específicos del proyecto. En Scrum el Product Owner tiene ingredientes de ambos, de Product Manager y de Project Manager, pero en mayor medida se acerca al primero.
Finalmente, ¿cómo se lleva a la práctica el concepto de proyecto cuando se trabaja con ítems (unidades de trabajo) en el Product Backlog o ítems en una determinada iteración (en el Sprint)?. En mi experiencia ha sido suficiente con asociar a un ítem su proyecto (si lo tiene) y luego al consultar ítems poder aprovechar dicho dato para realizar agrupaciones, filtros y selecciones de ítems. Otra característica que nos ha resultado útil es que un proyecto pueda tener asociado trabajo en diferentes productos. En este caso, cada producto tiene sus propias unidades de trabajo, y contando con el dato del proyecto se pueden tomar decisiones de coordinación entre las versiones de varios productos. En TUNE-UP Process estas funcionalidades están disponibles, y además se ofrece la posibilidad de realizar un seguimiento detallado del proyecto mediante un dashboard para este fin, el cual incluye entre otra información una gráfica Burndown para el proyecto, la cual permite supervisar su alcance global, es decir, más allá de la supervisión de cada sprint.
Patricio Letelier
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com
No hay comentarios:
Publicar un comentario