¿Es realista un gran aumento en la velocidad en un entorno Scrum?

Bueno, es perfectamente sencillo aumentar la velocidad en un 40%, solo agregue un 40% más de puntos a todas sus estimaciones y realice la misma cantidad de trabajo.

Dado que esto es así, debería ser evidente por qué el uso de la velocidad como objetivo es incorrecto, solo fomenta estimaciones infladas.

Una respuesta menos simplista es que tu estimación ya supone que vas a ir tan rápido como puedas mientras haces todo correctamente. La única manera de aumentar realmente la productividad en un 40% es trabajar horas extras o no hacer todo correctamente. Ambos aceleran las cosas a corto plazo, pero ralentizan las cosas a largo plazo. Y el largo plazo en este caso no es muy largo, un mes en el exterior. La estrategia óptima a largo plazo es nunca ir más rápido que su ritmo sostenible.

Peopleware habla con elocuencia sobre los problemas de tratar de forzar a los programadores hacia una mayor productividad, y es un clásico a menudo citado . Pero, en general, no será fácil cambiar la mentalidad de un gerente que está tomando el camino que es el suyo. Su proyecto puede estar en problemas, esto es ciertamente una bandera roja.

Como han señalado los comentarios, la solicitud es obviamente errónea en la forma en que se ha realizado. Pero no está realmente equivocado al querer mejorar constantemente la productividad. Como regla, eso es lo que los gerentes se esfuerzan (y son evaluados) por.

Dicho esto, los gerentes siempre buscan mejorar el rendimiento, y Scrum y Agile tratan de ser adaptables. Si bien la velocidad es una medida de tu ritmo actual sostenible, no debes sentarte en tus laureles. Scrum tiene un lugar para evaluar y cambiar lo que funciona y lo que no funciona en su proceso: la retrospectiva. Si aprovecha esto y ajusta su proceso, la productividad (y posiblemente la velocidad) debería aumentar.

Entonces, ¿estás buscando (en tus retrospectivas) formas de ser más productivo como equipo? ¿Hay algo en sus carreras que consuma regularmente una cantidad desproporcionada de esfuerzo? ¿Se puede abordar? Probablemente no le dará un aumento del 40%, pero 5-10% es un comienzo, ¿no? Cada sprint debe buscar cuellos de botella y abordarlos. Eventualmente, puede acercarse a la meta que se ha fijado para usted.

TL; DR

Velocity es muy útil para estimar programas o generar valores de planificación, y también puede ser un control de detección significativo para evaluar los cuellos de botella del proceso o cambios en la capacidad del equipo. Sin embargo, no es una medida válida de productividad.

Cuando Velocity se confunde con los objetivos de administración

"Velocidad" es un rango que expresa la capacidad promedio de un equipo durante un período histórico. Es un análisis estadístico del desempeño pasado, que luego se puede usar para proyectar estimaciones probabilísticas de la capacidad de carga de trabajo futura o los tiempos de ciclo. Esto está en marcado contraste con un "objetivo de programación", que es un objetivo administrativo que establece una línea de tiempo o un objetivo para la planificación.

Los gerentes de proyectos ágiles experimentados saben que el uso correcto de la velocidad es determinar si un equipo tiene la capacidad sostenible para cumplir con los objetivos de programación definidos por la administración. A veces la respuesta es sí, y todos son felices. A veces la respuesta es no, momento en el que el iron triangle obliga a tomar decisiones comerciales sobre el alcance, el costo, el tiempo y la calidad. / p>

Evalúa tus opciones políticas

  

Tenemos una velocidad promedio de 50 puntos de historia ... Me han pedido que la aumente en un 40% a 70 puntos de historia (sin aumento en los miembros del equipo).

Suponiendo que sus prácticas de estimación son sólidas y que su velocidad es razonablemente estable, su gerente no se alegrará de ajustar la escala de estimación o de establecer objetivos de administración que no se basen en el desempeño histórico. Como señala correctamente, esto es fundamentalmente un problema de capacidad .

