Metodologías ágiles ¿Aplican siempre?

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

[Ñuño Martínez]

Empezado por 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.

Talmente lo que hago yo.

Aunque todavía no me termino de encontrar en mi elemento, más que nada debido a necesidades derivadas de haberme metido empresario, pero tengo esperanzas en el futuro.

[mamcx]

Empezado por 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.

Si logras esos objetivos con cierta regularidad (que es mas habitual con la experiencia) es muy probable que la metodologia sea muy cercana a la que usan los programadores de experiencia

Todo este tema de las metodologias es mas que todo, el aspecto operativo. Como dicen en

http://scrummethodology.com/

Scrum is a simple set of roles, responsibilities, and meetings that never change. By removing unnecessary unpredictability, we’re better able to cope with the necessary unpredictability of continuous discovery and learning.

Por lo tanto estas cosas son aun mas valiosas para poner a un equipo en la misma pagina. Es como en un trabajo comun, uno sabe que el horario es de 8 a 6, que se trabaja en tal direccion de la empresas, que mi labor es esta, y lo que hacen los otros es aquello. Es la estructura del trabajo (pero no la garantia de hacerlo bien!) que es necesaria para coordinarse bien.

Eventualmente toda persona con experiencia termina re-descubriendo las buenas practicas, aun sin saber que tiene tal o cual nombre. El reto ocurre cuando se juntan 2: Como concordar en como hacer las cosas? Ahi es donde estos temas importan.

[[Delphius]]

Empezado por mamcx

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!)

Si le surgen discusiones es porque no es todo oro, por tanto no tiene sentido intentar venderlo como que es para todo.
Aquí ya deberías de terminar de seguirle la vuelta.

------

Empezado por mamcx

A mi me ha tocado de todo un poco. Desde el metodo clasico del desarollo en cascada, programacion extrema, SCRUM

¡Fantástico! Mezclemos metodologías y modelos. Che Mamx, ¿sabías que son agua y aceite? O aplicas metodologías o aplicas modelos. Es muy habitual mezclar y combinar y desarrollar un marco de trabajo propio con el que nos lleguemos a sentir cómodos pero a ver, la cosa es o mezclar metodologías, o mezclas modelos. Combinar metodología con modelos es tentar el desastre. No lo digo yo: lo dicen los propios investigadores de la Ingeniería de Software.

Empezado por mamcx

y el mas popular de todos en el mundo de la programacion:

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

Eso es casi inevitable. Generalmente cuando uno recién empieza o bien cuando ya ha adquirido experiencia y se le ha subido demasiado el optimismo del "si se puede".

Empezado por mamcx

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

El punto 1 y 2 pertenecen a las máximas. Se dan por entendido que tanto las metodologías como los Modelos toman a éstas. No tiene sentido que las numeres porque el sólo hecho de decir que uno aplica una metodología o un modelo ya los considera.
El 4 sobra.

Empezado por mamcx

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.

Che mamx, nos mandaste al final a decir que en wikipedia están bien acotado lo de sus limitaciones. Entonces... ¿a que jugamos? ¿Aplica en todo o no?
Te doy la respuesta: NO, no aplica para todo. Si tiene sus limitaciones. Cuanto más se intente estirar el modelo o una metodología para algo que no da, más se quiebra.

Empezado por mamcx

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.

Es cierto que la historia de la industria del software está llena de fracasos. Y los hay con todos los modelos, paradigmas y/o metodologías que se han propuesto.
Las culpas son compartidas: tanto por un mal marco de trabajo elegido, como del equipo. Los factores externos también influyen pero sobre éstos no tenemos absoluto control, y cuanto mucho podemos mitigar su impacto.
El defecto de scrum es que es mucho más dependiente de que las cosas salgan bien. Si tiene sus puntos de control de riesgos pero el problema es que no es intensivo, es reactivo. Otros enfoques en cambio tienen ya en su marco de trabajo un plan de riesgos y son más preventivos.
Scrum es de avanzar rápido, luego piensa. Y no siempre eso es bueno.

Empezado por mamcx

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

Obvio que las buenas prácticas por si solas no garantizan nada. Como así también el hecho de que se adopte algún método o proceso no es garantía.
Scrum tiene un plan muy centrado en la formación de equipo, por algo será.
Pero otros enfoques también lo tienen, pero no de forma tan explícita.

Creo que es por demás obvio que lo principal es tener un equipo aceitado y lo mejor capacitado. Esto va para cualquier enfoque que se adopte.
El extra, y volviendo al tema de Scrum, es justamente que no está pensado para todo tipo de equipo y personas. Scrum es burocrático: que reuniones todos los putos días para ver que se va a hacer y que al final tener que pasar el informe de resultados puede ser muy molesto. No todos funcionan así, hay personas a las que resulta más cómodos planes generales y no le estén rompiendo las pelotas cada día, o hasta en tiempos por horas a ver que hiciste y que grado de avance hay.

Scrum no es tan flexible como dices. Tiene un esquema rígido. Los modelos son rígidos también, pero al menos tienen muchas cosas "opcionales".

Empezado por mamcx

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

