¿Es la fecha de entrega fija de los elementos una forma de trabajo “ágil”?

Hay una diferencia entre cumplir el plazo y cumplir todos los requisitos. Es como el viejo adagio "rápido, bueno o barato, elige dos".

Entonces, aquí tiene fechas fijas para la entrega. Eso es bueno, significa que está limitado en el tiempo en que lo que entrega al final de su último sprint será el producto final. Recuerda que siempre tienes que lanzar un software funcional al final de cada sprint, ¿verdad?

Lo que puede suceder es que al software final le falten algunas características. Bueno, esto sucede con todas las metodologías de desarrollo, incluida la cascada. Todo lo que sucederá es que luego se le asignará la tarea de producir una versión de parche o una versión 2. ¡Eso supone que su entrega final es lo suficientemente buena, por supuesto!

Las fechas fijas no son una forma de trabajar no ágil. Agile no significa que haya un presupuesto ilimitado para que juegue con sus nuevas herramientas de planificación. Significa que tendrás que concentrarte en la entrega, eso nunca es algo malo.

No. Este es el tipo exacto de cosas que las empresas que no son de software tienden a hacer. Hay planes, y plazos, y presupuestos. E inevitablemente fallará, ya que los humanos apestan a predecir el futuro.

Repasemos los diversos puntos aquí:

  

La alta dirección nos sigue diciendo que trabajaremos de manera ágil en un nuevo proyecto por parte de la alta dirección.

Si fueras ágil, entonces estarías teniendo equipos auto organizados, sin que la administración te diga cómo trabajar.

  

Sin embargo, ahora han ideado un plan que detalla todo el trabajo que quieren que realicemos con fechas en cada elemento y muestren las fechas nuevamente con lo que se demostrará en cada uno.

No. Esa es más o menos la antítesis del desarrollo iterativo. Algo sucederá (alguien se enferma, alguien se va, se olvidó algún requisito, sus servidores mueren, lo que sea) y luego se olvida uno de estos objetivos. Ahora la administración puede volver a calcular el plan completo , o romper el látigo en el desarrollo.

  

el equipo de desarrollo no ha estimado ninguno.

Entonces, ¿cómo sabe la administración que este plan es viable en absoluto ? En Ágil, el trabajo es una negociación. El negocio dice: nos gustaría esto. La ingeniería dice: está bien, suponiendo que XYZ, eso tomará 3 semanas. No hay colaboración del cliente en lo que estás describiendo. Sin individuos e interacciones.

  

Para mí, esto parece que las partes interesadas mayores no han comprado Agile y, por lo tanto, estamos condenados a fallar en su implementación en un nivel inferior.

No estás necesariamente condenado, pero si no, es solo una coincidencia. Cuando todo el trabajo aparece porque la administración no puede ver el futuro, se perderá sus fechas (o producirá un código de mala calidad o requerirá más recursos de lo esperado). Eso será entonces tu culpa. La administración probablemente lo presionará para que trabaje más horas para llegar a la fecha, o tal vez arroje a la gente al problema.

Mejor caso , la administración es realmente ágil y es lo suficientemente inteligente como para reducir el alcance. Lo que significa que pasaron todo este tiempo construyendo un gran plan detallado que no vale nada.

Si existe la expectativa de que los conjuntos específicos de funciones se entreguen en fechas específicas, entonces no, esto no es una gestión de proyectos ágil. La gestión ágil de proyectos es de naturaleza empírica. Las proyecciones no se realizan basándose en los deseos de los ejecutivos, sino en el análisis del desempeño anterior.

Su descripción coincide con lo que considero ágil de culto de la carga. La atención se centra en los procesos y ceremonias específicos y no en los conceptos básicos de la gestión de proyectos basada en la evidencia. Podría tener algo de suerte para que los empresarios entiendan si relaciona esto con Lean o TPS . El problema real que necesita resolver aquí es hacer que la administración supere su miedo a lo desconocido. La respuesta correcta para los ejecutivos es "no podemos decirles cuándo se harán las cosas, pero una vez que comencemos a entregar valor, podemos crear proyecciones basadas en nuestra experiencia". Los desarrolladores tienden a decir cosas como "se hace cuando se hace" y "No sé cuándo se hará". Los gerentes no le dirán cosas así a los ejecutivos, los hace sonar como nincompoops. Simplemente están haciendo lo que saben.

Lo más probable es que el plan falle y deba revisarse. El mayor riesgo para el equipo es que habrá un gran impulso para cumplir con los plazos y la calidad se verá afectada. En algún momento no estará en el objetivo (lo más probable es que sea la primera fecha límite) y habrá un impulso para llegar a esa fecha. Se esperarán horas extras y habrá presión para cortar esquinas (omitir la prueba de unidad, revisiones de código, etc.) Esta es una pendiente resbaladiza y una vez que empiece por este camino, es un poco hacia abajo y las cosas se pondrán feas. La productividad empeorará a medida que el proyecto continúe de esta manera.