El límite de capacidad puede estar relacionado con la cantidad de personas en su equipo, o puede ser una limitación de sus procesos organizativos. Por supuesto, agregar más personas tampoco siempre agrega la capacidad real del proyecto; Consulte Ley de Brooks para obtener más información sobre este error común.

El problema que enfrentas es político. Desde el tono de su publicación, parece que su gerente quiere ver un aumento en la productividad sin realizar cambios reales en la capacidad subyacente del equipo. Por lo tanto, las soluciones son también políticas, y en gran medida de naturaleza educativa.

Si usted es una tienda Scrum, solicite a su Scrum Master que aborde este problema a través de los canales de marco apropiados. Backlog Grooming y Sprint Retrospectives son a menudo las oportunidades ideales de inspección y adaptación para este problema en particular.

Si no es una tienda Scrum, debe decidir cuál es la forma correcta de abordar sus inquietudes dentro de su organización. Si está en buenos términos con su gerente, incluso podría prestarle una copia de Estimación y planificación ágiles para que ustedes dos discutan durante el almuerzo.

Si todo lo demás falla, prepárate para una death march puliendo tu currículum y haciendo tu Mejor profesional hasta que implodes el proyecto. 68% de los proyectos de TI fallan ; a menos que los objetivos de gestión estén firmemente basados en la capacidad organizativa, el suyo probablemente será uno de ellos.

¿No entiendo qué rol tiene su gerente en el equipo de Scrum? ¿Es él un entrenador? ¿Es el dueño de un producto?

Si está dentro del equipo como un entrenador o algo así (trabaja en una tarea de desarrollo) puede preguntarle por qué subestima su propia productividad, porque parece que no fue el caso de otros miembros del equipo. Si cree que puede asumir personalmente 30 puntos de historia más en cada iteración, déjelo mostrarlo.

Más probable: está fuera del equipo, ¿quizás el dueño del producto? Si es así, debería entender que hacer una petición tan estúpida simplemente detuvo la agilidad.

Una regla básica es que el propietario del producto establece el objetivo, mientras que el equipo establece lo que se puede hacer en una iteración. No hacerlo conduce al clásico y conocido círculo de hierro: recursos, velocidad, características. ¡Elige dos! No puedes elegir tres de ellos a la vez (y recuerda: la calidad no es una variable de ajuste, tratar de reducir los ángulos con una calidad baja empeorará las cosas).

Si él no quiere cambiar la meta actual, ¿tal vez se pueda alcanzar un aumento del 40% en la productividad al reclutar más personas para el equipo? ¿Tal vez invertir en algún entrenamiento avanzado para algunos miembros del equipo? Los equipos también pueden ganar velocidad con el tiempo mediante la mejora continua, pero ciertamente no por decisión arbitraria.

Intentar cambiar la velocidad de un equipo es como intentar cambiar el tamaño de una habitación. Se puede hacer, pero básicamente necesitas cambiar la habitación.

¿No tienes a Scrum Master, u otras personas con conocimientos básicos de Scrum, que podrían explicarle eso?

En este caso, el gerente ha tomado la dirección equivocada luego de obtener una estimación honesta y fiel del equipo. Se supone que el gerente debe dirigirse a las partes interesadas e informarles que sus requisitos no se pueden completar en el tiempo solicitado. El gerente / analista debe entonces priorizar cuáles de las características DEBEN incluirse y las otras que pueden esperar (aunque sea solo un par de semanas). Si la parte interesada no es razonable, entonces puede ser necesario que los gerentes se involucren más, lo que generalmente puede ser un desafío y requerir otro conjunto de discusiones.

Si estuviera en su lugar, presentaría un caso detallado de por qué el proyecto IS va a tomar todo el tiempo estimado. También trate de identificar los artículos de bajo retorno. Encuentre los elementos que no agreguen mucho valor y que requieran esfuerzos de programación sustanciales, y defina cómo eliminarlos del sprint. También cree un enfoque iterativo que ofrezca una "X" en la fecha "Y" y asegúrese de que sea factible, luego cree una iteración de seguimiento que les permita obtener los elementos restantes.

