La flexibilidad es sin duda algo bueno, y el manifiesto Ágil tiene sentido. En comparación con la práctica frágil llamada cascada, Agile es notablemente mejor. Sin embargo, en la práctica, los enfoques flexibles a menudo causan un daño profundo y, de hecho, la dicotomía Ágil / Cascada es difícil aquí.

Vi cuántas variantes ágiles llamadas Scrum realmente matan a la compañía. Por "matar" no me refiero a "deterioro cultural", sino más bien cuando las acciones de la compañía caen casi un 90% en dos años.

¿Qué es ágil?

Agile surgió de un entorno de consultoría web en el que aportó algunos beneficios: cuando trabaja con clientes exigentes que no saben lo que quieren, generalmente tiene que elegir entre dos opciones. O para derrotar al cliente: establecer expectativas, pago apropiado por alteraciones y mantener relaciones de igualdad, no subordinación. O acepte el comportamiento incorrecto del cliente (como, por ejemplo, muchos diseñadores tienen que hacerlo) y oriente el flujo de trabajo alrededor de la disfunción del cliente.

Los programadores generalmente no funcionan muy bien con los clientes. Somos personas demasiado literales. Nos gustan los sistemas con comportamiento bien definido. Esto complica nuestra interacción con las humanidades, porque tendemos a tomar cada solicitud literalmente, en lugar de descubrir lo que realmente quieren. A nivel corporativo, los métodos ágiles (fuera del entorno de consultoría) van más allá y sugieren que los ingenieros no son lo suficientemente inteligentes como para comprender lo que quieren sus "clientes" internos. Esto significa que el trabajo se rocía en "historias de usuario" e "iteraciones", que a menudo nos privan de la satisfacción del trabajo realizado, así como de cualquier esperanza de una visión a largo plazo de hacia dónde van las cosas.

En general, generalmente se crean dos tipos de trabajo, ya sea dentro de la empresa o para el contratista. A un alto nivel, se contratan especialistas altamente calificados. En la parte inferior: todo el trabajo que no quieren hacer es arrojado a un lado. Obviamente, una clase de consultores recibe respeto, mientras que la otra no. Las empresas de consultoría mal administradas a menudo terminan como vertederos de basura para trabajos poco calificados. Scrum parece haber sido creado para organizaciones donde las relaciones con los clientes son tan malas que los ingenieros deben ser observados diariamente, porque se han convertido en un tanque de sedimentación para el trabajo base, inútil para una carrera que nadie quiere hacer (y probablemente este no sea un trabajo muy importante , por lo tanto, tasas bajas y respeto).

Transparencia violenta

Hay muchas tendencias en el lugar de trabajo de TI que hacen que una carrera de programación sea extremadamente poco atractiva, especialmente para las personas creativas e inteligentes.

El ejemplo más notorio son las oficinas de planta abierta. No son productivos. Es difícil concentrarse en ellos. Son antiintelectuales, ya que las personas temen que las atrapen leyendo libros (o simplemente pensando) en el trabajo. Cuando haces que las personas pretendan ser productivas, en realidad pierden productividad. Las oficinas de planta abierta generalmente no son para la productividad. Esta es una imagen corporativa. Las startups financiadas por empresas utilizan estos diseños para demostrar a los inversores que la oficina parezca ocupada. (En pocas palabras, un programador de plan abierto es más valorado como mobiliario de oficina, en lugar del código que escribe). Por varias razones culturales, esto hizo que la opción de plan abierto fuera "genial" y "sucia", y ahora infecta al mundo corporativo en su conjunto.

Es bien sabido que las personas creativas pierden su creatividad si se les pide que expliquen durante el trabajo. Lo mismo con el software. Los programadores a menudo tienen que trabajar en una transparencia unilateral. Estos sistemas ágiles a menudo se usan mal y requieren una transparencia de operación humillante, a pesar de la falta de reciprocidad. En lugar de trabajar en proyectos reales a largo plazo en los que una persona podría estar interesada, se ven obligados a trabajar en "historias de usuario" atomizadas y funcionales, y a menudo se les prohíbe trabajar en mejoras que no están relacionadas con las necesidades inmediatas a corto plazo de la empresa (a menudo desde la parte superior). Esta versión incorrecta pero común de Agile excluye el concepto de propiedad y considera a los programadores como componentes intercambiables e idénticos.

Scrum es la peor opción, con la estupidez de dos "iteraciones" de dos semanas. Esto causa una preocupación innecesaria por las microfluctuaciones en el desempeño humano. No hay absolutamente ninguna evidencia de que este enfoque realmente acelere o mejore el desarrollo a largo plazo. Simplemente pone nerviosa a la gente. Muchos en el negocio piensan que este es un buen enfoque, porque el trabajo "va más rápido". He estado en la industria de TI durante diez años, como gerente y como abeja trabajadora. Esto no es verdad

