Practicar ágil en entornos impulsados ​​​​por fechas límite

La única opción que tiene es usar la transparencia y el aspecto de "trabajar en las características importantes - alcance" de Agile. La fecha límite está establecida, por lo que lo único que puede hacer es averiguar qué se necesita realmente y cuál es el mínimo para el lanzamiento (las ventas lo dirán todo, pero rara vez es el caso).

La transparencia generará confianza en el equipo y le indicará a la organización lo que es realista lograr en el marco de tiempo dado. Además, esto puede ser útil más adelante cuando negocie nuevos negocios.

Trabajar en el alcance es esencial en cada proyecto, especialmente en los ágiles (no hay nada más que hacer realmente, porque el tiempo y los recursos son fijos, la única parte móvil debe ser el alcance). En sus sprints, intente comprender más sobre el caso comercial y descubra qué puede ofrecer su equipo para que el cliente alcance sus objetivos.

Siempre hay plazos (la agilidad no se trata de trabajar sin ellos), y su objetivo debe ser averiguar cómo ofrecer valor real cuando sea necesario. Ese es un buen desafío ágil.

Agile funciona bien en un entorno impulsado por plazos siempre que haya flexibilidad en el alcance.

Con Agile normalmente trabajamos con una acumulación priorizada de requisitos. Esto asegura que, a medida que trabajemos para cumplir con una fecha límite, se trabajará primero en las funciones más importantes. Cuanto más nos acerquemos al acuerdo, menos importante será la característica en la que trabajaremos. Es posible que no completemos todo el trabajo deseado antes de la fecha límite, pero podemos estar seguros de que el trabajo que no completemos tendrá menor prioridad que el trabajo que entregamos.

También ayuda si hacemos lanzamientos regulares a medida que avanza el proyecto. Esto ayuda a las partes interesadas (como el personal de ventas y los clientes) a ver un progreso concreto. De esa manera se pueden gestionar las expectativas.

En cuanto a su segundo punto, Scrum utiliza un enfoque llamado 'planificación de lanzamiento'. En su situación, haría esto poniendo requisitos en su cartera de pedidos que cubran la funcionalidad que espera que se necesite para el lanzamiento (o cualquier hito en el que esté trabajando). Esto puede parecer al principio como el enfoque no ágil de tener una especificación inicial. Pero con Agile tratamos el backlog como una lista dinámica, que se actualiza con frecuencia. Esta es una de las razones por las que en Scrum tendemos a trabajar con historias de usuarios que a menudo consisten en una simple oración. Solo agregamos el detalle a las historias cuando nos acercamos al momento en que trabajaremos en ellas.

Por lo tanto, en lugar de tener una especificación inicial rígida y detallada, tenemos una lista de requisitos mucho menos detallada y dinámica.

Puede ofrecer al cliente la hoja de ruta del proyecto que solicita, utilizando el backlog y la velocidad del equipo para mostrar los puntos potenciales en los que se completará la funcionalidad. Lo importante es que debes explicarle a tu cliente que esta hoja de ruta no será inamovible. Se revisará continuamente a medida que progrese, teniendo en cuenta los comentarios que proporcionen y cualquier cambio solicitado. Piense en ello como una hoja de ruta muy dinámica que se mejora continuamente.

Puede parecer que al cliente no le gustará este enfoque, ya que incluye cierta incertidumbre. Pero puede encontrar que si se lo explica cuidadosamente a sus clientes, ellos comprenderán los beneficios de este enfoque, como la flexibilidad para permitirles realizar cambios y ver un progreso concreto en forma de versiones provisionales.

Problema 1:

Como solución al problema 1, debe involucrar al cliente en el proceso . Como parte de scrum, cada sprint tiene una revisión de sprint que consta de dos partes: una en la que le muestra al cliente el resultado de lo que se ha hecho y otra en la que el equipo revisa el sprint para ver qué salió bien y qué debe mejorarse. (también conocido como la retrospectiva).

