ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? VALORES (II)
El capítulo 7 se centra en los cuatro Valores fundamentales de XP:
1. Comunicación: totalmente de acuerdo. Soy un defensor de las habilidades emocionales en la formación de un ingeniero o, en este caso, de un desarrollador. No dejan de ser elementos de un equipo, y los equipos funcionan con comunicación.
2. Simplicidad: este valor me da miedo. Aun creyendo en la simplicidad dentro de un diseño, veo dos problemas -sin meternos en tecnicismos-:
- ¿Cómo conseguir que el equipo completo entienda de la misma manera este concepto? Lo que para un es "simplificar", para otro es no comprender la complejidad del sistema.
- La filosofía "lazy" adoptada me puede resultar peligrosa cuando se trata de crear frameworks. Obviamente "simplicidad" no significa lo mismo en este ámbito que en el de una aplicación ad-hoc, pero ¿cómo simplificar en un desarrollo que busca ser lo más generalista posible?
3. Retroalimentación: sin duda. Se basa sobre todo en la realización constante de pruebas -de unidad, funcionales, etc.- y casos de prueba.
4. Coraje: igual que en el segundo valor, ¿qué significa coraje cuando cada componente del equipo lo entiende de diferente forma?
Y el quinto: el respeto. Ahí sí que me han dado. Ojalá existiera ese respeto en todos los proyectos, desde los grandes proyectos de decenas de personas, hasta los que involucran a tres o cuatro estudiantes de 4º de ingeniería informática...
El capítulo 7 se centra en los cuatro Valores fundamentales de XP:
1. Comunicación: totalmente de acuerdo. Soy un defensor de las habilidades emocionales en la formación de un ingeniero o, en este caso, de un desarrollador. No dejan de ser elementos de un equipo, y los equipos funcionan con comunicación.
2. Simplicidad: este valor me da miedo. Aun creyendo en la simplicidad dentro de un diseño, veo dos problemas -sin meternos en tecnicismos-:
- ¿Cómo conseguir que el equipo completo entienda de la misma manera este concepto? Lo que para un es "simplificar", para otro es no comprender la complejidad del sistema.
- La filosofía "lazy" adoptada me puede resultar peligrosa cuando se trata de crear frameworks. Obviamente "simplicidad" no significa lo mismo en este ámbito que en el de una aplicación ad-hoc, pero ¿cómo simplificar en un desarrollo que busca ser lo más generalista posible?
3. Retroalimentación: sin duda. Se basa sobre todo en la realización constante de pruebas -de unidad, funcionales, etc.- y casos de prueba.
4. Coraje: igual que en el segundo valor, ¿qué significa coraje cuando cada componente del equipo lo entiende de diferente forma?
Y el quinto: el respeto. Ahí sí que me han dado. Ojalá existiera ese respeto en todos los proyectos, desde los grandes proyectos de decenas de personas, hasta los que involucran a tres o cuatro estudiantes de 4º de ingeniería informática...
Comments