La Nueva Metodología

La inspiraci�n usual para las metodolog�as han sido disciplinas como las ingenier�as civil o mec�nica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qu� hay que construir y como deben juntarse estas cosas. Muchas decisiones de dise�o, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compa��a diferente, para ser construidos. Se supone que el proceso de la construcci�n seguir� los dibujos. En la pr�ctica los constructores se encuentran con algunos problemas, pero �stos son normalmente poco importantes.

Como los dibujos especifican las piezas y c�mo deben unirse, act�an como los fundamentos de un plan de construcci�n detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construcci�n razonablemente predecibles. Tambi�n dice en detalle c�mo deben hacer su trabajo las personas que participan en la construcci�n. Esto permite que la construcci�n requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual.

As� que lo que vemos aqu� son dos actividades fundamentalmente diferentes. El dise�o, qu� es dif�cil de predecir y requiere personal caro y creativo, y la construcci�n que es m�s f�cil de predecir. Una vez que tenemos el dise�o, podemos planear la construcci�n. Una vez que tenemos el plan de construcci�n, podemos ocuparnos de la construcci�n de una manera m�s predecible. En ingenier�a civil la construcci�n es mucho m�s costosa y tardada que el dise�o y la planeaci�n.

As� el acercamiento de muchas metodolog�as es: queremos un plan de trabajo predecible que pueda usar gente del m�s bajo nivel. Para hacerlo debemos separar el plan de la construcci�n. Por consiguiente necesitamos entender c�mo hacer el dise�o de software de modo que la construcci�n pueda ser sencilla una vez que el plan est� hecho.

�Qu� forma toma este plan? Para muchos, �ste es el papel de notaciones de dise�o como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construcci�n y entonces podemos dar planes a los programadores como una actividad de construcci�n.

Pero aqu� surgen preguntas cruciales. �Es posible armar un plan que sea capaz de convertir el c�digo en una actividad de construcci�n predecible? Y en tal caso, �es la construcci�n suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?

Todos esto trae a la mente m�s preguntas. La primera es la cuesti�n de cu�n dif�cil es conseguir un dise�o UML en un estado que pueda entregarse a los programadores. El problema con un dise�o tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programaci�n. Los modelos que los ingenieros civiles usan est� basado en muchos a�os de pr�ctica guardados en c�digos ingenieriles. Adem�s los problemas importantes, como el modo en que juegan las fuerzas, son d�ciles al an�lisis matem�tico. La �nica verificaci�n que podemos hacer con los diagramas UML es la revisi�n cuidadosa. Mientras esto es �til trae errores al dise�o que s�lo se descubren durante la codificaci�n y pruebas. Incluso los dise�adores experimentados, como me considero a m� mismo, nos sorprendemos a menudo cuando convertimos dichos dise�os en software.

Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcci�n. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. McConnell sugiere que para un proyecto grande, s�lo 15% del proyecto son c�digo y pruebas unitarias, una inversi�n casi perfecta de las proporciones de la construcci�n del puente. Aun cuando se consideren las pruebas parte de la construcci�n, el plan es todav�a 50% del total. Esto genera una pregunta importante sobre la naturaleza del dise�o en software comparado con su papel en otras ramas de la ingenier�a.

Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el c�digo fuente es un documento de dise�o y que la fase de construcci�n est� en realidad en la compilaci�n y el ligado. De hecho cualquier cosa que pueda tratarse como construcci�n puede y debe automatizarse.

Estas ideas llevan a algunas conclusiones importantes:

  • En software la construcci�n es tan barata que es casi gratis.
  • En software todo el esfuerzo est� en el dise�o, de modo que requiere de personas creativas y talentosas.
  • Los procesos creativos no se planean f�cilmente, de modo que la previsibilidad bien puede ser una meta imposible.
  • Debemos ser muy cautos al usar la met�fora de la ingenier�a tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente.

.�La Impredecibilidad de los Requisitos

Hay un dicho que oigo en cada proyecto problem�tico con que me he encontrado. Los desarrolladores vienen y me dicen "el problema con este proyecto es que los requisitos cambian todo el tiempo". Lo que yo encuentro sorprendente sobre esta situaci�n es que sorprenda a cualquiera. En el negocio de construcci�n de software los cambios en los requisitos son la norma, la pregunta es qu� hacemos al respecto.

Una forma es tratar los requisitos cambiantes como el resultado de una pobre ingenier�a de requisitos. La idea detr�s de la ingenier�a de requisitos es conseguir un cuadro totalmente entendido de los requisitos antes de empezar a construir el software, conseguir la firma del cliente sobre estos requisitos, y entonces preparar procedimientos que limiten los cambios de requisitos despu�s de la firma.

Un problema con esto es que simplemente tratar de entender las opciones para los requisitos es duro. Es aun m�s duro porque la organizaci�n del desarrollo normalmente no proporciona la informaci�n del costo en los requisitos. Usted termina en la situaci�n d�nde quisiera tener un quemacocos en su autom�vil, pero el vendedor no puede decirle si agrega 10 al costo del autom�vil, o 10,000. Sin una buena idea del costo, �c�mo puede usted decidir si quiere pagar por ese quemacocos?

