¿Qué es Developer Anarchy?

He estado leyendo sobre Developer (o Programmer) Anarchy, que parece ser considerado como una metodología de desarrollo post-Agile. Encontré algunos recursos en él ( 1 , 2 ) pero no parece que haya muchos por ahí.

Me preguntaba si alguien tenía buenos recursos donde pudiera obtener más información sobre el tema _ cómo implementarlo, pros y contras, comparación con otras metodologías, etc.

agile development-process development-methodologies

— Martyn
fuente

No he oído hablar de él antes, pero me parece un poco contradictorio. Dicen que "... la formalidad y las reglas limitan la creatividad y la productividad", pero al mismo tiempo tienen reuniones regulares (como parte de la metodología). No puedo creer que la descripción de tal metodología comience por establecer una regla.

— Giorgio

Al leerlo por primera vez, me parece que fue hecho por personas o personas que solo tenían experiencia con Agile a medias. Porque esta "Anarquía del desarrollador" es un ejemplo de libro de texto de "ágil hecho bien". P.ej. implementado adecuadamente ágil.

— Eufórico el

El primer enlace que cita parece que ya contiene todo lo que está buscando.

— Michael Borgwardt

¡Qué hermosa palabra de moda!

— CesarGon

@CesarGon: Las palabras de moda son más fáciles de inventar que las metodologías que son realmente nuevas. ;-)

— Giorgio

Puedo señalarle los pensamientos de Alistair Cockburn sobre este aspecto de los proyectos 'verdaderos' de Agile:

Un miembro de la familia de metodologías Crystal es Crystal Clear. Crystal Clear se puede describir a un oyente de Nivel 3 en las siguientes palabras:

“Ponga a 4-6 personas en una sala con estaciones de trabajo y pizarras blancas y acceso a los usuarios. Haga que entreguen software probado y en ejecución a los usuarios cada uno o dos meses, y de lo contrario déjenlos en paz "

De hecho, describí Crystal Clear en esas palabras a un patrocinador de proyectos inteligente. Siguió esas instrucciones e informó cinco meses después: "¡Hicimos lo que dijiste y funcionó!"

Entrevisté al líder del equipo unos meses después y su informe fue tan breve como mis instrucciones:

“Siguiendo su sugerencia, los cuatro nos hicimos cargo de esta sala de conferencias, que tiene conexiones de red. Lo conservamos durante los cuatro meses, dibujando en las pizarras blancas allí, entregando software a medida que avanzábamos. Funcionó muy bien ".

de eso se trataba Agile, y parece que este es el enfoque adoptado por la metodología de la Anarquía: el punto es que, si tienes muchachos experimentados , entonces puedes decirles que "se vayan y hagan que funcione" y ellos harán exactamente eso . (esto no funciona con personas menos experimentadas, no permitiría que un equipo de juniors lo haga sin al menos un poco de supervisión).

Todo el truco sobre el ágil que se ha ido acumulando a lo largo de los años, como standups y tableros de scrum diarios, sesiones de preparación del producto atrasado, reuniones previas a la reunión sobre el producto. gastos generales para la entrega exitosa del producto.

Demasiado hoy, sin embargo, estas cosas se consideran obligatorias y la metodología 'ágil' desciende a un sistema que tiene más procesos que los métodos anteriores.

— gbjbaanb
fuente

"Demasiado hoy, sin embargo, estas cosas se ven como obligatorias y la metodología 'ágil' desciende a un sistema que tiene más proceso que los métodos antiguos".: Llegas a un punto importante (+1). He estado trabajando con SCRUM en un equipo de desarrolladores experimentados y nuestra sensación, después de dos años es que ... antes éramos más ágiles, cuando no teníamos reuniones diarias (solíamos reunirnos dos veces por semana) y muchas otras actividades. sucedió "cuando el equipo decide que son necesarios" en lugar de "cuando la metodología los prescribe".

— Giorgio

+1. En última instancia, creo que estas metodologías son indicativas de un ciclo continuo: las metodologías pesadas fallan repetidamente, (algunas) personas se dan cuenta de que los programadores son lo suficientemente inteligentes como para manejar las cosas, eliminar el proceso y, en general, las cosas funcionan, pero el proceso ligero se prueba con equipos pobres o inexpertos, falla o pierde estimaciones, el proceso se agrega para aumentar la "certeza" y la "previsibilidad", y el ciclo continúa.

— asthasr

Gahhh ... ese ciclo suena preciso y deprimente.

— Graham el

"Tim era un desarrollador talentoso que trabajaba en una compañía llena de desarrolladores talentosos. Prácticamente cualquier metodología que se te ocurra iba a funcionar con estas personas".

— AakashM

@syrion: Puede que tengas razón. Leí en alguna parte que las prácticas ágiles funcionaban para programadores experimentados. Luego, tales programadores experimentados que habían estado entrenando equipos sin experiencia tuvieron que escribir reglas para ellos (porque el entrenamiento continuo cuesta mucho y es mejor tener algunas reglas escritas en un libro). De esta manera, se desarrollaron nuevas metodologías como SCRUM y similares: para que las personas ahora puedan vender libros o certificaciones. Pero el verdadero espíritu de agile es aplicar su propio sentido común en lugar de las reglas escritas por otros. Las reglas son pautas pero muchos las consideran como una religión.

— Giorgio