Te equivocas. No siempre la culpa es de la gente, las metodologías y los modelos también. Elegir mal el esquema de trabajo es un síntoma por demás habitual. Y ahí ya no es culpa del equipo sino del director.

Sacate el papel de comercial, ya sabemos que haces de consultoría. Por lo que es más que obvio que intentarás vendernos el paquete scrum. Y más tarde nos vendrás a vender otro... Ahora que recuerdo, hace un tiempo tu nos estabas comentando sobre que aplicabas Modelo-V.

El no reconocer que las metodologías y los modelos también pueden ser un dolor de cabeza y están provocando un desaguizado mental en los desarrolladores es un grave defecto de muchos pensadores y defensores de la Ingeniería de Software. Les faltan más "mea culpa". Tom DeMarco sacudió el bote hace un tiempo, pasó de ser un gran defensor de la Ingeniería de Software y ahora es uno de sus críticos.

Empezado por mamcx

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.

¿Que acaso los Modelos no tienen fecha límite, ni restricciones, alcances, etc?
Todo equipo debe ser dinámico, Scrum vende que lo es. Pero tiene una estructura rígida que no calza en todo. Es lo que vengo diciendo. Los Modelos incrementales en cambio a pesar de que tienen sus macro-actividades definidas, las actividades estructurales que uno le incorpore le permiten ser flexibles. Además por naturaleza el principio de los modelos incremental es trabajar según los riesgos y redefinen los incrementos según el avance. No hay esa presión que caracteriza y puede jugarle muy en contra a Scrum, de que esta actividad se hace en x hs y luego a llorar.

Scrum es útil para proyectos que más o menos ya están estudiados, en donde el equipo ya tiene su base y se siente cómodo. Para cosas nuevas e innovadoras y que amerita ir estudiando a la marcha no viene bien. ¡Entiendelo! Lo deja la wiki tu dices, pero que de todas formas aún insiste en que es para todo.

Empezado por mamcx

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.

Ya he dicho que ese tipo de mezcla no es buena. Lo que se termina haciendo es mezclar las máximas y buenas prácticas pero bajo otro esquema de trabajo propio. Una metodología no es combinable con Modelo. Advertí de esa diferencia unos post antes y ya antes hace tiempo en otros hilos les hice saber de cuales son sus diferencias y que define cada una.

Y por cierto, deberías repasar lo que es el ciclo de Cascada o Secuencial, porque es mucho más que atacar a los requerimientos desde el principio. Tienes un grave problema con los reduccionismos.

Empezado por mamcx

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.

Dice el dicho que hasta el cazador más experimentado se le escapa la liebre...

Empezado por mamcx

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

Los consultores viven de la moda. Son capaces de vender a su madre con tal de darte ciegas garantías de que seguir x enfoque, utilizar x lenguaje tendrás un pastón de guita y las personas se masturbarán virtualmente cada vez que usan tu soft. Ellos nunca tienen la culpa. La culpa siempre es: utilizan algo obsoleto, el equipo de trabajo no está capacitado, no aprendieron nada de lo que el consultor dijo.
No van a Google o a MS, van a empresas más chicas. Donde puedan sacar a lucir su corbatita y la lengua fácil.
M$ tiene un buen equipito de estos que de vez en cuando salen a vender a quien más vender su "innovador método para proyectos exitosos".
La red está repleta de testimonios de como el consultor termina resultando ser una enfermedad que una cura.

Empezado por mamcx

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.

No mamx, esa es justamente la crítica más fuerte que se le ha hecho a Scrum.
Scrum no sirve en proyectos de largo plazo, trabaja en media y baja escala. Si necesita gente entrenada y acostumbrada a trabajar de esa forma. Y para eso se necesita de disciplina, lo que implica haber pasado por un proceso en el que se da forma a la empresa.
No sirve en ambientes star-up precisamente porque para poner Scrum, se requiere experiencia previa y tener YA LA CASA EN ORDEN. Si es una empresa que recién se está formando, Scrum es la muerte.

Empezado por mamcx

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

Por ejemplo:

http://scrummethodology.com/



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.

Es cierto que Scrum intenta atacar las subjetividades al condicionar a que se defina justamente en unidades más concretas de tiempo. Pero lo que ha dicho Azid es muy importante, la presión. Hay presiones y presiones.
Aquellas ventajas de trabajar en cosas concretas, en tiempos concretos de Scrum es también su problema. Requiere de preparación, tener bien ordenado desde antes ya las cosas para que no aparezcan demasiadas sorpresas. No es tan flexible como dicen ser. Para un proyecto que se va armando en la marcha y que tiene muchas posibilidades de que aparezcan restricciones y/o condiciones ténicas-operativas y legales que lo modifiquen Scrum hace aguas.
Scrum necesita medidas concretas. Estudios y experiencias previas. Para innovar no va.

Insisto: no es para todo.

Saludos,

[[Al González]]

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

[Casimiro Notevi]

Empezado por Al González

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

[mamcx]

Empezado por Al González

No quisiera estar en los zapatos de Mario y tener un fan tan aguerrido.

Imagino que cierto Casimiro pensara lo mismo de mi

Y con Delphius las ultimas conversas, pues ni tan en desacuerdo estoy, solo que enfatiza unas cosas con mas pasion

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