Tratar con sprints fallidos y plazos

80

Muchos libros y artículos de Scrum dicen que un sprint fallido (cuando el equipo no completa algunas características del Backlog de Sprint) no es algo tan malo, sucede de vez en cuando, y puede ser útil si el equipo aprende de sus errores y mejora algo en los siguientes sprints. Y el equipo no debe ser castigado por no completar el trabajo al que se comprometieron.

Esto se ve muy bien desde el punto de vista del desarrollador, sin embargo, supongamos que tenemos una compañía de software " Scrum-Addicts LLC " desarrollando algo para clientes serios (" Money-Bags Corporation "):

  1. Los gerentes de Scrum-Addicts sugieren hacer una pieza de software para Money-Bags
  2. Acuerdan una lista de características, y Money-Bags pide que se les proporcione una fecha de envío.
  3. Los gerentes de Scrum-Addicts consultan a su equipo de scrum, y el equipo dice que tomará 3 sprints de una semana para completar todas las características
  4. El administrador de Scrum-Addicts agrega 1 semana para estar seguro, promete enviar el software en 1 mes y firma un contrato con Money-Bags
  5. Después de 4 sprints (fecha límite de envío), el equipo de Scrum solo puede entregar el 80% de las funciones (debido a la inexperiencia con el nuevo sistema, la necesidad de corregir errores críticos en funciones anteriores en el entorno de producción, etc.)
  6. Como sugiere Scrum, en este punto, el producto es potencialmente enviable, pero Money-Bags necesita el 100% de las características, como se menciona en el contrato. Entonces rompen el contrato y no pagan nada.
  7. Scrum-Addicts está al borde de la bancarrota porque no obtuvieron dinero de Money-Bags, y los inversores quedaron decepcionados con los resultados y no están dispuestos a ayudar a la empresa.

Obviamente, ninguna compañía de software quiere estar en el lugar de Scrum-Addicts. Lo que no entiendo sobre Agile y Scrum es cómo sugieren que los equipos deben lidiar con la planificación y los plazos para evitar la situación descrita anteriormente. Entonces, para resumir, tengo 2 preguntas:

¿A quién culpar?

  1. Gerentes, porque es su trabajo hacer la planificación adecuada
  2. El equipo, porque se comprometieron a hacer más trabajo del que podían
  3. Alguien más

¿Lo que se debe hacer?

  1. Los gerentes deben mover la fecha límite 2 veces (o 3 veces) más tarde que la estimación del equipo original.
  2. Se debe alentar a los miembros del equipo a hacer todo el trabajo al que se comprometieron sin importar qué (emitiendo sanciones por sprints fallidos)
  3. El equipo debería abandonar Scrum porque no se ajusta a la política de fecha límite de la compañía
  4. Todos deberíamos abandonar el desarrollo de software y unirnos a un monasterio
  5. ???
Andre Borges
fuente
31
El punto 3 en "Por hacer" supone que no usar Scrum hubiera cambiado nada al tener solo el 80% de las funciones listas en un mes. Eso es ridículo.
Doc Brown
77
@DocBrown, no puedo estar de acuerdo en que es ridículo. Dejar algunas actividades de Scrum como reuniones retrospectivas y de demostración podría acelerar el desarrollo. Y en caso de un contrato sólido como una roca, esto podría ayudar a lograr el objetivo final: entregar una cantidad fija de características al final de la fecha límite.
Andre Borges
26
@AndreBorges Su sugerencia para dejar caer retrospectivas y demostraciones es lo mismo que sugerir al quitar los frenos de un automóvil. Claro, los frenos solo te retrasan. Pero eso es lo que te permite ir realmente rápido.
Eufórico
13
el mismo problema sigue siendo bajo cualquier sistema - en cuenta que se puede sustituir más o menos scrum con una cascada y un equivalente de la compañía todavía se declara en quiebra
jk.
66
Quizás si esos gerentes de Scrum-Addicts hubieran prestado más atención durante esas molestas reuniones "retrospectivas", habrían tenido la oportunidad de pisar el freno en la semana 1 o 2, en lugar de ver el proyecto dirigirse hacia el acantilado y pisar el acelerador. .
Dorus

Respuestas:

134

Veo varios problemas de gestión fundamentales en su ejemplo:

  • si un gerente de Scrum-Addicts firma un contrato de "fecha límite", pero agrega solo un margen de seguridad del 33% en una situación en la que "está involucrado un nuevo sistema", eso es bastante imprudente.

  • la disponibilidad de entregar al menos el x% de las funciones después de un mes podría haberse utilizado para negociar un contrato en el que los clientes pagan el dinero al menos parcialmente cuando obtiene solo el 80% de las funciones en la fecha límite. Un contrato de todo o nada es algo de lo que ni el proveedor de software ni el cliente se beneficiarán; esto significa no solo 0 dinero para el proveedor, sino también 0 características para el cliente. Y una metodología de desarrollo de todo o nada como "Cascada" solo le permitirá escribir tales contratos, un enfoque ágil ofrece posibilidades adicionales.

  • mirar los resultados de los primeros uno o dos sprints debería haber hecho obvio para el gerente que el equipo no puede cumplir con la fecha límite. Por lo tanto, debería haber tomado medidas anteriores y volver a priorizar las tareas y características restantes, o tratar de renegociar con el cliente antes. Por ejemplo, el gerente podría haber tratado de reducir el alcance de algunas de las características restantes, por lo que el equipo podría haber entregado todas las características mencionadas en el contrato, pero cada una de ellas en un alcance reducido.