La estimaci�n es dif�cil por muchas razones. En parte porque el desarrollo de software es una actividad de dise�o, dif�cil de planear y costar. En parte porque los materiales b�sicos cambian r�pidamente. En parte por lo mucho que depende de los individuos involucrados, y los individuos son dif�ciles de predecir y cuantificar.

La naturaleza intangible del software tambi�n afecta. Es muy dif�cil saber qu� valor aporta un rasgo de software hasta que se usa en realidad. S�lo cuando se usa realmente una versi�n temprana de alg�n software se empieza a entender cuales rasgos son valiosos y cuales no.

Esto lleva al punto ir�nico de que es de esperarse que los requisitos sean cambiables. Despu�s de todo se supone que el software es "suave". As� no s�lo son cambiables los requisitos, sino que deben de serlo. Toma mucha energ�a conseguir que los clientes de software corrijan los requisitos. Es aun peor si ellos han estando alguna vez en desarrollo de software, porque entonces "saben" que el software es f�cil de cambiar.

Pero aun cuando se pudiera controlar todo esto y realmente se pudiera conseguir un conjunto exacto y estable de requisitos, probablemente a�n no estamos a salvo. En la econom�a de hoy las fuerzas de negocios fundamentales cambian el valor de los rasgos de software demasiado r�pidamente. El que podr�a ser un buen conjunto de requisitos ahora, no ser� tan bueno en seis meses. Aun cuando el cliente pueda corregir sus requisitos, el mundo de negocios no va a detenerse por �l. Y muchos cambios en el mundo de negocios son completamente imprevisibles: cualquiera que diga otra cosa o est� mintiendo, o ya ha hecho mil millones en la bolsa de valores.

Casi todo en el desarrollo de software depende de los requisitos. Si no se pueden obtener requisitos estables no se puede obtener un plan predecible.

.��Es Imposible la Previsibilidad?

En general, no. Hay algunos desarrollos de software d�nde la previsibilidad es posible. Organizaciones como el grupo de software del transbordador espacial de la NASA son un ejemplo selecto donde el desarrollo de software puede ser predecible. Requiere mucha ceremonia, mucho tiempo, un equipo grande y requisitos estables. Hay proyectos por ah� que son transbordadores espaciales. Sin embargo no creo que el software comercial encaje en esa categor�a. Para �ste se necesita un tipo diferente de proceso.

Uno de los grandes peligros es pretender que se puede seguir un proceso predecible cuando no se puede. La gente que trabaja en metodolog�as no es buena en identificar condiciones l�mite: los lugares d�nde la metodolog�a pasa de apropiada en inapropiada. La mayor�a de los metodologistas quieren que sus metodolog�as sean usadas por todos, de modo que no entienden ni publican sus condiciones l�mite. Esto lleva a la gente a usar una metodolog�a en malas circunstancias, como usar una metodolog�a predictiva en una situaci�n imprevisible.

Hay una tentaci�n fuerte para hacer eso. La previsibilidad es una propiedad muy deseable. No obstante creer que se puede ser predecible cuando no se puede, lleva a situaciones en donde las personas construyen un plan temprano, y entonces no pueden manejar la situaci�n cuando el plan se cae en pedazos. Usted acaba viendo el plan y la realidad flotando aparte. Durante alg�n tiempo usted podr� pretender que el plan es v�lido. Pero en alg�n punto la deriva es demasiada y el plan se cae en pedazos. Normalmente la ca�da es dolorosa.

As� si usted est� en una situaci�n impredecible no puede usar una metodolog�a predictiva. �se es un golpe duro. Significa que tantos modelos para controlar proyectos, y muchos de los modelos para llevar la relaci�n con el cliente, ya no son ciertos. Los beneficios de la previsibilidad son tan grandes, que es dif�cil dejarlos ir. Como en tantos problemas la parte m�s dif�cil est� simplemente en comprender que el problema existe.

De cualquier modo dejar ir la previsibilidad no significa que hay que volver al caos ingobernable. M�s bien hace falta un proceso que pueda dar control sobre la imprevisibilidad. De eso se trata la adaptabilidad.

.�Controlando un Proceso Imprevisible - Iteraciones

�As� que c�mo nos controlamos en un mundo imprevisible? La parte m�s importante y dif�cil, es saber con precisi�n d�nde estamos. Necesitamos un mecanismo honesto de retroalimentaci�n que pueda decirnos con precisi�n cual es la situaci�n a intervalos frecuentes.

La llave para obtener esta retroalimentaci�n es el desarrollo iterativo. Esta no es una idea nueva. El desarrollo iterativo ha estado durante alg�n tiempo bajo muchos nombres: incremental, evolutivo, escenificado, espiral... muchos nombres. La clave del desarrollo iterativo es producir frecuentemente versiones que funcionen del sistema final que tengan un subconjunto de los rasgos requeridos. �stos sistemas son cortos en funcionalidad, pero por otra parte deben ser fieles a las demandas del sistema final. Deben ser totalmente integrados y tan cuidadosamente probados como una entrega final.