Si puede hacer que el equipo de desarrollo presente un frente unificado, realmente debería hacer retroceder y mantener la línea en calidad. Mi experiencia es que los gerentes de proyecto tienden a pensar que la salida del software es lineal. Es decir, cada período X producirá Y 'precentage completado'. Es decir, si no estás "50% completado" a la mitad del tiempo permitido, los klaxons comienzan a sonar. En realidad, si lo está haciendo bien, la primera característica tiende a tomar mucho más tiempo que la característica 50 (de tamaño similar). Si puede superar ese período inicial de crisis de peligro ("¿qué está pasando?", "No" ¡No verás que se haga nada! ") probablemente estarás bien.

Bienvenido a negocios reales.

Hay un estilo de negocio más antiguo, que tiendo a llamar burlonamente "desarrollo tradicional" y luego hay un nuevo estilo, "desarrollo ágil". Si trato de tratar estos ideales opuestos, vemos una división directa en el medio: los planes y los requisitos van en la columna tradicional, el descubrimiento y la evolución en la columna ágil. Está limpio, ordenado y equivocado.

En realidad, los negocios son una búsqueda del medio feliz entre los dos. Es fácil demostrar que cualquiera de los extremos en realidad cae de plano. Nosotros, los que amamos a Agile, demostramos con entusiasmo todos los temas del ideal puro del desarrollo tradicional, y hay muchos que pueden mostrar las muchas maneras en que Agile puro se derrumba. Las empresas ágiles exitosas son las que encuentran su equilibrio particular entre las dos. Las empresas tradicionales exitosas son las que encuentran su equilibrio particular entre las dos. No puedes tener uno sin el otro.

Incluso nuestro bendito proceso SCRUM muestra un equilibrio entre los dos. Si bien hay un claro intento de maximizar la agilidad, se hacen algunas concesiones clave. Por ejemplo, el propietario del producto tiene el gran trabajo de defender a todos los clientes. SCRUM intencionalmente no especifica cómo funciona esa interacción. Intencionalmente, explica el hecho de que todos necesitan que se les pague al final del día. Es el trabajo del propietario del producto crear la ilusión de que eso no importa.

(Es interesante tener en cuenta que Pure Agile funciona a la perfección, siempre y cuando no se le pague hasta que produzca un producto y no tenga acceso a la información de propiedad exclusiva hasta que tenga el derecho. Creo que son los únicos ingenieros de software. que se sienten cómodos con este oficio son los empresarios)

Por lo tanto, la administración ha dictado qué características estarán allí y cuándo deben estar allí. Esta bien. Una frase que he escuchado es "el cliente elige el qué y el cuándo, el productor elige el quién y el Cómo". Se ha registrado para el "qué" y el "cuándo". No han dicho nada sobre quién o cómo, más que para ofrecerte la oportunidad de usar "Agile" como tu. Todo lo que queda es ayudar a la gerencia a entender cuántas personas necesitarán contratar para satisfacer sus necesidades.

En un mundo perfecto, tu empresa es ágil desde el exterior. Interactúa con sus clientes de forma ágil, lo que les permite a los desarrolladores desarrollarse ágilmente para ellos. Sin embargo, muy a menudo, la compañía debe interactuar con el exterior mientras se desarrolla con agilidad en el interior. En el medio es siempre un conjunto complejo de compensaciones, únicas para cada compañía.

Personalmente, trato esta situación como un caso de prueba para cualquiera que piense que entiende el desarrollo ágil. En algún momento en el futuro, tendrá que desarrollar un producto para una fecha límite, y ese par producto / fecha límite será relativamente fijo. Si un producto / plazo fijo destruye tu proceso, ¿puedes realmente decir que eras Agile en primer lugar?

Mi consejo: no pienses en esto como una cascada. Todavía controlas el "cómo". Aún puedes hacer todos los rápidos y flexibles prototipos por los que Agile es tan famoso. Simplemente debes ser consciente de que el caucho se encuentra con el camino y debes entregarlo. Este es el mundo real, no el mundo ideal. ¿Habría sido mejor para ellos preguntarte en primer lugar? Por supuesto. Puede que no haya sido tu llamada. Puede haber mil razones relacionadas con el negocio para hacerlo a su manera que simplemente no entiende completamente. Siéntase libre de rechazarlos, pero entienda que pueden tener una muy buena razón para lo que hicieron.

Agile no le impide planificar hitos (por ejemplo, lanzaremos V 1.0 en 3 meses), pero no se puede arreglar lo que implica cada hito.

Creo que la forma en que debería reaccionar depende de la naturaleza del proyecto. Si el proyecto es enviar a un hombre a la luna antes del segundo trimestre de 2017, todos estarán de acuerdo en que está condenado al fracaso. Si cree que puede entregar un MVP al final del segundo trimestre de 2017, debe trabajar en él sprint by sprint.

Si la administración cree que su equipo está haciendo todo lo posible y puede mostrar el progreso en cada carrera, debería poder negociar por más tiempo.

TODOS el proyecto relevante para el negocio tiene restricciones:

• tiempo
• Recursos
• Un conjunto mínimo de características esperado

Esto no es nada más. Desarrollar de forma ágil no significa que "la gente nos paga dinero, por lo que podemos desarrollar lo que queramos para cuando esté listo": siempre tendrá un plazo de tiempo. Siempre habrá alguna fecha con algunos requisitos mínimos y, si no se cumplen, el proyecto se cancelará y se considerará un fracaso. En ocasiones, pueden estar implícitos, por lo que el gerente sabe "Si no tengo una interfaz de usuario que funcione con estas funciones después de 4 semanas, este proyecto está condenado al fracaso", o puede haber accionistas que establezcan un objetivo.

Hay muchos proyectos resultantes de la legislación. - Si el gobierno decide que tiene que implementar la Característica X hasta 2017 para respetar una nueva ley, tendrá una fecha límite no negociable y un conjunto de características que deben estar listas. La única variable es la cantidad de recursos que la administración puede asignar a la tarea. - Y en estos proyectos, donde la fecha límite es una decisión externa, deberán vigilar su progreso, escuchar su pronóstico y asignar personal a los equipos o subcontratar parte del trabajo para cumplir sus objetivos.

Todo esto no se opone al desarrollo ágil. Aún tendrá sus sprints, desarrolle sus funciones en su propio marco de tiempo. Siempre obtendrá sus prioridades de funciones de un cliente, y trabajará para ofrecer todas las funciones que pueda hasta la fecha límite.

Si la fecha límite se cumplirá con los recursos disponibles es un problema de administración. Puede dar su pronóstico y actualizaciones de estado semanales / diarias y ellos pueden decidir si necesitan más recursos. De lo contrario, continuará trabajando en sprints y entregará runnables, igual que cualquier proyecto.

Como alguien ya ha señalado antes del manifiesto dice:

  

Personas e interacciones sobre el proceso

Le sugiero que eche un vistazo al plan presentado y sugiera cambios en él. Recuerde que el Manifiesto dice que el retraso nunca es definitivo, sigue evolucionando.

Para que puedas llevar tus sugerencias al equipo. Si tiene un razonamiento válido y el equipo lo acepta, cualquier propietario de un producto que valga la pena que lo considere lo considerará y se encargará de que el registro quede reflejado en la opinión de todo el equipo.

Este es el punto donde podría ir de dos maneras.

1. El propietario y la empresa del producto están de acuerdo con su razonamiento y pueden aumentar los recursos para cumplir con el plazo si es una opción O pueden optar por eliminar algunas características para cumplir el plazo.

2. Es posible que aún quieran seguir con su propia versión en contra de la opinión colectiva del equipo.

Si el resultado es el # 2, entonces esto no es Agile.

Si terminas con el # 1, diría que el equipo está en el camino correcto, porque Agile no se trata solo de los Devs "Respondiendo al cambio" sino que también la empresa puede responder al cambio.

Imagina que le pides a alguien que pinte una pared, una casa y luego una calle completa para ti, ¿cuánto tiempo le darías a esa persona para hacerlo?

Cualquiera que sea tu respuesta, estarás equivocado. Eso es todo.

No hay forma de que tengan razón acerca de las fechas si no les preguntan a las personas que necesitan hacer el trabajo lo que piensan.

Por cierto, si tú (como equipo) acepta estas fechas, estás equivocado.

Debería pedir algo de tiempo para trabajar en esta planificación junto con las partes interesadas, de modo que pueda establecer prioridades dependiendo de lo fácil y rápido que sea hacer las cosas.

Por ejemplo, tal vez el trabajo final demore el doble de lo que pensaban, pero podrían usar una versión beta mucho antes de lo que esperaban.

En general, no puede dejar que la gente piense que podrá hacer X en tiempo Y si no puede o podría ser más rápido, es su responsabilidad aclarar lo que necesita en términos de detalles y el tiempo.

No es una buena planificación.

Pero si usted piensa que no conoce el plan y simplemente trabaje sprint por sprint. Podría estar en funcionamiento.

Siempre habrá fechas y presupuestos. Siempre existe el riesgo de que se pierdan o superen, y cuando eso suceda, siempre tendrá que recurrir a un plan B.

Si has estado trabajando de forma ágil, entonces el plan B es la última demostración de sprint