process - metodologia - ¿Cómo evitar que la programación Lean se convierta en Codificación Cowboy?

kanban software free (14)

"¿Qué procesos no pueden eliminarse de manera segura en el impulso de Lean para eliminar el desperdicio"?

Esa es una pregunta muy general que es difícil de responder con precisión.

Si bien está descartando procesos de administración que no producen ningún valor, debe incluir más prácticas técnicas como las que se encuentran en la Programación de eXtreme. La mayoría de los entrenadores ágiles con los que he hablado consideran que el desarrollo guiado por pruebas, la programación de pares y la integración continua son un hecho cuando están trabajando con una adopción ágil. Es muy difícil salirse con la "programación de vaqueros" con estas técnicas implementadas. Si me preocupa que el código se salga de control, también incluiré algunas revisiones de código.

Mi equipo ha ido adoptando progresivamente más y más metodologías ligeras, pasando de Scrum a Lean / Kanban, donde hay menos procesos menos formales. En algún momento volveremos a Cowboy Coding; de hecho, me temo que ya podemos estar en la línea fronteriza.

¿Dónde se puede trazar la línea entre un proceso Lean y Agile muy ligero y la anarquía? ¿Cómo sabremos cuando hayamos cruzado la línea? ¿Y cómo podemos evitar que crucemos la línea?

La pregunta también podría formularse como "¿qué procesos no pueden eliminarse de manera segura en el impulso de Lean para eliminar el desperdicio"?

Hay menos y menos proceso formal. En algún momento volveremos a Cowboy Coding ...

La ironía del "proceso" de Agile / Lean / Scrum es que un proceso menos formal NO llevará a la programación de vaqueros.

Si bien estas metodologías prefieren "personas sobre el proceso", el proceso no se abandona por completo; la gestión sigue siendo necesaria. Al final del día, todavía tiene un compromiso con sus clientes y fechas límite. Estos compromisos deberían frenar a las vacas.

Nunca olvides tus pruebas unitarias automatizadas.
Nunca olvides tus pruebas funcionales.
Nunca olvides tus pruebas.

(He sido culpable)

¿Qué pasa con la codificación de vaquero? Si comienza a ver una calidad deficiente, la entrega del código tarda más y más tiempo, no cumple con las expectativas del usuario final (o la persona que paga), entonces es el momento (y soy un PM diciendo esto). Cuando tiene un equipo de programación bueno / sólido, la necesidad de un proceso formal no es necesario, generalmente se internaliza, los buenos programadores siguen un buen proceso / forma de forma natural, creo que se implementa un gran proceso para los que tienen un desempeño más bajo, lo que en muchos casos afectan negativamente a los buenos / grandes artistas. Un buen gerente de proyecto necesita equilibrar el proceso con la situación específica ... tipo de enfoque de liderazgo / seguimiento / alejamiento del camino

Aquí es donde entra en juego el valor de un entrenador de ScrumMaster / Lean / Agile. Quien desempeñe ese rol en su equipo debe poder detectar cuándo la autodisciplina del equipo se está deslizando y recordarle al equipo el compromiso que se han hecho entre ellos sobre el Calidad de su código.

Lo otro que puedes hacer es ajustar los contenedores. Agregue revisiones de código a su tablero Kanban y luego póngale un límite para asegurarse de que se haga. Mejor aún, exija que todo el código se escriba en parejas durante unas pocas semanas para que los buenos hábitos se refuercen y nadie pueda reclamar la propiedad de las secciones del código.

Finalmente, considere que tal vez su alejamiento del proceso formal de Scrum fue un poco prematuro. Las reglas de Scrum están ahí para enseñarte una forma completamente diferente de pensar y trabajar. Si los valores de Lean y Agile aún no se han incorporado a su equipo, es muy fácil volver a los viejos hábitos. Aquí es donde la aplicación estricta de las reglas de Scrum puede ayudarlo hasta que su equipo esté listo.

Recuerda, Kanban es una herramienta. Si no está aplicando constantemente los principios Lean y Agile a su uso, no obtendrá el beneficio completo.

Contrate (o sustituya) a un sheriff, y acorrale el código para que no solo se comprometa, sino que sea visto por toda la pandilla.

Cuando algo sobre el código es conocido o manejable por una sola persona en su grupo, está bajo un gran y bonito letrero rojo "Saloon", y básicamente está empujando las puertas.

La codificación del vaquero es una codificación deshonesta. Lo único que permite un comportamiento deshonesto es la ausencia de supervisión por parte de una autoridad.

La "autoorganización" de Agile a menudo se abusa hasta el punto de dejar el término mayormente sin sentido, ya que los equipos de desarrollo lo reinterpretan oportunamente para que signifique "autodeterminación".

