Hace unos meses que tengo pendiente comentar un poco los ensayos de Jack W. Reeves: Code as Design.
Se trata de unos textos realmente valiosos dada su relevancia a lo largo de dos décadas (el primero fue publicado inicialmente en 1992) y por la peculiaridad de que la idea fue revisada 13 años después. Pero además es decepcionante ver como aun hay muchos profesionales del sector que no tienen claro lo que comentaba Reeves ni nada remotamente parecido.
La idea central que plantea Reeves es simple en su formulación: el desarrollo de software es un proceso de diseño. Pero esa simpleza oculta multitud de ideas interesantes y de prejuicios dentro y fuera del sector que llevan a considerar al programador como un obrero más. Y así nos va.
Esa idea nos lleva a plantear la obligatoriedad de que los cambios de requisitos deberían ser caros. Y que los desarrolladores ni son albañiles, ni son intercambiables como les gusta pensar a las grandes consultoras. O que el presupuesto cerrado a la hora de entregar un software es una estupidez de base. Pero como es un ensayo corto y discutido a lo largo de 20 años, creo que será mejor que cada uno lo lea (es corto) y juzgue por sí mismo.
A continuación para tratar de animar a los mas perezosos a leerse los ensayos, pongo algunas citas interesantes:
The Unpredictability of Requirements
There's a refrain I've heard on every problem project I've run into. The developers come to me and say "the problem with this project is that the requirements are always changing". The thing I find surprising about this situation is that anyone is surprised by it. In building business software requirements changes are the norm, the question is what we do about it.
One route is to treat changing requirements as the result of poor requirements engineering. The idea behind requirements engineering is to get a fully understood picture of the requirements before you begin building the software, get a customer sign-off to these requirements, and then set up procedures that limit requirements changes after the sign-off.
One problem with this is that just trying to understand the options for requirements is tough. It's even tougher because the development organization usually doesn't provide cost information on the requirements. You end up being in the situation where you may have some desire for a sun roof on your car, but the salesman can't tell you if it adds $10 to the cost of the car, or $10,000. Without much idea of the cost, how can you figure out whether you want to pay for that sunroof?
Estimation is hard for many reasons. Part of it is that software development is a design activity, and thus hard to plan and cost. Part of it is that the basic materials keep changing rapidly. Part of it is that so much depends on which individual people are involved, and individuals are hard to predict and quantify.
Software's intangible nature also cuts in. It's very difficult to see what value a software feature has until you use it for real. Only when you use an early version of some software do you really begin to understand what features are valuable and what parts are not.
This leads to the ironic point that people expect that requirements should be changeable. After all software is supposed to be soft. So not just are requirements changeable, they ought to be changeable. It takes a lot of energy to get customers of software to fix requirements. It's even worse if they've ever dabbled in software development themselves, because then they "know" that software is easy to change.
But even if you could settle all that and really could get an accurate and stable set of requirements you're probably still doomed. In today's economy the fundamental business forces are changing the value of software features too rapidly. What might be a good set of requirements now, is not a good set in six months time. Even if the customers can fix their requirements, the business world isn't going to stop for them. And many changes in the business world are completely unpredictable: anyone who says otherwise is either lying, or has already made a billion on stock market trading.
Everything else in software development depends on the requirements. If you cannot get stable requirements you cannot get a predictable plan.
En serio. Si no lo has leído, léelo ya.
No hay comentarios:
Publicar un comentario