Defectos específicos ágiles y Scrum

1. Desarrollo orientado a los negocios.

Ágil a menudo se sirve en comparación con una "cascada". ¿Qué es una cascada?

El enfoque de la cascada es realmente terrible. En él, "el trabajo se despliega", donde cada nivel de la jerarquía organizacional selecciona lo que considera "material interesante" y lo pasa. Los gerentes determinan los proyectos, los arquitectos diseñan la arquitectura, los gerentes intermedios establecen los plazos personales, la implementación la llevan a cabo los caballos de batalla de alto nivel (programadores), y luego las operaciones y las pruebas se transfieren a los caballos de nivel inferior. Este es un esquema extremadamente no funcional. Cuando las personas sienten que ya se han tomado todas las decisiones importantes, no tienen motivación para trabajar lo mejor posible.

La cascada reproduce el modelo social de una organización disfuncional con una cierta jerarquía. A su vez, Agile replica con bastante frecuencia el modelo social de una organización disfuncional sin una jerarquía claramente definida.

Tengo opiniones encontradas sobre títulos de trabajo como "senior" y "director", y similares. Importan, y probablemente yo mismo no acepte un puesto por debajo del nivel del director, pero odio su importancia. Si nos fijamos en Scrum, priva específicamente los derechos de los ingenieros superiores y más capaces, porque aquí están obligados a adherirse a los procesos establecidos (trabajar solo en tareas creadas, 5-10 horas a la semana en planeadores). Estos procesos están diseñados para personas que comenzaron a programar hace un mes.

Al igual que un estado comunista fallido que iguala a las personas al propagar la pobreza, Scrum en su forma más pura coloca todo el desarrollo en el mismo nivel bajo: no está claramente definido, pero claramente por debajo del nivel de las personas de negocios que tienen el poder completo para decidir en qué trabajar.

Ágil, en su implementación habitual, aumenta la frecuencia de retroalimentación, sin dar a los ingenieros ningún poder real. Este es un trato perdido porque significa que es más probable que los programadores sean retirados o castigados cuando el trabajo lleva más tiempo del que supuestamente debería tomar. Esto crea mucha ansiedad y prisa, pero de hecho tiene poco que ver con lo que realmente importa: crear excelentes productos.

Silicon Valley ha cometido muchos errores, especialmente en los últimos cinco años, pero ha hecho algo bien. Incluyendo introdujo el concepto de empresa de "ingeniería". No siempre es mejor para los ingenieros administrar toda la empresa, pero cuando los ingenieros administran el desarrollo y establecen prioridades, todos ganan: los ingenieros están contentos con el trabajo que se les asigna (o, mejor aún, se asignan a sí mismos), y el negocio obtiene una calidad de desarrollo mucho más alta.

Pero tienes una "empresa comercial", está bien. Entonces no contrate ingenieros en el personal si necesita talento. Puede obtener las mejores personas como consultores (a partir de $ 200 por hora y aumentando considerablemente desde este nivel), pero no como empleados a tiempo completo de una "empresa comercial". Los buenos ingenieros quieren trabajar en empresas dirigidas por ingenieros, donde participarán en la planificación del trabajo sin tener que dar excusas a los "maestros de scrum", "propietarios de productos" y varios niveles de gerentes de humanidades.

En última instancia, Agile (como se practica) y Waterfall son formas de desarrollo orientado a los negocios y, por lo tanto, ninguna de ellas es adecuada para desarrollar software de calidad o motivar a los empleados.

2. La posición subordinada de los jóvenes.

Desafortunadamente, en el desarrollo de software se ha desarrollado una cultura de subordinación joven con el concepto (extremadamente erróneo) de programación como "juguetes de hombres jóvenes", aunque casi ninguno de los mejores ingenieros son jóvenes, y algunos de los mejores no son hombres.

El problema con las iteraciones ágiles de dos semanas (o sprints) y las historias de usuarios es que no hay una estrategia de salida. No hay opción "Ya no tendremos que hacer esto cuando lleguemos a [X]". Se supone que este sistema es para siempre: las manifestaciones orientadas a los negocios nunca desaparecerán. La arquitectura, la I + D y el desarrollo de productos dejan el trabajo del programador porque no encajan en "historias de usuario" atomizadas y sprints de dos semanas.

Como resultado, para los programadores más o menos experimentados, es incómodo trabajar de esta manera, porque quieren asumir los tipos de proyectos que se ignoran en esta estructura, y estos proyectos son difíciles de justificar en términos de valor comercial a corto plazo. La excelencia técnica es importante, pero es muy difícil convencer a la gente de este hecho si obstinadamente no quieren ser convencidos.