Básicamente, alguien necesita decirle a las partes interesadas lo que pueden esperar recibir antes de la fecha límite y eso incluye la mayoría de sus requisitos. y que por la siguiente versión tendrán los elementos restantes. Si el cliente es irrazonable, entonces la gerencia superior debe involucrarse, el gerente debe poder hacer que esto suceda.

Sin embargo, si el cliente fue más que prometido, y nadie ha hablado hasta ahora, será una batalla cuesta arriba. Esto no es una situación poco común, lamentablemente.

Parece que te enfrentas a dos problemas.

La parte sobre la velocidad de medición que te molesta es probablemente que la medición es el costo . Lo que realmente quieres mejorar es el valor . Desafortunadamente, medir el valor del software es notoriamente difícil y subjetivo. Aún así, incluso una métrica imperfecta y subjetiva puede ser útil. Podría ser que el problema real no sea que su equipo necesite escribir más código, sino que las historias deben ser más valiosas.

El otro problema es que, según su cuenta, su gerente esperaba un aumento del 40% en la productividad. No se indicó en su pregunta el contexto de esta solicitud. Podría ser un buen deseo si el deseo de tu equipo para mejorar. O podría ser una indicación no tan sutil de que su gerente cree que su equipo tiene un bajo rendimiento.

editar: Basado en tu comentario, la situación se ve mal. Parece que su compañía está sentando las bases para despedirlo a usted y a su equipo (quizás también a su gerente). Te sugiero que busques otro trabajo.

despedirlo. Es decir, pasar por alto su cabeza y explicar que ha perdido toda la confianza de su equipo y explicar que no tiene ningún valor para el negocio. Explique que los gerentes con este nivel de incompetencia son mucho más fáciles de reemplazar que el equipo a continuación.

No hay una buena razón para aguantar a un gerente de este tipo, pero eso no debería significar automáticamente que los desarrolladores deban renunciar. No hay necesariamente algo malo con el negocio, solo con este individuo. Soluciona ese problema.

Y para evitar cualquier sacudida por parte de la alta gerencia, deje en claro que esto no es un error perdonable. Indica que el gerente responsable tiene no comprensión del equipo que está administrando. Eso no se presta a reparaciones, ni hay necesidad de hacerlo en el mercado laboral actual. Los gerentes son eminentemente reemplazables al igual que los entrenadores deportivos. Los propietarios no disparan equipos.

Ahora, esto podría parecer una estrategia que puede ser contraproducente. Pero considere: si la gerencia superior está del lado de su gerente, de todos modos, ya estaría en una posición perdedora. Por lo tanto, si solo considera las situaciones en las que aún no está en esa posición perdedora, el resultado probablemente será mucho más positivo. El verdadero riesgo es que la alta gerencia simplemente despida a todo el equipo, incluido el gerente. Solo tú puedes estimar ese riesgo. Al parecer, se desea su producción, de lo contrario no pedirían más, pero ¿a qué precio?

Mi experiencia es que ha sido muy, muy difícil aumentar la velocidad real de un equipo, dado que ni el equipo, el dominio del problema ni la pila de tecnología cambian.

Donde he podido lograr aumentos, ha sido una cuestión de:

• limpiando la deuda técnica; garantizando que todo se ejecute en la versión correcta (¡no necesariamente la última!), que el código esté bien factorizado y que no haya redundancia en el sistema (código duplicado, código no utilizado, etc.)

• mejorar las prácticas; emparejarse donde sea posible (sí, he encontrado que aumenta la velocidad), tomarme el tiempo para refactorizar agresivamente (¡ídem!) y ser implacable con el alcance y el enfoque

• encontrar y / o comprar las mejores herramientas para el trabajo (por ejemplo, ReSharper para .NET vale su peso en oro, Airbrake y Splunk para desarrollo de Ruby, etc.)

Estoy de acuerdo con otros aquí que dicen que su gerente que solicita un aumento arbitrario en la velocidad es una bandera roja. Yo estaría buscando otro trabajo como una alta prioridad.

