Metodologías ágiles ¿Aplican siempre?

[[AzidRain]]

En los últimos años se pusieron de moda las metodologías ágiles para desarrollar software. De ahí surgieron varias propuestas, siendo las más exitosas o al menos las que más acogida han tenido extreme y scrum. Al igual como pasa con cualquier nuevo lenguaje hubo un boom de "ingenieros" que a la voz de "es lo de hoy" a diestra y siniestra empezaron a aplicarlas para toda clase de proyectos aunque no siempre el proyecto se prestara para ello.

Es interesante ver que una de las características de este tipo de metodologías es la de sacar las cosas rápido y dejar documentación para después. Es muy adecuado para pequeños desarrollos innovadores que requieren un tiempo mínimo para salir a producción. Pero a mi juicio no lo es para desarrollos importantes tipo sistemas CRM o ERP, misión crítica, automatización, etc. en donde las cosas pueden tornarse enormes y con un alto grado de complejidad en cuanto a interdependencia y demás. Mi especialidad es el software administrativo y operativo para empresas. El objetivo siempre es partir de un proceso o procesos, identificar todo lo necesario respecto al mismo, modelarlo, hacer la arquitectura del mismo y ya con ella en mano entonces sí partir hacia el desarrollo. En el software empresarial casi siempre es imposible que todos los módulos del sistema trabajen de forma independiente pues esa es la forma en que trabajan todas las empresas: a base de interrelaciones y operaciones cruzadas entre los diversos departamentos de manera que lo que pasa en un proceso A puede afectar lo que pasa en un proceso B y a su vez puede requerir que se efectúe un proceso C.

Bajo este planteamiento, considero que las metodologías ágiles, en mi caso particlar, scrum, se enfocan más a ver pequeños pedazos de un todo aplicando el famoso "divide y venceras" y deja de lado la importancia de las interrelaciones. En un sprint es posible que no pueda incluirse solo una o dos partes de ese todo ya que dependen para funcionar como se debe de el resto de ellas, por lo que forzosamente hay que desarrollarlas todas para poder obtener algo utilizable. Si vemos el software como un auto, es como querer armar solo la transmision y el chasis y dejar para el siguiente sprint las ruedas y el motor. Y aún así si se arma el chasis, motor y dirección en un primer sprint, al cliente no le aporta ningún valor todavía.

Además de lo que comento, siento que está diseñado pensando en equipos más o menos grandes de desarrolladores enfocados en un mismo proyecto. La filosofía de que "tiene que salir en el tiempo que tiene que salir" también me parece errónea pues implica que todo mundo trabaje jornadas extenuantes cuando se aproximan las fechas de entrega. Además si no se cuenta con un buen scrum master no se va a ningún lado, pues el desarrollador termina usando mejor google que el consejo de él y entonces todo se viene para abajo. Por otro lado requiere de un compromiso de parte del cliente para contar con un representante que trabaje junto al equipo todo el tiempo, lo cual es casi imposible en la mayoría de las empresas. Al menos en la mentalidad latinoamericana.

No se si esté yo equivocado pero creo que estas metodologías van más por el lado de "hagamos una app que nos haga 3 o 4 cosas" que por el de hagamos todo un sistema completo que controle todas las operaciones habidas y por haber de una empresa (por ejemplo SAP pero a menor escala). También me parece una muy buena estrategia para implementar mejoras e innovaciones sobre algo ya diseñado y probado. Es decir, si ya tienes un sistema mas o menos completo trabajando y solo te faltan algunas piezas, entonces sí que se puede aplicar este esquema.

Pero bueno, yo solo opino. No se si alguien tenga alguna experiencia por ahí sobre este tipo de metodologías en proyectos similares.

[[Delphius]]

Yo no tengo experiencia en abordar un proyecto bajo esa metodología pero si la he estudiado.
Al día de hoy no me convence demasiado y es que para que pueda funcionar necesita que todo trabaje perfecto porque con que una pieza de todo el engranaje falle se cae todo.
No tiene un esquema de trabajo demasiado tolerante a fallos bruscos ni de condiciones de cambios inesperados. Es más rígido, una vez trazado el plan se busca mantenerlo. No es como otros paradigmas que tienen medios para absorver cambios de último momento y planes de riesgos a lo largo del ciclo de vida.

Desde el vamos, el ya, o de entrada o el término que más se escuche en sus lares, requiere de un equipo altamente preparado y en el que todos se conozcan muy bien, hayan trabajado un buen tiempo juntos. Todos deben tener experiencia previa en Scrum.
Si no hay equipo capacitado, de nada sirve seguir.

