Historias
Slashboxes
Comentarios
 

¿Por qué los usuarios odian las metodologías ágiles?

Entrada escrita por monster y editada por nettizen el Jueves, 06 Junio de 2013, 22:00h   Printer-friendly   Email story
desde el dept. reflexiones-ágiles-para-bitácoras-estáticas
Vía Slashdot, leo un artículo sobre ¿por qué los usuarios odian las metodologías ágiles?. En resumen, lo que para los desarrolladores es flexibilidad y capacidad de adaptación, los clientes lo ven como caos, falta de organización y carencia de proceso. ¿Casos de implicación excesiva de los usuarios en el proceso interno de desarrollo, tal vez? ¿Ágil llevado al extremo?

Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • No hay balas de plata

    (Puntos:2, Interesante)
    por pobrecito hablador el Miércoles, 05 Junio de 2013, 13:31h (#1339932)
    No es que los usuarios odien las metodologias agiles, es que las metodologias agiles se han convertido en una especie de comodin que supuestamente vale para todo, y no es asi.

    Hay proyectos que no conviene llevarlos con metodologias agiles; hay usuarios que no conviene meterles en metodologias agiles; y hay desarrolladores que no conviene meterles en metodologias agiles.

    Es muy facil llenarlo todo de buzzwords y confundir al personal, y resulta que luego, como dicen en slashdot, "agil" no es mas que un eufemismo para no hacer tal o cual tarea porque te resulta tediosa o complicada. Y asi, obviamente, no se llega a ninguna parte.

    [ Responder ]
  • No me lo creo

    (Puntos:1, Interesante)
    por pobrecito hablador el Miércoles, 05 Junio de 2013, 16:16h (#1339951)
    Los usuarios adoran las metodologías ágiles, cambios y mas cambios mientras se desarrolla, nuevas funcionalidades a tutiplen, exigencia de entregar partes y pedir modificaciones en cuanto lo reciben.

    Al menos eso es lo que se vende como metodología agil, si luego resulta que no es así, es lógico que el usuario se sienta estafado
    [ Responder ]
  • Mi opinión

    (Puntos:4, Interesante)
    por monster (49083) el Miércoles, 05 Junio de 2013, 17:20h (#1339970)
    ( Última bitácora: Miércoles, 05 Junio de 2013, 10:43h )
    Mi opinión: Lo que el cliente quiere fundamentalmente es una solución a un problema. Tal vez no sepa describir completamente el problema, o la solución que se le ocurre no es la mejor para él, pero lo que sí sabe es que tiene un problema que justifica pagar para poder solucionarlo.

    Desde ese punto de vista, al cliente le preocupa poco la metodología que se vaya a usar, lo que le preocupa es saber cuándo va a tener una solución y cuánto le va a costar. Por eso lo importante en el trato desarrollador-cliente es que la comunicación sea clara y dé confianza por un lado de que el proceso avanza y por el otro que no se están quedando cosas importantes en el tintero, pero ese aspecto muchas veces no es el que más se cuida cuando se aplica metodología ágil y con ello volvemos a lo del "No hay balas de plata" de comentáis más arriba.
    [ Responder ]
  • Mis dos centimos

    (Puntos:5, Informativo)
    por sammael (16347) el Jueves, 06 Junio de 2013, 09:17h (#1340037)
    ( http://barrapunto.com/ | Última bitácora: Miércoles, 27 Febrero de 2013, 11:25h )
    Antes de nada, yo estoy a favor de las metodologias agiles en general, pero es muy dificil implementarlas bien y casi imposible a menos que todos los involucrados esten de acuerdo en que es lo que significa y dispuestos a hacer un esfuerzo extra (sobre todo al principio con el tiempo se hace mas sencillo).

    Tambien, cuando depende de mi, suelo poner mas enfasis en lo de "agil" que en lo de "metodologia". Un cafe en la cantina charlando distendidamente del estado del proyecto durante 10 minutos es mucho mas valioso (siempre IMHO) que un stand-up de 2 minutos que se convierte en algo forzado y a desgana.

    En general, los clientes con los que he trabajado con metodologias agiles les ha gustado porque han conseguido lo que a ellos les interesaba: Mas informacion del estado de las funcionalidades que pedian y la posibilidad de dar feedback muchisimo antes que en los procesos tradicionales. Pero eso siempre ha sido despues de hacerles entender que eso supone un trabajo extra para ellos (tienen que estar ahi y tienen que participar) y que es posible que haya cosas que a ellos no les parezcan tan importantes/urgentes pero que tendran prioridad.

    Generalmente, la mayor parte de las empresas en las que he estado usan las metodologias agiles solo como buzzword (he visto a gerentes defendiendo que el modelo en cascada tradicional es agil), como excusa para recortar en tareas que les parecen no esenciales (documentacion, sobre todo) o lo implementan como norma sin tener en cuenta la opinion de los subordinados y perdiendo una de las mayores ventajas de estas metodologias: La flexibilidad poder adaptarlas al proyecto especifico y a la gente que lo va a llevar a cabo.

    Personalmente, no uso ninguna metodologia agil especifica, sino que cojo lo que me apetece de varias; me encanta el concepto de "velocidad" del equipo y el poder estimar las tareas en dias perfectos (te quita muchisimo trabajo y estimaciones creativas), me gusta la idea de tener una pizarra donde aparezcan todas las tareas y en que estado estan (kanban), no creo que todas las tareas tengan que ser "historias" ni que se tengan que adaptar a un ciclo de releases predeterminado... En general me funciona.
    --

    Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
    [ Responder ]
  • Intangibles

    (Puntos:3, Inspirado)
    por almarag (7381) el Jueves, 06 Junio de 2013, 21:41h (#1340114)
    ( http://almarag.wordpress.com/ | Última bitácora: Domingo, 04 Noviembre de 2012, 17:19h )
    El problema no es la metodología, es el cómo se pide que se implemente. Ágil no es para todos, necesitas que el cliente esté dispuesto a cooperar en el proceso. Un cliente que no quiere involucrarse y sólo mandar fabricar un software no debe usar ágil. Se habla de la desconfianza del cliente en el artículo, en este caso tampoco debe usarse ya que es imprescindible porque el cliente DEBE interactuar en el proyecto e implica ser parte del equipo y tomar responsabilidad en el proceso, y saber que si falla, es porque fallaron todos incluyéndole, cosa que es muy complicada de pedir para alguien que pone los billetes.

    Ágil también requiere que el cliente entienda, al menos a un nivel elemental, ciertos tópicos del desarrollo de software. Un cliente que no tiene ni idea de cómo se hace un software tendrá más problemas para involucrarse en un proyecto ágil que un cliente con algunos elementos básicos, y tendrá menos posiblidades de éxito.

    Para la parte de la predictibilidad, hay muchas herrmientas como la integración contínua, la revisión por pares, el test-drive development, que pueden adaptarse al trabajo y mejorar esos aspectos donde se vuelve oscuro el desarrollo, que es las pruebas y la detección temprana de errores. También ágil requiere gente autogestionada, con personas que no son disciplinadas difícilmente tendrás buenas prácticas, y lo he visto infinidad de veces.

    En resumen, ni ágil es el demonio ni es imposible implementar procesos ordenados y predecibles con ágil, siempre depende de cómo lo implementes y por ello los usuarios tienen esa impresión de desorden, porque se implementa en situaciones y personas que no son las adecuadas para el proceso.
    --
    -- Si yo no soy yo, entonces tú no eres quien dices
    [ Responder ]
  • por ataulfo (21584) el Viernes, 07 Junio de 2013, 06:11h (#1340126)
    ( Última bitácora: Sábado, 19 Diciembre de 2009, 16:06h )
    El problema es que (como con todos los buzzwords de turno) se busca poder poner la pegatina de "ágil", SCRUM y esas cosas en el proyecto para ganar clientes/inversores. Pero luego no se tiene el más mínimo interés en cambiar la mentalidad ("te hemos puesto un Kanban de esos, deberías ser capaz que la aplicación geoescale en el cloud y metareplique el BigData para esta tarde. Por que ya nos hemos comprometido con el cliente") y claro, cuando las cosas fallan, pues son culpa de la metodología (o del equipo de desarrollo) nunca del gerente que no entiende cual es su trabajo...
    Lectura recomendada: We Tried Baseball and It Didn't Work [xprogramming.com]
    --
    "Cuando el copyright impide el progreso de la ciencia, la ciencia debe desechar el copyright" - Richard M. Stallman
    [ Responder ]
  • Ágil funciona

    (Puntos:1)
    por MaQy (39221) el Viernes, 07 Junio de 2013, 10:17h (#1340144)
    No entiendo mucho el pesimismo que veo en algunos comentarios, o las críticas a los que van de usar metodologías ágiles y luego no es así. A ver, Scrum mal hecho sale mal, claro, pero es que te pasa lo mismo si usas Cascada o cualquier otra metodología que se te ocurra. Algo mal hecho va a salir mal siempre. Pero para mí las ventajas de la metodologías ágiles son obvias. Y lo digo por propia experiencia, no por repetir frases comerciales. Por mucho que un cliente te pida una fecha de finalización de un proyecto cerrada, es imposible que se la des, con metodología ninguna. Más aún sabiendo que siempre están pidiendo cambios de requerimientos. Así que dando una fecha y un presupuesto fijos vas a fallar seguro. ¿Que exige un cambio de mentalidad por parte del cliente? Seguro. Y el proyecto está abocado al fracaso si todos los miembros del equipo (e incluyo al cliente en el equipo) no creen que la metodología ágil es lo que deben hacer. Pero un proyecto en el que el cliente se desentiende de él hasta la entrega final tampoco va a funcionar.
    [ Responder ]
  • por pobrecito hablador el Viernes, 07 Junio de 2013, 17:04h (#1340188)
    Las criticas del articulo son el malentendido de siempre. Para empezar no existe eso de "metodología ágil", ágil no es una metodología concreta, es un conjunto de principios y valores. Como con cualquier cosa que tiene cierto éxito y esta "de moda" hay muchos que dicen "ser ágiles" cuando en realidad lo único que hacen es coger una de las metodologías agiles (SCRUM habitualmente que es más facilito) y seguir sus rituales sin entender sus principios. Como decía james shore hacen cargo cult agile: http://www.jamesshore.com/Blog/Cargo-Cult-Agile.ht ml [jamesshore.com].
    • Ser ágil es pensar que las personas son más importantes que los procesos/metodologías (articulo más que recomendable de alistair cockburn sobre el tema: http://alistair.cockburn.us/Characterizing+people+ as+non-linear,+first-order+components+in+software+ development),vamos [cockburn.us] que la primera idea de ser ágil es precisamente no ser un taliban de ningún metodo.
    • Ser ágil es pensar que el progreso de un proyecto se mide en función del software funcionando entregado al cliente.
    • Ser ágil es pensar que es más importante adaptarse al cambio que seguir un plan trazado inicialmente como si este fuera la verdad divina.
    • Ser ágil es pensar que la relación con el cliente debe ser cercana de confianza y este debe estar mucho más involucrado en el proceso de lo habitual.
    • Ser ágil es ser autoexigente con tu trabajo y trabajar con la maxima calidad (por ejemplo a raiz de esto surge el manifiesto de software craftmanship, para complementar el ideario agil)
    Luego en las practicas concretas podemos usar Scrum, XP, kanban, crystal o FDD y implementar practicas como IC, TDD, pair programing, propiedad colectiva del código etc,etc si pensamos que esas cosas nos ayudan a cumplir con los principios anteriores.

    Parece que mucha gente piensa que ser ágil "es facil" que son metodologías que consisten en poner cuatro post-it en una pizarra, pues nada más lejos, ser ágil requiere un cambio de mentalidad y dominar tecnicas que no son precisamente sencillas y exigen una enorme disciplina (mucha más disciplina que escribir uemeles por ejemplo, que total como no se ejecutan no pasa nada si están mal). Dominar TDD, usar integración continua, automatizar pruebas de regresión end-to-end, hacer deploys continuo y eliminar la barrera entre desarrollo y sistemas (infraestructure as code, devops etc,etc) no son precisamente "cosas sencillas". Por supuesto estás técnicas se pueden usar fuera de un equipo ágil, pero todas tienen su origen en estas ideas y es la comunidad ágil (la de verdad, no los cuatro vende-motos) la que las lleva impulsando años.

    Luego sobre el articulo concretamente, por supuesto que siendo ágil se puede tener un presupuesto, si mides tu velocidad, por supuesto que siendo ágil puedes hacer arquitectura, lo que ocurre es que en lugar de hacerla sólo al principio la haces SIEMPRE, todos los días haces arquitectura. (una critica habitual al agilismo es que "no hay diseño" cuando la realidad es que al contrario, siempre se esta diseñando y programando y haciendo arquitectura diferentes puntos de vista de la misma actividad que se desarrollan de forma continua).

    Al final es lo de siempre, la gente busca culpables en las "metdologias" (o donde haga falta) para tapar su propia incompetencia.
    [ Responder ]
  • Pérdida de tiempo

    (Puntos:2)
    por pleyades (544) el Sábado, 08 Junio de 2013, 10:53h (#1340215)
    ( http://barrapunto.com | Última bitácora: Lunes, 14 Enero de 2013, 12:43h )

    Al implicarle demasiado al cliente, le obligas a acudir a demasiadas reuniones (a él o a personal de la empresa). Prefieren un ritmo de trabajo en que le dicen lo que quiere al principio y los desarrolladores se lo hacen sin molestarle.

    Para él todas estas reuniones para ver como va etc supone una pérdida de tiempo que podría emplear en otras cosas.

    [ Responder ]
  • por monster (49083) el Lunes, 10 Junio de 2013, 09:11h (#1340283)
    ( Última bitácora: Miércoles, 05 Junio de 2013, 10:43h )

    Por señalar la diferencia más evidente, en software no existe fase de construcción o el costo de esta es casi inexistente (ejecutar un build), en software todo es diseño y esto provoca que desaparezcan tanto las fases como los roles anteriores.
    No estoy de acuerdo. La fase equivalente a la construcción es la integración de componentes y subsistemas y su coste no es ni mucho menos despreciable, ni en tiempo ni en medios. Si quieres, la comparación es "construcción = poner ladrillos en su sitio con la argamasa" con "construcción = poner componentes en su sitio y conectar las interfaces".
  • Re:Disiento

    (Puntos:1, Interesante)
    por pobrecito hablador el Lunes, 10 Junio de 2013, 10:01h (#1340286)

    Y no sólo me refiero a comunicación a traves de la palabra, dentro de un equipo de desarrollo de software hay otros elementos fundamentales para la comunicación, el principal el código fuente, si tu código fuente no comunica bien sus intenciones, no se entiende claramente, puede ser estupendo y funcionar de puta madre, pero es más un peso con el que tienen que cargar el resto que un activo de tu proyecto.
    Bueno, yo estoy lo dejo al margen. Se puede ser poco comunicativo verbalmente, se puede ser incapaz de coordinar trabajo con otros, pero escribir codigo de buena calidad e inteligible, que es lo que yo considero buen programador.

    Si yo te doy unas especificaciones y tu me devuelves un trozo de codigo eficiente, claro y sin errores, eres un buen programador.

    La relación es clara, el desarrollo de software es una actividad donde la COMUNICACION es una actividad esencial, a no ser por supuesto que estes desarrollando el soft que tu quieres y tu solo, entonces puedes hacer lo que te la gana. Si tienes unos clientes tienes que comunicarte con ellos, si tienes un equipo tienes que comunicarte con ellos, por tanto tener buenas habilidades de comunicación no seras nunca un buen desarrollador.
    Pues sigo sin verla. Un programador normalmente no tiene por que comunicarse con el cliente, eso puede ser responsabilidad de otros, como por ejemplo analistas y arquitectos. Un programador tampoco tiene por que comunicarse con todo el equipo necesariamente de forma proactiva, eso puede ser responsabilidad perfectamente de quien organice el trabajo, sea el project manager, el team leader u otro.

    Y aun y con todo, una cosa es comunicarse, y otra trabajar en equipo. Se puede crear buena documentacion y bases de conocimiento, y aun con todo, rendir la mitad cuando tienes que trabajar en equipo. Sigo pensando que eficiencia no es algo directamente relacionado con talento.

    Ahora, si eres autonomo y desempenyas y todos esos roles, pues si, necesitas tener buenas habilidades comunicativas, nos ha jodido, y buenas habilidades de comercial tambien.

    • Re:Disiento de pobrecito hablador (Puntos:1) Lunes, 10 Junio de 2013, 15:48h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • 3 respuestas por debajo de tu umbral de lectura actual.