Si una tarea tarda más de lo que pensabas, ninguna metodología de desarrollo te salvará de eso. Pero un enfoque ágil como Scrum brinda a la gerencia más oportunidades para controlar lo que sucede en esa situación. Si no hacen uso de esas oportunidades, es claramente culpa suya, no del equipo, no de "Scrum", y no del cliente porque "no acepta la agilidad".

Doc Brown
fuente
47
+1 para "Un contrato de todo o nada es algo de lo que ni el proveedor de software ni el cliente se beneficiarán" . Es la clave de la contratación ágil.
guillaume31
55
Y es cierto que el 80% no es bueno para algunos tipos de proyectos (en última instancia, es posible , aunque poco probable, que ágil sea demasiado limitante para prever esos proyectos). Entonces, por ejemplo, no sirve de nada tener el 80% de las características de su satélite cuando lo lanza, por lo que no se molesta con la contingencia en esos proyectos. Si no cumple, la misión de su cliente fallará (o se retrasará), no hay nada que pueda hacer en el contrato para cambiar eso.
Steve Jessop
66
@SteveJessop: Estoy bastante seguro de que incluso cuando construyes algo tan complejo como un software para un satélite, existen diferentes prioridades para diferentes características, y habrá muchas características en las que el alcance puede variar hasta cierto punto. La fecha límite puede ser fijada para tal situación, por supuesto, porque cuando no lleves el cohete al espacio hasta diciembre del próximo año, es posible que no tengas una segunda oportunidad.
Doc Brown
66
Pero para este ejemplo específico ... por supuesto, nadie habría enviado nuevos horizontes si no hubieran terminado las cámaras del hardwaredriver. Pero incluso para proyectos en esa escala, apostaría que uno no irá al espacio con todas las características que se imaginaban.
Zaibis
66
quizás pagar por hito o funcionalidad también podría ser una opción.
Bram
68

Una de las declaraciones de valor del " Manifiesto para el desarrollo ágil de software " es:

Colaboración del cliente sobre negociación de contrato

El hecho de que Scrum-Addicts LLC negocie un contrato en lugar de establecer una colaboración con un cliente me hace cuestionar su agilidad.

Una cosa está clara: la agilidad debe ser aceptada por TODOS. La agilidad no es solo para desarrolladores. Los gerentes y los clientes también deben aceptar los valores del Manifiesto Ágil. Si los clientes no aceptan la agilidad y aún requieren contratos rígidos y una colaboración mínima, entonces no utilices ágil o encuentres mejores clientes.

Es culpa del cliente que estén atrapados en su burbuja de contrato con un desarrollo impulsado por la fecha límite.

Eufórico
fuente
99
@RubberDuck Todavía no se ha implementado una metodología de gestión de proyectos de software que permita que las funciones se decidan por adelantado, se establezca un plazo y no sea terriblemente costoso. Alcance, tiempo, dinero; Elige dos.
Eufórico
8
@RubberDuck: El proyecto ya no es ágil, porque los requisitos están establecidos en piedra. Y la estimación es solo de tres semanas. No hay nada mágicamente malo en la cascada que lo haga siempre tarde, simplemente no puede lidiar con vagos requisitos y cambios. Sí, usaría "cascada" en este caso, o más exactamente "decidamos qué hacer y hagámoslo".
RemcoGerlich
3
@RemcoGerlich, irónicamente, "decidamos qué hacer y
hagámoslo
2
@RemcoGerlich ah, creo que no entiendes mi punto: en ese ágil no se trata realmente de los métodos de desarrollo, sino de la capacidad de continuar con el trabajo, usando lo que quieras. Se trata de progreso, no de procedimientos, después de todo. (por ejemplo, un equipo que solo hace Scrum no es ágil, un equipo que solo hace estilo cascada pero lo modifica para adaptarse a las circunstancias)
gbjbaanb
2
Estoy de acuerdo con Doc Brown aquí. Absolutamente puede tener un "límite de tiempo" sin decir exactamente "para qué". Es perfectamente razonable decir, por ejemplo, "Nuestra fecha límite es <alguna fecha>. En esa fecha, enviaremos lo que hemos hecho". El alcance de lo que se envía no tiene que establecerse en piedra en el momento en que se crea la fecha límite. El desarrollo ágil tiene que ver con la gestión del alcance y la comunicación del progreso dentro de incrementos de tiempo, que en realidad son plazos mínimos propios.
Eric King
15

¿A quién culpar?

Gerentes, departamento legal, contadores: elija ...

Sé que el ejemplo es un tanto artificial, pero el hecho de que la compañía podría retirarse sin pagar un centavo si no estuvieran 100% satisfechos debería haber hecho sonar las alarmas inmediatas, al igual que mezclar cascada y pensamiento ágil.

Los clientes quieren tener su pastel y comérselo: están felices de aceptar cascada, mini cascada, ágil, la-la-tierra siempre que obtengan el producto X por $ Y por la fecha Z.