El esquema de dejar la documentación para después, y el de definir las pruebas desde un comienzo son unas buenas máximas. Tienen sentido y es para que las cosas se encaminen bien desde el inicio. Funciona esta forma. Yo utilizo parte de estas máximas, que dicho sea de paso es compartida con el paradigma UP/USDP, y el tener un plan de pruebas desde el comienzo ayuda a que los fallos del software se reduzcan... Pero... para esto se debe ser bien ordenado. Para tener el plan de pruebas, previamente se debe tener una idea más o menos elaborada.

Por estas cosas es que no veo que las metodologías ágiles sean para todos los equipos, ni también para todos los proyectos.
El modelo incremental al menos me parece más realista y que tiene más capacidad de asimilarse. Puede ir desde un equipo unitario a una buena cantidad de personas. Y el que explícitamente incorpore hitos de control y estudios de riesgos hace que la planificación pueda ajustarse mejor antes fechas límites.

Pero bueno, son modas... seguramente luego vendrá una nueva metodología o un nuevo paradigma o modelo (por favor no confundir una metodología con los modelos o paradigma de proceso) y habrá un "consultor" enamorado de toda la vida convencido de que es el arma para atacar a cualquier proyecto. Aparecerán cursos, conferencias, casos de estudio y/o de éxito, escribirán libros y la van a llenar de laureles... hasta que empiecen a surgir los peros y nuevamente vendrá el grito de los desarrolladores de que el nuevo esquema de trabajo no les sirve y el ciclo continúa.

El mejor modelo de trabajo es aquel que elabora uno propio. Es lo más habitual... La Ingeniería de Software nos llenó de literatura para que al final las empresas e independientes terminen haciendo mix de varios modelos y/o metodologías y terminan formando su propio esquema de trabajo.

Asi que mejor ni te preocupes si no te sumas tanto a la moda.

Saludos,

[[AgustinOrtu]]

Comparto tu visión respecto a scrum.

Sin embargo, creo que en el caso de programación extrema, no queda otra alternativa que ser practicante; basicamente la corriente te lleva a eso.

No, no lo digo en plan de "ahora esta de moda y esto es lo que debemos hacer", lo digo mas bien porque los usuarios se han vuelto mas exigentes; hay que entender que el mundo de ellos "cambia bastante seguido", y en algunas ocasiones no es culpa de ellos.

El único punto de discrepancia que tengo contigo tiene que ver con la documentación

Yo considero que la mejor forma de documentar el código, es, auto-documentando el código . Es decir, escribiendo código que no haga falta documentar: codigo breve, conciso, extensible. Más de una vez he dicho en el foro que es importantisimo minimizar dependencias y el acoplamiento; estamos de acuerdo en que es imposible independizar los procesos de la empresa. Pero si es posible minimizar dependencias entre objetos; si es posible reducir el acoplamiento entre clases

Ahora bien, si el caso es que se esta implementando una API, una biblioteca de programación, una suite de componentes, en ese caso si, la documentación es crucial

[[Delphius]]

Empezado por AgustinOrtu

Comparto tu visión respecto a scrum.

Sin embargo, creo que en el caso de programación extrema, no queda otra alternativa que ser practicante; basicamente la corriente te lleva a eso.

No, no lo digo en plan de "ahora esta de moda y esto es lo que debemos hacer", lo digo mas bien porque los usuarios se han vuelto mas exigentes; hay que entender que el mundo de ellos "cambia bastante seguido", y en algunas ocasiones no es culpa de ellos.

El único punto de discrepancia que tengo contigo tiene que ver con la documentación

Yo considero que la mejor forma de documentar el código, es, auto-documentando el código . Es decir, escribiendo código que no haga falta documentar: codigo breve, conciso, extensible. Más de una vez he dicho en el foro que es importantisimo minimizar dependencias y el acoplamiento; estamos de acuerdo en que es imposible independizar los procesos de la empresa. Pero si es posible minimizar dependencias entre objetos; si es posible reducir el acoplamiento entre clases

Ahora bien, si el caso es que se esta implementando una API, una biblioteca de programación, una suite de componentes, en ese caso si, la documentación es crucial

Yo también defiendo la documentación. Es más di largos sermones en el foro de porqué debe hacerse. Y creo que hago lo mismo que vos: auto-documentar en la medida que avanzo y consigo código que considero lo suficiente estable como para que no sufra 50 cambios en un buen tiempo.
El punto es que en XP y en general en las metodologías ágiles esto va en un 2do plano. Documentar es aburrido, se dicen los scrummers. Y lo dejan para después. La idea es escribir código basado en planes de prueba superables cuanto antes. Se documenta después... si queda tiempo.

