¿Cómo uno o un equipo cumplen con éxito los compromisos / pronósticos de Scrum mientras producen código de calidad?

El código de calidad y la entrega rápidamente van de la mano, pero no de la forma en que la mayoría de la gente piensa.

TL; DR: diseño apenas suficiente y de calidad minimiza la volatilidad en el costo marginal de las características; por lo tanto, el deseo del programador de un mejor código no solo no entra en conflicto, sino que en realidad respalda la necesidad de las partes interesadas de tener más funciones antes. La eterna lucha entre empresas y programadores

Solo a corto plazo, es posible que parezca entregar antes reduciendo la calidad (tanto errores / errores como diseño pobre / costoso de mantener), pero en realidad solo está aplazando parte del trabajo para más adelante. Si se encuentra en una crisis de efectivo (“Cerraremos las puertas el próximo mes si no hacemos ventas ahora”), entonces es posible que deba diferir el trabajo de “hacerlo bien” para hacerlo más tarde. algo lo suficientemente bueno como para vender ahora. Aun así, ese trabajo diferido no desaparece: solo lo aplazas para más adelante.

Cuando difiere este trabajo, aumenta el costo de entregar funciones futuras. Desafortunadamente, probablemente no pueda predecir cuánto costará hacer ese trabajo más tarde ni cuándo tendrá que hacerlo absolutamente. Solo notará que es “inesperadamente difícil” enviar una determinada característica. Este es el punto en el que te has encontrado con el trabajo que habías aplazado antes cuando elegiste hacer un trabajo de menor calidad. Eso es lo que lo hace peligroso: no sabes cuándo se convertirá en un problema y no sabes en qué medida se convertirá. (Esto empeora cuando un gerente apuesta que ese trabajo diferido será el problema del próximo gerente).

Cuando aplazamos este trabajo, se hace más costoso porque tenemos que volver a cargar en nuestro cerebro lo que sabíamos cuando hicimos la primera parte del trabajo. Este es el costo de “cambio de contexto” del que todos hablan. (Sí, a veces el trabajo diferido se vuelve innecesario, y ahorramos esfuerzo en general, pero eso solo sucede por suerte, y la suerte no es una estrategia). Debe suponer que todo trabajo diferido tiene este costo, por lo que cuando difiere el trabajo, Estás haciendo una apuesta que no siempre funciona.

Como resultado, si desea equilibrar el bajo costo con el costo predecible, debe escribir un código de calidad sobre la marcha: no paga la tarifa de cambio de contexto porque hace todo el trabajo ahora, pero a veces escribe una calidad ligeramente superior código de lo que necesitas. Este segundo problema cuesta mucho, mucho menos que el primer problema, en promedio. La mayoría de los programadores no escriben código con un nivel de calidad demasiado alto, incluso cuando lo intentan. 🙂

Si necesita entregar antes, generalmente es más seguro ofrecer características más pequeñas con alta calidad que ofrecer características más grandes con menor calidad. Puede mantener su ritmo más fácilmente de la primera manera que de la segunda, y aunque las personas afirman querer “rápido”, por lo general prefieren “predecible” sobre “lo más pronto posible”. (Una vez más, esto supone que permanecen en el proyecto durante más de 6 meses. De lo contrario, exprimen lo que pueden de usted y dejan que el costo adicional sea el problema del próximo gerente).

El objetivo principal del código de calidad es hacer que cueste menos extenderlo y / o cambiarlo con el tiempo, de modo que se reduzca el costo de cada característica futura en comparación con simplemente piratearlo y arreglarlo más tarde.

Una última cosa: si entrega características antes con baja calidad, entonces su parte interesada esperará que mantenga este ritmo, y nunca arreglará nada. Un día, sin previo aviso, todo lo que intente hacer comenzará a tomar 3-5 veces más de lo que debería. Entonces entras en pánico. Entonces el proyecto muere.

No hay una respuesta fácil. En algunos casos, incluso puede haber una razón comercial legítima para sacrificar la calidad del código por la velocidad a corto plazo, por ejemplo, si está en una pequeña empresa que necesita sacar un producto o cerrar el negocio. Pero eventualmente, la mala calidad del código comienza a costar más en tiempo de ingeniería de lo que produce en competitividad de características. Esperemos que la gerencia de la compañía lo crea al menos en principio. Si no, podrías estar en problemas.

Para abordar el problema de la característica frente a la calidad, comenzaría asumiendo que los ingenieros que están trabajando directamente en el código son los dueños de las estimaciones. Eso tiene sentido, ya que quién más está en condiciones de saber cuánto tiempo llevará una tarea. Si puedes vender esa idea, entonces construye a tiempo para revisiones de código y pruebas unitarias. Como parte de cada revisión de código, los revisores deben asegurarse de que existan pruebas unitarias para cualquier código nuevo o modificado. Puede usar medidas de cobertura de código como una verificación secundaria. Después de algunas iteraciones, las personas deberían tener una idea intuitiva de cuánto tiempo necesitan para escribir pruebas unitarias, si aún no las incluyen en sus estimaciones.