Una vez trabajé para una empresa donde un gerente de producto dijo que la diferencia entre un ingeniero senior y un ingeniero junior es la capacidad de dar estimaciones de tiempo más precisas. Bueno, en realidad no. Y hasta es insultante. Odio las evaluaciones porque generan políticas y en realidad no hacen el trabajo más rápido o mejor (de hecho, generalmente lo contrario).

La peor parte de las evaluaciones es que estimulan el desempeño del trabajo que puede evaluarse. Esto hace que los programadores den preferencia a cosas simples de bajo nivel que las empresas realmente no necesitan (incluso si los gerentes torpes de nivel medio piensan de manera diferente), pero es "seguro". Todo lo que realmente vale la pena tiene una probabilidad de falla no nula y demasiados parámetros desconocidos para una estimación razonable del marco de tiempo. El enfoque de Agile en el valor comercial a corto plazo en última instancia aleja a las personas del trabajo que la empresa realmente necesita, para administrar la reputación de cada programador en tiempo real.

Tal cultura sugiere que la programación es infantilismo, que debes eliminar antes de los 35 años. No estoy de acuerdo con esta opinión. De hecho, creo que este es un mal pensamiento. Tengo más de 30 años y siento que recién estoy comenzando a programar bien. Acosar a los programadores senior solo porque tienen la experiencia suficiente para saber que este proceso flexible / scrum no tiene nada que ver con la informática y que no agrega valor es una idea terrible.

3. Enfoque a muy corto plazo, que es estúpido y peligroso.

Agile está destinado a empresas de consultoría secundarias que no tienen crédito suficiente para negociar con sus pares en igualdad de condiciones, y que enfrentan plazos ajustados, y cada proyecto de cliente es un riesgo existencial. Él es para los extraños "marginales". Pero aquí está el problema: Scrum a menudo se implementa en grandes empresas y nuevas empresas financiadas. Pero las personas acuden a esas empresas porque no quieren ser extraños . Quieren seguridad. Por eso trabajan en estas empresas, en lugar de crear las suyas. Nadie quiere quedarse atrás si no hay un beneficio personal significativo. Ágil en una empresa significa dolor y riesgo sin recompensa.

Cuando cada proyecto de cliente conlleva un riesgo reputacional existencial o grave, Agile puede ser la solución adecuada, ya que centrarse en iteraciones a corto plazo es útil cuando la empresa está en riesgo y puede desaparecer a largo plazo. La gestión agresiva de proyectos tiene sentido en una emergencia. Esto no tiene sentido como un arreglo permanente; al menos no para programadores talentosos que tienen opciones menos estresantes y más agradables.

Como parte de Agile, la deuda técnica se acumula y no se resuelve porque las personas de negocios que asignan tareas no verán el problema hasta que sea demasiado tarde o al menos demasiado costoso para solucionarlo. Además, los ingenieros individuales son recompensados ​​o castigados únicamente sobre la base de los "sprints" actuales de dos semanas, es decir, nadie está mirando cinco "sprints" por adelantado. Agile es solo un "sprint" inútil y miope tras otro: sin progreso, sin mejoras, solo boleto por boleto, por boleto.

Las personas que están de acuerdo con la combinación de tareas sin sentido pueden soportarlo, pero los ingenieros realmente buenos odian ir a trabajar el lunes por la mañana, sin saber en qué trabajarán ese día.

4. No tiene nada que ver con construir una carrera.

Las historias de usuarios individuales no son buenas para una carrera de ingeniería. A la edad de 30 años, se espera que pueda trabajar al nivel de todo el proyecto y que al menos esté listo para ir más allá de ese nivel en infraestructura, arquitectura, investigación o liderazgo.

En una emergencia, ya sea una consulta que busca tranquilizar a un cliente importante o una "sala de guerra" corporativa, los pensamientos sobre un currículum pueden esperar. Pocas personas abandonan un par de semanas de trabajo desagradable u otro que no está relacionado con el desarrollo profesional, si es realmente importante para la empresa. La importancia del trabajo es prioridad aquí. Si puede decir: "Me senté en la sede y hablé con el CEO durante 20 minutos al día", eso justifica hacer un trabajo tonto.

Pero si no hay emergencia, los programadores esperan que sus carreras se tomen en serio. De lo contrario, se irán. "Estaba en el equipo Scrum" significa que eres un saco de boxeo. Una cosa es hacer un trabajo tonto, porque el CEO reconoció que una tarea desagradable agregará millones de dólares en valor (y la recompensará en consecuencia). Pero si simplemente se le asignaron "historias de usuario" y tickets de Jira, entonces se lo considera un perdedor.