A mi ver ese eso puede ser peligroso y contra producente.

Pero si que hay principios y máximas de la XP que si valen la pena adoptar. Sin necesariamente aplicarlo en alguna metodología ágil. Ya he dicho que por ejemplo UP adopta algunos de esas máximas: planes de pruebas para reducir los fallos hacia adelante es quizá el más evidente.

Comparto que las cosas nos están empujando hacia esas máximas, la corrientes nos lleva a adoptar rutinas y actividades estructurales que soporten algunas de las máximas de la XP. Pero no necesariamente a que todo se haga por la metodología ágil. Hay que tener presente que justamente al ser metodología, ésta no propone sino que te condiciona a que sigas sus pasos al pie de la letra.

Lo que diferencia una metodología de los modelos es que las primeras te ponen el COMO y QUE y CUANDO hacer. Los modelos como lo son Espiral, Prototipado, Evolutivo e Incremental (UP/USDP y variantes) y hasta el Cascada o Secuencial no te condicionan el COMO, simplemente te dan un marco de referencia de lo QUE deberías hacer, pero no hay imposición sino más bien es un molde al que uno puede ajustar y modificar a gusto y luego volcar en ese marco de trabajo las propias actividades que uno considera. Es más, ¡Los procesos te piden que los llenes! Las metodologías como Scrum, por ejemplo, te dan el molde y sus propios ingredientes. No admite innovación de tu parte para meterlo en su diseño. De allí que no necesariamente es para todos los equipos y a su vez también no es la mejor opción para conducir todos los proyectos.

Saludos,

[[Delphius]]

Lo de hacer código lo más indepente posible creo que todos buscamos eso. Pero hay que evitar que se nos suba demasiado a la cabeza.
Cohesión y Acoplamiento son dos conceptos diferentes pero relacionados de una forma especial. Lo que se gana en uno se pierde por el otro. No tiene sentido luchar contra ambos de forma separada. Lo digo por experiencia.

Es el Ying-Jang de la informática. El asunto para por aprender a reconocer y a sentirnos cómodos con el nivel de cohesión y acoplamiento que mejor nos satisfaga. No nos tenemos que dejarnos llevar a la batalla de "quiero que no exista acoplamiento y lo voy a conseguir" o "Esto no es nada cohesivo, necesito un diseño mejor y separar mejor las cosas" porque es inútil. Nos va a demorar más y será una batalla en la que siempre vamos a perder. Para ganar la única forma es no dejarse entrar al juego.

Saludos,

[[AzidRain]]

Gracias amigos, estas opiniones son las que sin duda enriquecen la taberna. En efecto creo que el meollo del asunto es precisamente el que uno como arquitecto de un sistema sepa identificar cual metodología es la adecuada para encarar cada proyecto y no casarse con una de ellas y pretender usarla para todo. Al menos en casi 25 años que tengo programando he visto que no existe ninguna solución ideal para nada. Y que en efecto van surgiendo modas y tendencias que casi siempre van enfocadas a resolver algo pero que a la vez no resuelven todo.

Por aquí a un consultor externo le hicieron esta pregunta: ¿Si ya todo está hecho en Delphi, por que no completas lo que le falta al proyecto con ese lenguaje? Al final hasta ahora está funcionando sin problemas en producción. La respuestas más sensatas podrían ir mas o menos así:

* No tengo presupuesto para comprar el IDE ni los componentes que necesito
* Me cuesta trabajo encontrar desarrolladores de nivel que conozcan el lenguaje
* NO SE DELPHI

En lugar de:
* Es un lenguaje "viejo"
* Ya no se enseña en universidades
* Encuentro más fácilmente desarrolladores de x lenguaje
* SOLO SE X LENGUAJE

(caso real)

Definitivamente no veo como una metodología ágil encaje en proyectos de gran envergadura y no he visto implementaciones de la misma a ese nivel. Por ahí en un seminario me decían que scrum requiere: desarrolladores con alto nivel de especialización y compromiso, proyectos con una gran urgencia de salir a producción, y una serie cosas que sencillamente en proyecto muy grande es imposible de cumplir. Y luego está la cuestión de los constantes imprevistos, scrum se basa en una apreciación subjetiva de "cuanto tiempo tardas en hacer tal tarea" lo que sabemos implica que en medio de la tarea surja algo que no se había previsto y la presión para quien desarrolla es bastante alta. Un programador estresado definitivamente no pude producir nada bueno, salvo honrosas excepciones.

