Bueno, parece que últimamente las malas son las metodologías tradicionales y las buenas son las metodologías ágiles, pero a fin de cuentas, ambas son metodologías y las metodologías, en general, presentan sus problemas. ¿Por qué?. Este artículo de Joel on Software nos da la respuesta.
Un cocinero excepcional hace lo siguiente:
Ahora bien, el Chef Desnudo no sigue ningún apestoso Manual de Operaciones. No mide nada. Mientras esta cocinando, usted ve un frenesí de comida sacudida y siendo arrojada por aquí y allá. "Simplemente pondremos una pizca extra de romero por acá, que no lo arruinara, y le daremos una buena sacudida", dice el. "Amásenlo así. Perfecto. Solo espárzanlo por todos lados." (Si, de verdad se ve como si simplemente lo esparciera por todos lados.
es decir, una persona brillante (cocinero en este caso), no necesita seguir ninguna metodología ni medir nada para obtener un producto genial. ¿Por qué las metodologías?. Pues porque gente brillante hay poca y del resto hay un montón. Para conseguir que el resto de la gente haga un buen producto, la persona brillante escribe una serie de reglas para que la gente del montón sea capaz de hacer lo mismo que él … y eso no funciona. Si se hace, se tienen "Big Macs". El resumen del proceso es el que indica Joel on Software en el mismo artículo
1. Algunas cosas requieren de talento para hacerse realmente bien.
2. Es difícil tener talento a la medida.
3. Una forma en que la gente intenta igualar el talento es haciendo que el talentoso cree las reglas para que los menos talentosos las sigan.
4. La calidad del producto resultante es muy baja.
¿Y qué pasa con el software?. Pues más o menos lo mismo. Unas personas geniales escribieron unas metodologías para hacer buen software, sean las tradicionales, sea Scrum, sea TDD y el resto de los mortales tratamos de seguirlas. ¿Y qué pasa?. Pues cosas como esta
- "Scrum no nos gusta por la reunión diaria de 90 minutos" http://www.dosideas.com/noticias/metodologias/917-scrum-diario-efectivo.html
- "Hacer TDD mal es más costoso que no hacerlo" http://geeks.ms/blogs/lontivero/archive/2009/09/28/unit-tests-contras-de-implementar-test-unitarios.aspx
- etc, etc.
Total, que para hacer bien Scrum o hacer bien TDD o cualquier otra de las metodologías ágiles hay que hacer un cambio importante de mentalidad, ser bueno en muchas materias incluido como programador, tener mucho sentido común, etc, etc.
Y digo yo… la persona que cumple todo eso y puede hacer realmente bien TDD/Scrum/metodologías ágiles… ¿necesita realmente hacer todo eso?. Estoy totalmente convencido que un programador genial es totalmente capaz de hacer un muy buen software sin preocuparse en absoluto por ninguna metodología concreta, sino siguiendo simplemente su intuición. Y estoy convencido que el resto de los mortales estamos predestinados a hacer mal software directamente o hacer mal software después de haber seguido deficientemente una metodología ágil.
A pesar de todo, es mejor seguir una metodología que ninguna. Imagina en el McDonalds si cada uno se hace los BigMac de cualquier manera. Pero aunque lo he dicho muchas veces, me reitero. Si se quiere un buen software que destaque, el punto más importante a tener en cuenta es elegir a los mejores programadores.
Estoy de acuerdo, hay programadores y chef’s natos pero te haz olvidado de los que se forman.
Bueno aun no sé si este articulo viene desde tu punto de vista personal o basado literalmente en el que mencionas, pero no hay que olvidar que hay personas que en base a la experiencia mucha experiencia se forman como buenos profesionales.
Pingback: Tweets that mention Diario de Programación » Blog Archive » Metodologías ágiles y tradicionales. ¿De verdad sirven para algo? -- Topsy.com
Hola:
Es mi experiencia, al final he visto que da igual qué se haga o como se haga, las personas que valen, lo hacen bien, las que no valen, lo hacen mal. Posiblemente mañana o pasado ponga un post que tengo en mente con un ejemplo sobre el tema.
Desde luego, la experiencia es un grado y los errores de novato los cometemos todos al principio. Pero desgraciadamente, en este mundo de software es muy difícil encontrar programadores con muchos años de experiencia, enseguida los hacen jefe de algo y dejan de programar. Los programadores con muchos años de experiencia… ¿sabes quienes son? .. pues sí, precisamente esos, a los que les encanta y han nacido para hacer software.
Se bueno.
ese chuidiang esceptico y pragmatico, a prueba de modas y fuegos artificiales! el otro dia coincidimos en un articulo http://www.programania.net/desarrollo-agil/lo-que-los-gurus-nunca-te-cuentan-sobre-kanban-y-scrum/
en el que me preguntaba lo mismo (nadie me contesto claro) … si para llevar a cabo una metodologia necesito a una cuadrilla de programadores geniales tal vez no necesite la metodologia sino a la cuadrilla de programadores
Je, al final voy a pillar complejo de «protestón». Me quejo de Grails, me quejo de las metodologías ágiles, …
Y sí, según pasa el tiempo y veo más programas y programadores, estoy más convencido de que lo que se necesita es la cuadrilla de programadores geniales.
Yo también soy de la opinión que con un buen equipo de desarrolladores, con «cualquier» metodología se puede llegar a tener un buen resultado.
Pero hay que tener en cuenta que las metodologías ágiles se supone que ponen énfasis en las personas(aunque a veces algunos supuestos «agilistas» caigan en el tópico de hablar re recursos…). Y una de las cosas que he vivido con metodologías tradcionales tipo cmmi, es que gente… digamos que no excesivamente brillante, conseguía escudarse tras los procesos. No sé, una de las cosas que creo más se destaca de las metodologías ágiles(o a mi me llama más la atención) es que saca a la luz, entre otras cosas, a la gente menos competente.
Como experiencia personal, con los equipos con los que he tenido oportunidad de trabajar o que he visto de cerca, los más inteligentes/capaces seguían/siguen prácticas ágiles, igual no scrum, kanban, tdd… a pies juntillas, pero sí adaptar partes de algunas de esas metodologías. Vamos, que para mi que gente a la que considero mucho más lista que yo, se acerque más a unas metodologías que a otras, es suficiente para convencerme por dónde está el camino a seguir 🙂
Espero no haber sonado a «evangelizador agilista», sólo es mi opinión 😉
Hola Dani:
Si tengo que elegir, yo también prefiero mil veces una metodología ágil a una tradicional. De hecho, en el trabajo, aunque no conseguimos ser realmente ágiles ni a tiros, sí hemos obtenido importantes mejoras intentándolo y por eso seguimos.
El problema es ese, que «intentamos» ser ágiles, pero no lo conseguimos. ¿Por qué?
– Porque es realmente difícil,
– porque cuando viene el cliente a una demo de sprint hoy te dice una cosa y en la siguiente te dice otra. Sí, ya sé que hay que acoger con alegría el cambio, pero a veces cuesta.
– porque hay gente que hace test o código que es mejor ni verlo.
– porque algún scrum master o propietario de producto tiende a ver las reuniones diarias como reuniones de «a ver quién es el que vaguea».
– porque por más que se planifique y ajusten planificaciones, cuesta un horror terminar el sprint en plazo.
– porque la gente tiende a coger las tareas de su tema, por lo que al final cada desarrollador tiende a trabajar aislado.
También tienes razón en que con una metodología ágil se ve enseguida quién es más torpe y los compañeros le ofrecen su ayuda más fácilmente en un grupo ágil, pero eso no hace que su código sea bueno y tarde poco en hacerlo, sino sólo un poco menos malo y que tarde algo menos. Y decir que no le quieres en el grupo es duro.
En fin, que no sabemos, los problemas son muchos y nos cuesta mucho conseguirlo, y la calidad del código resultante depende del que lo ha hecho. Los que antes lo hacían mal, siguen haciéndolo mal, los que antes lo hacían bien, ahora también lo hacen bien.
Se bueno.
Bueno esta claro que el problema con las metodologias anteriores es peor todavia. Pero las anteriores no estan pensadas para que las lleven a cabo buenos programadores sino «normales», que son justo los que mas pueden necesitar una metodologia. Creo que con un conjunto de programadores «buenos» y apasionados no hace falta una metodologia (con sus cursos, su marketing, sus gurus, sus certificaciones) asi que casi le veo menos sentido a una metodologia que te pone como condicion indispensable que tengas a un grupo de buenos programadores
Que no quiere decir que haya buenas ideas en el scrum,kanban, xp etcetc que se pueden utilizar siempre y cuando se adapten al contexto en el que desarrollas (grupo de programdores, tipo de cliente, tipo de aplicacion etcetc)
Todo tiene un origen, unos nacen en ambientes que favorecen su vocación(programadores) y otros tienen que esforzarse para adaptar su ambiente a su vocación, todo ello en el caso que ames tu vocación.
A buen chef aprendió habilidades en su comienzo, a partir de esas habilidades creo nuevas que lo llevaron a no depender tanto de las primeras.
Las metodologías ágiles son abstracciones del sentido común de aquellas personas que aman su trabajo, eso no quiere decir que sean las únicas y que siempre tendremos que aplicarlas, cada mente puede generar nuevas metodologías e incluso mejorarlas y eso lo hará diferente a los demás.
La única cosa que no varia en todas las mentes brillantes, es que aman lo que hacen y tratan de compartirlo para generar nuevas mentes brillantes.
De forma que cuando amas algo, evolucionas en base a ideas de otros que te ayudan a generar tus propias ideas.
Así que todos dependemos de alguna u otra forma de algo, dependemos hasta de nosotros mismo xD.
Pues tienes razón de nuevo. Los que son buenos son buenos desde un comienzo, así como los lideres.
Que mal que no se pueda replicar los comentarios o citar con un clic.
Pingback: de la red – 2/07/2010 « Tecnologías y su contexto
Pingback: Linux Hispano | Lo mejor de mi RSS del 28 de junio al 4 de julio
Jejeje el desarrollo de sistemas de información no es una receta, no somos cocineros ni artesanos, creamos soluciones para problemas concretos y no ´para paladares exijentes o mediocres o como sea, creo que la analogía no es valida, la computación y la ingeniería de software distan bastante de la cocina, solo es una excusa para la pereza y la reducción de costos, si aplicando metodologias hay caos, no quiero imaginar como sería todo sin ellas
Bueno, la comparación sería entre usar metodologías con programadores mediocres o no usar metodologías con programadores geniales dejándolos a su aire (que no quiere decir que vayan descoordinados, sino que se les dejaría coordinarse como quisieran).
Yo creo que se obtienen mejores resultados de la segunda forma, al igual que un cocinero genial obtiene mejor comida inventando la comida sobre la marcha que un cocinero mediocre obtiene una comida mediocre siguiendo una receta a rajatabla.
Se bueno.
Lo importante es que estas programando, para que sirve,y el resultado, la metodologia es para realizar el camino mas facil.
Tienes que cruzar un valle, es mas facil ir por el camino,donde vas es lo mas importante.
Por experiencia podría decir que dependiendo del tipo de proyecto varia el tipo de metodología que convenga aplicar.
Por ejemplo en aplicaciones que no requieren inovacion ni meter tecnologias nuevas, pero que necesiten ser muy estables y mantenibles, se obtienen buenos resultados aplicando metodologias que se orienten en el modelado.
En cambio, en proyectos que requieran implementar muchas tecnologías experimentales y el cliente tenga mas tolerancia a fallos a cambio de tiempos de entrega mas cortos, yo optaría por una metodología ágil.
En todo caso cuando te topas con programadores gurus (o divas) suelen tolerar mas metodologías ágiles o incluso ninguna metodología. En ese caso tendrás un producto entregable en un tiempo muy corto pero el costo del mantenimiento se suele disparar horrores.