El desarrollo ágil requiere absolutamente que el equipo de desarrollo y el cliente estén en la misma página desde el punto de vista de la metodología. Pensar que las diferencias culturales saldrán a la luz es una ilusión.

Robbie Dee
fuente
12

Los proyectos de TI tratan con incógnitas ; Algunas de estas incógnitas son incluso incógnitas desconocidas . Qué significa eso?

Tome por ejemplo un puente de juguete para su modelo de ferrocarril. Hay todos los parámetros que conoce:

  • Sabes lo grande que es el valle

  • Conoces el material de las montañas, su altura, estabilidad, etc.

  • Sabes cuanto material necesitas

  • Usted sabe de "proyectos" anteriores cuánto tiempo le llevó construir cosas similares

Hay muchas variables involucradas que influyen en su cálculo de invertir tiempo y dinero. Pero se podría decir sin pensar, si está terminado el próximo fin de semana.

Lleva el ejemplo un paso más allá:

  • Digamos que no construyes el puente para tu propio modelo de ferrocarril, sino que lo construyes para un completo desconocido: tu trabajo es construir un puente de ferrocarril entre dos montañas

  • Digamos que tiene información casi nula antes del panorama del modelo

  • La información sobre el paisaje es que tiene dos montañas, que no parecen demasiado grandes.

  • La consistencia de la montaña es entre roca y gelatina.

  • El costo total tiene un máximo de 10 $

  • El lugar de trabajo está completamente oscuro y no hay posibilidad de luz: solo tienes una caja de 8 fósforos

  • La fecha límite es de 3 horas.

Esa sería la analogía de un proyecto de TI. Tiene experiencia en la construcción de puentes y es fácil caminar en terrenos conocidos. Lo que hace difícil es la oscuridad . Hay muchas cosas que difícilmente puedes predecir: las medidas de las montañas solo se conocen después de hurgar en la oscuridad. Así es la consistencia de las montañas. A partir de eso, puede hacer estimaciones sobre cuánto tiempo le llevará y cuánto costará. Aquí las incógnitas son cosas que no sabes al comienzo del proyecto, como el terreno concreto, etc. Pero hay cosas que no puedes prever, incluso con la mayor experiencia y las estimaciones más conservadoras. Estas cosas son las incógnitas desconocidas que tienen un poco de caos.

Toda empresa de TI debería saber eso. Tienen que lidiar con el riesgo del proyecto.

1) Hay varias formas de minimizar el riesgo (financiero): el acuerdo podría incluir que el cliente pague por cada incremento de trabajo. Entonces, después de que se entrega el incremento 1, se debe pagar una tasa parcial. Mientras Scrum-Addicts LLC cumpla, existe un riesgo financiero mínimo. Cuanto más planificados sean los objetivos de sprint , menor será el riesgo total de cada sprint. Eso significa que si Money-Bags Corporation recibió el 80% del contrato, al menos deberían pagar el 80% del valor del contrato. Si se negaron a pagar después de un sprint fallido, el riesgo no es tan alto como negarse a pagar el 100%.

2) Scrum-Addicts LLC tiene un problema con sus desarrolladores

Los gerentes de Scrum-Addicts consultan a su equipo de scrum, y el equipo dice que tomará 3 sprints de una semana para completar todas las características El administrador de Scrum-Addicts agrega 1 semana para estar seguro, promete enviar el software en 1 mes y firma un contrato con bolsas de dinero

Eso sugiere que a) los desarrolladores no tienen experiencia con scrum ob) están haciendo mal scrum Mientras más tiempo trabajen los equipos con scrum, mejores serán sus estimaciones. Si los equipos hacen estimaciones y el gerente agrega un "amortiguador" como "seguridad", el gerente parece saberlo mejor que el equipo, lo cual es una mala señal . Si tiene un equipo experimentado, no hay necesidad de un "managerbuffer", el equipo ya lo incluyó en la estimación. La idea es que cuantos más sprints haya trabajado el equipo juntos, más sabe el equipo sus fortalezas y debilidades y tiene algunas métricas para hacer estimaciones realistas. Por supuesto, hay, como ya se mencionó, las incógnitas desconocidasque tienden a dificultar las estimaciones; o al menos impreciso. Pero a la larga, las estimaciones deberían mejorar y mejorar.

¿A quién culpar?

1) gestión

Como se dijo anteriormente: claramente hay una falla en la gestión de riesgos. Si la empresa está al borde de la bancarrota, se lo merece. Si trabajas en una empresa así: ¡vete!

2) El equipo

Incluso si la administración es completamente estúpida, el equipo debería haber hablado en contra de tal proyecto. Un buen gerente debe conocer los riesgos; pero un buen desarrollador debe señalar los riesgos. Y sobre todo: el equipo debe informar temprano si algo falla.

¿Lo que se debe hacer?

Ahora: lleve bolsas de dinero a los tribunales

Para el futuro: no haga tales contratos

Scrum no tiene la culpa de fallas en la administración. Scrum fue desarrollado en base a la experiencia de muchos proyectos de TI que fracasaron. No puede evitar el fracaso, ni puede curar la incompetencia de los equipos o la administración. La idea básica es:

  • para estructurar formas de comunicación (quién habla con quién cuando sobre qué)

  • para alentar a los desarrolladores a reportar fallas temprano

  • para dividir problemas en tareas y subtareas

  • para estructurar el tiempo y las capacidades (quién trabaja y en qué)

  • para distribuir las tareas en los intervalos de tiempo

  • hacer que lo impredecible sea un poco más predecible (planificación de póker)

