|
10.10.2005 |
 Razón no le falta a la gestión formal de proyectos cuando afirma que la mayor eficiencia se consigue haciendo las cosas bien a la primera, sin generar re-codificación o re-diseño; y que la forma de lograrlo es partiendo de una descripción de requisitos detallada, sin excesivos TBD's (To Be Determined), y conduciendo el proyecto con una gestión de proyectos formal, sobre un plan pormenorizado.
Razón lo le falta a la gestión ágil de proyectos al afirmar que el ciclo de desarrollo lineal: requisitos - diseño - codificación- pruebas - integración y operación, es utópico por su rigidez.
"Aunque los requisitos (o los objetivos) normalmente cambian en las
fases iniciales del proyecto, hay un punto a partir del cual los
cambios resultan dañinos".
"Son
bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos ágiles se doblegan al cambio como ventaja
competitiva para el cliente".
Los primeros abogan por definir el diseño con detalle antes de comenzar la codificación. Los requisitos que llegan tarde al desarrollo requerirán posiblemente rehacer partes del diseño, generando re-trabajo, dilataciones en los planes iniciales y pérdida de eficiencia.
Para los segundos, conocer el alcande completo de los requisitos en las fases iniciales del proyecto es una utopía. Por esta razón trabajan desarrollando y mejorando el diseño de forma paulatina, y a la par de la codificación a través de iteraciones breves y sucesivas.
La refactorización es uno de los principios fundamentales de Programación Extrema
"El objetivo, por el contrario, es mejorar la facilidad de comprensión del código o cambiar su estructura y diseño y eliminar código muerto, para facilitar el mantenimiento en el futuro"
Wikipedia.
Ken Pugh acaba de publicar "Prefactoring" donde propone una solución inteligente que comparte ambos principios:
- El re-trabajo resulta ineficaz y alarga las agendas. Lo mejor es hacerlo bien a la primera.
- No es posible conocer los requisitos detallados al principio del proyecto. Los principios ágiles de iteraciones frecuentes y descubrimiento paulatino son una buena aproximación.
La solución: "Prefactorización".
Ken Pugh define en su libro:
"El arte de la prefactorización aplica en el desarrollo de nuevos proyectos de software las enseñanzas cosechadas por las experiencias".
"Este libro establece directrices de prefactorización en el diseño, la codificación y las pruebas. La aplicación de las pautas de este libro no le garantiza el que nunca vaya a necesitar refactorizar el diseño o el código. Sin embargo podrá reducir el trabajo de refactorización."
La obra plantea y desarrolla un sistema para una tienda de alquiler de CD's, siguiendo un proceso ágil con iteraciones de desarrollo frecuentes. Durante la exposición se muestran las situaciones típicas, especialmente en la comunicación con los clientes.
El sistema se comienza con un conjunto de requisitos expresados como casos de uso. Los detalles de cada uno se irán conociendo conforme avanza el desarrollo.
"A preliminary analysis of the entire system is performed and an overall architecture is formed. The overall architecture is the big picture. It does not contain every detail of every class. After filling in the details for the first set of requirements, the solution is designed in detail and implemented. For waterfall programmers, it might seem as though we are coding too early. For extreme programmers, this might seem like overanalysis. I prefer such an intermediate approach. It is important to deliver a working system to the user early in the development cycle, but the system should fit into the overall solution to the problem."
La prefactorización se basa en llevar al "extremo" 3 principios:
- Abstracción
- Separación de las responsabilidades
- Legibilidad
"If abstraction is good, Extreme Abstraction is better; if separation of concerns is good, Extreme Separation is better; and if readability is good, Extreme Readability is better."
 |
RSS de los comentarios