Un enfoque organizativo Lean para la administración puede ser una diferencia marcada de lo que estamos acostumbrados, incluso de los equipos Agile. Y es este tema de organización y dirección y su mecánica organizativa lo que marca la diferencia.

La adopción de Lean Product Development en software aún es bastante joven, y desafortunadamente sufre bastante distracción por Kanban. Pero esto es de esperar: los aspectos más externalizables de un método suelen ser los primeros en ser reconocidos y adoptados, y estos suelen ser los aspectos más mecánicos. Kanban es una parte flagrantemente mecánica de Lean. Pero es solo una parte.

Lean es un cambio organizacional mucho más que Agile. Si no cambia el rol de los directores en la organización, es probable que acabe accediendo solo a los aspectos más materiales y mecánicos de Lean, y probablemente de la manera más ingenua.

Para evitar que cualquier persona en cualquier organización se convierta en pícaro, debe ser dirigido a cumplir con las expectativas. Sin embargo, el rol del director en una organización Lean no es solo un acosador. Un director en una organización Lean (equipo de desarrollo, etc.) también es un trabajador calificado y es capaz de enseñar a otros las habilidades necesarias para llegar a ser cada vez más competentes para cumplir con las expectativas de las que han aceptado la responsabilidad.

Independientemente de los procesos específicos que realice (revisiones de código, emparejamiento, incentivos, etc.), dependen de demasiados factores que son específicos de su organización en el momento particular en que los está considerando. El director del esfuerzo debe entender cómo reclutar la capacidad mental colectiva de todo el equipo para encontrar buenas soluciones o vías de exploración, experimentación y aprendizaje, y tomar una decisión en pos de lo mejor, incluso si en ocasiones significa contradecir al colectivo (especialmente si el colectivo es joven en formas magras).

A menos que su organización se distraiga por completo de los débiles problemas de dirección por el materialismo intelectual Lean, como Kanban, por ejemplo. Si hay personas que se vuelven ilegales, no tiene un problema de metodología, tiene un problema de organización. Y si tiene un problema de organización, inevitablemente tiene un problema de dirección y un problema de usos improductivos de la autoridad.

La pregunta de cuándo es una tarea / historia / unidad de trabajo realizada viene a la mente como parte de esa línea. Si necesita pruebas y que un par de ojos haya revisado algo puede ayudar a prevenir la situación del desarrollador deshonesto que quiere ser un vaquero. Del mismo modo, ¿cómo entra en producción el código? Si alguien en el equipo puede empujar el código por un capricho, sería una señal de advertencia para mi mente.

Un par de otras señales de advertencia que notaría son:

¿Tiene el equipo un estándar de codificación y un compromiso para mantener ese estándar?
¿Hay un montón de cambios de código de un individuo que hace "refactorización" que nadie más cree que vale la pena?

Presumiblemente estás preocupado por los efectos de la codificación de vaqueros:

Sin requisitos
Sin diseño
Sin pruebas
No hay comentarios de los usuarios.
Sin horario
Inalcanzable
Factor de bus
...

Mientras tenga un plan / mecanismo / proceso para evitar estos efectos negativos, entonces estará bien; ¿Correcto?

Probablemente no haya una lista definitiva de señales de advertencia que, si ves, te dicen que estás en territorio de vaqueros. Personalmente, si las personas están liberando códigos no probados, desarrollando funciones que no se entienden definitivamente, o de alguna manera acelerando el trabajo o ignorando las señales de advertencia, me preocupo.

Mejor usar tu propio juicio. Con suerte, ya que estás haciendo la pregunta, eres la persona adecuada para ser sheriff.

Supongo que si mantienes algún tipo de revisión de código, no puede ir demasiado mal en este lado. Si nadie sabe qué están haciendo los otros programadores y cómo lo están haciendo, entonces es posible que haya cruzado esta línea.

Tal vez comprometa al cliente, ¿por lo que no escribe un sistema teórico con un presupuesto BAU que el negocio realmente no quiere? Hable con su (s) gerente (s) más.

Tanto Lean como Agile implican minimizar el desperdicio en un contexto muy específico: entregar valor.

Si deja de usar procesos que lo ayuden a producir valor de manera eficiente, entonces producirá menos valor o producirá valor menos rápidamente.

Ya que las técnicas Lean y Agile implican medir cómo progresa en la producción de valor, debe poder saber cuándo cruza la línea y elimina una práctica útil.

Si no está utilizando la velocidad o el tiempo de ciclo para medir su entrega de valor, ¡ya ha cruzado la línea!