El punto es que no hay nada como un sistema probado, integrado para traer una dosis poderosa de realidad en cualquier proyecto. Los documentos pueden esconder toda clase de fallas. El c�digo no probado puede esconder bastantes defectos. Pero cuando las personas realmente se sientan delante de un sistema y trabajan con �l, entonces las fallas se vuelven aparentes: tanto las relativas a defectos como las relativas a los requisitos mal entendidos.

El desarrollo iterativo tambi�n tiene sentido en los procesos predictivos. Pero es esencial en los procesos adaptables porque un proceso adaptable necesita poder tratar con los cambios en los rasgos requeridos. Esto lleva a un estilo de planear donde los planes a largo plazo son muy fluidos, y los �nicos planes estables son a corto plazo hechos para una sola iteraci�n. El desarrollo iterativo da un fundamento firme en cada iteraci�n que puede usarse para basar los planes posteriores.

Una pregunta importante es cu�nto debe durar una iteraci�n. Diferentes personas dan respuestas diferentes. XP sugiere iteraciones de entre una y tres semanas. SCRUM sugiere un mes. Cristal estira aun m�s. La tendencia, de cualquier modo, es hacer cada iteraci�n tan corta como se pueda manejar. Esto proporciona la retroalimentaci�n m�s frecuente, as� que usted sabe m�s a menudo donde se encuentra.

.�El Cliente Adaptable

Este tipo de proceso adaptable requiere un tipo diferente de relaci�n con el cliente que las que se consideran a menudo, particularmente cuando el desarrollo es hecho por otra empresa. Cuando contrate una empresa separada para hacer el desarrollo del software, la mayor�a de los clientes preferir�n un contrato a precio fijo. D�gale a los desarrolladores lo que quieren, negocie, acepte una oferta, y entonces la carga queda en la empresa de desarrollo para construir el software.

Un contrato a precio fijo requiere requisitos estables y por tanto procesos predictivos. Los procesos adaptables y los requisitos inestables implican que no se puede trabajar con la noci�n usual de precio fijo. Tratar de encajar un modelo de precio fijo a un proceso adaptable acaba en una explosi�n muy dolorosa. La parte sucia de esta explosi�n es que el cliente queda herido tanto como la compa��a de desarrollo de software. Despu�s de todo el cliente no querr�a un software a menos que su negocio lo necesitara. Si no lo consigue su negocio sufre. As� aun cuando no pague nada a la compa��a de desarrollo, todav�a pierde. De hecho pierde m�s de lo que pagar�a por el software (�por qu� habr�a de pagar el software si el valor comercial de ese software fuera menor?).

De modo que hay peligro para ambos lados al firmar un contrato a precio fijo en condiciones d�nde un proceso predictivo no puede usarse. Esto significa que el cliente tiene que trabajar de otro modo.

Esto no significa que no se pueda fijar un presupuesto para software por adelantado. Lo que significa es que no se puede fijar el tiempo, precio y alcance. La manera �gil usual es fijar tiempo y precio y permitir que el alcance varie de manera controlada.

En un proceso adaptable el cliente tiene mucho control a escala fina sobre el proceso de desarrollo de software. A cada iteraci�n puede tanto verificar el progreso como alterar la direcci�n del desarrollo de software. Esto lleva a una relaci�n mucho m�s �ntima con los desarrolladores de software, una verdadera sociedad de trabajo. Este nivel de compromiso no es para cualquier organizaci�n cliente, ni para cualquier desarrollador de software; pero es esencial para lograr que un proceso adaptable funcione apropiadamente.

El beneficio importante para el cliente es un desarrollo de software mucho m�s sensible. Un sistema usable, aunque m�nimo, puede entrar en producci�n pronto. El cliente puede cambiar sus capacidades de acuerdo a los cambios en el negocio, y tambi�n aprender c�mo se usa el sistema en realidad.

Una pieza tan importante como �sta es una visibilidad mayor sobre el verdadero estado del proyecto. El problema con los procesos predictivos es que la calidad del proyecto se mide por la conformidad con el plan. Esto dificulta a la gente se�alar cuando la realidad y el plan divergen. El resultado com�n es un gran resbal�n m�s tarde en el calendario del proyecto. En un proyecto �gil hay un constante rehacer del plan con cada iteraci�n. Si las malas noticias est�n al acecho, tienden a aparecer m�s temprano, cuando aun se puede hacer algo al respecto. De hecho este control del riesgo es una ventaja clave del desarrollo iterativo. Los m�todos �giles van m�s all� manteniendo corta la duraci�n de la iteraci�n, pero tambi�n viendo estas variaciones como oportunidades.

Hay un aspecto importante en lo que constituye un proyecto exitoso. Un proyecto predictivo se mide a menudo por lo bien que coincide con el plan. Un proyecto que est� a tiempo y en costo es un �xito. Esta medida no tiene sentido en un ambiente �gil. Para el agilista la cuesti�n es el valor de negocio - que el cliente consiga un software m�s valioso que el costo que puso en �l. Un buen proyecto predictivo ir� de acuerdo al plan, un buen proyecto �gil construir� algo diferente y mejor que lo que se esperaba en el plan original.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP
ARTÍCULO ANTERIOR