Metodologías ágiles ¿Aplican siempre?
 

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.

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

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

Saludos,

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,

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,

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

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

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.

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,

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

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.


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.

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

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.

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

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.

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

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

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.


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.

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.



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

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.


¿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. :rolleyes:


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.

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

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.


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.


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,

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

:D:D:D:D:D:D

A mi lo que es Ingeniería de Software me atrae Al. Y en estos temas es imposible no entrarle. :rolleyes:

¿Fan? Y... no se... puede ser che. Mamx fue una de las personas que más ha relatado sobre Ingeniería de Software en el foro, y eso lo aplaudo porque a pesar de que tengo mis críticas estoy seguro que hay una lección tras esto en la que el y yo concidiremos:

Esa frase lo resume bien. Es preferible que siga trabajando la Ingeniería de Software y se enfoque en traer orden a la casa, antes que tirar a la basura todo y hacer las cosas a lo tin-marin-de-don-pingue.
El punto es que ha llegado el punto en que por traer orden a la casa hemos tirado la basura en el patio y los trastos en aquel placard viejo. Y ya no hay donde más pasar sin darnos cuenta que hemos creado un monstruo.

La Ingeniería de Software nos ha traído grandes maravillas, pero también nos la venden como espejitos de colores y nos enamoramos de ella y se ha perdido mucho en los años.
Tenemos que desenenamorarnos de algunas prácticas.

Yo, aún siendo defensor de las buenas prácticas de la Ingeniería de Software, me permito la crítica a este elefantiásico monstruo en que se ha convertido. Es necesario quitarles varios laureles y poner en la mesa la discusión eterna: La crisis del software no se superó.

Saludos,

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

Sorry no me he podido leer todos los mensajes :p. Pero en mi caso si he aplicado la metodología Scrum en algunos proyectos, cabe mencionar que tiene que estar conformado por un equipo multidisciplinario, y como bien indica Azid, es de vital importancia que el scrummaster sepa lo que tiene que hacer, sino...., y que todos tengan claro lo que tienen que hacer. En mi caso ha sido una bonita experiencia, y todo salió bien, se cumplian con los sprints, las retroalimentaciones, la gestión de riesgos, se hacian los productlog, y demás; claro todo esto de la mano de la planificación por que si uno se pone a programar a la loca no salen las cosas. Por otro lado también tengo experiencias en otras metodologías como: XP (que no me gusta personalmente), RUP, MOPROSOFT, PAR (banco BCP), COM (metodología de Everis -España), MEGON (telefónica), ICONIX, y otras. También conozco de la metología del PMI (Gestión de Proyectos) :). Si hay un chupo de metodologías y demás, pero siempre hay que saber cuando utilizar qué en donde como bien indica Azid.

Ahora en uno de los cursos que llevé en mi maestría se hizo un estudio del tema ¿por qué fracasan los proyectos de software?, y en este estudio se pudo observar que hay un gran porcentaje de proyectos (más del 70%) que fracasa por temas de gestión.

Pero, ¿qué sucede cuando, tienes un cliente que no sabe bién lo que quiere, y para cambiando de requerimientos?, algunos mencionan que el scrum se ajusta para el tema de cambio de requerimientos porque es ágil, pero ahí les suelto la pregunta, ¿cómo manejan ustedes a un cliente que no tiene en claro lo que requiere como software?

En mi experiencia personal, un ing. de software es un consultor que debe guiar al cliente y ayudar en este punto, esto es critico a mi modo ver, y también del por qué fallan muchos proyectos de software, en la cual el cliente no queda satisfecho con lo realizado. Ya he escuchado en muchos sitios a gente de este rubro decir, yo me limito a cumplir con los requerimientos y con lo que indica el triangulo (ahora es un hexágono) de la calidad y piensan que eso es suficiente. Sin pensar que muchas veces el cliente puede no conocer bien lo que quiere, y al final por más que hayas cumplido con los requerimientos no se siente cómodo con el resultado final.

