Cita:
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,