¿Se puede lograr Agile sin la participación del cliente?

No pude escribir un libro sobre Agile. He trabajado en varias tiendas que llaman ágil a su proceso. Uno de los puntos principales del desarrollo ágil es la participación regular del cliente. Después de un sprint, el trabajo se puede mostrar al cliente para obtener sus comentarios. Enjuague y repita.

El problema que encuentro es que muchos clientes no quieren involucrarse tanto. Preferirían mucho un enfoque de cascada. Reúna los requisitos por adelantado, luego regrese cuando haya terminado. En mi experiencia, la cascada no funciona. Los clientes no saben lo que quieren hasta que lo ven. El dilema de la cascada se propaga aún más por una gran comunidad de desarrolladores que desean tener todos los requisitos por adelantado. De esta manera, saben lo que están construyendo, pueden diseñar en consecuencia, y el cliente tiene la culpa porque "firmaron" dichos requisitos.

¿Soy incorrecto? ¿Puede Agile trabajar sin la participación del cliente? Si es así, ¿cómo y cómo superas los problemas que discutí?

Como podria La naturaleza misma de la técnica dicta algún tipo de circuito de retroalimentación entre el cliente y el desarrollador.

Sin embargo, partes de su equipo pueden actuar como clientes "proxy" (un proceso similar a "comer su propia comida para perros") para que pueda "fingir" ser ágil, aunque eso no será tan satisfactorio como conseguir un cliente real realimentación.

Nos guste o no, el cliente estará involucrado en el proceso de diseño; es solo una cuestión de cuánto quieren que cueste el reproceso (cuanto más se retrasa, más caro es).

Dado que el cliente quiere "Big Design Up Front", ayúdelos a comprender que tomará más tiempo y esfuerzo por adelantado para que el diseño sea correcto la primera vez.

La respuesta corta a su pregunta es 'no'. Aquí hay comentarios sobre algunas partes de su pregunta. Para ser exactos, la mayoría de las respuestas se basan en mi experiencia personal y observación.

En mi experiencia, la cascada no funciona.

Waterfall es una metodología sólida para entregar sistemas de complejidad variable. Es lamentable que no esté bien presentado o entendido. Una razón para eso es que no gana suficiente dinero compitiendo con la metodología del día que sigue apareciendo. Es posible que se sorprenda al saber que muchos de los sistemas bancarios, de seguros y de fabricación se construyeron solo con el enfoque Waterfall y que muchos de ellos todavía están en producción en la actualidad. Es triste que la industria del software se base más en la publicidad que en la ciencia.

Los clientes no saben lo que quieren hasta que lo ven.

Esto es un mito Una grande también. Este puede ser el caso en el diseño / diseño de la página web, pero para el procesamiento de datos comerciales, la mayoría de los usuarios quieren algo que funcione. Algunos de esos usuarios todavía usan pantallas AS / 400 y monitores 3270 CICS con RGB y pueden hacer sus negocios con esas herramientas. Además, esos mismos usuarios aceptan los sistemas SAP y ORACLE ERP sin tener voz en el diseño de la interfaz (y algunas veces en la funcionalidad). La mayoría de los usuarios comerciales incluso adaptarán sus hábitos y flujos de trabajo si el sistema está produciendo la función correcta. El estrés aquí está en la función no se ve. Los empresarios entienden cómo hacen su trabajo muy bien el 90% del tiempo.

El dilema de la cascada se propaga aún más por una gran comunidad de desarrolladores que desean tener todos los requisitos por adelantado. De esta manera, saben lo que están construyendo, pueden diseñar en consecuencia, y el cliente tiene la culpa porque "firmaron" dichos requisitos.

No se puede culpar a los desarrolladores por querer saber lo que están construyendo porque esos desarrolladores quieren ir a casa a cocinar la cena y presionar sus camisas para otro ejercicio después de pasar 3 horas más o menos aprendiendo la próxima tecnología. eso reemplazará su conjunto de habilidades actual! El juego de la culpa no hace que nadie sea un ganador. Piense en términos de los roles y responsabilidades de cada parte y la imagen será muy clara.

En conclusión, los gerentes de proyecto, los programadores y los diseñadores web no reemplazan a los analistas de negocios que deben saber cómo recopilar los requisitos de los usuarios finales, independientemente de la metodología.

No quieren dedicarle tiempo y si se les da la opción, preferirían obtener software de forma gratuita, pero aún así les cobrarán, ¿verdad? Esto se vuelve borroso si está desarrollando software internamente para su empresa. Piensan que el departamento de TI ha sido comprado y pagado (empleados asalariados), por lo que podrían obtener tanto trabajo de usted como puedan.

Puedes ser potencialmente ágil. Obtenga todas las especificaciones y comience a codificar. Una vez que el cliente interrumpe el trabajo porque solo pensó en algo y tienes que hacer cambios y reelaboraciones, te vuelves un poco más ágil. También puede hacer las aprobaciones dentro de su equipo. Haga que un miembro de su equipo se ponga un traje y corbata y pretenda ser el cliente.