El departamento de ventas debe dejar muy claro al cliente que la fecha límite es una estimación y que el cliente formará parte del proceso, brindándole demostraciones incrementales del trabajo que se está realizando para que pueda dar su opinión a lo largo del proceso. Si tiene un cliente que no quiere ser parte del proceso, resolver el problema 1 se vuelve casi imposible.

Además, mientras el departamento de ventas siga haciendo promesas que es muy improbable que se cumplan, la imagen de la empresa se verá afectada. Se les debe hacer darse cuenta de que es mejor tener una fecha límite posterior y, a veces, terminar el trabajo antes que prometer una fecha límite más temprana y tener que ganar más tiempo con excusas o limitar el alcance del proyecto para poder hacer el plazo.

Idealmente, el equipo debe ayudar a establecer la fecha límite: primero, el equipo de ventas obtiene los requisitos del cliente, luego el equipo convierte esos requisitos en historias y tareas y hace una estimación aproximada de cuánto tiempo llevará completarlos y finalmente, usted y/o el equipo de ventas agregan algunos sprints de tiempo a esa estimación para determinar la fecha límite para el cliente. Si el equipo no está formado en su totalidad por personas que acaban de salir de la escuela, su experiencia (ya sea en el equipo actual o en otro equipo) debería ayudarlos a hacer esta estimación muy aproximada y, si el equipo permanece unido, seguirán mejorando. .

Problema 2:

Como puede deducir de mi solución al problema 1, no estoy del todo de acuerdo. El inicio del proceso en ágil es determinar cuáles son las necesidades del cliente y definirlas a un alto nivel. Tan pronto como se haga esto, se debe trabajar con el cliente para dividir los fragmentos de alto nivel en partes más concretas y se debe determinar la prioridad de esas partes concretas.

Con base en esta información, el equipo puede hacer una estimación más concreta del trabajo que se requerirá para satisfacer las historias y, en esa estimación, puede basar una hoja de ruta: descubra las interdependencias, combínelas con las prioridades acordadas con el cliente. y ahora puedes definir una hoja de ruta general. Esta hoja de ruta no sobrevivirá a la realidad, pero debería ser una buena indicación.

Tenga en cuenta que, a veces, el cliente insistirá en que todo tiene la misma prioridad, lo necesitan todo antes de la fecha límite. Esto nunca es cierto: seguramente en una aplicación de hoja de cálculo, la capacidad de la aplicación para realizar cálculos es más importante que la capacidad del usuario de tener un selector de color para hacer que las celdas de la tabla cambien de ese color.

En general, ¡recuerde el triángulo de gestión de proyectos !

Si el proyecto es de precio fijo, el plazo es fijo y el alcance es fijo, lo único que puede variar es la calidad. Si el cliente quiere un producto de alta calidad, necesitatener flexibilidad en al menos un punto: costo, cronograma o alcance. Este triángulo ha demostrado su eficacia una y otra vez, pretender que no es cierto para su empresa es una ilusión. Ayude a su equipo de ventas a comprender esto, trabajen juntos para establecer un proceso que funcione para la empresa y sea aceptable para los clientes. Inevitablemente, perderá algunos clientes potenciales por esto, pero tenga en cuenta que, para empezar, lo más probable es que hubiera sido imposible satisfacerlos. En lugar de arriesgar el buen nombre de la empresa (y los recursos potenciales necesarios para completar el producto antes de la fecha límite a toda costa...) es preferible trabajar con clientes que puedan entender la realidad del desarrollo de software.

Viniendo del lado de los desarrolladores, sé que los vendedores que prometen el cielo y la tierra son un problema grave, especialmente cuando prometen funciones y dispositivos diminutos, que tienen poco valor real, pero alteran profundamente la arquitectura y las premisas del sistema.

Las velocidades de sprint de los equipos toman algún tiempo (muchos meses) para determinarse, e incluso entonces, son solo promedios. Si realiza estimaciones de tiempo a la antigua con un número optimista, promedio y pesimista (por ejemplo, 2, 3, 7 días), el pesimista suele ser aproximadamente el doble del tiempo y más que el promedio, pero debe tomarlo si desea hacer un compromiso que tiene casi la posibilidad de un tiro en la cabeza de la ruleta rusa para perder la fecha límite.

