¿Cómo gestionar los desarrolladores ágiles que trabajan con personas de negocios tradicionales (en serie)? [cerrado]

Buenas tardes,

Mi ambiente de trabajo tiene algunos problemas. Nuestro equipo de TI está tratando de ser más ágil, pero en realidad no estamos obteniendo la aceptación del negocio. Asisten a nuestras revisiones diarias de stand-up y sprint, y ayudan con la planificación del sprint, pero luego dan la vuelta y hacen 4 meses de recolección de requisitos para un proyecto antes de avanzar con un estilo de desarrollo en serie (en su mayoría). Los objetivos del sprint son cosas como "acercarse un XX% al lanzamiento".

Para el equipo de TI, han convertido a los Sprints en una especie de marcha de la muerte. Terminamos un Sprint un día y comenzamos un nuevo Sprint al día siguiente. No hay reflejos ni cambios realizados entre sprints, solo durante.

Nunca antes había hecho ninguna de las metodologías ágiles, no he tenido una introducción muy agradable a ellas. Entonces mis preguntas son:

1) ¿Debería haber algún tiempo (tal vez una semana más o menos) entre sprints para hacer la reflexión / introspección / cambios / etc.? ¿O son los sprints consecutivos la norma?

2) ¿Hay alguna posibilidad de supervivencia para un equipo ágil sin contrapartidas comerciales ágiles? Si no, ¿hay algunas metodologías de transición o incluso consejos para mover el negocio hacia una mentalidad iterativa, si no necesariamente ágil?

3) ¿Debería estar todo tu equipo en cada sprint? Tenemos casi 20 programadores en un solo sprint pero trabajando en proyectos completamente diferentes (típicamente equipos de 3-5, a veces más grandes). ¿Es normal tener un único sprint o deberíamos tratar de administrar múltiples sprints independientes? ¿Deberíamos tratar de mantener los sprints múltiples al mismo tiempo o deberían permitir que sus horarios se superpongan y sean flexibles?

Cualquier pensamiento o consejo es apreciado. Esta es la primera vez que vengo de SO para hacer una pregunta, así que avíseme si hay mejores formas de formular este tipo de preguntas (las preguntas frecuentes fueron bastante útiles, pero aún no estoy seguro de seguirlas perfectamente). ¡Gracias!

1) Por lo general, puede revisar el último sprint en una reunión, planificar la siguiente y comenzarla. Particularmente revise cuán precisas fueron las estimaciones de tareas y alimente esto en las estimaciones para el próximo sprint. Podría retrasar el próximo sprint si necesita esperar los comentarios de los clientes de los resultados del anterior y cree que los comentarios influirán en las tareas para el próximo sprint.

2) No será más fácil, pero el equipo puede tener éxito. Tu comentario

Los objetivos del sprint son cosas como "acercarse un XX% al lanzamiento"

es un poco preocupante ya que lo ideal es que quieras incluir características / funcionalidades demostrables como objetivos en un sprint.

3) Dices que hay 3-5 proyectos completamente diferentes. Si no están relacionados, es decir, para diferentes productos, no hay necesidad de tenerlos sincronizados, pero cada uno debe tratarse como sprints independientes. Parece que tus equipos para cada sprint son probablemente de buen tamaño.

1) ¿Debería haber algún tiempo (tal vez una semana más o menos) entre sprints para hacer la reflexión / introspección / cambios / etc.?

No. una semana? Debes estar loco. 2 horas es el límite.

¿O son los sprints consecutivos la norma?

Absolutamente. De lo contrario, estás girando las ruedas.

¿Hay alguna posibilidad de supervivencia para un equipo ágil sin contrapartidas comerciales ágiles?

Los negocios nunca son "ágiles". Ágil es algo que haces. Ellos no. De hecho, nunca ellos. Solo piden cosas al azar. Lo logras.

Si no, ¿hay algunas metodologías de transición o incluso consejos para mover el negocio hacia una mentalidad iterativa, si no necesariamente ágil?

Ninguna. Descompones los requisitos en sprints. Es tu disciplina. No de ellos.

¿Debería estar todo tu equipo en cada sprint?

Si.

Tenemos casi 20 programadores en un solo sprint pero trabajando en proyectos completamente diferentes (típicamente equipos de 3-5, a veces más grandes).

¿Qué? Eso no es un equipo. Eso es un montón de equipos. 4 o quizás 5 equipos separados.

¿Es normal tener un único sprint o deberíamos tratar de administrar múltiples sprints independientes?

No tengo idea de lo que estás hablando. Pero, dado que parece tener 4 o 5 equipos todos juntos, está claro que tendrá una confusión masiva.