¿Quisiera saber la opinión de ustedes, de como manejan como vuelvo a mencionar a los clientes que no tienen claro lo que desean :D?


Saludos.

Es bastante interesante lo que planteas. Un buen porcentaje de clientes piensan que tienen bien claro lo que desean pero muchas veces esos deseos no se reflejan en necesidades. Es decir, casi siempre quieren cosas que no necesitan y necesitan cosas que no quieren. Pero bueno, partamos del caso de un cliente que tiene una idea de que es lo que necesita. El chiste de esto es ayudarle a modelar esas necesidades en función de como le resolverá n números de problemas. Sin embargo hay otros casos en donde el cliente se aferra a lo que el piensa que necesita y no importa cuantas juntas, correcciones, entregas e iteraciones hagas al proyecto, nunca está conforme con el resultado aunque éste se adhiera perfectamente a los requerimientos indicados.

Volviendo al punto de las metodologías en efecto pienso que no existe una "navaja suiza" que se pueda aplicar con éxito en todos los casos de desarrollo. Creo que el verdadero valor de un líder, gerente o cabeza de desarrollo es determinar la metodología que mejor se adapte a las características del proyecto aun y cuando no sea la que mejor domina o conoce. Scrum en efecto es muy divertido ya aplicado y con los elementos correctos (proyectos de rápido desplegado, equipos multidisciplinarios, equipos autogestionados, participación del usuario, etc.)

Ese es otro tema peludo. Pero seria mejor un tema aparte de este...

En este momento releyendo el hilo me di cuenta de algo: Sin saberlo dos compañeros y yo (uno de ellos Q.E.P.D.) practicábamos la metodología XP, pues hacíamos largas jornadas de madrugada con uno al mando de la pc y otro al hombro observando y aportando. Ese esquema nos funcionaba porque se trataba de proyectos para concurso, que teníamos que terminar en un cierto tiempo sí o sí para poder participar y nos dio en su momento muy bien resultado. Hablo de por alla de 1990 cuando la OOP apenas estaba en pañales y Mr. Grady Booch era el referente, y en donde "Programacion I" se daba basado en Turbo Pascal 3.0. y más tarde en Turbo Pascal 5.0 y 6.0 que ya traían Turbo Vision y otras cosas que más tarde se convertirían en Delphi.

Turbo Pascal 6.0 presentó Turbo Vision. La versión 5.0 no tenía capacidad de orientación a objetos. Sin embargo, Turbo Pascal 5.5 introdujo el concepto de tipo de objeto y con ello se convirtió en el primer lenguaje de programación popular POO.

En aquellos buenos años los navegantes sostenían el timón, no los mercaderes. :rolleyes:

A pesar de no tener tanta experiencia con muchos clientes, creo que así como no hay una única forma de encarar un proyecto; tampoco habrá una única forma mágica de sobrellevar y guiar a estos clientes. Depende de muchas cosas, la propia formación y el conocimiento/asimilación sobre informática que pudiera tener el cliente, del negocio/empresa/emprendimiento en que maneja, hasta incluso se podría debatir la situación personal del mismo.
No es lo mismo hablar por ejemplo con un ingeniero industrial que nos solicita ayuda para diseñar un sistema que controle el proceso de una fábrica de metales que hablar con un panadero que posiblemente apenas ha terminado la secundaria e hizo un curso sobre panadería. No es lo mismo hablar con alguien que vive envuelto en un mundo de mucha tecnología y tiene 30 años que hablarlo con un abogado de 90 años que se ha quedado en el tiempo y es reacio incluso a tener un celular.
Hay clientes y clientes... y no creo que se pueda generalizar.

Ahora bien desde el punto de gestión ahí si podríamos poner cartas en la mesa. Pero de nuevo: todo depende de como uno agarra el taco. En lo personal, y en mi poca experiencia, para situaciones como la que describes yo consideraría modelos basados en Prototipos, o en Espiral. O alguna combinación de éstos dos.