o en general: para minimizar el riesgo.

Scrum es una herramienta como lo es un martillo. Si es una buena herramienta depende de su conocimiento sobre cómo usarla. Pero a veces un destornillador encaja mejor. Tu decides.

Thomas Junk
fuente
1
Hay otro aspecto de Scrum que es de vital importancia para comprender por qué este proyecto falló: scrum acepta el fracaso . Se espera que los primeros sprints de un nuevo equipo o proyecto fracasen. A través del proceso scrum de las retrospectivas, el equipo mejorará a sí mismo y, a largo plazo, será preciso en sus estimaciones, pero solo mientras sigan siendo el mismo equipo trabajando en el mismo proyecto. Cuando cualquiera de esos cambios, una vez más, debe esperar alguna falla ya que las variables subyacentes están cambiando.
Cronax
9

En primer lugar, "¿Quién tiene la culpa?" es la pregunta incorrecta que hacer. Asignar la culpa es divertido y todo, y probablemente hará que todos, excepto las personas culpadas, se sientan aliviados (en un sentido de "¡oye, no es mi culpa, el jefe lo dijo!"), Pero no es un uso productivo de tu tiempo , y en realidad puede ser contraproducente y causar una caída en la moral de los empleados.

Una mejor manera de verlo es "¿Qué causó el retraso?". ¿Fue falta de experiencia en la tecnología? ¿Errores críticos que no se detectaron en las pruebas / QA? Falta de pruebas / QA? ¿Demasiado optimista en la estimación? ¿No tiene en cuenta las estimaciones no tan optimistas del equipo? ¿Alguien fue atropellado por un autobús? Cualquiera sea la causa, la siguiente pregunta es "¿Cómo nos aseguramos de que esto no vuelva a suceder?". En algunos casos (con suerte raros), la respuesta para eso podría ser "deshacerse de tal y tal", pero si comienza con "Necesito castigar a quien sea responsable", es poco probable que vea la mayoría de los casos donde no es la solución correcta.

Dentro del proyecto, ya estás hundido. La fecha límite llegó y se fue, advirtió al cliente tan pronto como era evidente que iba a resbalar (porque lo hizo, ¿verdad? Si no, eso es parte del problema), y ahora tiene que ser manejado sin embargo, se explicó en el contrato (en realidad se detalla en el contrato, ¿verdad?). En términos generales, eso debería implicar negociar con el cliente cómo va a entregar lo que falta. A muchas personas les gusta pensar en un contrato como algo que no se puede cambiar, pero que se enfrentan a: a) cancelar el contrato y no tener lo que compró, b) demandar a la empresa por incumplimiento de contrato y gastar mucho dinero en los tribunales, yc) negociando cómo obtener su producto con la menor cantidad de problemas posible, la mayoría de las empresas eligen c.

Mirando hacia el futuro, antes de cotizar un precio / fecha límite a un cliente, debe analizar los riesgos involucrados en una fecha límite resbalada o sobrecoste (¿cuáles son las posibles causas de tal cosa? ¿Qué causas puede mitigar de alguna manera y cuáles no puede y solo tiene que planificar) y usar esa información para ayudar a decidir lo que va a prometer. Si es un caso en el que es 100% o nada, obviamente cotizará precios más altos y plazos más largos, porque el riesgo es mayor.

Notarás que no hablé sobre Agile en toda esta respuesta. Eso es porque (voy a olvidarme de la participación del cliente en Scrum por un segundo, aunque es muy, muy importante) en este punto, realmente no importa. Te enfrentarás a este problema en Agile, Waterfall o cualquier proceso de desarrollo que uses. Sí, se supone que Agile lo ayudará a administrar mejor los riesgos, al permitirle ver si se han convertido en problemas reales antes e involucrar al cliente en el proceso mismo para que siempre estén informados, pero no es una panacea.

Iker
fuente
3
-1 El punto ágil es que muchos de los riesgos simplemente no se pueden predecir. Por ejemplo, agregaron 1 semana de amortiguación en caso de que las cosas se resbalen. Siempre puede triplicar el tiempo necesario, pero luego pierde contra la competencia que no hace eso. Ágil debería adoptar la mentalidad "Se hace cuando se hace". Lo cual es simplemente incompatible con los contratos y los plazos como se describe.
Eufórico
3
@Euphoric No puedo estar totalmente de acuerdo. Sí, el punto de Agile es que no se pueden predecir muchos riesgos, y para eso es el búfer, lo concederé. Sin embargo, eso no significa que todos los riesgos sean impredecibles, ni tampoco que deba ingresar a un proyecto a ciegas, sin considerar los riesgos que puede predecir.
Iker
2
@Iker Uno no excluye al otro, pero el punto de ser realmente ágil en el proceso de desarrollo es que la mentalidad de "se hace cuando se hace" tanto para el cliente como para el equipo. Claro, siempre hay algunos riesgos que puede predecir, pero nunca puede predecir con éxito todos los riesgos posibles y exactamente qué impacto tendrán en su progreso. A menos que puedas ver el futuro de alguna manera. Es por eso que el trabajo ágil requiere una contratación específica, donde usted acepta que "continuaremos trabajando hasta que se acabe el dinero, o cualquiera de las partes ya no esté dispuesta o no pueda, o se satisfagan todas las necesidades de los clientes"
Cronax
ok, voté por el rechazo inmediato de la culpa como concepto. Estoy de acuerdo en que la culpa es un componente improductivo que es una distracción del éxito. Cambiemos la pregunta. Tal vez podríamos decir "¿cómo podríamos haber manejado esto"? "¿Cómo podemos convertir esto en un éxito para nosotros?" "¿Qué cambios de cada parte podrían haber tenido un resultado positivo?" Podría estar de acuerdo con cambiar "culpa" a "responsable", pero como cada proyecto con un vendedor y un cliente es una interacción de equipo, ¿no es responsable todo el 'equipo' global de todos modos? La cuestión de quién tiene la culpa se vuelve retórica.
Joshua K
4

