¿Cómo gestionar un ejército de no-realmente-desarrolladores que intentan escribir código por el bien de la gestión de proyectos?

La idea de que "todo el mundo es desarrollador" y "todo el mundo escribe código" no es lo mismo. En este sentido, "desarrollador" no significa "programador", sino "persona o cosa que desarrolla algo". Los diseñadores, programadores, probadores, analistas de negocios y otros de UX están involucrados en el desarrollo de un producto.

A veces, la idea de que "todos somos desarrolladores" puede ser útil para formar la cultura de que todos somos iguales. Algo que he visto antes son los programadores que piensan que son mejores que los evaluadores o que no presionarán a un diseñador de UX con respecto a las decisiones de diseño. Pensar en todos como desarrolladores puede poner a todos en una posición de iguales colaboradores.

No hay razón para hacer que todos escriban código. En cambio, todos deberían contribuir usando sus habilidades. Podría haber formas de entrenar de forma cruzada. Quizás los diseñadores de UX puedan aprender habilidades de programación front-end para obtener una comprensión más profunda de la implementación de sus diseños. Los probadores pueden aprender a programar para una capacidad más profunda para realizar pruebas de caja blanca o automatización de pruebas. Del mismo modo, los programadores pueden aprender estas habilidades para aliviar parte de la carga de estos roles y compartir la carga de trabajo general.

El problema de que todos necesitan completar la misma cantidad de "puntos" probablemente esté empeorando esto. Por lo general, medir un trabajo como este se realiza a nivel de equipo. El equipo, en su conjunto, planifica y ejecuta el trabajo. Todos aportan todas sus habilidades para ayudar al equipo a terminar el trabajo y entregar productos y servicios de alta calidad.

No creo que esto sea algo que se pueda trabajar dentro, al menos de manera efectiva. Algo debe cambiar; de lo contrario, tendrá personas que realizan trabajos para los que no están capacitados o calificados en nombre de "lograr puntos" en lugar de contribuir con su conocimiento y experiencia a los objetivos del equipo.

no hay roles en el equipo (un equipo "multifuncional" donde "todos los miembros del equipo son desarrolladores")

Una cosa que quiero señalar es qué significa exactamente multifuncional :

no es un equipo donde cada miembro puede hacer todo. Más bien, es un equipo que es capaz de hacer de todo.

Lo que sugeriría ante todo es confirmar qué es exactamente lo que quiere decir la alta dirección con "funcionalidad cruzada". Es posible que la alta gerencia simplemente dijera "¡hagan que los equipos sean interfuncionales!" y los mandos intermedios malinterpretaron eso como '¡hacer que todos hagan todo!' y todo esto es un gran malentendido.

No ayuda que cada desarrollador tenga una cierta cantidad de puntos requeridos por sprint y no hay diferencia entre las personas según la experiencia.

Tengo dos palabras para ti.

• Realidad
• Transparencia

Para ser buenas, las estimaciones deben basarse en la realidad. Ordenado en términos de mejor pero menos probable que se permita a peor pero más probable:

1. Dígale a la gerencia que está reduciendo los puntos de la historia por iteración. Usted (el desarrollador de software real) se reducirá para que coincida con todos los demás.
2. Dígale a la gerencia que está modificando la cantidad de trabajo a la que corresponde 1 punto de historia. Exactamente igual que el anterior pero con una capa adicional de direccionamiento indirecto.
3. Ignore todas las estimaciones por completo. Ellos no existen. Cuando la gerencia lo cuestione, explique que las estimaciones no son realistas.
4. Vota con los pies (encuentra un nuevo trabajo).

Es común que las estimaciones las haga el equipo incluso en equipos no autogestionados. Una estimación poco realista, impuesta por alguien que no está familiarizado con el trabajo, no vale los bits utilizados para almacenarlo y debe tratarse como tal.

Además, la gerencia debe ser consciente del efecto de las decisiones. La transparencia es clave: la gerencia que toma malas decisiones cuando tiene todos los hechos es incompetencia, pero tomar malas decisiones porque no sabe lo que está pasando es una tragedia evitable.

Analogía: "Todos los que saben cómo ocupar una casa, o que tienen interés en cómo se ve su casa, saben cómo construir una y, por lo tanto, saben cómo contribuir de alguna manera significativa a cómo se debe hacer tal cosa". construirse".

Mi Experiencia: No pretendo saber. Por favor, no me den una tarjeta de regalo de Home Depot para Navidad. Elijo contratar contratistas profesionales con licencia. Me dan montones de tarjetas de presentación y yo las distribuyo diligente y felizmente.

Mejor recomendación: "Este barco se está hundiendo. Dirígete a los botes salvavidas".

Esto me huele a un muy mal malentendido de Scrum. La intención nunca fue homogeneizar a todos para que tuvieran el mismo conjunto de habilidades y realizaran las mismas tareas, como si las personas con diferentes conocimientos fueran intercambiables. Puede buscar algo de claridad sobre lo que significan estas directivas. Si los miembros del equipo quieren capacitarse para comprender el trabajo de los demás, eso es beneficioso, pero si no contrataría a alguien para hacer el trabajo de un desarrollador sin experiencia en ese trabajo, entonces no espere que otro empleado con un conjunto de habilidades diferente sea mejor en un papel diferente. Esta idea de que cada empleado necesita cumplir con una cuota de 'puntos' es una tontería. Si esa es realmente la dirección que ha recibido, es posible que deba descartar la definición de 'puntos',