Por favor Azid, ¡que no todo es metodología! Existen los modelos.
Ya he dicho hasta el cansancio que una cosa es metodología y otra son los modelos de procesos. No se dan por aludidos.

Me extraña que no asimilen esto, o es que ya tienen medio oxidado lo que han aprendido de la universidad. Me inclino a por lo 2do.

Saludos,

Yo no fui a la universidad, Marcelo. Por eso escribo "dislates".

No lo dije por ti Al, sino a los demás. Que tuvieron formación académica y aún insisten en resumir todo a metodologías.
Lo cierto es que hay modelos de proceso y por el otro metodologías.

Lo del enlace y la palabra dislates no comprendo. El link apunta a un post tuyo de un hilo sobre TIOBE y la posición que ocupa Delphi... del año 2013 :confused:

Saludos,

Supongo que se refiere a esto :):

Y, en cuanto al siginificado de dislate, use google, my friend.

LineComment Saludos

Pues justamente en que a ese post me cuesta entenderle el nexo con este hilo. Y pensé que quizá se ha confundido de post o enlace y quiso poner otro.

Yo se que el buen compañero Al es un excelente idóneo y su experiencia viene de forma totalmente autodidacta. Lo cual no digo que sea malo o de menosprecio. Todo lo contrario, es de un gran respeto. En el área Informática hay muchos idóneos que han sido (y siguen siendo) grandes ejemplos a imitar.

Yo espero que Al entienda que lo que yo he expresado post antes no es algo hacia el, sino de asombro por los otros miembros que han intervenido y que sabiendo que han recibido instrucción formal en alguna carrera de Informática y no hagan una correcta separación y distinción entre Metodologías y Modelos. Lo vengo advirtiendo desde el comienzo del hilo.
Es un grave error meter en la misma bolsa y confundir Modelos como si fueran metodologías. Es algo que se da mucha incapié en las cátedras de Ingeniería de Software, pero lamentablemente hay mucha literatatura tendenciosa, sobre todo en Internet, que desinforma y ponen por igual a ambos conceptos.

Es cierto que a nivel general se suele recurrir a la palabra Metodología para explicar tanto a los diferentes Modelos (Cascada, Prototipado, Espiral, etc) como a las Metodologías (XP, Scrum, etc) pero esto es un error. Y es justamente esa dualidad lo que hace y genera la confusión. Es deber nuestro corregir eso. Se aconseja, y mucho, que en lugar de emplear esa palabrita para referirse en términos generales se use el término Paradigma de Proceso o bien Ciclo de Vida de Proceso, Proceso de Software.
Y hago esa advertencia a los profesionales que siguen insistiendo en hablar de metodologías sin hacer las debidas aclaraciones. Voy a seguir insistiendo: una cosa son Modelos y otra son las Metodologías.

¿Tan difícil es pedir un mínimo de respeto a nuestra formación? El no hacer esas debidas referencias les quita valor a sus expresiones y con todo respeto, le baja la calidad profesional a sus argumentos.

Volviendo a lo que ha dicho Al, me queda pensando en el trasfondo de lo que ha intentado poner. Quizá se me ha activado el Chip Asperguiano y no logro encontrarle el buen sentido.
Yo se que Al al no haber recibido formación universitaria quizá se sienta un poco intimidado por como yo al menos le di giros al hilo. Pero no me cabe duda de que su capacidad Idónea no necesita de que alguien le diga que debe aplicar algún modelo o metodología.

En la práctica uno termina desarrollando su propio método (esta es otra palabra aconsejada para decirlo en forma general) y estoy convencido de que Al tiene el suyo. ¡Vuelvan a la frase de Grady Booch que he citado! Es muy probable que sin proponérselo haya redescubierto muchas de las máximas y de las buenas prácticas y concebido una versión mixta de algunos modelos y/o metodologías.

Yo espero que Al pueda sentirse a gusto con lo que ha logrado. Porque su rica experiencia bien le ha dado su calidad técnica y el bien reconocido valor que esta comunidad le da y recuerda cada vez que puede. Y sus palabras tienen peso, validez y capacidad de ver a largo plazo. La profesía de ese post sobre el repunte de Delphi se cumplió.

