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

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

SIGUIENTE ARTÍCULO

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.