¿Deberíamos tratar de mantener los sprints múltiples al mismo tiempo o deberían permitir que sus horarios se superpongan y sean flexibles?

Cada equipo, y los sprints del equipo, son el problema del equipo. De nadie más.

Algunas personas piensan que grandes proyectos como este deberían ser un "Scrum of Scrums". Los equipos establecen sus objetivos, construyen sus cosas. Los representantes de cada equipo se reúnen periódicamente para coordinar a los equipos para obtener lanzamientos mutuamente beneficiosos.

Lamento que estés en una organización tan obviamente disfuncional.

Si desea tener alguna capacidad para medir el progreso, es absolutamente imprescindible que planifique en términos de hitos 100% completos. Si alguna vez hay espacio para un desacuerdo honesto sobre lo que es un hito en particular, la tendencia natural es que la persona que hace el trabajo tome la interpretación más optimista posible sobre cuánto han hecho, y la persona que escucha lo que dice para escuchar eso de la manera más optimista posible. Esto significa que las noticias mejoran a medida que avanza en la cadena, lo que lleva a una desconexión completa entre la realidad y lo que escucha la parte superior. http://www.davar.net/HUMOR/JOKES/SHIT.HTM es una versión humorística y completamente realista de este fenómeno.

¿Qué tan mala es esta desconexión? Considera esto. En el proyecto promedio, el tiempo real que se tarda en completarse (si alguna vez llega allí) promedia el doble de las estimaciones originales. Pero no importa cuánto se demore el proyecto, por lo general, las personas en la parte superior no reciben las primeras indicaciones de que el proyecto está retrasado hasta aproximadamente 2 semanas antes de la fecha de vencimiento, ya que ese es el punto en el que la desconexión entre las expectativas y La realidad ya no se puede ocultar.

Por lo tanto, los objetivos XX% más cercanos no son requisitos reales. Literalmente, su equipo debe negarse a aceptarlos como requisitos reales. Es su trabajo educarlos en cuanto a que necesita tareas concretas y procesables, y en la planificación deberán desglosarse en tareas específicas que pueden estimarse como un máximo de unas pocas horas.

En segundo lugar, como han dicho otros, es absolutamente necesario dividir su equipo en unidades más pequeñas, que probablemente tendrán que estar en horarios diferentes. La investigación indica que un solo equipo de software de 20 personas que trabajan en una cosa puede lograr tanto como un equipo de 5-8 personas. (Me encontré con este hecho sorprendente en el excelente libro de Steve McConnell Software Estimation ).

En tercer lugar, es una gran bandera roja que se siente como una marcha de la muerte. Si se siente como una marcha de la muerte, probablemente sea una marcha de la muerte. Los desarrolladores de software tienden a tener un rendimiento máximo cuando trabajan 35-40 horas a la semana. (Obtuve esa cifra del Desarrollo rápido de Steve McConnell ). Trabajar más horas puede aumentar el rendimiento temporalmente, a costa de una reducción a largo plazo del rendimiento. Un proyecto grande es un maratón, necesitas mantener el ritmo.

Cuarto, realmente debe haber un ritmo para un sprint. Cuando trabajé en un equipo haciendo scrum, nos pareció muy útil dividir cada sprint en dos secciones que llamamos "enfoque largo" y "enfoque corto". Durante el "enfoque prolongado", hicimos un avance en el desarrollo de software sobre las tareas acordadas para ese sprint. Durante el "enfoque breve" hicimos todo lo necesario para involucrar muchas interrupciones y cambios de tareas. Entonces fue cuando hicimos el control de calidad, la corrección de errores, varias reuniones, las tareas de estimación para el próximo sprint, y finalmente acordamos qué sería y qué no sería en el próximo sprint. Esto funcionó muy bien para nosotros porque gran parte del desarrollo de software solo se puede hacer cuando estás en la "zona", que generalmente no

Si sigues un ritmo como ese, entonces obtienes otra victoria al tener diferentes horarios entre equipos: tu equipo de control de calidad siempre puede trabajar en cualquier equipo que esté actualmente en control de calidad, lo que los mantiene con un nivel constante de trabajo.

Buena suerte, y tenga en cuenta que sin el apoyo de la parte superior es posible que no pueda solucionar la disfunción. Si ese es el caso, entonces su mejor opción realista puede ser encontrar una organización más saludable de la que formar parte en lugar de tratar de convertir su organización en algo en lo que no se convertirá.