No me parece que sus expresiones sean un disparate, es más comparto lo que ha dicho en ese post enlazado. Hace tiempo que Microsoft viene preparando la muerte de .NET y volver a ruedo con un nuevo lenguaje... no lo suelta todavía porque tiene algo de "escuela" hecha y quiere sacarle el jugo hasta donde pueda y la burbuja caótica de los tropezones de un paso de versión a otra explote. Las escuelas de Java están empezando a perder prestigio, mucho JAVA todo bonito pero por querer dar las cosas rápida y a los bifes se ha perdido la base. Mamx citó una vez la crítica que Joel Spolsky supo hacer a las JAVA Schools. Estas escuelas se difundieron como un cáncer. Y si, en esta le estoy con Joel: hay algunos que tienen 10 en JAVA pero si le preguntas sobre lo que es recursividad o punteros se sacan un 1.

Hace poco se supo de una buena noticia, el gobierno de Sudáfrica eligió Delphi al nivel educativo. Ya antes Rusia también dió ejemplo al comprar 1 millón de licencias, y casi al mismo tiempo de que Joel publicase su artículo con la crítica a las Java Schools nos habíamos enterado de que el gobierno de Inglaterra aconsejaba seriamente abandonar estas escuelas y ponía mucho énfasis en la escuela basada en Pascal/Object Pascal.

La comunidad Pascalera/Object Pascalera pareciera ser un ave fénix que tiene ciclos de vida de 5 años, pone su huevo cuando todo pareciera morirse en su propia ceniza y de pronto el huevo se rompe y nace nuevamente con nuevos aires. Es Inmortal... es el que todos odian pero le guardan unos celos no confesados... me recuerda cuando una compañera de la universidad se quedaba maravillada en como de rápido terminaba los prácticos y ella se tardaba más en hacerlo en Visual Basic o en .NET. En una "discusión" en la que no nos poníamos de acuerdo para hacer un trabajo en grupo ella misma había sugerido Delphi... Nos odian, y nos celan. :D A ver si no se roban otro CEO más (si es que aún queda alguno en Idera... porque ya se fue el último del equipo original de CodeGear de la parte del equipo del compilador hacia Google)

Saludos,

Ya relájese, no se estrese, ¡pare de sufrir! :D

Acá todo bien, Marcelo. No era ningún reproche personal. Yo te estimo, y si tuvieras novia te daba un abrazo. :p

Ya quisiera yo volver a tener tu edad para que las chicas del gimnasio me hicieran caso. ¡Aproveche la vida, cabrón!

https://plus.google.com/105521752150...ts/AEt5Lob91FL

:eek: ¿Google hace eso?

LineComment Saludos

Ufff... soy el señor estrés. Disfrazo mi ya inevitable calvicie dejándome el pelo un poco más largo. Y lo más chistoso es que canas me salen desde los 20... 22. Por ahí.
Ya quisiera yo tener suerte con las mujeres. ¡Con una me conformo!, ¡Ay! si me diera más bola cierta personita. :o
Acá con NewDelphius y el resto de la banda andamos intentando conquistar el mundo amigo. No nos vamos a rendir, aunque por momentos nos da ese bajonazo que nos pone muy drepe.

Coincido a lo que dice román... ¿Cómo es eso de que Google "censura" páginas sobre Delphi? Me cuesta creer eso.

Saludos,

Google es un gran lobo vestido de corderito. No solamente censura sitios que son competencia a sus proyectos, lenguajes, etc. sino a montones de webs de distinto tipo por diversos motivos: taringa, anonymous, páginas de descargas, torrents (the pirate bay, isohunt, torrentreactor, etc.), muchas webs ecologistas (ignoro la razón), webs de ideas políticas que no les gusta, religiones con las que no están de acuerdo, etc.
Hace años que procuro/intento no usar nada de google.

