ABRACEMOS LA PROGRAMACIÓN EXTREMA... ¿O NO? PRINCIPIOS BÁSICOS (III)
- Retroalimentación rápida: vamos, que reaccionemos cuanto antes.
- Asumir simplicidad: tal y como escribí en mi post anterior, es la parte que menos clara tengo. Quizá soy un ingeniero de sw "de los de antes", que da mucha importancia a la reutilización, y al dejar las cosas preparadas para posibles cambios futuros. Es cierto que esta filosofía conlleva más trabajo, y quizá la mayor parte de los desarrollos no lo requieran, pero también es tarea del ingeniero la de saber cuál es el nivel de complejidad que la herramienta va a requerir.
- Cambio incremental: con esto tengo que estar de acuerdo. Llevo años aplicado el Proceso Unificado, que se basa también en esto.
- Abrazar el cambio: ¿dónde está mi queso? ;)
- Trabajo de calidad: aquí sí creo que el "pair programming" ayuda. Aún dando por hecho que todos queremos hacer un trabajo de calidad -y habría que discutirlo en algunos casos-, desde luego, a nadie le gusta hacer el ridículo delante de un compañero. Esta situación nos obliga a sacar lo mejor de nosotros mismos.
Sin embargo, hay veces que el trabajo de dos en dos dificulta o coharta ese tiempo de reflexión que algunos necesitamos para llegar un poco más lejos.
Otros principios que se citan en el libro son, entre otros:
- Juega para ganar: en la universidad yo siempre decía lo mismo: me presento al examen para sacar un 10. Es la única manera de, salga lo que salga, salir orgulloso, y, desde luego, la única de poder ganar. Kent Beck habla de baloncesto, del equipo de UCLA de John Wooden. Si alguna vez habéis jugado a un deporte de equipo, sabéis lo que significa llegar a los segundos finales y "saber" que ese partido lo ganais, o tirar con tres tíos defendiéndote y "saber" que ese balón entra en el aro sin tener que comprobarlo.
- Aceptación de responsabilidad: bueno, esto no es nuevo, ya existe desde hace años en
el código ético del IEEE.
Sin duda la mayor parte de los profesionales del sw son sinceros, y aceptan sus errores. ¿Pero todo el mundo es así? ¿Cómo minimizar ese número?
- Retroalimentación rápida: vamos, que reaccionemos cuanto antes.
- Asumir simplicidad: tal y como escribí en mi post anterior, es la parte que menos clara tengo. Quizá soy un ingeniero de sw "de los de antes", que da mucha importancia a la reutilización, y al dejar las cosas preparadas para posibles cambios futuros. Es cierto que esta filosofía conlleva más trabajo, y quizá la mayor parte de los desarrollos no lo requieran, pero también es tarea del ingeniero la de saber cuál es el nivel de complejidad que la herramienta va a requerir.
- Cambio incremental: con esto tengo que estar de acuerdo. Llevo años aplicado el Proceso Unificado, que se basa también en esto.
- Abrazar el cambio: ¿dónde está mi queso? ;)
- Trabajo de calidad: aquí sí creo que el "pair programming" ayuda. Aún dando por hecho que todos queremos hacer un trabajo de calidad -y habría que discutirlo en algunos casos-, desde luego, a nadie le gusta hacer el ridículo delante de un compañero. Esta situación nos obliga a sacar lo mejor de nosotros mismos.
Sin embargo, hay veces que el trabajo de dos en dos dificulta o coharta ese tiempo de reflexión que algunos necesitamos para llegar un poco más lejos.
Otros principios que se citan en el libro son, entre otros:
- Juega para ganar: en la universidad yo siempre decía lo mismo: me presento al examen para sacar un 10. Es la única manera de, salga lo que salga, salir orgulloso, y, desde luego, la única de poder ganar. Kent Beck habla de baloncesto, del equipo de UCLA de John Wooden. Si alguna vez habéis jugado a un deporte de equipo, sabéis lo que significa llegar a los segundos finales y "saber" que ese partido lo ganais, o tirar con tres tíos defendiéndote y "saber" que ese balón entra en el aro sin tener que comprobarlo.
- Aceptación de responsabilidad: bueno, esto no es nuevo, ya existe desde hace años en
el código ético del IEEE.
Sin duda la mayor parte de los profesionales del sw son sinceros, y aceptan sus errores. ¿Pero todo el mundo es así? ¿Cómo minimizar ese número?
Comments