Una discusión anterior de Agile aquí tuvo buenas respuestas especificando lo que es crítico para el éxito de implementar la metodología Agile en el desarrollo de software. La mayoría de los puntos eran los desafíos típicos de organización y gestión, pero un punto me preocupa y es que el cliente debe participar en todo el proceso.
El cliente es lo único que no puede controlar de manera realista, tal vez su modelo de negocio lo orienta al trabajo contratado por el gobierno, por ejemplo, donde un contrato estrictamente estricto obliga a la compañía a:
Proporcione las características de X exactamente según lo solicitado
Las solicitudes de funciones se lanzarán sobre una pared, no nos moleste, no queremos escucharlas.
No existe un concepto de prioridad de función en la mente del cliente, todos son importantes o no los hubiéramos pedido.
El proyecto no costará ni más ni menos que Y, independientemente de los excesos o plazos.
Plazo absoluto, estricto, final y no negociable para la entrega completa de todo el trabajo.
Nunca antes habíamos trabajado con un cliente así, pero el dinero del proyecto es demasiado bueno para dejarlo pasar. Necesitamos este trabajo.
Vine aquí y trabajé DURO para cambiar los procesos internos para avanzar hacia el desarrollo ágil y aquí no sé cómo conciliar dónde encaja este proyecto en nuestro nuevo proceso. Nunca antes había tenido el lujo de una administración abierta de mente abierta que confiaba en mí para liderar el equipo de desarrollo y los procesos en este camino y ahora que estamos aquí no puedo decirme honestamente que este proyecto realmente se realizará en un Manera ágil. Siento que la gerencia confió en mí para liderar este camino y que los decepcioné porque esta situación en la que nos encontramos ahora claramente exige Cascada. Me temo que podría perder su confianza si retrocedo ahora.
Otras respuestas como la de aquí dicen que Agile es imposible con este tipo de cliente, ¿está de acuerdo? ¿Alguno de ustedes ha estado en una situación similar y lo hizo funcionar? ¿Qué estrategias implementó para que Agile suceda con éxito?
fuente
Respuestas:
Creo que lo primero que debe darse cuenta es que hay una diferencia entre ser ágil y ser ágil. Desplegando lentamente técnicas y características ágiles: los equipos interfuncionales, la planificación adaptativa, la entrega evolutiva / incremental, las iteraciones cronometradas e incluso la introducción de conceptos de Lean son muy diferentes a la introducción de la Programación extrema, Scrum o Crystal.
Usted menciona explícitamente la participación del cliente. Sí, muchas de las metodologías ágiles requieren la participación del cliente, pero no es necesario que sea ágil. En cada programa relacionado con el gobierno / defensa, siempre he tenido un gerente de programa o proyecto que era el punto de contacto con el cliente. Esta persona se convierte en la "voz del cliente". Puede que se ralentice a medida que teleconferencia o correo electrónico o llamar y aclarar, pero puede tener una sola persona (o un grupo, si tiene PMs adjuntos también) que es el representante del cliente de su equipo. Es cierto que no es lo mismo. ¿Pero no es ser ágil para ser flexible y responder al cambio?
También menciona algunos conceptos clave: requisitos predefinidos, solicitudes de funciones "descartadas", falta de priorización porque "todas son importantes" y proyectos de costo fijo y / o de horario fijo. Cada uno de estos puede abordarse de diferentes maneras.
Si cree que tiene todos sus requisitos por adelantado, es probable que no los tenga. Los requisitos cambian. El hecho de que tenga una especificación "terminada y firmada" no significa que esté establecida en piedra. Dado el documento de requisitos que tenga, capture cómo se siente cómodo y / o de la manera especificada por el contrato y entregue los requisitos, el diseño y la arquitectura. Además, vea si puede tratar estos documentos vivos (un documento de diseño que vi hoy en el trabajo está etiquetado como Revisión G, lo que significa que está en su octava actualización). Pregunte cuánto puede dejar como TBD en una iteración dada y cuánto necesita confirmarse ahora; puede haber algo de toma y daca.
Sé ágil con tu documentación. No duplique los esfuerzos entre "lo que quiere su equipo" y "lo que quiere el cliente". Por ejemplo, si su cliente desea una especificación de requisitos de software tradicional y su equipo quiere usar historias de usuario, intente adaptarse a un SRS tradicional y use elementos de acción y una lista de elementos de acción continua en lugar de historias de usuario para que no pierda tiempo formulando "el sistema debe ..." y "debe poder hacerlo porque". Sin embargo, esto requiere disciplina por parte del equipo para adaptarse a las diferencias entre los proyectos. Captura problemas en reflexiones.
Una vez que llegue al desarrollo, puede ejecutar 5 o 6 iteraciones y luego invitar a su cliente a su instalación para ver un subconjunto de su implementación. Enjuague y repita este proceso. No es la participación constante exigida por algunas metodologías, pero sí tiene la ventaja de una alta visibilidad. Si su cliente dice que no, al menos lo intentó. Si dicen que sí, puedes iluminarlos para que sean ágiles. En un proyecto en el que estaba, el cliente visitaba el sitio cada pocos meses (generalmente de 3 a 5 meses). Nos verían pasar por las pruebas de control de calidad, debatirían inquietudes con los ingenieros y los negocios con la oficina del programa / proyecto. Fue una oportunidad para todos para estar en la misma página.
Las pruebas y el mantenimiento suceden igual que en otros proyectos ágiles. Cree sus procedimientos de prueba y documente los defectos de la manera adecuada, realice un seguimiento de las métricas según las obligaciones contractuales y documente los resultados de las pruebas. Si desea seguir TDD, hágalo. La integración continua es otra buena idea. Durante las reuniones de estado del proyecto, su gerente de proyecto puede usar esta información para decir "implementamos los requisitos de N, tenemos M pruebas, pasamos X pruebas" y actualizamos la salud y el estado del proyecto a las personas con el dinero.
Hablando de dinero, tenemos el problema de costo fijo y / o horario fijo.
Tratar con un horario fijo es bastante sencillo. Dados sus requisitos, sabe cuántas iteraciones puede completar. Su carga de trabajo para cada iteración está prácticamente establecida en términos de características para implementar, probar e integrar. Puede ser difícil, pero no es imposible dividir características y asignarlas a iteraciones por adelantado. Esto se remonta a mi punto de invitar al cliente: si tiene un año y está utilizando iteraciones de 2 semanas, quizás invite al cliente trimestralmente (e invítelo cada trimestre) y muéstreles los resultados del trabajo anterior. Permítales ver su priorización de requisitos, sus planes futuros y cómo va a programar.
Tratar con un presupuesto fijo es similar. Usted sabe cuánto tiempo tiene, cuántos recursos tiene para el proyecto, cuánto cuestan y, por lo tanto, cuántas horas pueden trabajar todos por iteración. Es solo una cuestión de asegurar que todos hagan un seguimiento de esto cuidadosamente. Si su empresa puede comer el costo de las horas extra, hágalo. De lo contrario, asegúrese de que todos trabajen el tiempo adecuado y use buenas habilidades de gestión del tiempo y boxeo de tiempo para mantener a todos productivos. Lo que necesita para mantener bajos los costos es horas más productivas: entregue más documentos y software que agreguen valor sin el costo de las reuniones y los gastos generales.
En última instancia, no se trata necesariamente de ser ágil, sino de aplicar las cosas que hacen que Agile sea bueno y ágil. Ser capaz de responder a los cambios en los requisitos, ser capaz de entregar software frecuente incluso si el cliente no lo desea, solo producir documentación de valor agregado (junto con lo que esté obligado por contrato a producir), y así sucesivamente.
fuente
Sí, ágil no es apropiado para tal proyecto, porque parece que los requisitos ya están hechos y fijados en piedra, probablemente el resultado de años de análisis por consultores caros, reuniones de comités y compromisos políticos. Waterfall funciona bien si el cliente es tan disciplinado que puede decirle por escrito exactamente lo que quiere. Pueden estar equivocados, pero al menos lo tiene por escrito, y se le pagará si entrega eso. (Por supuesto, esto no dice nada de la satisfacción del cliente. Lo más probable es que entregue algo que realmente no necesita).
Agile fue creado para resolver un problema que no tiene: riesgo debido a la incertidumbre en los requisitos.
Es cierto que el cliente puede solicitar solicitudes de cambio, pero usted sigue uno de estos dos caminos:
La relación se siente mucho más amigable en la situación n. ° 1, pero el hecho es que es bastante raro encontrar departamentos de compras que no le exijan el precio, por lo que la mayoría de las veces está en la situación n. ° 2. Eso significa que la relación es de confrontación, pero si quieres sobrevivir en los negocios, debes ser bueno en la gestión de la relación mientras te mantienes firme. Esta es una gran parte del trabajo del gerente del proyecto.
Parece que podrías estar en la situación # 1, lo cual es bueno. Me imagino que los contratos del gobierno son el único lugar donde no les importa el dinero, porque, después de todo, no están gastando su dinero, están gastando su dinero.
fuente
Primero. Es estricto Pero no es inflexible. Simplemente requiere atención al detalle y una larga, larga serie de órdenes de cambio.
Las agencias gubernamentales en realidad son ágiles de manera lenta e ineficiente. Debe escribir (y negociar) órdenes de cambio formales y detalladas todo el tiempo.
Hasta que sea modificado por una orden de cambio.
El canal de comunicación es el orden de cambio. Impacto del presupuesto y el cronograma.
Esto es difícil de solucionar. Incluso las empresas no gubernamentales que gastan una gran cantidad de dinero para el "análisis de requisitos" no quieren que se les diga que una pila grande, plana y humeante de requisitos sin gravámenes por prioridad e información de compensación es incompleta. Pagaron un buen dinero para obtener todos los requisitos. ¿Cómo puedes querer más información?
Este es un problema dificil.
Excepto por las órdenes de cambio. Que modifican Y y la Fecha límite.
"no negociable" generalmente no es cierto. Es negociable Es doloroso negociar.
La parte importante de la negociación con las agencias gubernamentales es el hecho de que necesita "evidencia a nivel de abogado" para sus costos y cambios de horario. Algunas presentaciones técnicas cuidadosas con una buena diapositiva de powerpoint no son "evidencia". Necesita mucha documentación para presentar su caso.
La gente del gobierno debe proporcionar pruebas irrefutables de que han hecho todo lo posible para que esto sea lo más barato y efectivo posible. Saben que cada decisión se reproduce en la prensa pública y se analiza a posteriori.
La complejidad del desarrollo de software, y el aspecto posterior al hecho del "quarterback del lunes por la mañana" del trabajo del gobierno los hace reacios a hacer cambios al contrato sin evidencia abrumadora.
Hace que un enfoque ágil sea difícil.
"Individuos e interacciones sobre procesos y herramientas" es difícil. No está trabajando con un individuo, sino con un representante del gobierno cuyo trabajo está limitado por el proceso.
fuente
En un proyecto como este, han vinculado sus manos con el alcance, los recursos y el tiempo. Lo único que le queda por gestionar es la calidad. Asi que...
No obtendrá la mayor parte del beneficio de un enfoque ágil que de otro modo podría obtener, pero puede hacer todo lo posible para mitigar los riesgos de calidad y poder informar al cliente de los problemas más temprano que tarde.
Así que sé tan ágil como puedas:
Si comienza a correr contra la fecha límite, podrá mostrar lo que se ha hecho, y tal vez en ese momento el cliente, sabiendo que no va a obtener todo, priorizará lo suficiente como para decirle lo que quiere. También debe hacer las cosas más riesgosas, lo que significa que las tareas en el tiempo límite son las más fáciles de trabajar en horas adicionales.
fuente
Creo que este tipo de cliente no es la norma. Estás tratando con un grupo que ha solicitado proyectos similares antes, por lo que saben exactamente lo que quieren. Nunca mencionas que sus especificaciones cambiarán.
Tengo suerte si proporciono la función X vagamente como se sugiere y estoy listo para cambiarla en cualquier momento.
Si sabes lo que quieren, ve a construirlo.
No puedes perder en este. Construirlos como mejor le parezca.
Esa es una pregunta difícil si nunca has construido un proyecto para el gobierno. Si tiene algo de historial, puede determinar si puede entregarlo. Esto no significa que no paguen bien (son conocidos por pagar $ 50 por un martillo de $ 10) o que tengan expectativas irrazonables. Con estas especificaciones, alguien en su equipo debe actuar como cliente y aprobar el trabajo en comparación con las especificaciones. Incluso si encuentra una falla y les ruega que cambien los requisitos, probablemente no lo harían.
fuente
Lamentablemente, lo que ha descrito es la típica vista del cliente sobre cómo debe abordarse un proyecto de software. Esto no quiere decir que el cliente no sea razonable; después de todo, ¿no es así como se ejecutaría la construcción de cualquier otra cosa (una casa, por ejemplo)? Dicho esto, no estoy ofreciendo nada más de lo que todos sabemos. Lo que estás preguntando es ... ¿es factible la aplicación de prácticas ágiles en esta situación?
Tengo el beneficio de haber terminado un proyecto que es similar en muchos aspectos a la situación que usted describe, es decir,
... y, por supuesto, el equipo de desarrollo con visión de futuro está tratando de trabajar de manera ágil, a pesar de lo anterior:
¿Algo de esto es remotamente significativo para los negocios? No. Dos meses antes de la fecha límite, las iteraciones hasta entonces cuidadosamente observadas y las reuniones de planificación se abandonan en un frenesí de gallinas sin cabeza.
Las respuestas que otros han proporcionado anteriormente son compromisos en mayor o menor grado. En mi opinión, ágil (ya sea "ágil" o "ágil") se "hace en" de una manera perniciosa cuando nos comprometemos. En mi opinión:
No hay compromiso, o no hay ágil.
El mismo espíritu de agilidad se trata de ir al grano, eliminar el desperdicio, ser brutalmente honesto consigo mismo. Es un hecho ahora bien documentado e innegable que la estimación de software en grandes proyectos es, en el mejor de los casos, una apuesta. ¿No es nuestro deber como profesionales del software educar a los posibles clientes de esto? Si los clientes no están dispuestos a aceptar que somos los expertos, ¿no es nuestro deber profesional alejarnos?
fuente
Cuando comencé a trabajar donde estoy ahora, me encontré haciendo la misma pregunta que usted hizo bastante. Hay algo que decir sobre la cascada con la contratación del gobierno. Irónicamente, ágil se ha convertido en una palabra de moda entre los clientes del gobierno (que trabajan de manera realista en cascada), por lo que ahora nos queda esforzarnos aún más para implementar un proceso ágil con un cliente básicamente inflexible.
Tenemos un sistema que se ha descrito como "Scrummerfall", "Agilefall" o "A mess", pero en muchos aspectos hemos podido adoptar lentamente un proceso cada vez más ágil a medida que este proyecto (gigantesco) ha avanzado a lo largo de los años. . Una de las formas en que lo hicimos es básicamente encontrar canales de comunicación con los USUARIOS de nuestro sistema, en lugar de con nuestros CLIENTES. Nuestros clientes son un departamento pesado encabezado por funcionarios designados que nunca tocarán nuestro software en su vida laboral y no quieren entenderlo. Nuestros usuarios son personal regular del gobierno en el campo que intenta realizar una tarea importante. Para nosotros, la clave para establecer un circuito de retroalimentación de comunicación que nos permitió ser tan ágiles como nosotros fue la necesidad de UAT (Pruebas de aceptación del usuario).
En un punto temprano de nuestro proyecto, se decidió que un grupo representativo de USUARIOS ACTUALES de varias oficinas de nuestro vasto cliente gubernamental se reuniría en el lugar AQUÍ y tendríamos un par de semanas de cara a cara con ellos mientras corren a través de una serie de probar scripts para probar nuestro software. Como algo informal, el equipo de requisitos convirtió esta vez en una forma invaluable de obtener comentarios de los usuarios finales reales. Mientras tanto, el equipo de prueba de UAT dentro del gobierno trabajó a través de su burocracia para tener más y más influencia sobre el proceso de requisitos formales en su extremo, incluidas las órdenes de cambio. El resultado final es que los BA como yo actúan como propietarios de productos independientes integrados en equipos scrum y son capaces de obtener un valioso tiempo cara a cara con clientes reales que nos permiten funcionar de una manera muy ágil.
Obviamente, hay muchos problemas, y todavía no estamos realmente ágiles, pero somos lo suficientemente ágiles como para haber sido presentados como un ejemplo de un proyecto ágil importante que realmente usa esa metodología en el sector de contratación del gobierno.
En resumen: use su experiencia como un evangelista ágil dentro de su propia organización para infiltrarse en su cliente. Realice un proceso de aprendizaje con ellos, establezca una asociación basada en la confianza con las personas clave de su lado y trabaje ALREDEDOR del Proceso de requisitos formal y osificado que inevitablemente tienen implementado. ¡Te agradecerán los chicos en el terreno que realmente tienen que usar lo que estás desarrollando!
fuente
Asume que los requisitos están bien escritos y cree que significan lo que piensan que significan. La ida y vuelta del proceso ágil ayudará a garantizar que obtengan lo que querían decir además de lo que pidieron.
fuente