Lo más normal es que dentro de 20 años veas las cosas de una manera muy distinta. Tan distinta que te parecerá increible que ahora mismo pienses como piensas.
Te darás cuenta que no vale la pena obsesionarse o amargarse por cosas sin importancia. Un esguince es algo que se cura en unas semanas o meses, no hay que darle mucha importancia.
Te importará nada si tienes pelo corto, largo, canas o eres totalmente calvo. En cuanto a mujeres, la mitad de la población mundial son mujeres, hay miles de millones de ellas ;)
También te darás cuenta que la vida pasa muy rápido y cada vez más rápido, y que hay que hacer todo lo posible por no perder tiempo, porque cuando menos te lo esperes y sin que te des cuenta, ya no estarás pensando en todos los años que tienes por delante para hacer cosas, sino todo lo contrario, entrarás en modo "cuenta atrás", queriendo darte prisa para poder hacer lo más posible antes de que sea demasiado tarde.
La vida es muy extraña, nos la pasamos adormilados sin darnos cuenta de la realidad, hasta que es demasiado tarde, descubrimos la realidad (o eso nos parece) y nos damos cuenta que ya es muy difícil conseguir lo que realmente se quiere.

¿Cuál es entonces el objetivo real de Google/Alphabet de censurar sitios sobre Delphi, y a la comunidad Pascal en general, cuando ellos mismos han invertido y subsidiado costos al proyecto de Lazarus/FreePascal?
El problema de Taringa no es con Google, es judicial por la ley SOPA/Sinde. Google simplemente obedeció lo que le ordenó la Corte de eliminar los resultados de búsquedas en dicha red social relacionadas con el tema de descargas de libros y otros materiales con derechos de autor.
Y si, penaliza a sitios de descargas (sobre todo a los fams links) aunque esto no los eliminó de su búsqueda. ¿O acaso no sigue mostrando resultados de sitios como Softonic acaso?
Que ignore el lado oscuro ¿no es medio obvio?
Eso de que censure web ecológicas es nuevo. ¿Tienes alguna fuente para comprobarlo? ¿Que sitios? Sabés porque te lo pregunto porque yo soy pro-ecologista y vengo haciendo investigaciones sobre permacultura y hasta ahora no he visto que google se niegue a darme resultados (y eso que el movimiento pro-permacultura le puede dar motivos para que lo censuren, pero ahí están.. Cientos de sitios que hablan del tema, libros, web de testimonios, blogs, etc. Si quiero informarme sobre la depredación que se está llevando en nuestros mares tengo data... quieres saber como es que el Micelio puede que sea un buen salvador del futuro, ahí tienes tus resultados. Por favor Casimiro, dime a quien está censurado...

Saludos,

Es que no tiene que censurar nada. No es ni polícia ni juez, debe ser absolutamente neutral en las webs. Si hay algo ilegal o prohibido tendrán que ser los jueces quienes dictaminen si debe cerrarse una web, pero no es algo que corresponda decidir a google, ni a ninguna otra empresa que ofrece servicios de ese tipo.
¿Por qué no iban a ofrecer resultados de softonic?

Pues a mi me sorprende lo de delphi. ¿En qué sentido es competencia para Google? Además de que nunca he notado que haya censura al respecto; al menos siempre he encontrado enlaces a muchos sitios que hablan de delphi. Claro, mi consulta regularmente incluye la palabra delphi. Ojalá Al nos pueda aclarar a lo que se refiere.

Por otra parte, no entiendo esto:

Desde luego así debería ser, pero en la realidad, no puedes estar por encima de la ley. ¿No hay acaso una ridícula ley del derecho al olvido? Google está obligado a cumplirla en los países donde se aplica.

Y bueno, aunque a mi también me parece que Google no es un corderito, creo que tampoco podemos caer en la visión de que es el nuevo Microsoft, culpable de todos los males ;)

LineComment Saludos

Por supuesto, no es como microsoft, menos mal :rolleyes:

Si te soy sincero, siento que vivimos en la era de la posverdad. Ya no sé en qué creer.