Hacer un gran compromiso por adelantado puede asustarlos. Sugiere hacer un sprint para probarlo. Luego deles la oportunidad de optar por no participar. Siempre puede cambiar a una cascada para el resto del proyecto. Sugiera también que diferentes personas de su equipo puedan hacer la revisión y aprobar si el tiempo es una limitación para la persona que escribe el cheque.

En algún momento, debes decirles que no crees que la cascada vaya a funcionar. Pregúnteles si estaban satisfechos con este enfoque y, de ser así, ¿por qué no tienen al último tipo para hacer este proyecto?

Ninguna metodología puede funcionar sin la participación del cliente. Tener la aprobación de los requisitos puede no tener sentido, ya que fui testigo de los proyectos en los que participé. Su problema va más allá de poder hacer Agile, necesita educar a su cliente y asegurarse de que entiendan lo importante que es para ellos participar.

Creo que uno de los principales beneficios de Agile es la capacidad de obtener requisitos más detallados para cada característica en general. Cuando el cliente da todos sus requisitos por adelantado, cada característica tiende a ser una idea vaga, con un poco de funcionalidad definida. Agile obliga al cliente a volver a visitar cada característica y centrarse exactamente en lo que quiere y cómo la característica se ajustará a la imagen más grande. Para obtener esta misma cantidad de detalles (detalles suficientes para implementar las características) en la especificación, la cascada realmente requiere que haga una de dos cosas:

1. Adivinar. Implemente hasta que se encuentre con algo vago, luego juzgue cómo cree que la característica se implementaría mejor. Obviamente, esto no es lo ideal, ya que lleva a "¡Espera, eso no es lo que pedí!" guión.

2. Ponga mucho más énfasis en el diseño por adelantado. Esencialmente, cuando el cliente le arroje sus especificaciones a medio hornear el primer día, planee revisar cada detalle antes de implementar cualquier cosa. Pídale al cliente que aclare todo hasta la náusea hasta el punto de conocer todos los detalles de implementación para todo el proyecto. Si bien no es perfecto, es mejor que la opción 1. Es posible que aún se encuentre con detalles que no había anticipado, e incluso podría enviar al cliente corriendo por las colinas, pero si realmente no quieren estar en comunicación durante el desarrollo y usted no son psíquicos, esto es una necesidad. Esto es básicamente una cascada, y viene con todas las desventajas asociadas, incluyendo ser extremadamente difícil de ejecutar correctamente.

3. Tome la especificación a medio hornear, pero solicite una aclaración a medida que avanza de todos modos. Trabaje hasta llegar a una parte vaga de la especificación, luego pídale al cliente que lo aclare. Por supuesto, esto no es lo que solicitó el cliente, pero si no quieren una aplicación tan turbia como la especificación y se niegan a definir la especificación por adelantado, esta es la única opción restante. No tiene todos los beneficios de Agile (como la aprobación regular del cliente para asegurarse de que todos estén en la misma página), sin embargo, le permite obtener la información que necesita para desarrollar. Dado que la opción 1 probablemente lo dejará con un producto de baja calidad, la opción 2 es un despilfarro y frustrante para el cliente (probablemente necesitará dedicar al menos el doble de tiempo al diseño y la recopilación de especificaciones en general si lo hace por adelantado), Esto realmente no es una mala opción. La clave aquí es ser diligente en modificar las líneas de tiempo y el precio con cada cambio que surja. Si lo hace bien, es posible que la mayoría de las prácticas ágiles sean compatibles con este acuerdo, incluso si el cliente no lo sabe. En mi humilde opinión, esto está realmente de acuerdo con el espíritu de Agile, ya que se supone que debes adaptar las metodologías a tu disposición particular.

Si el cliente realmente no puede vivir con las consecuencias de cualquiera de estas tres opciones o Agile completo, me resulta difícil imaginar cómo este cliente realmente podría valer la pena.

Creo que es difícil pero aún posible. Creo que la idea de proxy de Robert funciona, pero es necesario que el proxy pase el mayor tiempo posible con el cliente 'real' para que puedan ver las cosas desde su punto de vista. De esa forma, el proxy puede determinar qué características son realmente importantes y tener una idea de la experiencia del usuario que el cliente espera / desea.

Pero en algún momento necesitará mostrar el software al cliente 'real' ...

Es posible evitar clientes reales, de hecho a veces es necesario para la regulación. Por lo general, los clientes de software médico no están involucrados. En esos casos, otras entidades pueden sustituir el rol del cliente, por ejemplo, el equipo de marketing puede considerarse los clientes.

Agile requiere un bucle cerrado para reemplazar el gran diseño inicial que es difícil: bastante difícil, pero en realidad se puede hacer, ágil no es la única forma.