En primer lugar, este es un problema con cualquier metodología de desarrollo. Al menos con un sistema de desarrollo iterativo, tiene algo que mostrarle al cliente al final de la fecha límite, que puede ser suficiente para obtener una extensión para completar el producto (¡incluso si el cliente no paga más!).

Hay casos en los que una fecha límite es una fecha límite, sin embargo, imagina que estás escribiendo un juego y absolutamente tiene que ser lanzado a tiempo para las vacaciones de Navidad. ¡Hacer eso mal ha llevado a la bancarrota a muchas compañías!

Para los métodos ágiles que tienen que completar una cierta cantidad de características en una fecha determinada, scrum probablemente no sea el mejor método para usar (como siempre he encontrado que scrum hace que el desarrollo sea más lento y no permite suficiente agilidad para alterar el proceso cuando necesario.

Lo que necesita, independientemente de la metodología, es configurar una acumulación de funciones requeridas para dar visibilidad del progreso. El progreso por sprint no es lo suficientemente bueno, no sabrá si está cumpliendo el objetivo final. Por lo tanto, una metodología de estilo kanban sería mejor: configure todas las características de la izquierda y trabaje con ellas a través del sistema para mostrar el progreso hasta su finalización.

Eso enfoca las mentes de las personas en lo que aún debe hacerse de una manera que Scrum no maneja, y permite que otras personas que no sean el equipo de desarrollo vean lo que queda y si es probable que cumplas con el objetivo (y por lo tanto gestiones las expectativas del cliente temprano) , u organizar esos bonos de tiempo extra antes de que sean necesarios).

Scrum es un sistema que funciona para siempre, definiendo y refinando continuamente algo. Simplemente no es adecuado para este tipo de desarrollo. Otros pueden manejar este estilo y aún mantener el concepto de desarrollo iterativo, Kanban es uno así, Crystal es otro. Pero lo que es esencial entender es que si sigues a Scrum religiosamente, no estás siendo ágil. Cualquier verdadero sistema ágil debería poder transformarse para hacer frente a estos problemas particulares, es por eso que se llamó ágil en primer lugar, se trata de hacer lo que debe hacerse, y si una fecha límite fija es parte de eso, entonces debe tenga en cuenta eso en su forma de trabajar.

gbjbaanb
fuente
66
"Juego listo para Navidad" podría ser un posterchild para Scrum. Envía el 80% que hayas terminado, vende el resto como DLC. Esa no es la situación hipotética discutida aquí, donde la fecha límite fijó tanto el tiempo como el alcance, con una multa del 100% por entrega parcial.
MSalters
2
@MSalters asume que el juego funciona, que al 80% no le faltan características que se pueden agregar más tarde, sino que rompen la funcionalidad o fallan errores. No tiene que ser un juego, podría ser cualquier software que deba enviarse por un plazo definitivo e inmutable (¡ya que ni Apple puede posponer la Navidad!)
gbjbaanb
66
Esa es la premisa básica de Scrum! La funcionalidad rota no cuenta. Si vienes de un fondo de Cascada, encontrarás que Scrum, por lo tanto, prioriza la corrección de errores en lugar de agregar nuevas características. "80% hecho" significa que faltan niveles, jefes faltantes, etc.
MSalters
1
@gbjbaanb Según ese razonamiento, algo podría estar hecho al 99.9% pero aún no funciona porque se bloquea inmediatamente al inicio.
user253751
@immibis pero eso es cierto sin embargo. Cosas como los juegos no tienden a dejar de lado las funciones hasta el final, la mayoría de las partes del juego tienen que implementarse para que todo funcione, mientras que puedes sacar algunas funciones (y sé que los juegos que han hecho esto) no agregan características incrementalmente. Entonces, un jefe perdido sería un juego roto. Solo elegí los juegos como ejemplo, ya que tienden (particularmente antes de la entrega por Internet) como ejemplos de plazos estrictos.
gbjbaanb
4

El paradigma de desarrollo no está sincronizado con el paradigma del contrato. Idealmente, la forma en que se escriben los contratos cambiaría, pero es poco probable que suceda. Sin embargo, incluso si dejaras caer el scrum, aún tendrías sorpresas y plazos vencidos (¡solo es probable que sea mucho más tarde porque hiciste todo ese diseño por adelantado y todo estaba mal!).

