¿Se puede hacer que el alcance fijo + la fecha límite fija + el contrato de precio fijo trabajen con “ágil”?

Algunos proyectos que ejecutamos internamente son Scrum, mientras que todavía "arreglamos todo" al cliente. Estamos experimentando un éxito mixto por nuestra parte (al cliente le gusta la visibilidad del gráfico de consumo). ¿Se pueden ejecutar con éxito los tipos de proyectos con los que trabajamos utilizando los métodos ágiles?

Bueno, he trabajado principalmente en entornos "ágiles" (aunque no usamos la jerga), y he hecho cosas de costo fijo. En general, se trata de un costo adicional, ya que ninguna empresa puede permitirse hacer todo de forma gratuita, y los requisitos cambian y evolucionan a medida que el cliente descubre más claramente lo que quiere.

Los requisitos iniciales para la porción de costo fijo deben hacerse con mucho más cuidado que en un entorno iterativo típico, lo que hace que el proceso sea algo menos iterativo. La parte "más" del contrato puede ser más iterativa, siempre que hayamos cumplido la parte del costo fijo de manera más o menos satisfactoria para el cliente.

Me gustaría plantear una contrapregunta:

¿Se puede hacer que el alcance fijo + el plazo fijo + el contrato de precio fijo lleguen a funcionar, punto ?

El dicho "bueno / rápido / barato: elige dos" no es solo una broma tonta de ingeniería. Todo gerente de proyecto que se precie sabe sobre el Triángulo de gestión de proyectos :

Nos está diciendo que el costo, el alcance y el cronograma son fijos. Eso no deja espacio para la maniobrabilidad o el error. Ninguno . Puede optar por ver "Calidad" como un atributo, pero no es un atributo "real", es más como un metaatributo que se deriva de los otros atributos (costo / alcance / programa).

El problema es que esto nunca sucede en la realidad mientras su proyecto sea planeado y ejecutado por humanos.

• Los requisitos y especificaciones nunca cubren todos los casos límite a menos que hayan sido redactados en inmenso detalle por arquitectos y diseñadores calificados, en cuyo caso el proyecto ya está a medio terminar; e incluso entonces todavía existe la posibilidad de error.

• Aparecerán costos inesperados que conducirán a sobrecostos presupuestarios. Una suscripción expiró. Un fabricante suspendió su soporte para un producto que está utilizando y tiene que encontrar uno nuevo. Un contratista por hora aumentó su tarifa bajo amenaza de partida. Todo su equipo se declaró en huelga, exigiendo un aumento del 10% y una semana adicional de vacaciones.

• Horarios de deslizamiento. Surgen problemas imprevisibles; ese componente de gráficos que ha estado usando durante 5 años consecutivos no es compatible con Windows 95, que su cliente todavía está usando. Un error oscuro en Windows de 64 bits causa fallas serias en la interfaz de usuario y pasas casi una semana rastreando y desarrollando una solución (esto realmente me sucedió a mí). Su desarrollador senior fue atropellado por un autobús y usted tiene que ir a reclutar y entrenar a uno nuevo. Su fecha de entrega estimada siempre es incorrecta. Siempre.

  Ver la Ley de Hofstadter :

  Ley de Hofstadter: siempre lleva más tiempo de lo esperado, incluso cuando se tiene en cuenta la Ley de Hofstadter.

Los métodos ágiles consisten en hacer malabarismos con el costo, el cronograma y el alcance. La mayoría de las veces, se trata específicamente de hacer malabarismos con el alcance y, a veces, con el cronograma , por lo que comienza con historias de usuarios nebulosas y revisiones de planes en lugar de versiones completas. Diferentes metodologías usan una terminología diferente, pero es la misma premisa básica: lanzamientos frecuentes y un reequilibrio de la programación y el alcance con cada lanzamiento.

Esto hace que no tiene sentido con un proyecto que es (o reivindicaciones sean) ya sea alcance fijo o horario fijo.