Parece que sus clientes están en una posición de poder para empujar a su empresa a compromisos muy arriesgados o imposibles, o su empresa es demasiado codiciosa en términos de crecimiento, prometiendo deliberadamente más de lo que puede manejar. En el primer caso, es muy arriesgado, porque los clientes pueden terminar sin pagar el precio o incluso exigir sanciones. Si los vendedores no pueden negociar plazos razonables y condiciones suficientemente flexibles, la empresa está condenada. El último puede funcionar por un tiempo, pero es peligroso, porque la reputación se daña, y el desarrollo puede verse obligado a crear una deuda técnica en forma de código realmente malo y apresurado, que es imposible de mantener, muy difícil de mejorar y pura apuesta sobre si funciona correctamente.

No puedes hacer brujería a los desarrolladores, o hacerlos más rápidos con un látigo, sus habilidades son limitadas. Tal vez, la agilidad le permita escalar a una aplicación de consola con comandos y parámetros de escritura, en lugar de una interfaz gráfica de usuario elegante en la fecha límite (y tal vez hacer el resto más tarde), pero si es realmente imposible, los empleados terminarán pasando la pelota a unos a otros para el inevitable desastre.

Hagas lo que hagas, ¡nunca, realmente nunca intentes simplemente rebajar las estimaciones o instar a los desarrolladores a hacer compromisos imposibles! Sus estimaciones son requisitos serios, y los instaría a mentir sobre ellos. Esto, además, destruiría toda la previsibilidad ganada a través del proceso Scrum. Recuerde, los desarrolladores son para el diseño y la programación de software, no para los políticos y para resistir la presión, por lo que es posible que cedan a la presión y acepten una estimación más baja, ¡sabiendo que nunca podrán cumplir con tal compromiso! ¡Todos saben que el trabajo real requerido no puede ser vencido con presión!

Tienes el mismo problema que obtienes con cualquier metodología. ¡Vas a correr el riesgo de perder ese plazo!

Tener una especificación de cliente por adelantado es realmente una ventaja porque define sus criterios para el éxito.

Aglie aconseja no planificar por adelantado porque daña los cambios para lograr el valor comercial. En su caso, no tiene que hacer eso, solo lograr lo solicitado.

1: Asegúrese de cumplir con su fecha límite siendo *implacable* con el producto mínimo posible que coincida con las especificaciones. Si no se especifica el color, es lo que haya puesto el desarrollador ese día. Si no especificaron los tiempos de respuesta, no genere un error para las páginas lentas. Realmente tienes que ser brutal incluso si crees que es una mierda. no agregar/cambiar funciones

2: Trate de terminar al menos el 75% del tiempo permitido del proyecto. Si no vas por buen camino, empieza a preocuparte.

3: al 50% deberías tener ese producto mínimo hecho. ¡Uf! contractualmente usted está seguro. Demuéstrele al cliente que le queda el 25% del tiempo para responder a los "errores" y ajustes, haciéndolo agradable y feliz al cliente, puliendo, etc.

4: al 75 %, bloquee y comience su puesta en marcha/implementación lo que sea. Esto siempre expone nuevos errores. Le queda un 25% de margen de maniobra si no ha tenido ningún problema, nuevas características, enfermedades inesperadas, etc. para solucionarlos. En la práctica, le pedirá al cliente otras 2 semanas y los detalles de redacción de ftp/firewall/política que le prometieron el mes pasado.

Nunca he estado en un proyecto ágil sin una fecha límite. Tal vez solo he tenido mala suerte, sin embargo, para obtener el presupuesto en el primer caso, necesita el caso comercial que tiene una fecha límite...

Desde mi experiencia trabajando con Agile, los plazos tienen que ver con la gestión del alcance, la velocidad del equipo y las expectativas de las partes interesadas. He estado utilizando pronósticos y seguimiento de Agile Monte Carlo con buenos resultados. Primero en una hoja de Excel bastante compleja y luego creando la solución a continuación. ¡Pruébalo y déjame saber lo que piensas!

https://agilemontecarlo.com/