1. Mi experiencia es que los sprints generalmente son consecutivos con cierta pérdida de tiempo para hacer retrospectivas, demostrar funcionalidad y planificar el próximo sprint. Por ejemplo, el último día de un sprint a menudo se consideraría una cancelación, ya que normalmente habría 3 reuniones que abarcaron ese día, por lo que un sprint de 2 semanas equivale a 9 días hábiles. La retrospectiva al final de un sprint puede traer cambios para probar en el próximo sprint que comienza casi de inmediato en cierto sentido.

2. Una posibilidad sí, pero bastante pequeña, como si usara Scrum, debería haber un propietario del producto aprobado por la gerencia para priorizar directamente la urgencia de algunas historias en comparación con otras. Debe haber una cierta comprensión de la responsabilidad que tienen, aunque otra parte es que el "XX% más cercano a la liberación" es una métrica bastante pobre en mi mente, ya que esto tiende a no incluir errores y otros problemas de última hora que son casi imposibles de corregir adecuadamente estimar en mi experiencia limitada. También hay algo que decir para entender cuándo los cambios en las prioridades pueden ser conocidos por el equipo y utilizados en la planificación de un sprint. La aceptación de la administración es crucial, ya que si no entienden lo que está haciendo, puede ser como tratar de hacer entregas mientras camina en una cinta estacionaria. Mientras tus piernas se mueven, tú no

3. No necesariamente, pero a veces ese puede ser el caso. La clave es saber cuánto se asigna cada desarrollador al proyecto y mantener esto constante para que cuando haya una velocidad de los primeros sprints iniciales, esto sea útil para predecir velocidades futuras en lugar de ser inútil como la cantidad de horas hombre en los proyectos rebotan demasiado para estimar más fácilmente cuántos puntos se pueden hacer en un sprint. Cada proyecto debe tener su propio conjunto de sprints si el proyecto es lo suficientemente grande como para abarcar semanas de trabajo.

Buena suerte en educar a la gerencia en términos de lo que tienen que hacer y cómo funciona, ya que puede ser su gran obstáculo para superar aquí.

Si su proyecto está utilizando Scrum, entonces debe tener un Scrummaster cuyo trabajo sea educar a todas las partes sobre cómo se supone que debe funcionar exactamente el proceso. Si está haciendo Scrum, parece que el scrummaster no está haciendo su trabajo, ya que no tener una recompensa del lado comercial del proyecto es un obstáculo ENORME (y no infrecuente).

Dígale a la gente del programa que lo arruine si dice que se acerque un XX% más para completarlo. DÍGALOS que terminará los requisitos X, Y y Z en tal o cual fecha. Si quieren contratar el horario, pregúnteles qué quieren eliminar, si se niegan, dígales que eliminen piezas o agreguen tiempo. Decir que se haga o de lo contrario no servirá de nada. Si presionan, asigne su código de administrador de proyecto para completar ese sprint. Tenga en cuenta que Agile es un esfuerzo de equipo. Si la gente de la administración del proyecto no trabaja 12 horas al día, es mejor que estén allí para buscar pizza y refrescos para las personas que están, y cualquier bonificación por hacer las cosas a tiempo o antes de lo previsto es mejor que vayan a las personas que hicieron el trabajo también. Dígale a la administración superior si usted también tiene, probablemente ellos fueron los que presionaron a Agile sobre usted sin capacitar a las personas de gestión de proyectos.

Haga un seguimiento de su progreso, realice ajustes y luego elija los siguientes requisitos para cumplir. Si el proyecto no se entregará hasta que todo esté terminado, no se preocupe por la prioridad de las características, preocúpese por las características que son importantes para usted para que se realicen para futuras piezas. Tienes que tomar posesión de esto. Tampoco debería ser una marcha de la muerte. Los proyectos de Scrum deben medir la cantidad de trabajo que puede completar en la duración de un sprint NORMAL. Que 10 (o 9 como se señaló anteriormente) días hábiles normales de 8 horas.

Una cosa que escuché en la conferencia Agile hace unos años fue que su equipo es como una fábrica y puede producir X cantidad de automóviles (o en su caso características) por sprint.

Además, sus equipos de sprint deben ser de 3 a 5 personas, no 20. Eso podría ser parte del problema. Cada equipo debe elegir sus historias (líneas de pedido de requisitos si lo desea) y trabajar para esas. Deben desplazarse por separado, pero reunirse con un grupo grande de alguna manera para compartir ideas.

Al administrar este tipo de equipos, puede ser mejor para los gerentes desplazarse por separado para determinar qué tareas entre equipos son necesarias y poner en contacto a las personas adecuadas. Un standup de 20 personas es monótono y aburrido para los involucrados.