El proyecto de desarrollo de un producto se inicia para suplir algún objetivo o necesidad empresarial, ya sea de un cliente específico, un grupo de clientes o para una oportunidad de mercado. La Visión de Producto es la forma más utilizada para establecer este objetivo a alcanzar.
El desarrollo del producto y el equipo Scrum
El Product Owner es el responsable de definir el producto de forma iterativa e incremental. Debe definir, comunicar y mantener la Visión del Producto relativamente constante a lo largo del proyecto.
El Product Owner es único. Trabaja con los clientes del proyecto y cualquier otra parte interesada que pueda contribuir a comprender y definir la Visión del Producto.
El grupo de partes interesadas del proyecto también incluye a los propios usuarios del producto, quienes recibirán partes hechas de este para usar durante su desarrollo.
Antes de que comience el desarrollo de un producto, el proyecto suele pasar por una fase inicial en la que se realizan las definiciones y los preparativos básicos. Esta fase tiene una duración que depende de qué y cuánto es necesario definir y preparar. Es denominada por algunos como “prejuego” o, por otros, erróneamente como “Sprint Cero”, ya que el trabajo realizado en esta fase, como se verá más adelante, en modo alguno caracteriza un Sprint.
Aún en esta fase inicial, se decide quiénes serán las personas que trabajarán en el proyecto y formarán el Equipo de Scrum: además del Product Owner, los miembros del Equipo de Desarrollo y el ScrumMaster. Este proceso de selección varía de una organización a otra. Entre diferentes posibilidades, puede haber un departamento encargado de seleccionar al personal, un Product Owner o Scrum Master que elige al resto del equipo de la organización, o se puede asignar al proyecto un equipo que ya trabaja en conjunto, por ejemplo.
Roles de Scrum
El Equipo de Desarrollo realiza el trabajo de desarrollo del producto. Es multidisciplinar, lo que significa que tiene, en sus miembros, todos los conocimientos necesarios para llevar a cabo esta labor. El Equipo de Desarrollo también es autoorganizado. Es decir, define cómo llevará a cabo el trabajo y gestiona su progreso hacia las metas de negocio acordadas con el Product Owner.
El Scrum Master es responsable de asegurar que se eliminen los impedimentos que el Equipo de Desarrollo encuentre en su trabajo, actuando cuando sea necesario como agente de cambio en la organización. Estos impedimentos generan el riesgo de no alcanzar los objetivos.
El Scrum Master está presente y actúa como facilitador en todas las reuniones de Scrum, facilita el trabajo diario del Equipo de Desarrollo y las interacciones entre el Equipo de Desarrollo y el Product Owner. También enseña Scrum al Equipo Scrum y cómo autoorganizarse. El Scrum Master es lo más neutral posible y tiene soft skills. Es decir, habilidades conductuales y personales, para llevar a cabo su labor.
Todavía en esta fase de “prejuego”, puede ser necesario especificar una arquitectura básica del producto para reducir los riesgos de decisiones tardías que invalidarían lo que ya se ha producido. También puede ser necesario crear o adaptar una infraestructura que apoye el desarrollo del producto.
La idea es generar solo lo mínimo necesario y suficiente para reducir los riesgos, pero sin trabar el desarrollo del producto ni generar gran cantidad de desperdicios.
El Product Backlog es una lista priorizada: por ejemplo usando software, hoja de cálculo o notas adhesivas.
Antes del comienzo del desarrollo, el Product Owner inicia, a partir de la Visión del Producto, la creación de una lista ordenada (priorizada), incompleta y dinámica de elementos que representan lo que cree se producirá a lo largo del proyecto. Esta lista se llama Product Backlog.
Los elementos en la parte superior del Product Backlog son los más importantes en ese momento y, por esta razón, tienen más detalles para desarrollar primero. Los elementos inferiores tienen gradualmente menos detalles.
El Product Backlog inicial puede ser largo, desde elementos pequeños y bien detallados hasta elementos grandes e imprecisos. Pero también puede contener solo la cantidad de elementos necesarios para comenzar el desarrollo. El Product Backlog evolucionará a lo largo de todo el proyecto y se modificará con frecuencia agregando, restando, reordenando y modificando sus elementos.
User Story es la forma preferida por los equipos Ágiles para representar cada uno de los elementos del Product Backlog que se ocupan de las necesidades u objetivos comerciales, describiéndolos desde el punto de vista de los usuarios del producto y de una manera concisa, simple y ligera. Sin embargo, User Story no forma parte del marco de trabajo de Scrum y depende del equipo Scrum definir la mejor manera de representar los elementos del Product Backlog.
El Equipo Scrum ya está listo para comenzar el primero de varios ciclos del proyecto, en los que se llevará a cabo el trabajo de desarrollo del producto. Estos ciclos se denominan Sprints. El proyecto con Scrum sucede Sprint tras Sprint. De este modo, al final de un Sprint, inmediatamente comienza el siguiente.
Los eventos de Scrum (el propio Sprint y las reuniones Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective) tienen una duración máxima o fija definida, denominada timebox. Los timeboxes son importantes, ya que evitan el desperdicio, limitando el tiempo en el que se debe lograr una meta, además de ayudar a crear un ritmo o regularidad en el trabajo realizado.
¿Quieres saber más sobre Scrum?
- Formación Certified ScrumMaster (CSM)
- Contenido Todo sobre Agilidad