Su gerente le pide (o le dice) a su equipo que trabaje horas adicionales. Si bien eliminar los cuellos de botella y aumentar la eficiencia puede mejorar su velocidad de alguna manera, la única forma de lograr ese aumento (40%) es trabajar horas más largas, ya que necesita rellenar más unidades de trabajo en ese período de tiempo.

Tomemos un escenario.

Para una interation de dos semanas, digamos 10 días. La utopía sería de 8 horas al día, con un punto de historia resumido a un día de trabajo. Por lo tanto, desde la cima, su velocidad debería ser 8. Pero, a la larga, las personas probablemente reciben 6 buenas horas al día con correos electrónicos, reuniones, descansos en el baño, etc. Así que ahora tiene 6 por desarrollador. Entonces, su línea de base es 6. Digamos que quiere que las personas trabajen horas extra, ahora que están allí 10 horas al día. Entonces, eso sería 10 puntos de velocidad por desarrollador.

Su velocidad siempre fluctuará, tal vez fue baja porque tuvo que lidiar con muchos errores durante esa iteración, tal vez faltaron los requisitos, tal vez alguien se enfermó durante unos días. Quizás fue alto porque el trabajo fue sobreestimado o su equipo trabajó horas extras.

Pero si estás en un establo 50, realmente para llegar a 70 necesitarás horas adicionales.

El problema con la velocidad es que es una variable dependiente, una salida medida de su proceso de desarrollo. Exigir aumentar la velocidad en un 40% es como tratar de llegar antes al trabajo gritándole a los autos que vayan más rápido. La velocidad aumenta al suministrar más combustible y aire al motor o al obtener un automóvil más rápido, además de encontrar una ruta con menos tráfico.

Trabajar más horas no aumenta la velocidad si lo mide correctamente, por ejemplo, en puntos de características por hora de desarrollador. Solo funciona si mide puntos por día y luego redefine lo que es un "día" en la mitad de la medición. Esto proporciona solo la ilusión de velocidad.

Un aumento en la velocidad requiere mejorar las variables independientes en el proceso dev; Computadoras y compiladores más rápidos, sistema de compilación más eficiente, mejor proceso de diseño, desarrolladores más capaces, mejor espacio de trabajo, motivación súper duper. Una mejora del 40% requeriría cambios muy significativos.

Pregunte si su gerente consideraría ubicar a su equipo en oficinas cerradas alrededor de una sala de trabajo común, comprar el nuevo equipo de desarrollo de equipos o contratar a un par de desarrolladores realmente superiores para que sirvan de mentores al equipo si eso le ayudaría a obtener sus 40 %. Si no hay recursos disponibles para mejorar las entradas a su proceso de desarrollo, eso descarta un sincero interés en mejorar. Esto deja a su gerente de ingeniería inversa para descubrir qué es lo que realmente lo motiva, lo que sería el tema de todo un 'otro hilo'.

Bueno, estoy un poco sorprendido de que las otras respuestas tomen en serio la solicitud del jefe. Alguien que exige un aumento del 40% en la productividad no sabe nada sobre el desarrollo de software.

Todavía disfruto leyendo Phil Factor sobre este tema:

  

Hay dos rutas básicas hacia la administración de TI. Puedes aprender tu   comercia a través de la sangre, el sudor y las lágrimas y sube por la escalera   gradualmente, basado en la credibilidad que ha ganado con los ganados con esfuerzo   Conocimientos técnicos y proyectos exitosos. Alternativamente, usted puede don   un traje y una corbata afilados, aprenda la jerga y hable suavemente hasta llegar a la   arriba.

     

Ambas rutas parecen igualmente efectivas. Tratar con la última raza.   Ciertamente puede causar algunos momentos de consternación e incredulidad ... desesperación   incluso ... y algo de eso está documentado en estas historias.

     