Si se corrigiera un atributo del proyecto (costo / alcance / cronograma), le diría que podría no ser una buena opción para metodologías ágiles.

Si dos atributos del proyecto son fijos, entonces su proyecto definitivamente no es una buena opción para metodologías ágiles.

Si los tres atributos son fijos, entonces su proyecto probablemente fallará. Si realmente se envía, o bien el cronograma original fue fraudulento, o el cliente ha logrado engañarse a sí mismo al pensar que realmente entregó lo prometido.

Si este contrato aún está sobre la mesa, le insto a que lo rechace. Y si ya lo has aceptado, que Dios tenga piedad de tu alma.

Me encanta esta cita:

“Scrum es ideal tanto para fecha variable de alcance fijo como para fecha variable de" alcance fijo "(que siempre crece). Si está haciendo un alcance fijo de fecha fija, le recomiendo cascada o RUP, que le comprará unos meses para buscar un nuevo trabajo. ”~ Michael James

Claro, siempre y cuando su barra de calidad se mantenga notablemente baja. Soy un creyente en el viejo triángulo de hierro de "tiempo de entrega / calidad / precio" donde puedes elegir dos, pero luego el otro flota. Parece que ha fijado el tiempo de entrega y el precio (y también las características), por lo que realmente lo único que puede ofrecer es la calidad.

Dicho esto, si está utilizando un gráfico de quemado y tiene los elementos de mayor prioridad que se están haciendo primero, podría ser aceptable tener un puñado de los elementos más importantes en el marco de tiempo especificado para el monto monetario especificado. Como mínimo, su cliente verá que usted está controlando el proceso de alguna manera, con una entrega al final de cada iteración y tiene la capacidad de decir lo que es más importante.

De lo contrario, creo que comprometerse con un tiempo fijo, un conjunto de características y un precio es una locura y conducirá a esfuerzos heroicos que resultarán en una menor calidad y un código menos mantenible. Ágil no es polvo mágico de hadas.

El precio fijo / fecha límite fija / alcance fijo se puede hacer al menos tan ágil como en cascada.

En cascada, las estimaciones de tiempo son inexactas y los detalles terminan siendo implementados de manera diferente a las especificaciones originales. En otras palabras, la fecha límite / alcance no puede conocerse exactamente de antemano.

En ágil, puede hacer un sprint cero para generar una acumulación de historias de usuarios y hacer algunas estimaciones. Luego acuerde cumplir con las historias de valor por un precio fijo, dentro de un plazo fijo. El alcance se fija en términos de las historias de valor que tiene la intención de cumplir, y no se hacen promesas sobre las historias de los usuarios.

En otras palabras, promete entregar lo que importa y evita hacer promesas sobre decisiones de diseño específicas que no están relacionadas con los ingresos / ahorros / etc. que se supone que debe entregar el proyecto.

Estoy de acuerdo con Bruce hasta cierto punto. Aunque no estoy demasiado familiarizado con la cascada o RUP, y por lo tanto no puedo comentar sobre eso.

Lo que leí recientemente, y pensé que estaba muy bien dicho, fue que incluso en Agile descuidamos la planificación. Una sesión de planificación exhaustiva una vez que una iteración es excelente, no, es esencial, pero también lo es planificar TODA LA iteración.

Trabajo en la industria del entretenimiento, donde las cosas cambian constantemente. El equipo necesita cierto grado de clemencia / flexibilidad que les permita "volver a planificar" las historias a mitad del sprint para alinearse con nuevas metas o metas revisadas.

Me encanta la idea de una planificación continua, ya que con demasiada frecuencia los desarrolladores le dicen al propietario del producto que se vaya cuando están trabajando en historias a mitad de carrera. Esto es excelente si su equipo trabaja en historias que todavía son válidas, y el propietario de su producto es una molestia. Pero en algunos casos, las historias se vuelven redundantes DURANTE el sprint, y es imperativo que el propietario del producto detecte esto, y que el equipo se vuelva a alinear con objetivos / historias cambiadas, ¿no es eso de lo que se trata Agile?