Esa combinación de prácticas (ingenieros que poseen estimaciones, revisiones de códigos y pruebas unitarias) no es una bala de plata, pero es un buen comienzo.

No hay absolutamente nada de anatema entre Scrum y el código / producto de calidad. Las iteraciones son, de hecho, una excelente manera de asegurarse de que está creando código y producto de calidad, ya que tiene que mostrarle a la gente el resultado final de sus esfuerzos al final de cada iteración, y esto descubrirá problemas y casos de uso que usted no había considerado cuándo estabas construyendo el producto durante la iteración.

Dicho esto, hay un par de cosas realmente importantes para recordar aquí:

(1) nunca creará un código perfecto, y siempre habrá errores o problemas que no podría anticipar cuando su código entre en el “mundo real” y se encuentre con usuarios reales y datos reales. Por lo tanto, el objetivo no es crear un código perfecto, sino tener procesos y principios que minimicen la probabilidad de tales errores.

(2) El objetivo del equipo no debe ser “aumentar la velocidad con cada sprint”; de hecho, en algún momento se va a normalizar en una cantidad estándar de velocidad que no va a cambiar drásticamente de sprint a sprint. El objetivo del equipo debe ser entregar un software de calidad que satisfaga las necesidades del cliente, y todo lo que hacen debe centrarse en ese objetivo , si eso significa que de alguna manera se pierde un compromiso porque había algo mal con el código, que así sea. al respecto en retrospectiva y averiguar la causa raíz, luego solucionarlo.

El problema con el que se encuentra la mayoría de las personas es que los equipos de Scrum que no internalizan una calidad y un enfoque en el cliente, o que no conocen bien el proceso y la forma en que se aplica, terminarán funcionando tan rápido como puedan. su compromiso, sin centrarse en la calidad. Esto es lo incorrecto que hacer por completo. Es el proceso sobre el resultado, que es lo opuesto al pensamiento ágil.

Scrum no es la causa del mal código: los desarrolladores malos, los desarrolladores descuidados, los desarrolladores desenfocados o la presión indebida para cumplir con los compromisos sin tener en cuenta la calidad, son todas las cosas que hacen que el código malo se comprometa y se entregue, y todas esas cosas existen fuera Melé.

La organización necesita dejar en claro que la calidad es una prioridad. El problema es que muchas organizaciones no son buenas para hacer esto. Tener objetivos claros de calidad es útil. Las empresas son mucho mejores para proporcionar visibilidad para los principales hitos y compromisos de los clientes, pero por alguna razón, las métricas de calidad no tienen la misma visibilidad.

Nos encontramos con esto en eBay en ~ 2001. Cuando llegué, el mantra en la organización era que “el liderazgo” valoraba la “velocidad sobre la calidad”. Cuando le dije esto al CTO, ella dijo, “eso no es cierto. Queremos ambos”. Le dije: “bueno, entonces debemos darle a la calidad la misma visibilidad y prioridad que le damos a la entrega”. Procedimos a crear objetivos y colocamos paneles LCD que mostraban dónde estábamos parados. Se hizo conocido como “Bug TV”. Tenía cosas como Open Production Bugs y Bug Close Rate y Test Case Pass para los próximos 3 lanzamientos. OMI, fue muy efectivo.

PD: también leí un artículo recientemente que recomendaba establecer un cierto porcentaje de capacidad o número de puntos en cada sprint para la corrección de errores. He hecho esto y ha funcionado bien. Calibra esto calculando datos reales pasados ​​(puntos gastados en la corrección de errores). En Jira, acabamos de crear una épica llamada corrección de errores. Los errores que no estaban asociados con una historia se pusieron en este cubo.

Estoy dando desde las trincheras, por lo que puede no estar completamente de acuerdo con el manifiesto.

1. La teoría se desvanece a la realidad.
2. El código de calidad comienza con la contratación de personas de calidad. Solo puede mejorar la calidad del código por proceso, pero no puede inculcarlos.
3. Los sprints de números primos están reservados para la deuda técnica / calidad del código.
4. Mejorar la calidad del código es más fácil que la calidad de la arquitectura. No comprometa la calidad de la arquitectura.

Mantenga la calidad alta, solo entregue en incrementos más pequeños y frecuentes.

¿Cómo? Uso de historias cortas de usuario .

Esto significa que se entregarán rápidamente, y puede aumentar el alcance de una función agregando una nueva pequeña historia de usuario.

Si las tareas en las que están trabajando los desarrolladores son demasiado grandes, es más fácil para ellos llamar a la historia ‘terminada’ y ocultar la deuda técnica bajo esto. Lo curioso es que alcanzará todas sus marcas de velocidad, pero … también deteriorará el producto, línea por línea.

Tienes fabricantes y contadores de frijoles. Uno puede vivir sin el otro. No se puede. Tú tienes el control. Sin ti, los contadores de frijoles no tienen frijoles.

Sus objetivos para cada ciclo deben ser factibles, en funcionalidad y calidad.
Decidir tus objetivos es un elemento central en Scrum.