5. El objetivo es determinar tasas bajas, pero el nivel de resultados falsos positivos es inaceptablemente alto.

Scrum se propone como una buena manera de identificar a los "empleados rezagados". El problema es que crea programadores más ineficaces de lo que revela. Este es un sistema de seguimiento total en el que los ingenieros individuales muestran en detalle el progreso de su trabajo, con una evaluación de la productividad.

En un debate sobre las libertades civiles, a menudo se menciona un error común: el argumento "nada que ocultar". A algunas personas les gusta argumentar que invadir la privacidad, por ejemplo, por la policía, no es un problema, porque ellos mismos no son delincuentes. Estas personas pierden algunas cosas clave. Por ejemplo, que las leyes están cambiando. Pregúntele a cualquiera que fuera judío en Europa Central en la década de 1930. Incluso para personas respetables, el estado de vigilancia es un estado de ansiedad.

El hecho de la observación cambia la forma en que trabaja la gente. En áreas creativas, duele. Es casi imposible trabajar creativamente si necesita informar sobre el trabajo todos los días.

Otro tema viene a la mente: sensibilidad al estado . Los programadores adoran fingir que han superado varios millones de años de evolución de los primates relacionados con el estado social, pero el hecho es que el estado social es importante, y no es vergonzoso admitir este hecho. Las personas mayores, las mujeres, las minorías raciales y las personas con discapacidad son generalmente sensibles al estado laboral porque es una cuestión de supervivencia para ellos. El monitoreo constante del trabajo indica una falta de confianza y un bajo estatus social, y los más sensibles al estado (incluso si son los mejores empleados) son los primeros en sufrir un mayor monitoreo. Si sienten que no son de confianza (¿y qué más se transmite por la cultura, donde cada elemento del trabajo debe ser aprobado?), Rápidamente pierden su motivación.

Ágil y especialmente Scrum son vulnerables al error "nada que ocultar". Si no eres un "mal trabajador", no estás en contra del deslizamiento diario, ¿verdad? Las únicas personas que se opondrán a los informes diarios sobre su trabajo en términos de valor comercial a corto plazo son los "holgazanes" que quieren robar dinero de la empresa, ¿verdad? Pues no. Obviamente no.

Una cultura de transparencia violenta está diseñada para los más insensibles al estatus: hombres jóvenes, generalmente blancos o asiáticos, privilegiados que nunca han sido presionados en el trabajo. Para aquellos que piensan que los recursos humanos y la gestión son una pérdida de tiempo, y el empleado simplemente debe tragar humillación e insultos.

A menudo, los mejores empleados sufren la implementación de Agile / Scrum, porque la I + D se elimina efectivamente. La obsesión con las "iteraciones" o sprints a corto plazo significa la incapacidad de probar algo nuevo, arriesgado.

La verdad sobre los empleados rezagados es que puede identificarlos sin ningún Ágil. La gente sabe quienes son. La razón por la que algunos equipos están llenos de mocasines, personas incompetentes o tóxicas es porque nadie hace nada con ellos. Este es un problema de gestión a nivel de personal, no a nivel de flujo de trabajo.

6. El efecto borracho.

Parece que la gestión agresiva puede hacer que algunas personas un poco incompetentes sean bastante capaces de trabajar. Yo lo llamo el efecto borracho: cuando las chicas se vuelven tan en forma, pero realmente lindas, ya no quieren tener nada que ver contigo. — , , -.

, , , : «» 7+ Scrum, 3- 4- 5-. , 7 5 , 5 3. ( ), , Scrum, .

Scrum Agile , . , , . 5 3 ( ) , .

Agile/Scrum , . , , , ( 50% , 10-30 ).

, , «» — . 22- 6, , 3 Scrum, 50- 9, , , 9 8,5, 3 6. , , . . , . , 5- , ( ) 4, 8 8.

7. .

Scrum. , Scrum « Agile», — Agile. (, : , Agile).

Scrum : , . , .

Scrum

, Agile , Scrum « » « ». , , .

, (, “Scrum Master”) . , « » ( ). , . «», , , , , , . , , . .

, , . , « », . . . , , , , , , , .

, . — « ». ( ) 4 , - , . -, , , .

, Scrum , «» : , , , . . .

, . , , . , , . , . , , .

(-?) , . Scrum - , (« ») ( «»), .

Agile Scrum . . , «-». . , , — , . , , .

, . , «» . , . , , « » ( ). , , Scrum — .

Agile Scrum, . , , , , . Scrum , — , , — «» , Agile . ( «-», ) .

, . . , -, , . , - , - « » — . : . Agile, , , , , — , , , . - — . , .