Sin embargo, es fácil sentirse triste y amargado cuando uno   Se encuentra con la incompetencia técnica en posiciones de poder, y para atacar a todos.   Gerentes con ese mismo pincel. Phil aconseja no hacerlo. La mayoría de los gerentes   Trabajar duro y contribuir bien a la empresa, e incluso a los gerentes pobres.   puede ser entrenado hasta el estándar requerido, si solo sigue unos pocos   Directrices simples. Es parte de la responsabilidad de su equipo ayudar a su   función de administrador de una manera que beneficie a todos.

     

En última instancia, si no puedes entrenarlos, promocionarlos o evitarlos,   Tal vez puedas aprender a amarlos solo por su no intencional.   Contribución a la rica comedia del lugar de trabajo.

El consejo de no llegar a ser "triste y amargado" es lo mejor que puede obtener. No pelee con un jefe técnicamente incompetente por asuntos técnicos. Simplemente verá eso como un ataque personal.

Su administrador ha entendido mal el uso de la velocidad. No es una métrica y no es un objetivo. Su finalidad es la calibración de la carga de trabajo del equipo por sprint.
Si lo piensas bien, tu velocidad emerge de una mejor suposición, que vuelves a medir después de cada sprint. Por lo general, a medida que avanza el tiempo, debería ser algo estable. Pero eso no cambia el hecho de que es un subproducto de lo que realmente está haciendo su equipo: crear valor para sus clientes.

La razón por la cual es incorrecto usarlo como un objetivo y / o una métrica es porque eso lo convertiría en una métrica de vanidad. Se vería bien en papel, pero no haría absolutamente nada para reflejar si sus productos satisfacen o no sus productos. Y eso es lo más importante (espero).

Con respecto a mi experiencia e ir directamente al grano.

Primero, podrías inflar la estimación, pero eso no significa que estés haciendo más.

Segundo (premisa: sin inflar, solo enfocado en la velocidad del equipo),

Intenta encontrar las habilidades dentro de tu equipo. ¿Están trabajando en lo que son mejores? ¿Necesita un arquitecto de sistemas para tomar las decisiones difíciles relacionadas con la construcción de la aplicación y las cosas complejas? ¿Cómo el equipo está gastando sus esfuerzos? ¿Pasan tiempo buscando soluciones para sus problemas, refactorizando, tomando decisiones de negocios o qué?

¿Son cómodos, enfocados y estimulados? ¿Qué será lo próximo para ellos?

Esto no es "estoy presionado en los límites" ... es más como una pregunta para todo el equipo "¿Estamos en los límites?" y "¿Cómo podemos empujar los límites?" ...

Tengo equipos de alto rendimiento líderes (para la primera construcción y / o migraciones) ... la motivación del equipo es la clave del éxito ... y es esencial planificar cómo sería la base de la aplicación. A veces, yo o un compañero de equipo tomamos el rol de Arquitecto de sistemas y decidimos cómo y dónde debería ir la "cosa".

A veces, cuando veo que mis compañeros están perdiendo eficiencia, trato de romper e invitarlos a salir a tomar una cerveza o algo que les guste. Esto resuelve cualquier conflicto y al día siguiente están enfocados nuevamente.

VENDIENDO...

Si explica las razones por las que no puede aumentar la velocidad es difícil, use el ROI.

Scrum se enfoca en lo que es más importante para el cliente. Teóricamente las tareas más rentables.

Si sus problemas se relacionan con la venta del esfuerzo de desarrollo, ¿qué cree que vender cuál es el retorno de la inversión del esfuerzo de desarrollo en lugar de convertir directamente los puntos de la historia al "precio"? Si puede probar que su equipo trabaja con un alto retorno de la inversión, ¿quién lo interrogará? Además, cada equipo tiene sus límites si el equipo ha encontrado su "tamaño de confort", intente un mes a mes un ligero aumento, si no pudieron terminar todas las tareas, este es (probablemente) el límite.

Muestre el historial de las tareas, el ingreso de ganancias (si está disponible), el punto de historia que ha usado y demuestre que LA PRODUCTIVIDAD NO ES EL ESFUERZO DEL EQUIPO es un cálculo determinado por el equipo para evaluar la complejidad y quizás el momento para hacer algo