En nuestro proyecto trabajamos en una metodología de cero errores (también conocida como cero defectos). La idea básica es que los errores siempre tienen mayor prioridad que las características. Si está trabajando en una historia y tiene un error, debe resolverse para que la historia sea aceptada. Si se encuentra un error durante el sprint de una historia anterior, debemos colocarlo a continuación en nuestra cartera de pedidos y resolverlo: máxima prioridad.
La razón por la que digo resolver es que no siempre solucionamos el error. En algún momento simplemente declaramos que "no se solucionará", ya que no es tan importante. En general, suena genial. Estamos enviando productos de alta calidad y no llevamos "una joroba" en forma de una gran acumulación de errores.
Pero no estoy seguro de que este enfoque sea correcto. Tiendo a estar de acuerdo en que siempre tenemos que corregir los errores graves lo antes posible y necesitamos eliminar los errores no interesantes. Pero, ¿qué pasa con los errores que son importantes pero no tan importantes como las nuevas características? Tiendo a pensar que deberían archivarse en la cartera de pedidos con una prioridad adecuada.
Daré un ejemplo para que sea más claro: en mi proyecto trabajamos con una interfaz de usuario escrita en flex. Tenemos una pantalla de asistente que se abre en el mismo tamaño para cada resolución de pantalla. Resulta que cuando ampliamos la ventana del asistente, una de las páginas no se ve bien (hay una barra de desplazamiento vertical que no desaparece, aunque el asistente ahora puede presentar todo y no requiere la barra de desplazamiento). Creo que este error es feo. Estoy seguro de que DEBE ser reparado. Pero tenemos un calendario apretado y tenemos muchas características que tememos que no logren el corte e ingresen al lanzamiento. Siento que podemos vivir con ese error. Es necesario corregirlo, pero con una prioridad menor que otras características (por lo tanto, en caso de que no podamos completarlo, al menos no omitimos características más importantes). Pero,
Me encantaría escuchar opiniones sobre cómo manejar errores que no quiero marcar como "no solucionarán" pero que tampoco son de la mayor importancia.
Respuestas:
Corregir errores antes de escribir un nuevo código es en realidad uno de los doce puntos de la prueba de Joel . Joel también explica por qué esto es imprescindible:
Tienes una opción:
O implementa una característica muy solicitada y retrasa la reparación de un error, lo que inevitablemente aumentará el costo de solucionarlo,
O puede solucionar el error ahora, dado que los clientes se sentirán decepcionados de que sea tan lento en ofrecer la función que tanto necesitan.
Si el error no es muy importante, mientras que la función sí lo es, la gerencia se inclinará a solicitar implementar la función primero y luego corregir el error. Desde el punto de vista comercial, esta es una opción perfectamente válida, en la medida en que la gerencia entienda claramente las consecuencias, es decir, que sería más difícil solucionar el error más tarde que ahora.
Cumplir con "no hay nuevas características hasta que se corrijan todos los errores" puede no ser la mejor opción comercial. Ya mencionó sus limitaciones, por lo que no hay necesidad de explicarlo.
Dicho esto, el riesgo de permitir que se implementen características muy importantes antes de corregir errores menores tiene un riesgo: ¿dónde poner los límites? ¿Una característica solicitada por 1000 clientes es más importante que un error encontrado por 100 clientes? ¿Cómo evaluar si se debe realizar una función determinada antes de corregir un error determinado?
Sin reglas estrictas y si la administración no comprende muy bien el proceso de desarrollo, es posible que se vea dentro de unos años con una acumulación de errores que no se consideraron lo suficientemente importantes como para solucionarlo antes que otra característica sofisticada.
fuente
Además de sumergirse en detalles particulares de bajo nivel de su situación, es mejor asegurarse de tener las cosas básicas y fundamentales correctas.
En este sentido, creo que es muy importante señalar que la política que menciona, "los errores siempre tienen mayor prioridad que las características", particularmente la palabra siempre se desvía de al menos dos de los cuatro principios establecidos en el Manifiesto Ágil :
No insisto en que debe cambiar la política, porque creo firmemente que uno debe ser ágil acerca de la aplicación misma de los principios ágiles.
Pero al menos debe tener en cuenta cuándo se desvía y comprender si y cómo se justifica la desviación . En pocas palabras, es mejor que te asegures de que lo que llamas "ágil", en realidad no se deslice en falso sin sentido, tan elocuentemente cubierto en el Manifiesto Ágil Medio Arsed :
En aras de la complicidad, la política de cero errores no solo se desvía de los principios ágiles.
En los proyectos no ágiles en los que participé, generalmente se ha considerado er ... imprudente dedicar tiempo a los programadores a corregir errores que no son lo suficientemente importantes como para justificar la demora en el lanzamiento de funciones de alta prioridad.
Debido a eso, la administración generalmente invirtió (tal vez sería más exacto decir invertido ) algunos esfuerzos para decidir qué errores podrían esperar hasta la próxima versión.
Sabes, a menos que trabajes en software de misión crítica, recomendaría evaluar más de cerca las habilidades y habilidades de pensamiento de tu gerencia.
Quiero decir, por lo que describe, parece que simplemente son incapaces de priorizar adecuadamente los errores y las características. Si este es el caso, si no pueden manejar una tarea tan rutinaria, ¿de qué otra cosa no son capaces? ¿Proporciona un salario competitivo? oportunidades de crecimiento profesional? ¿las condiciones de trabajo?
fuente
Como indica correctamente, una política de cero errores tiene el riesgo de que los problemas no críticos sean ignorados o empujados debajo de la alfombra, porque ahora no es el mejor momento para resolverlos.
Lo que podría hacer es, cuando se informa un nuevo problema, tomar una decisión tripartita:
De esta manera, los problemas menos importantes no se olvidarán por completo, pero tampoco obligarán a sacar todas las nuevas características brillantes del próximo sprint. El 'convertirlo en una historia' es solo para que la administración pueda continuar afirmando que está siguiendo una política de cero errores y el propietario del producto debe poder equilibrar la importancia del problema con la importancia de las características en la cartera de pedidos.
Tenga en cuenta que, con este procedimiento, problemas como la barra de desplazamiento que mencionó podrían terminar sin resolverse al final del proyecto, pero fue porque nadie pensó que fuera lo suficientemente importante (incluidos los clientes), no porque no hubiera hora en que se encontró el problema.
fuente
Sin embargo, me gusta su esquema, como lo ha identificado, necesita solo un pequeño cambio para que funcione: como ha observado, la realidad es a menudo una nueva característica que supera una corrección de errores .....
Mi sugerencia es forzar que la prioridad del error aumente cada sprint. Digamos que tienes un error en el nivel 5 (escala 1-alta, 5 = baja). Comienza como 5, 4 sprints más tarde, es un error de nivel 1. Sin embargo, la mentalidad necesaria para el cálculo de prioridad es "Prioridad actual - Número de sprints", en lugar de "Aumentar la prioridad de errores pendientes al final de cada sprint": esto evita que la prioridad se "restablezca" a baja para diferirla aún más.
Los errores de nivel 1 deben abordarse en el próximo sprint ......
Es simple de explicar, fácil de implementar ...
Ahora, amplíe eso para presentar solicitudes, tal vez una tasa diferente. Después de un tiempo, la solicitud debe ser tratada, ya sea hecha o descartada, evitando una acumulación de características que no tienen valor ...
fuente
Te metes en problemas cuando intentas ser demasiado literal o inflexible sobre cualquier cosa en el desarrollo de software, ya que todos realmente queremos que las cosas se corten y se sequen. Los errores deben corregirse antes de agregar nuevas características, pero aún consideraría la importancia de cada uno al tomar esta decisión junto con el alcance del problema. Hay excepciones a todo.
Algunas aplicaciones son tan grandes que tienen secciones que no están relacionadas en absoluto. No veo por qué cada nueva característica del módulo de cuentas por pagar tiene que quedar en espera, porque hay un par de errores molestos en la GUI de beneficios para los empleados. Si se encontró alguna molestia de GUI de paso de asistente en la sección de compras del sitio web de la compañía, corríjala, pero es posible que muchos errores no se corrijan si la característica adicional es el resultado de una seguridad adicional, necesidad comercial y especialmente cambios en las regulaciones.
Además de una gran discrepancia en el tiempo y los recursos para completar cualquiera de los dos, es mejor obtener alguna información del usuario / cliente. Si pueden vivir con el error si eso significa obtener la nueva función, agregue la función. El objetivo debe ser evitar que los errores se acumulen, así que tenga un espacio libre. En algún momento, muchos pequeños problemas se vuelven importantes.
fuente
Escribir pruebas para mostrar el error cuando se ejecuta la prueba es un buen comienzo para corregir los errores. Pero cuando tratamos de corregir los errores que tienen la menor prioridad, debemos pensarlo dos veces antes de continuar. No quise omitir arreglarlo. Pero podemos usar recursos no críticos para corregir esos errores. Digamos, en mi equipo, entrenamos los nuevos recursos con los errores menos priorizados en la lista de errores. De esta manera, tenemos la oportunidad de capacitar al nuevo recurso, así como de transmitirles un tinte de confianza de que han solucionado el problema al ingresar a la aplicación. Esto ciertamente los hará voluntarios para la próxima tarea priorizada.
Espero que esto ayude :)
fuente