ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? PR�CTICAS (IV)
- Las prácticas de XP:
1. Planning Game: diálogo entre negocio y técnico. Sin duda uno de los puntos calientes, que no creo que ninguna metodologÃa pueda resolver, pues la gente de negocio no se atendrá a ello casi nunca -y esto no es echarles las culpas, sino que una metodologÃa no puede dictarles cómo comportarse-.
2. Pequeñas releases: poco que decir. El PU, el modelo en espiral de Boehm, ... lo plantean desde siempre. La idea es hacer las releases cortas, consistentes y estables.
3. Metáforas: entiendo que es lo más cercano a una mezcla entre requisitos funcionales y no funcionales, pero estructurados como la arquitectura del sistema.
4. Diseño simple: está en contra del dicho de diseñar con el futuro en mente. No digo que no pueda ser factible en muchas aplicaciones, pero ¿no corremos el riesgo de posicionarnos en el otro extremo?
5. Pruebas: nada que decir: probar, probar, probar.
6. Refactoring: modificación del código, y reestructuración posterior para ver si es posible simplificarlo tras el cambio. No soy un experto en refactorización, apenas he tenido que hacerlo "en serio" un par de veces o tres. Queda pendiente la lectura del libro de Martin Fowler Refactoring: improving the design of existing code.
7. Pair programming: ya lo he comentado en un post anterior: pair programming, sÃ, pero con "minutos de soledad", como cuando vives en pareja ;)
8. Pertenencia colectiva: me parece perfecto, pero eso obliga a utilizar el estado del arte de las herramientas de gestión de versiones.
9. Integración continua: esto lo he podido comprobar de primera mano en un gran proyecto realizado hace unos años, y, de verdad, ¡funciona! Aunque, tal y como dice Beck, suele obligar a tener una máquina de integración dedicada, debido a la gran cantidad de checkins-checkouts-integraciones que se realizan al dÃa.
10. Semanas de 40 horas: jajajajajajajajajajajajajajajajajajajajajajajajajaja!!!!!! Seamos realistas. Estamos de acuerdo en que una cosa es un "pico", y otra una "meseta"=conjunto de picos continuos. Pero esto no lo va a cambiar XP, me temo.
11. Cliente al lado: me parece una gran idea, que jamás he visto en serio. O el cliente no tiene tiempo para estar "ahà contigo", o tú no lo quieres "ahà contigo".
12. Estándares de codificación: mi duda -y lo es de verdad- es si hay o habrá estándares oficiales y mundialmente reconocidos de codificación para cada lenguaje de programación.
Mi impresión es que es un "mix" de ideas muy bien pensadas y valoradas, junto a una lista de deseos que, de vez en cuando, se cumplen.
- Las prácticas de XP:
1. Planning Game: diálogo entre negocio y técnico. Sin duda uno de los puntos calientes, que no creo que ninguna metodologÃa pueda resolver, pues la gente de negocio no se atendrá a ello casi nunca -y esto no es echarles las culpas, sino que una metodologÃa no puede dictarles cómo comportarse-.
2. Pequeñas releases: poco que decir. El PU, el modelo en espiral de Boehm, ... lo plantean desde siempre. La idea es hacer las releases cortas, consistentes y estables.
3. Metáforas: entiendo que es lo más cercano a una mezcla entre requisitos funcionales y no funcionales, pero estructurados como la arquitectura del sistema.
4. Diseño simple: está en contra del dicho de diseñar con el futuro en mente. No digo que no pueda ser factible en muchas aplicaciones, pero ¿no corremos el riesgo de posicionarnos en el otro extremo?
5. Pruebas: nada que decir: probar, probar, probar.
6. Refactoring: modificación del código, y reestructuración posterior para ver si es posible simplificarlo tras el cambio. No soy un experto en refactorización, apenas he tenido que hacerlo "en serio" un par de veces o tres. Queda pendiente la lectura del libro de Martin Fowler Refactoring: improving the design of existing code.
7. Pair programming: ya lo he comentado en un post anterior: pair programming, sÃ, pero con "minutos de soledad", como cuando vives en pareja ;)
8. Pertenencia colectiva: me parece perfecto, pero eso obliga a utilizar el estado del arte de las herramientas de gestión de versiones.
9. Integración continua: esto lo he podido comprobar de primera mano en un gran proyecto realizado hace unos años, y, de verdad, ¡funciona! Aunque, tal y como dice Beck, suele obligar a tener una máquina de integración dedicada, debido a la gran cantidad de checkins-checkouts-integraciones que se realizan al dÃa.
10. Semanas de 40 horas: jajajajajajajajajajajajajajajajajajajajajajajajajaja!!!!!! Seamos realistas. Estamos de acuerdo en que una cosa es un "pico", y otra una "meseta"=conjunto de picos continuos. Pero esto no lo va a cambiar XP, me temo.
11. Cliente al lado: me parece una gran idea, que jamás he visto en serio. O el cliente no tiene tiempo para estar "ahà contigo", o tú no lo quieres "ahà contigo".
12. Estándares de codificación: mi duda -y lo es de verdad- es si hay o habrá estándares oficiales y mundialmente reconocidos de codificación para cada lenguaje de programación.
Mi impresión es que es un "mix" de ideas muy bien pensadas y valoradas, junto a una lista de deseos que, de vez en cuando, se cumplen.
Comments