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


23

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í?


12
No dejes que "ágil" se convierta en tu martillo para que todo lo demás parezca un clavo que necesita ser golpeado.
Patrick Hughes

1
En mi experiencia, la preferencia hacia los enfoques en cascada generalmente se debe a una falta de comprensión de cómo funciona el software o el diseño. La buena noticia es que Agile no es el gran problema, es la actitud / comprensión del cliente. La mala noticia es la actitud del cliente.
Ben Brocka

@BenBrocka: Eso no es terriblemente sorprendente, teniendo en cuenta que para eso se diseñó Waterfall específicamente. El autor quería escribir un artículo sobre cómo podría ser un proceso de desarrollo creado por alguien que no entiende el desarrollo de software y por qué tal proceso no puede funcionar. Entonces, él inventó específicamente Waterfall como ejemplo, un proceso diseñado por alguien que no entiende el desarrollo de software y que posiblemente no puede funcionar. Obviamente, no es sorprendente que atraiga a las personas que no entienden el desarrollo de software ni es una sorpresa ...
Jörg W Mittag

@BenBrocka: ... que no funciona. Lo sorprendente es por qué alguien querría usar un proceso que esté específicamente diseñado para no funcionar. Supongo que nadie se molesta en leer el periódico.
Jörg W Mittag

1
@ JörgWMittag La adopción real de Waterfall (ya sea que se den cuenta de que es una cascada o no) se debe principalmente a que es un modelo estándar de decisiones comerciales; jefe quiere algo, subordinado lo hace, el cliente está contento, ¿verdad? Por supuesto que no funciona, pero es un modelo simple y agradable para mentes simples y bonitas :)
Ben Brocka

Respuestas:


17

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.


55
Sin embargo, partes de su equipo pueden actuar como clientes "proxy" ; en mi experiencia, los evaluadores hicieron "representantes" bastante efectivos del tipo que usted menciona. Cuando yo mismo era un probador, a veces también fingía usar un traje de cliente, por así decirlo. Tal proxy tiene limitaciones aunque - por ejemplo, control de calidad chico se quejan de la cantidad de tiempo que se necesita para instalar el producto sólo podría sentirse de esa manera porque lo hacen todos los días mientras que el cliente lo hace una vez al año o dos
mosquito

it's just a matter of how much they want the rework to cost (the longer it is delayed, the more expensive it is).¿Pero para quién es realmente más caro? La mayoría de los clientes no lo ven como el pago de su tiempo para obtener su visión actual de una solución. A veces simplemente tienen un problema y no tienen forma de saber cuál debería ser la solución hasta que les diga cuál será. En ese punto, si lo que les dijiste en realidad no resuelve su problema, entonces es TU ERROR, no el suyo. ¿Cómo es su culpa que hayas malinterpretado sus problemas reales en primer lugar? cont ...
maple_shaft

cont ... ¿por qué deberían pagarlo? Solo para salvar la cara del cliente y no perder por completo cualquier posibilidad de repetir negocios, entonces tiene que darse la vuelta y hacer el trabajo de forma gratuita porque, en primer lugar, exigieron el contrato de precio fijo. Esta es la actitud más frecuente y exactamente lo que P.Brian.Mackey está experimentando. Los clientes arman estas negociaciones y cuando eres solo una de las 100 nuevas empresas que intentan anotar el contrato, el tipo con el contrato realista y justo basado en Agile tendrá que esperar al final de la línea. Es DURO ahí afuera en este momento.
maple_shaft

@maple_shaft: Claramente te has quemado por esto. Pero, como con todas las cosas, todo se reduce a elecciones. Agile existe porque la cascada tiene sus problemas y las personas no son perfectas. Si el cliente ha sido informado de los riesgos y quiere una cascada de todos modos, esa es su elección. También es la elección de la tienda de software decidir si vale la pena arriesgarse o no a un cliente que no comprende los riesgos o niega la validez de esos riesgos.
Robert Harvey

@RobertHarvey Incluso un mal cliente en una mala economía sigue siendo un cliente y todavía mantienen las luces encendidas durante unos meses más. Los riesgos para el cliente en el caso que mencioné son mínimos y contienen si recibieron la solución prometida a tiempo. El riesgo para la tienda de software en este caso es si este cliente con problemas en la parte posterior nos va a chupar.
maple_shaft

7

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.


3
+1 - Por competir "los clientes no saben". Se trata de diferentes dominios que tienen diferentes tipos de clientes. Es por eso que los agilistas no pueden entender a las personas de las cascadas. Creen que solo puedes decir lo que quieras cuando lo ves. No es cierto, pero eso es todo lo que ven de sus clientes. Si bien los defensores de las cascadas no pueden entender por qué no se puede entender la abrumadora mayoría de los requisitos por adelantado para que el diseño pueda tener en cuenta todos los problemas. Probablemente se deba a que la gente de las cascadas no trata mucho con los clientes.
Dunk

1
@ Dunk, gracias por tu comentario. Me gusta su redacción "" clientes de todos modos!
NoPuerto

2

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?


2

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.


2
¿No se trata de la cantidad y frecuencia de participación del cliente y no de todo o nada?
JeffO

3
En mi opinión, un cliente que se niega a participar es un cliente que necesita educación. No es inusual que los expertos comerciales del cliente se pongan en una posición en la que tengan que interactuar con la compañía de desarrollo de software y aún realizar sus actividades cotidianas y eso debe abordarse hablando con sus superiores.
Otávio Décio

2

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.


Omitió la opción 4. Toma la especificación con la abrumadora mayoría de los requisitos. Realice el diseño (probablemente iterativo) con las opiniones de los clientes. Implemente y pruebe el código (probablemente iterativo). Realice revisiones periódicas del programa informando al cliente sobre el progreso y las decisiones. Dan comentarios, incorporas sus comentarios y sigues adelante.
Dunk

Las situaciones que describe arriba solo ocurrirían con equipos que no saben cómo hacer una cascada. Sí, es difícil de ejecutar correctamente. Ágil también es difícil de ejecutar correctamente. Cada vez que alguien falla en ágil, algún agilista rechaza una nueva regla que no se siguió y afirma que esa es la razón del fracaso. Nunca es culpa de Agile. Al menos los defensores de las cascadas admiten que se necesitan buenas personas con buenas habilidades para que la cascada funcione.
Dunk

Su opción 4 es exactamente lo que pretendía describir en la opción 3.
Morgan Herlocker

¿Cómo podría mejorar mi respuesta? No puedo decir si estás de acuerdo o en desacuerdo con lo que estoy diciendo.
Morgan Herlocker

Puede mejorarlo quitando la palabra a medias para empezar. Eliminar la parte sobre esto no es lo que el cliente quería. Elimine la parte de especificaciones turbias, etc. En cascada, la parte importante de capturar los requisitos es obtener los significativos arquitectónicos y los que el sistema debe hacer absolutamente para ser útil desde el principio. Después de eso, los cambios generalmente no son tan importantes. Lo creas o no, hay y siempre ha habido iteraciones, ya sean formales o informales en el desarrollo de la cascada. Mucho antes de que llegara Agile.
Dunk

1

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' ...


0

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.


0

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.


0

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. 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 , 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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.