Soy Scrum Master en un proyecto con tres desarrolladores, una persona de control de calidad, un diseñador y yo. Trabajamos en un proyecto que heredamos hace unos tres años, un sitio web "portal" y una aplicación cordova. Ahora estamos planeando reducir el equipo a un equipo mínimo de un desarrollador, con el objetivo de terminar todo lo crítico en las próximas cinco semanas antes de hacerlo.
El proyecto siempre ha tenido problemas con el problema de la deuda técnica que heredamos junto con el código base, y ahora al equipo le gustaría ver si hay alguna forma en que podamos integrar este trabajo sin que nos "desvíe" de las principales funciones y errores. queremos completar antes de que terminen nuestras cinco semanas.
Es importante que el equipo se concentre tanto como sea posible en las características y los errores porque han estado trabajando en algunas páginas de la aplicación durante meses y están emocionados de terminar con ella. Para su moral, quiero asegurarme de que mantengamos ese enfoque, pero también creen firmemente que algunas de estas tareas de ingeniería deben realizarse.
¿Cómo debemos equilibrar estas dos cosas para que los desarrolladores aún sientan que pueden progresar en las iniciativas de ingeniería mientras se mantienen enfocados en terminar el conjunto de características?
¿Por qué vas a un equipo mínimo? Parece que el plan a largo plazo para estas aplicaciones/sitios es que tengan una muerte lenta. En ese caso, ¿a quién le importa pagar la deuda técnica?
La deuda técnica eleva el costo del trabajo futuro. Esto no es un problema si no habrá ningún trabajo futuro significativo.
Como nota al margen, ha tenido este proyecto durante tres años: debería haber estado pagando la deuda técnica durante los últimos tres años. Pagarlo antes habría hecho que el resto del tiempo de su proyecto fuera más productivo.
Lo que puede ayudar es pensar en todo en términos del valor que ofrece.
El valor de terminar el conjunto de características es obvio, pero el valor de las tareas de la deuda técnica requiere un poco de reflexión.
Por ejemplo, digamos que liquidar un poco la deuda técnica hace que sea más fácil agregar nuevas funciones. Esto luego da una pequeña recompensa de eficiencia con cada nueva característica que se agrega. Puede argumentar que este tipo de trabajo de deuda técnica tiene más valor que simplemente agregar una sola característica nueva.
Ahora comience a priorizar su deuda técnica junto con el nuevo trabajo de desarrollo. Es posible que descubra que ciertos tipos de deuda técnica terminan ocupando un lugar bastante alto en sus prioridades. Otros tipos pueden ofrecer menos valor en el mundo real y, por lo tanto, terminar siendo de menor prioridad.
han estado trabajando en algunas páginas de la aplicación ahora durante meses y están (sic) emocionados de terminar con ella [...] pero también sienten firmemente que algunas de estas iniciativas de ingeniería deberían llevarse a cabo.
Si esa es la razón principal por la que evitaría liquidar la deuda técnica, entonces el primer paso es hablar con el equipo y averiguar cuál creen que es más importante.
Sin embargo, es más probable que no pueda elegir simplemente retrasar el plazo de 5 semanas para comenzar a limpiar la deuda técnica. Sin embargo, eso no significa (necesariamente) que simplemente puedas ignorarlo .
El hecho de que, una vez que haya "terminado [ed] todo lo crítico", el equipo se reduce a un solo desarrollador, a pesar de la gran cantidad de deuda técnica, es preocupante. ¿Ese promotor se va a centrar únicamente en sanear la deuda? ¿O se centrará también en el mantenimiento, los requisitos de menor prioridad y otros proyectos? Si es lo último, entonces la deuda simplemente se acumulará y el código del proyecto puede terminar colapsando bajo el peso de sus propias imperfecciones.
Ya sea que se ocupe de la deuda ahora (potencialmente retrasando la fecha límite) o la trate después , de cualquier manera necesitará tener suficiente tiempo y esfuerzo presupuestado para atenderla. Si no lo hace, lo pagará más adelante.
Tenga en cuenta, sin embargo, que esto se aplica solo bajo el supuesto de que su proyecto se mantendrá indefinidamente . Si no es así , la deuda técnica se vuelve menos importante, especialmente a medida que se acerca la 'fecha de lanzamiento'.
También podría incorporar el trabajo de la deuda tecnológica en la definición de hecho. Es decir, el 10 o el 20 % del tiempo dedicado a la entrega de nuevas funciones debe dedicarse a tareas de deuda tecnológica, como la refactorización del código heredado.
Esto funcionará para artículos pequeños y podría cambiar el enfoque de los equipos sobre la deuda tecnológica. Luego, podría introducir elementos de mayor deuda en la cartera de productos y priorizar junto con las funciones.
Está tratando de equilibrar la deuda técnica con las características del producto dentro del Equipo de desarrollo, pero esto es una violación de los principios básicos de Scrum. El equipo debe hacer visible la deuda técnica y recomendar soluciones, pero la responsabilidad de gestionar la deuda pertenece al Product Owner.
Soy Scrum Master en un proyecto con tres desarrolladores, una persona de control de calidad, un diseñador y yo.
Te falta un Product Owner claramente definido. Scrum requiere la participación activa de los tres roles (Propietario del producto, Scrum Master y Equipo de desarrollo) para que el marco funcione de manera efectiva.
¿Cómo debemos equilibrar estas dos cosas para que los desarrolladores aún sientan que pueden progresar en las iniciativas de ingeniería mientras se mantienen enfocados en terminar el conjunto de características?
Todo el trabajo contiene gastos generales, incluida la refactorización y el "pago de intereses" sobre la deuda técnica existente. Eso debe incluirse en sus estimaciones cuando acepta el trabajo en cada sprint.
Sin embargo, programar el trabajo que consume una capacidad sustancial del equipo nunca es algo que el equipo de desarrollo deba hacer directamente. El rol del propietario del producto es el único responsable del contenido y la priorización de los elementos de la cartera de productos, y es su decisión si asigna o no los recursos del equipo para pagar la deuda técnica o para nuevas funciones.
Por supuesto, si hay una deuda sustancial y no se paga, eso actúa como un lastre para la productividad del equipo. Sin embargo, equilibrar ese arrastre con el cronograma de entrega es trabajo del propietario del producto, no del equipo de desarrollo.
El Equipo Scrum como un todo debería hacer visible el costo de la deuda técnica a través de estimaciones, seguimiento de velocidad y retrospectivas. La recomendación de elementos de la lista de pedidos del producto que reduzca la deuda técnica se debe realizar durante el refinamiento de la lista de pedidos o la retrospectiva del Sprint, pero la administración real de la lista de pedidos del producto sigue siendo competencia del propietario del producto en todo momento.
Ewan