Trabajo en una empresa de desarrollo de software, donde usamos algo que se parece a scrum.
Nos encontramos con el problema de que cuando estamos trabajando en nuestros desarrollos y los errores comienzan a aparecer, debemos abandonar nuestro trabajo de desarrollo y centrarnos en la depuración. Cuando se alcanzan los niveles máximos, ya no lanzamos nuestro software y primero debemos corregir los errores antes de crear nuevas versiones para nuestros clientes.
Todo esto parece perfectamente razonable, ya que solo lanzamos cada medio año y tenemos clientes esperando que se solucionen los errores.
Sin embargo, esto crea la situación en la que a veces no encontramos el tiempo para trabajar en nuestros desarrollos, porque a veces tenemos que seguir depurando durante semanas.
¿Cómo podemos planificar correctamente para los errores? He pensado en un par de cosas, pero tengo curiosidad por saber cuál es tu opinión.
Hay varias formas de abordar esto, he probado la mayoría de ellas y ninguna es ideal simplemente porque estás lidiando con lo que Scrum llama "trabajo no planificado".
Una de las cosas más importantes, según mi experiencia, es tener un buen sistema de clasificación de errores. Cuando se informa un error, alguien debe tomar una decisión informada, basada en una política conocida en toda la empresa, cuál es la gravedad del error y si debe abordarse de inmediato o puede posponerse hasta el próximo Sprint. Las cosas que desea considerar aquí son la tasa de reproducción, el porcentaje de base de usuarios afectados, el riesgo de corrupción de datos, etc.
Una vez que sepa cuál es la gravedad de su error, puede decidir qué hacer con él y cómo manejarlo. Si la gravedad es lo suficientemente alta como para incluirlo en el Sprint, lo maneja como un trabajo no planificado con la prioridad más alta en el Sprint Backlog.
La forma en que maneja el trabajo no planificado es algo completamente diferente; hay varias formas de hacerlo. A continuación se muestran las dos técnicas que he usado en el pasado; ambos funcionan igual de bien, pero no se adaptarán a todos los equipos.
Utilice un "carril de vía rápida" . Cualquier error que aparezca en el Sprint Backlog que necesite atención inmediata se coloca en la "vía rápida" y debe corregirse antes de que se inicie cualquier otro trabajo nuevo. La vía rápida es un "carril" de prioridad separada o un carril "expedito" que va por encima de todos los demás carriles.
Use un "equipo SWAT" si su equipo es lo suficientemente grande. Introducir un sistema de rotación en el Equipo, donde cada Sprint una o dos personas son el "equipo SWAT" que inmediatamente saltará sobre cualquier trabajo no planificado que surja en el Sprint. La menor disponibilidad de estos desarrolladores debe tenerse en cuenta en la velocidad del equipo para el Sprint. Por lo general, desea que el equipo swat trabaje en historias de Sprint de menor prioridad, ya que podrían retirarse de las tareas en cualquier momento. Obviamente, esto solo funciona en equipos lo suficientemente grandes.
usamos algo que se parece a scrum
Mi sugerencia para usted sería acercarse a Scrum buscando tener un incremento potencialmente entregable al final de cada sprint.
Tenga en cuenta que la palabra clave para usted aquí es 'potencialmente'. Todavía puede lanzar cada seis meses si eso es lo que quiere hacer su propietario del producto, pero aún debe apuntar a tener algo listo para enviar cada sprint.
Para hacer esto, deberá pensar en funciones que solo se realicen cuando estén libres de errores. El trabajo que realice en cada sprint será la capacidad que tenga su equipo para desarrollar un nuevo trabajo y corregir cualquier error que surja por el nuevo desarrollo.
Trabajar de esta manera facilitará la planificación, ya que su equipo tomará conciencia de su capacidad real para entregar el trabajo.
También tiene mucho mérito reducir las posibilidades de que ocurran errores en primer lugar, mediante el uso de técnicas de ingeniería como pruebas de regresión automatizadas, integración continua y desarrollo impulsado por el comportamiento (BDD).
Hay varias formas en las que puedes lidiar con los errores. Pero independientemente de su política de errores, hay una cosa que realmente debe hacer.
Si sus desarrolladores dedican una cantidad significativa de su tiempo a corregir errores, debe darle una alta prioridad para averiguar de dónde provienen esos errores y qué se puede hacer (a nivel técnico o a nivel de proceso) para evitarlos. tipos de errores en el futuro.
Por ejemplo, si sus clientes solo ven las nuevas funciones cuando las lanza y luego se quejan de que esas funciones no funcionan como esperaban, entonces debe buscar formas de involucrar a esos clientes antes en la validación de las nuevas funciones. .
En cuanto a las políticas de errores, las dos principales que conozco son
"Cero errores": cualquier error es demasiado y debe resolverse con prioridad sobre el desarrollo de nuevos desarrollos. Esto requiere que tenga un proceso de clasificación sólido para evitar que los cambios en la funcionalidad que funciona correctamente se clasifiquen como errores. Si hay muchos errores informados, esto puede significar que no se realiza ningún nuevo desarrollo durante un tiempo significativo.
Priorizar los errores junto con el nuevo desarrollo: para cada elemento de trabajo se determina la prioridad en relación con el otro trabajo, independientemente de si el elemento de trabajo es un error o un nuevo desarrollo. Durante la planificación, los N elementos principales se incluyen en el sprint, donde N depende de la capacidad del equipo. Al menos para fines de planificación, es útil tener una indicación de cuánto esfuerzo se dedicaría a resolver cada error.
Personalmente, me gusta el segundo enfoque, porque le da al Product Owner la posibilidad de decidir caso por caso si esa nueva característica tan demandada es más importante que corregir ese error que casi nadie nota.
Mientras resuelve el problema de cómo asignar tiempo para los errores, es posible que también desee buscar formas de reducir la cantidad de errores que encuentra. Es posible que pueda detectarlos antes en el proceso, lo que lleva a una menor repetición del trabajo más adelante.
Hay una serie de métodos/herramientas para ayudar a hacer esto: programación entre pares; revisiones de código; herramientas de análisis de código estático; pruebas automatizadas; garantizar que las historias de usuario tengan buenos criterios de aceptación acordados entre el Propietario del producto, el Probador y el Desarrollador antes de que comience el trabajo; estrecha comunicación entre evaluadores y desarrolladores al principio del proceso de desarrollo.
Toda la suerte
El principal problema que veo es que lanzas cada 6 meses, lo cual es muy raro. Hay una razón por la que Scrum dice un máximo de 4 semanas por Sprint. Porque al final de las 4 semanas, el incremento debe ser potencialmente liberable. No tienes que hacerlo, pero tiene que estar en este estado.
Entonces, debido a que el ciclo de lanzamiento es demasiado largo, sus clientes plantean sus problemas como errores, que se ven obligados a corregir antes del nuevo lanzamiento. No puede convencerlos de que esperen el lanzamiento porque lleva 6 meses, lo que claramente es demasiado tiempo.
¿Qué debes hacer, como empresa?
Debe elegir una duración de Sprint que sus clientes acepten para corregir los errores. Obviamente, habrá algunos errores críticos que deben resolverse lo antes posible. Destinar a esos el 10% del Sprint. Tenga en cuenta que es una métrica de equipo.
El resto de los errores van a la Lista de Producto y se priorizan junto con las funciones que está desarrollando.
Supongamos que haces esto y comienzas un nuevo Sprint con algunas funciones y errores. Ahora tienes tres tipos de errores:
Al final del Sprint entregas una nueva versión que tiene:
El cliente puede aceptar esto porque es razonable esperar de 2 a 4 semanas por algunos errores menores, mientras que los errores críticos se solucionan lo antes posible.
Ahora, si el 10% de la duración del Sprint no es suficiente, entonces tienes Deuda Técnica. Puede aumentar hasta un 15% o un máximo de 20%.
Necesitas anticiparte a estos errores. Debe refactorizar o rehacer parte de su código si sabe que tiene errores críticos que su cliente descubrirá. Cree algunos elementos en el Product Backlog para anticipar estos errores y hable con su Product Owner para que les dé alta prioridad. Anticípate a los errores de tus clientes y tendrás una mejor Planificación del Sprint y gestión del tiempo.
Por último, es posible que tenga un cliente que afirme que todos los errores son críticos. Cuando lo recibas, échale un vistazo. Si no es crítico (p. ej., algún botón en la interfaz de usuario que nunca funcionó), pídale al propietario del producto que hable con el cliente o hágalo usted mismo si puede entregar el mensaje.
Al evaluar la prioridad/criticidad, póngase en el lugar del cliente. Puede ser un pequeño error técnico, pero si el cliente está perdiendo dinero, entonces tiene alta prioridad. ¿Qué tan alto? Pregúntele al propietario del producto.
Si asigna el 10 % de su tiempo para corregir errores críticos y, de hecho, usa más, su Product Owner debe decidir cuál de los elementos de Sprint Backlog no debe entregarse. Es simple: pones algo, sacas algo.
joao silva