Pero bueno, modas al fin. LO que me gusta de Delphi es que con todo y modas aquí sigue y parece que va de subida nuevamente.

[[Delphius]]

Azid, ojo. No necesariamente debe ser una metodología. Puede ser un Modelo.
No es por ser pesado, pero es que no es lo mismo decir metodología que Modelo.

De todas formas, lo importante es tener un plan de trabajo y de como llevar el progreso y los procesos.
Es mejor tener un proceso que no tenerlo. Hay una frase medio conocida que resume muy bien esto. Ahorita no me la recuerdo bien... era algo parecido a lo que dije y relaciona a las personas y el proceso. La había leido en UML y Patrones.

Saludos,

[[Al González]]

Muy buen tema. Yo no sería capaz de definir qué metodología o modelo utilizo. Me gusta pensar que todo camino es válido mientras entregues en un tiempo razonable algo funcional, satisfactorio y que sea consistente y estético tanto por dentro como por fuera. En ocasiones hay suerte y hasta toca añadir alguna pequeña innovación.

Agrego: Eso sí, sigo pensando que algo como la DTE puede beneficiar mucho el trabajo en equipo. En ese sentido, tengo la fortuna de haber sido contratado para realizar solamente programación de bibliotecas de clases, exceptuando aquellas relacionadas con interfaces de usuario. Mis "clientes" son otros programadores, ya no el usuario final. Por fin estoy en mi elemento.

[mamcx]

Empezado por AzidRain

Definitivamente no veo como una metodología ágil encaje en proyectos de gran envergadura y no he visto implementaciones de la misma a ese nivel.

Si te puedo asegurar algo, es que las empresas grandes y de proyectos de envergadura, SEGURAMENTE han probado de *todo*. SCRUM y AGILE lo usan MS, Google y seguro un monton mas.

De esas empresas, en esos proyectos... de eso viven los consultores que promueven esas metodologias

Ahora, si lees del tema, veras que lo implementan a nivel de equipos (a nivel tactico) y en empresas con MS, Google, permiten a diversos grupos implementar metodos diferentes...

Empezado por AzidRain

Por ahí en un seminario me decían que scrum requiere: desarrolladores con alto nivel de especialización y compromiso, proyectos con una gran urgencia de salir a producción, y una serie cosas que sencillamente en proyecto muy grande es imposible de cumplir.

Que tipo tan despistado!

Lo que esta describiendo no es SCRUM, ni nada parecido. Esta describiendo el tipo de ambiente que se vive en una startup.

Empezado por AzidRain

Y luego está la cuestión de los constantes imprevistos, scrum se basa en una apreciación subjetiva de "cuanto tiempo tardas en hacer tal tarea" lo que sabemos implica que en medio de la tarea surja algo que no se había previsto y la presión para quien desarrolla es bastante alta.

De hecho, los metodos agiles son los mas IDEALES PARA ESTO.

Por ejemplo:

http://scrummethodology.com/

Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Scrum emphasizes decision making from real-world results rather than speculation.

Por lo tanto, adaptarse a un ambiente cambiante es la RAZON DE SER de estos metodos.

Lo de "cuanto tiempo tardas en hacer tal tarea" creo que lo estas entendiendo mal. Si existe algo bueno rescatable de SCRUM es precisamente ese punto. La parte CLAVE es que si una tarea se estima como muy larga, entonces hay que partirla en pasos mas pequeños.


Es lo normal hacer tareas que duren horas, no dias. El punto clave es que estimar a corto plazo tiende a ser preciso, pero a largo es casi imposible.

-----

En cuanto a las limitaciones de SCRUM, wikipedia las expresa bien.

[mamcx]

Empezado por AzidRain

Pero bueno, yo solo opino. No se si alguien tenga alguna experiencia por ahí sobre este tipo de metodologías en proyectos similares.

No estas desencaminado. De hecho cada cierto tiempo surgen debates de esos como https://news.ycombinator.com/item?id=10543180 y https://news.ycombinator.com/item?id=10543180. (Habia una discusion mas reciente y mucho mejor expresada, pero no la encuentro, asi que voy a ver que me acuerdo!)

------

A mi me ha tocado de todo un poco. Desde el metodo clasico del desarollo en cascada, programacion extrema, SCRUM y el mas popular de todos en el mundo de la programacion:

Vamos pa delante sin frenos y sin mirar pa' donde!

Ahora lo que aplico es:

1- Tener un control de codigo fuente (mercurial)
2- Tener un sistema donde anotar BUGS, requerimientos, etc (uso pivotaltracker)
3- SCRUM
4- +17 años de experiencia

------