Es posible que desee encontrar una de las modificaciones de Agile: hay muchas y una probablemente aborde este problema específico, pero si no, haga las suyas si cree que puede hacerlo.

Todos estos procesos fueron creados por personas inteligentes, y las personas inteligentes pueden hacer que cualquier proceso funcione. No crees que la cascada fue inventada porque nunca funcionó para nadie, ¿verdad? Evolucionó porque algunas personas podían hacer que funcionara, y otras miraron y dijeron "Tengo que refinar eso y alimentarlo a MI equipo que parece que no puede producir de manera tan efectiva", en ese momento probablemente funcionó mejor de lo que ellos pensaban. estaban haciendo, pero si no reconoce que no todos los programadores pueden resolver todos los problemas, realmente puede confundirle por qué dos equipos que usan el mismo proceso pueden tener resultados diferentes.

El problema es que muchos procesos requieren talento para implementarlos; estamos hablando de talento tan raro como los jugadores deportivos profesionales de un grupo de todos los que han practicado algún deporte, es probable que la mayoría de nosotros nunca hayamos conocido a alguien capaz de hacer los procesos de mierda como el trabajo en cascada y es por eso que muchas personas piensan que no puede tener éxito, nunca lo han visto funcionar.

Se necesita mucho menos talento para hacer que Agile funcione, sin embargo, requiere algunas inversiones muy específicas, como hacer que el cliente vea lo que está haciendo constantemente para que los errores no puedan propagarse y cosas como la refactorización despiadada para que no se acumule una deuda técnica que el equipo no puede desentrañar unos meses más adelante.

Definir al cliente.

¿Es otra compañía? Otro individuo?

¿Es otro equipo dentro de su empresa?

¿Es un campeón de productos dentro de su empresa?

¿Eres tú?

Todo lo anterior es posible y bastante razonable según las circunstancias. No desea tener una sola vista en el túnel sobre lo que es ser ágil, por lo que decir un NO definitivo sería incorrecto. SÍ por otro lado requiere un poco de pensamiento lateral.

Piensa en la palabra ágil por un momento. El grupo muy inteligente de personas que acuñaron el término no podría haber escogido una mejor metáfora del concepto que intentaban describir. Cuando dices agilidad , ¿qué te viene a la mente? Siendo flota de pie? ¿Rápido para reaccionar tal vez? ¿Rápido para adaptarse?

Ahora piense en todas las prácticas ágiles comúnmente aceptadas y pregúntese qué aportan realmente a los métodos de desarrollo de software que se consideran ágiles .

Soy el cliente a todos los efectos para mis proyectos en solitario. Incluso llevo un sombrero real a veces, cuando realmente quiero hacer un cambio mental distintivo en mi rol de cliente . Esto me hace no menos ágil de lo que soy cuando estoy en el trabajo. Por lo que me importa, mi gato puede ser el gerente. Se asegura de que tome un descanso de vez en cuando y me recuerda que evite obsesionarme demasiado con ninguna tarea. ¡Puede que prefiera usar su elegante "Técnica Pomadoro", pero prefiero el temporizador "Rascal"! La cuestión es que trabajo en un proceso estrictamente ágil cada vez que escribo código para mí. No soy del tipo hacker-come-cowboy, que vive una vida de picos de desarrollo interminables y sin lograr nada. Me gusta crear mi software, programar el desarrollo en torno a mi vida laboral y personal, y completarlo de una manera que esperaría si estuviera trabajando para un cliente real. Cuando las cosas interrumpen mi horario, ajusto y priorizo ​​el trabajo de mi proyecto en consecuencia. Uso todas las prácticas y técnicas ágiles estándar que puedo aplicar solo, y "entrego" código de trabajo para mí (o un amigo o colega para probar) tan a menudo como pueda. Si todo esto no es ágil, te pregunto qué es.

Entonces, mi respuesta es Sí , puedes ser un desarrollador de software ágil, y puedes aplicar una metodología ágil, y no necesariamente necesitas al cliente, o incluso al gerente. Puedes trabajar en un proyecto solo y usar varios sombreros. Sin embargo, puede no ser necesariamente ideal eliminar esos otros roles, ya que es muy útil cooperar con otros para lograr un objetivo. Actúan como una caja de resonancia para sus ideas, y satisfacen los requisitos que de otro modo podría ser difícil generar de manera sensata por su cuenta. La otra función muy importante que el cliente y el gerente satisfacen es la de mantenerlo enfocado en sus objetivos, sin agregar características sin fin y refinar su código más allá de lo estrictamente necesario.

Aún así, si trabaja de manera disciplinada, siguiendo estrictamente su metodología de elección y aplica prácticas ágiles, y si se desvía o cambia de opinión (cuando usa el sombrero del cliente) y el diseño o la dirección de su producto toma un turno, si puede adaptar su horario y ajustar sus prioridades tal como imagina que su cliente esperaría que lo haga, entonces está siendo ágil.