¿Qué son los planes de entrega?
A medida que las organizaciones de desarrollo crecen, necesitan reorganizarse en equipos más pequeños que puedan administrar eficazmente las unidades de trabajo. Estos equipos normalmente tienen sus programaciones de trabajo, paneles y otros procesos que satisfacen sus necesidades particulares en el contexto de los principales objetivos de la organización. Con el tiempo, las organizaciones podrían darse cuenta de que disfrutan de las ventajas de la red al consolidar sus procesos en torno a un marco coherente.
Un plan de entrega es una visualización de una o varias programaciones de trabajo. Está diseñado para proporcionar a los equipos y a la dirección una visión general de lo que cada equipo está planeando producir y cuándo lo va a hacer. Esto permite tomar decisiones que optimicen las inversiones en toda la organización.
Los equipos deben revisar periódicamente sus planes de entrega para asegurarse de que su programación de trabajo se alinee con las programaciones de otros equipos. Estas revisiones deberían abordar cuestiones como las siguientes:
- ¿Estamos seguros de que podemos ofrecer aquello a lo que nos hemos comprometido en nuestra programación actual?
- ¿Estamos seguros de que los equipos de los que dependemos ofrecerán lo que necesitamos en su programación actual?
- ¿Hay pausas en nuestra programación que podríamos llenar con trabajo?
- ¿Hay problemas con las dependencias dentro de un equipo o entre equipos?
Los planes de entrega agregan valor en cualquier momento del ciclo de vida de un proyecto. Dado que se generan dinámicamente en función de los trabajos pendientes del equipo, siempre están actualizados y ofrecen la información más reciente.
Vamos a unirnos al equipo web de Tailspin en su discusión.
Andy: Acabo de tener una gran reunión con la dirección de ingeniería. Les he enseñado el trabajo que estamos haciendo con Azure Boards y están entusiasmados con la idea de que se incorporen otros equipos.
Mara: ¡Genial! ¿Cuándo empezarán?
Andy: Esa es la mejor parte. ¡Ya tienen! Anoche el jefe del proyecto del motor de juegos creó un equipo con algunos sprints y empezó a agregar elementos de trabajo. Le he echado un vistazo rápido esta mañana y tiene buena pinta. Dejad que os muestre lo que están haciendo.
Andy accede al panel de sprints actual del motor de juegos. Junto con Mara revisa los elementos de trabajo con gran interés.
Andy: Mmm... Acabo de ver que no tienen previsto desplegar su beta al final de este sprint. ¿No esperamos integrar nuestra tabla de clasificación con la base de datos beta durante nuestro próximo sprint? No lo podemos hacer si no envían primero la versión beta.
Mara: Es un buen argumento. Tenemos una dependencia en ese equipo para generar esa entrega, de modo que podamos generar una propia.
Andy: Esto podría haber afectado bastante a nuestro siguiente sprint de productividad. Voy a llamarles para saber qué sucede.
Desafortunadamente, las estructuras de equipo más sofisticadas pueden dar lugar a brechas o retrasos en la comunicación. Cuando se bloquea un equipo, es posible que no pueda generar algo de lo que depende otro equipo. Esto podría no suponer un problema importante para un grupo de equipos pequeño que tienen reuniones diarias de todos los implicados. Sin embargo, a medida que los equipos se escalan en tamaño y ubicación, se puede volver insostenible que todo el mundo sepa lo que ocurre en todas partes. En este punto, las organizaciones deben pasar de un modelo de "inserción" puro (como anuncios en persona o por correo electrónico) a un modelo de "extracción" (donde los equipos pueden revisar y realizar un seguimiento de las programaciones de los demás).
Andy: Bien, acabo de hablar con el responsable de desarrollo. Me ha dicho que su equipo está bloqueado en el envío de la versión beta hasta que el equipo artístico vuelva de Cliffchella.
Mara: ¿El festival de música Mountain Top?
Andy: Sí, parece que es un gran acontecimiento en la comunidad del diseño y todo su equipo desaparece del mapa durante toda una semana para asistir al mismo. El equipo del motor de juegos está muy molesto porque ha pospuesto su programación tres semanas. De haber sabido que iba a ocurrir, se habrían asegurado de conseguir los artefactos que necesitaban con antelación. También se han disculpado por no habernos avisado antes. No se dieron cuenta de que íbamos a esperar su versión beta para enviar nuestra parte.
Mara: Bueno, al menos podemos alegrarnos de que el equipo del motor de juegos publique sus planes de sprint. Nos ha ayudado a encontrar este problema de dependencia lo suficientemente pronto como para ajustar nuestra programación.
Andy: Me gustaría que hubiera una forma de ver estos riesgos potenciales con mayor facilidad. Nuestros equipos tienen tantas dependencias en toda la empresa que no es posible asistir a todas las reuniones y suscribirse a todos los grupos de distribución.
Mara: Debemos crear un plan de entrega para poder ver los sprints del equipo en paralelo. Esto ayudará a los equipos a identificar más fácilmente cómo se ven afectadas las programaciones.
Recomendaciones para administrar varios equipos ágiles
Un enfoque de Agile, junto con Azure DevOps, puede mejorar considerablemente la transparencia y la previsibilidad del proyecto. Sin embargo, los proyectos pueden seguir teniendo problemas tradicionales, a menudo relacionados con el personal o la falta de comunicación. Estos son algunos aspectos que debe tener en cuenta a medida que escale sus esfuerzos ágiles.
Crear una relación de confianza en sus usuarios y procesos
Los primeros detractores de las implantaciones de Agile suelen ser escépticos sobre su capacidad de mejorar el rendimiento del equipo. Es importante que los directivos de la organización generen confianza ilustrando cómo producen los resultados las herramientas y los procesos. A veces, estos resultados son mejoras en la productividad y son fáciles de cuantificar. Pero no olvide resaltar las victorias del equipo que se producen al sortear posibles problemas, como desviaciones del calendario o problemas de calidad evitables. Mostrarán más entusiasmo a medida que empiecen a asociar las ventajas con el proceso que las consiguió.
Elevar la organización por encima del equipo (y el individuo)
Algunos equipos y personas se vuelven territoriales cuando se proponen nuevos procesos o políticas. En lugar de enmarcar las nuevas políticas como algo que expone de forma negativa el rendimiento de equipos o personas concretos, resalte cómo la nueva transparencia de toda la organización informa a todo el mundo de las expectativas. Disponer de un único lugar en el que cualquier persona pueda realizar un seguimiento de cómo se relaciona su trabajo con el cumplimiento de los objetivos de la organización le hará ver la importancia de su compromiso con el proceso.
Fomentar una cultura de transparencia
Desafortunadamente, el término "transparencia" está mal visto. Nadie pide más transparencia cuando todo va bien. En su lugar, se suele culpar a la transparencia (o la falta de esta) cuando los equipos tienen problemas. Incluso con todas las oportunidades de transparencia que ofrecen los equipos ágiles, sigue estando sujeta a la honestidad de las personas y los equipos. Resalte que uno de los motivos de la transparencia es poder identificar y solucionar posibles problemas antes de que sea demasiado tarde. Todo el mundo entiende que las personas a veces se encuentran en circunstancias que les impiden cumplir fechas límite de programación. Pero si no se sienten seguros al informar de noticias decepcionantes hasta el último momento, puede tener un impacto mucho más destructivo. La creación de un nivel de confort con transparencia puede empezar con el agradecimiento a la gente por informar de los retrasos esperados lo antes posible.