Sirven mas este o aquel para equipos pequeños, grandes, desarrollos complejos, simples, etc? En teminos generales, se puede hacer funcionar en todos los casos.

El problema, es que EL FRACASO ESTA GARANTIZADO y el exito es escaso (Me explico por fracaso: Que el proyecto no se termine, se salga de forma exagerada de presupuesto/tiempo o termine muy lejos de lo que debio ser, la gente se agarre de los pelos, un evento inesperado altero todo, se quemo el disco con todo el codigo fuente, la empresa se quebro, etc)

Asi que aun con un buen metodo, es probable que el proyecto fracase.

----

Microsoft hizo un estudio muy amplio de varias cosas (publicado aca) y el resultado es que muchas cosas que se consideran "buenas practicas" por si solas no predicen con certeza si el proyecto saldra bien o no. EN CAMBIO, el predictor mas certero de todos? Que la organizacion sea disfuncional (Ej: Jefes/Clientes/Programadores problematicos, Burocracias, tener que coordinar el trabajo entre mucha gente, etc).

Esto se puede entender asi:

Que el equipo de futbol de Brasil gane muchas veces, no es tanto debido a que usen esta o aquella formacion, sino a que tiene buenos jugadores/tecnicos, que se les da lo necesario.

Obvio, un buen equipo vera que esta o aquella formacion les es mas conveniente. Pero la formacion sin el equipo, es inutil.

----

Pienso que esto se puede entender asi:

1- Cualquier sistema estructurado/metodologia sera una gran mejora sobre "Programemos a lo loco!". Es por eso que muchos al principio obtienen muchas ventajas.

Sin embargo, la burocracia mata cualquier ventaja que este traiga...

2- Es cierto como dice Delphius que el factor dominante es la calidad del equipo de trabajo. Por lo tanto, mejor que imponerles un estilo, darle el abanico de opciones y que implementen lo que les parezca.

De la misma manera, uno se puede adaptar a cualquier cosa. Desafortunadamente la personas que no entienden que el factor determinante es la gente y no los metodos, terminan haciendo que lo que sea se convierta en un lio: Documentar, hacer pruebas, usar control de versiones, usa scrum, hacer testeo, etc Todo eso es bueno, pero muchas veces la forma de implementarlo le quita la gracia...

----

Empezado por AzidRain

Bajo este planteamiento, considero que las metodologías ágiles, en mi caso particlar, scrum, se enfocan más a ver pequeños pedazos de un todo aplicando el famoso "divide y venceras" y deja de lado la importancia de las interrelaciones.

SCRUM/XP y similares tienen claro el asunto de las interrelaciones. Ahora, es muy comun que eso lo pasen por la galleta los equipos y/o los mismo clientes (de ahi a que parezca a veces que esas consideraciones no existen!_. El punto de falla principal es la comunicación de la gente, no sus metodologias

Hay un factor mas diciente, que recuerdo fue un articulo basado en la estructura de comando de los ejercitos (que fue bien aplicada para este caso, pero no logro encontrar la fuente)

Hay una diferencia clara entre la estrategia y la tactica, lo global y lo especifico.
Hay una diferencia entre seguir ordenes, el rumbo fijado sin desviarse y adaptarse a las circunstancias.

Los metodos agiles, en su aplicacion comun, son TACTICOS y para equipos ADAPTABLES. Pero sin la ESTRATEGIA y un norte claro, se pierde el enfoque.

La ESTRATEGIA es dejar claro que es el proyecto, sus limites y alcances. Es tener el panorama globla claro. En este punto, es mejor SEGUIR EL CAMINO que estar cambiando de parecer.

Pero sin la tactica o la flexibilidad, no se puede avanzar.

Por lo tanto, alguien dijo que el mejor metodo es mezclar ambas cosas:

1- Tener un conjunto fijo y relativamente inflexible que delimita la ESTRATEGIA del proyecto, el cual abarca la duracion de todo este

2- Operar TACTICAMENTE en el dia a dia, poniendo tareas pequeñas y alcanzables.

Si la estrategia del proyecto/requerimientos deja ser viable, no solo hay que replantearse la misma, sino que eso tambien va a afectar el dia a dia. Lo uno no es sin lo otro.

De ahi a que funciona muy bien el mezclar el desarrollo en cascada (Sacar primero requerimientos tan completos como sea posible, con todo lo que implica) pero dejar los *detalles* a un metodo agil.
-----

Por ultimo, es mi parecer que la forma mas segura de que un proyecto sea lo mas certeramente posible exitoso es:

Dejar que las personas competentes hagan su trabajo, y darles los recursos y apoyo necesario.