¿Cómo evitar que la programación Lean se convierta en Cowboy Coding?

Question

Mi equipo ha ido adoptando progresivamente metodologías cada vez más ligeras, pasando de Scrum a Lean/Kanban donde cada vez hay menos procesos 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 Ágil muy ligero y la anarquía? ¿Cómo sabremos cuándo hemos cruzado la línea? ¿Y cómo podemos evitar que crucemos la línea?

La pregunta también puede formularse como "¿qué procesos no se pueden eliminar de forma segura en el disco de Lean para eliminar el desperdicio"?

Answer 1

Cuando algo sobre el código es conocido o manejable por una sola persona en su grupo, se encuentra debajo de un letrero "Saloon" que brilla intensamente, y básicamente está empujando las puertas.

Answer 2

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

Un par de otras señales de advertencia que me gustaría tener en cuenta son:

• ¿El equipo tiene un estándar de codificación y un compromiso de mantener ese estándar?
• ¿Hay un montón de cambios de código de un individuo haciendo "refactorización" que nadie más piensa que vale la pena?

Answer 3

Supongo que si mantiene algún tipo de revisión de código, no puede salir mal de este lado. Si nadie sabe lo que hacen los otros programadores y cómo lo están haciendo, es posible que haya cruzado esta línea.

Answer 4

Probablemente no haya una lista definitiva de señales de advertencia que, si ves, te dicen que estás en territorio vaquero. Personalmente, si la gente está liberando código no probado, desarrollando funciones que no se entienden definitivamente, o de todos modos apresurando el trabajo o ignorando las señales de advertencia, me preocupa.

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

Answer 5

1. Nunca olvide las pruebas automatizadas de su unidad.
2. Nunca olvide sus pruebas funcionales.
3. Nunca olvide sus pruebas.

(he sido culpable) Alquiler

Answer 6

(o delegar) un alguacil, y el corral del código para que no sólo se confirmen, sino más bien se miraba por toda la pandilla.

Answer 7

Es de suponer que usted está preocupado por los efectos de codificación de vaquero:

• No hay requisitos
• Ningún diseño
• Ninguna prueba
• Sin retroalimentación de los usuarios
• N calendario
• No se puede mantener
• autobús factor de
• ...

Siempre y cuando usted tiene un/mecanismo/proceso del plan para evitar estos efectos negativos, entonces estás bien; ¿derecho?

Answer 8

hay un proceso cada vez menos formal. En algún momento volveremos a Cowboy Coding ...

La ironía de Agile/Lean/Scrum "process" es que el proceso menos formal NO conducirá a la programación de vaqueros.

Aunque estas metodologías prefieren "personas mayores de proceso", el proceso no es completamente abandonado; la administración aún es requerida. Y al final del día todavía tiene un compromiso con sus clientes y fechas límite. Estos compromisos deberían controlar a las vacas.

Answer 9

¿Qué pasa con la codificación Cowboy? 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 con quien esté pagando), entonces es hora (y yo soy un PM que dice esto). Cuando se tiene un buen/sólido equipo de programación, no se necesita la necesidad de un proceso formal, generalmente se internaliza, los buenos programadores siguen la buena forma/proceso de forma natural. Creo que se implementan muchos procesos para los actores más débiles que en muchos casos tienen un impacto negativo en los buenos/grandes intérpretes. Un buen gerente de proyectos debe equilibrar el proceso con la situación específica ... tipo de aproximación lead/follow/get-of-the-way

Answer 10

Aquí es donde entra el valor de un entrenador ScrumMaster/Lean/Agile. Quien desempeñe ese rol en su equipo debería ser capaz de detectar cuándo la autodisciplina del equipo está disminuyendo y recordarle al equipo el compromiso que se han hecho mutuamente con respecto a la calidad de su código.

La otra cosa que puede hacer es ajustar los contenedores. Agregue revisiones de código a su placa Kanban y luego ponga un límite para asegurarse de que se haga. Mejor aún, requiere que todos los códigos se escriban en pares durante algunas semanas para que los buenos hábitos se refuercen y nadie pueda reclamar la propiedad de las secciones del código.

Finalmente, considere que quizás 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 arraigado en tu equipo, es muy fácil volver a los viejos hábitos. Aquí es donde la aplicación estricta de las reglas de Scrum puede ayudarte hasta que tu equipo esté listo.

Recuerde, Kanban es una herramienta. Si no aplica consistentemente los principios Lean y Agile a su uso, no obtendrá el beneficio completo.

Answer 11

"lo que los procesos no se puede decir con seguridad eliminados en la unidad de Lean eliminar los residuos"?

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

Mientras descarta los procesos de gestión que no producen ningún valor, debe incluir más prácticas técnicas, como las que se encuentran en eXtreme Programming. La mayoría de los entrenadores ágiles con los que he hablado consideran que el desarrollo impulsado por pruebas, la programación de pares y la integración continua son una realidad cuando se trabaja con una adopción ágil. Es muy difícil salirse con la "programación de vaquero" con estas técnicas en su lugar. Si estuviera preocupado porque el código se salga de control, también incluiría algunas revisiones de código.

Answer 12

La codificación de Cowboy es rogue codificación. Lo único que permite el comportamiento deshonesto es la falta de supervisión de una autoridad.

La "autoorganización" de Agile a menudo se abusa hasta el punto de dejar el término en gran parte sin sentido, ya que los equipos de desarrollo lo interpretan oportunistamente para significar "autodeterminación".

Un enfoque organizacional Lean para la administración puede ser una marcada diferencia con respecto a lo que estamos acostumbrados, incluso de equipos Agile. Y es esta cuestión de organización y dirección y su mecánica organizativa lo que hace toda la diferencia.

La adopción de Lean Product Development en el software todavía es bastante joven, y desafortunadamente sufre bastante por la distracción de 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 alguien en cualquier organización se vuelva pícaro, deben ser dirigidos a cumplir con las expectativas. Sin embargo, el papel del director en una organización Lean no es solo un matón. 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 ser cada vez más competentes en el cumplimiento de las expectativas de las que han aceptado la responsabilidad.

Cualquier proceso específico que implemente (revisiones de código, vinculación, incentivos, etc.) depende de demasiados factores que son particulares para su organización en el momento en que los está considerando. El director del esfuerzo debe entender cómo obtener el poder mental colectivo de todo el equipo para encontrar buenas soluciones o vías de exploración, experimentación y aprendizaje, y tomar una decisión para lo mejor, incluso si ocasionalmente significa contradecir al colectivo (especialmente si el colectivo es joven en formas Lean).

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

Answer 13

Involucrar al cliente tal vez, por lo que no escribir un sistema teórico en un presupuesto BAU que la empresa realmente no quiere? Hable más con su (s) gerente (es).

Answer 14

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

Si deja de usar procesos que le ayudan a generar valor de manera eficiente, entonces producirá menos valor o producirá menos valor rápidamente.

Dado que las técnicas Lean y Agile implican medir cómo progresa en la producción de valor, usted debería ser capaz de saber cuándo cruzar la línea y eliminar 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!