Con o sin un cambio en la forma en que se escriben los contratos, envía lo que tiene funcionando . Luego, cumpla el contrato comiendo un ciclo de tiempo de desarrollo para finalizar las funciones que no realizó.

¿Es bueno que no hayas cumplido todo lo que prometiste el día que prometiste? No, pero su cliente estará mucho más feliz si puede entregar algo que funciona a tiempo, y luego entregar el resto rápidamente después que si simplemente llega tarde y no tiene nada en absoluto para darles.

RubberDuck
fuente
3
Sí, a veces el cliente está más feliz si el equipo ofrece al menos algunas funciones de trabajo en porciones, pero este no es siempre el caso. Estoy hablando de casos en que (1) el producto es inútil para los usuarios finales a menos que se implemente el 100% de las funciones (por ejemplo, requiere una certificación costosa que debe hacerse solo cuando todo esté terminado) o (2) el cliente es una empresa de la vieja escuela con el enfoque de "todo o nada": si el producto no está 100% listo, consideramos que falló, rompe el contrato y despide a todos los responsables.
Andre Borges
2
El cliente siempre estará más feliz de ver el progreso en la forma de trabajar con el software. La certificación costosa puede esperar hasta que el producto esté satisfecho. Publicarlo al cliente no significa que tenga que hacerlo público. En el caso 2, realmente no hay otra opción que hacer que sus equipos legales / de ventas escriban mejores contratos. Honestamente, sin embargo, sus problemas serían los mismos, si no peor, con la cascada allí.
RubberDuck
2
@AndreBorges ¿Seguramente el cliente estará más feliz de ver el 80% de las funciones que de ver el 0% de las funciones? Al menos de esa manera, el cliente sabe que el producto está hecho principalmente.
user253751
@immibis, si dices eso, significa que has sido lo suficientemente feliz como para evitar algunos clientes 'peculiares' en tu trabajo. Existen algunas corporaciones enormes y torpes relacionadas con el gobierno que hacen cumplir términos de contrato no tan razonables, pero si invierte todos sus recursos en su tarea y logra tener éxito, pagan un dinero serio que podría elevar a su pequeña empresa por las nubes. Sin embargo, si fracasa, puede encontrarse buscando un nuevo trabajo. Es el riesgo que algunas personas están dispuestas a asumir.
Andre Borges
2
¡Exactamente! Debido a su burocracia interna y la falta de personal de gestión experimentado, a veces es más fácil para una gran empresa considerar un plazo fallido como un "experimento fallido" y abandonar el proyecto por completo, que hacer un mayor esfuerzo para tratar de comunicar y renegociar el alcance. Triste, pero cierto :(
Andre Borges
1

Muchos libros y artículos de Scrum dicen que un sprint fallido (cuando el equipo no completa algunas características del Backlog de Sprint) no es algo tan malo, sucede de vez en cuando, y puede ser útil si el equipo aprende de sus errores y mejora algo en los siguientes sprints. Y el equipo no debe ser castigado por no completar el trabajo al que se comprometieron.

La forma de "castigar" este tipo de comportamiento es limitando la cantidad de trabajo que los que no terminaron pueden realizar el próximo sprint. Las posibilidades de trabajar en cosas interesantes están desapareciendo. La recompensa por hacer un buen trabajo es más trabajo.

Esto se ve muy bien desde el punto de vista del desarrollador, sin embargo, supongamos que tenemos una compañía de software "Scrum-Addicts LLC" desarrollando algo para clientes serios ("Money-Bags Corporation"):

Los gerentes de Scrum-Addicts sugieren hacer un software para Money-Bags Acuerdan una lista de características, y Money-Bags solicita que se les proporcione una fecha de envío. Los gerentes de Scrum-Addicts consultan a su equipo de scrum y el equipo dice que tomará 3 semanas Sprints de larga duración para completar todas las funciones El administrador de Addumts de Scrum agrega 1 semana para estar seguro, promete enviar el software en 1 mes y firma un contrato con Money-Bags Después de 4 sprints (fecha límite de envío) El equipo de Scrum solo puede entregar el 80% de características (debido a la inexperiencia con el nuevo sistema, la necesidad de corregir errores críticos en características anteriores en el entorno de producción, etc.) Como sugiere Scrum, en este punto, el producto es potencialmente transportable, pero Money-Bags necesita 100% de características, como se menciona en el contrato. Entonces rompen el contrato y no pagan nada.

Scrum-Addicts está al borde de la bancarrota porque no obtuvieron dinero de Money-Bags, y los inversores quedaron decepcionados con los resultados y no están dispuestos a ayudar a la empresa.

Si el lunes te apuesto $ 100 a que lloverá el jueves y no lloverá hasta el viernes, estarías en lo correcto al tomar mi dinero. Si, en lugar de una oportunidad de jugar, lo que desea es un pronóstico del tiempo, entonces necesitamos un contrato que me permita darle un pronóstico actualizado el martes.

Obviamente, ninguna compañía de software quiere estar en el lugar de Scrum-Addicts. Lo que no entiendo sobre Agile y Scrum es cómo sugieren que los equipos deben lidiar con la planificación y los plazos para evitar la situación descrita anteriormente.

Piensa en POR QUÉ MB quiere llevarse la pelota e irse a casa. MB no exigió que el trabajo se realizara en un mes desde el principio. SA prometió el 100% de las funciones críticas en un mes y no cumplió. SA estableció la fecha límite no MB. SA incluso agregó arbitrariamente una semana a la fecha límite. Entonces, ¿por qué es una fecha límite?

Ocasionalmente, cuando compiten por el trabajo, las compañías de software ceden a la tentación de presumir y prometer la luna. Los profesionales establecen cuidadosamente si incluso se requiere una luna. ¿Cuál es la necesidad más crítica de MoneyBags? ¿El 100% de las funciones o un producto en funcionamiento en un mes? ¿Saben siquiera lo que es realmente crítico? ¿Hay algún evento próximo que establezca una fecha límite difícil?

Si yo fuera Scrum-Addicts negociando este contrato, me gustaría saber mucho más sobre las necesidades comerciales de Money-Bags y estructurar el contrato para otorgar tanta flexibilidad como Money-Bags se sienta cómodo. Les enseñaría cómo funciona el proceso ágil para que sepan qué esperar de nosotros.

De esta manera, en lugar de esperar que todo funcione de repente perfectamente en un mes, estarían esperando evaluar el primer producto en 1 o 2 semanas.

Entonces, para resumir, tengo 2 preguntas:

¿A quién culpar? Gerentes, porque es su trabajo hacer la planificación adecuada
El equipo, porque se comprometieron a hacer más trabajo del que podrían
Alguien más

Cualquiera podría haber detenido esta parodia antes de que tengamos un mes más adelante.

Podría ir tan lejos como culpar a Money-Bags Corp por contratar a un equipo que obviamente representaba fraudulentamente un proceso en cascada como ágil. El contrato en sí deja en claro que esto no es ágil. La planificación para hacerse en un mes no lo hace ágil.

Si insiste en que es ágil, es ágil con solo un sprint que dura un mes. Lo cual, sí, no recomendaría porque es, de nuevo, lo mismo que una cascada.

¿Lo que se debe hacer?

¿Qué tal ágil? Entregar algo cada sprint? Obtener comentarios antes de la fecha límite? ¿Sprints de una semana? ¿Qué tal renegociar el contrato draconiano en el momento en que sospechas que la fecha límite está en peligro en lugar de esconderte y orar? Como mínimo, puede dejar de perder el tiempo en un proyecto condenado y encontrar un cliente más razonable.

Los gerentes deben mover la fecha límite 2 veces (o 3 veces) más tarde que la estimación del equipo original.

Los multiplicadores de fechas límite son tan útiles como configurar su reloj 15 minutos antes para que nunca llegue tarde. Solo puedes engañarte a ti mismo tanto tiempo antes de darte cuenta de lo que estás haciendo.

Las primeras estimaciones son incorrectas. Intenta capturar lo equivocado. 5 semanas, más o menos, es una expresión simple que le permite expresar cuán incierta es realmente la fecha de finalización. En lugar de tratar de adivinar con precisión, adivina qué tan salvaje es su suposición. Haga un trabajo real y obtenga algunos datos reales. Entonces puede comenzar a hacer estimaciones con un rango más estrecho. Una o dos semanas es tiempo suficiente para hacer esto.

Se debe alentar a los miembros del equipo a hacer todo el trabajo al que se comprometieron sin importar qué (emitiendo sanciones por sprints fallidos)

Los miembros del equipo deben ser alentados. Fallido, cometido o de otra manera. En lugar de construir cualquier consecuencia artificial, como castigos o incluso bonificaciones (zanahoria y palo), los estudios han demostrado que las personas que realizan un trabajo creativo, como la programación, responden mejor si se les proporcionan tres cosas: autonomía, dominio y propósito.

Daniel Pink tiene una charla TED sobre esto. La charla es sobre la motivación no ágil, pero fácilmente vi cómo mapear estos puntos a ágil:

Autonomía: quiero dirigir mi propia vida. Permítanme elegir el trabajo del trabajo atrasado.
Dominio - Quiero mejorar en algo que importa - Comentarios de los clientes.
Propósito: quiero ser parte de algo más grande que yo: un equipo colaborativo.

El equipo debería abandonar Scrum porque no se ajusta a la política de fecha límite de la compañía. Scrum puede cumplir una fecha límite con mayor precisión que la cascada. Dado un plazo, el scrum puede cumplirlo. Puede cumplirlo con solo 1 de 47 funciones, dependiendo del tiempo, la función y la habilidad, pero puede cumplirlo.

Un proyecto ágil puede diseñarse tan extremadamente que cada noche, cuando el equipo se va a casa, está listo para enviar. Esto parece una tontería a menos que pienses en el envío como pedirle al cliente que pruebe y proporcione comentarios. Cuanto antes suceda, antes podrá hacer ajustes. Esto llega a todos los plazos posibles. Simplemente no todas las características. Pero te lleva a las características que importan.

Todos deberíamos abandonar el desarrollo de software y unirnos a un monasterio

Bien, como encerrarme en una habitación lejos de la vida real me va a hacer escribir MENOS código.

He editado esta respuesta a medida. Si tienes curiosidad, lee el historial de edición.

naranja confitada
fuente
Me gustaría suponer que te referías a sprint, no atrasados : me refería exactamente a lo que escribí en la pregunta: el retraso de sprint
Andre Borges,
las personas que realizan trabajos creativos como la programación responden mejor si se les proporcionan tres cosas: autonomía, dominio y propósito : este puede ser un gran tema para la especulación por sí solo, pero el hecho es que desafortunadamente mucho trabajo de programación se está volviendo menos creativo y más rutina (tareas aburridas, conjuntos tecnológicos fijos de pila y fetures, contratos estrictos). Por lo tanto, en muchos casos la zanahoria y el palo funcionan bien.
Andre Borges
@AndreBorges Tienes razón, estaba pensando en la cartera de productos. Recientemente he estado trabajando con una herramienta que llama al retraso del sprint el sprint y al retraso del producto. Me pillaste perdiendo la lucha para evitar que mi vocabulario se convirtiera en propiedad.
candied_orange
La programación de @AndreBorges nunca será un relleno de sobres. Es firmemente un problema de velas. La razón es porque cualquier problema repetitivo puede resolverse con el mismo código que resolvió el primer problema. A pesar de esto, la gerencia puede entrar en una mentalidad en la que piensan que la creatividad es un problema a ser eliminado. Trabajé y corrí desde varias de estas tiendas. No mantienen buenas personas. No producen buen software. Los desarrolladores son artesanos. Intentar convertirlos en trabajadores de la línea de montaje solo perjudica su causa. Mi trabajo no es voltear huevos. Es para asegurarse de que los huevos estén volteados.
candied_orange
0

Todos tienen que ser ágiles. Sea lo que sea que decida, será, quién hace qué, cómo, cuándo, dónde y por qué por todas las partes. Clientes ágiles, gestión y desarrolladores.

No puede dar una fecha de envío demasiado lejos en el futuro. Tú das una estimación.

Alguien necesitaba gestionar las expectativas del cliente. La razón por la que no te preocupas demasiado por perder un par de carreras es porque te ajustas para evitar que todo el proyecto se quede atrás. Si llega a la conclusión después de un sprint o dos de que no va a terminar de cumplir con la "fecha de envío", es entonces cuando se lo informa al cliente.

Ahora que quieres hacer? Deshágase de las funciones que no necesita o mueva la fecha. Si pudieras entregar a tiempo, lo harías. No dudes en traer malas noticias.

Quién sabe, en algunos proyectos, puede enviar antes.

No puedes ser ágil si el cliente no quiere.

JeffO
fuente
0

Gol

Creo que las siguientes dos "métricas" deberían ser la base para cualquier decisión comercial:

  • es el trabajo rentable (para el cliente)
  • ¿Estamos trabajando de la manera más eficiente posible?

Estos son bastante universales. Por supuesto, se vuelve más complicado muy rápido, por ejemplo, el trabajo rentable se trata de que el producto haga lo correcto, que el usuario pueda usar el producto, que el producto se comercialice correctamente, etc., para muchos de estos " Adictos al Scrum " LLC "no tiene responsabilidad.

Problema

El contrato no se centra en los objetivos descritos anteriormente. Hay una cláusula de "todo o nada": haga todo y pague, o no haga nada y no le paguen. Sin embargo, esto no se relaciona directamente con el valor que se está creando. Otro inconveniente que sigue: ahora debemos gastar tiempo y dinero para asegurar y verificar que se cumpla el contrato. ¿Por qué demonios querríamos gastar este dinero? ¿De qué manera asegurarse de que se cumpla un contrato ayuda cuando los requisitos han cambiado mientras tanto y hemos descubierto que el software solicitado no está creando ningún valor? ¡Solo hay más dinero por el desagüe! Ahora, por supuesto, hay una razón para este comportamiento:

  • Culturalmente estamos acostumbrados a comprar cosas así. Esperamos comprar el software como lo haríamos con un automóvil: elija una configuración, se le dará un precio y una fecha límite, y se sentirá muy descontento si no se cumplen los dos.
  • queremos descargar el riesgo y la responsabilidad
  • queremos estabilidad, ayuda con la planificación y nos hace sentir mejor (¡y también a nuestro cliente, que es un aspecto importante!)

Al final del día, tendremos que elegir un compromiso que nos permita satisfacer nuestras metas lo mejor posible.

Así es como debería funcionar

  • tener un contrato de servicios y trabajo en lugar de un producto
    • necesita ser rescindible en un plazo relativamente corto
  • trabajar en estrecha colaboración para garantizar una eficiencia óptima
  • involucrar a todas las partes necesarias, tanto de " Scrum-Addits LLC " como de " Money-Bags Corporation ": un "punto de contacto único" que canaliza toda la información no va a funcionar aquí

bueno, básicamente solo dije "sé ágil". Ahora aquí está el por qué:

  • proceso y contrato están optimizados para gastar tanto dinero en la meta como sea posible
  • tendrá que confiar en el contratista para hacer su trabajo, y no necesitará invertir mucho dinero para verificar que está a la altura del trabajo.
  • la capacidad de demandar a su contratista si no se cumplen sus expectativas / contrato generalmente no ayuda, porque hacerlo costará más que simplemente abandonarlo. Algunas de las principales preocupaciones aquí son el tiempo de comercialización. Lo más probable es que pierda mucho más dinero / negocio yendo a la corte de lo que obtendrá.
    • al final del día solo tendrás que correr algunos riesgos tú mismo.
BatteryBackupUnit
fuente