Mes: julio 2007

Este artículo fue publicado anteriormente en dotNetmania.

Realizar estimaciones es uno de los más complejos problemas de los varios que los desarrolladores de software enfrentamos día a día. Además es uno que históricamente hemos fallado a la hora de resolver. Por eso precisamente es esta la cuestión que he elegido para mi primera participación en esta columna.

Aprovecho también para comentar que no pretendo dar desde estas páginas soluciones concretas, más que nada porque, en mi opinión, en el desarrollo de software no existen recetas universales, sino mover a la gente que la lea a pensar de otra manera, de una manera ágil, en los problemas que nos encontramos día a día cuando tratamos de desarrollar software.

Voy a hablar, en la presente entrega, sobre que armas hemos utilizado tradicionalmente los desarrolladores a la hora de realizar estimaciones, de cómo este es un problema complejo, quizás irresoluble, y de cómo las metodologías ágiles los asumen y conviven con ello. Pero antes de nada me gustaría dejar claro, una vez más, que en este tema, quizás más que en ningún otro, la única verdad absoluta es que ha quedado totalmente demostrado que no existen balas de plata.

Hagamos un repaso de cómo se ha enfrentado el problema de la estimación hasta ahora y que ventajas y problemas, a muy grandes rasgos, tiene cada aproximación.

Primero, se utilizo el juicio del experto. Es un enfoque simple y directo. Basta con buscar a un desarrollador que haya desarrollado un sistema lo más similar posible al que queremos estimar y que nos diga cuál es su estimación. Las pegas de esta aproximación son: Primero, que es difícil encontrar alguien que haya construido un sistema lo suficientemente similar como para obtener una buena estimación, se suelen desarrollar sistemas que no existen, si lo que necesita nuestro cliente ya existe es mejor que simplemente lo compre. Segundo, cada proyecto es un mundo. Cada proyecto evoluciona de un modo diferente, se desarrolla en un entorno diferente, con un equipo diferente, en una tecnología diferente. Luego es claro que el juicio del experto no es demasiado fiable. Además se trata de la voz de una única persona, lo que siempre introduce riesgos.

El siguiente paso fue abordar el problema desde un enfoque más ingenieril, más matemático. De aquí surgieron toda una serie de técnicas basadas en utilizar la matemáticas, como COCOMO y surgieron bastantes herramientas que implementaba este modelo. El problema es que descubrimos que alimentar de datos estas herramientas era demasiado costoso para obtener unos resultados que no era mucho más ajustados que el que se obtenían usando el juicio del experto.

La siguiente aproximación fue los puntos función. La idea es simple, utilizando datos históricos podemos evaluar lo que en nuestra empresa cuesta hacer un formulario o un informe, basándonos en lo que informes o formularios similares costaron anteriormente. Luego, a la hora de estimar un desarrollo, simplemente tendremos que multiplicar ese valor por el número de informes o formularios que tenemos. Pero resulto que aunque el método es simple y sin duda funciona, es muy difícil recopilar una cantidad significativa de datos fiables que soporten subsiguientes estimaciones. Recopilar estos datos es algo que exige tiempo, y en ese tiempo se producen cambios (tecnológicos, humanos u organizativos, por citar algunos) que invalida los datos anteriormente recogidos.

Es evidente que antes de la aparición de las herramientas RAD era mucho más complejo hacer un formulario o un informe, por poner un ejemplo fácilmente entendible.

Que estimar sea un problema difícil, no quiere decir que no sea un problema importante. Los desarrolladores tenemos una continua relación con las estimaciones: damos estimaciones, recibimos estimaciones y sufrimos estimaciones que gente equivocada, comerciales, gerentes, departamentos de marketing, etc, sin suficiente conocimiento del problema, hace por nosotros comprometiéndonos. Muchos problemas y riesgos habituales que aparecen en la gestión de los proyectos tienen que ver con una estimación deficiente. Es un problema que merece mucha de nuestra atención.

Pero no podemos obviar la relación que nuestra industria ha tenido con las estimaciones, la cruda realidad que todos vivimos: nunca se respetan y nunca son suficientemente ajustadas, da igual la técnica que usemos. Por lo tanto es muy importante a la hora de estimar no consumir demasiado tiempo. Al fin y al cabo, la fecha o el precio de proyecto probablemente ya se hayan fijado por motivos ajenos al desarrollo de software, mucho antes de que el equipo de desarrollo haya podido siquiera construir su estimación. Incluso, en muchos casos antes de que exista un equipo de desarrollo. Además las estimaciones se basan en los requisitos y los requisitos cambian constantemente o por lo menos, desde el planteamiento de las metodologías ágiles así lo asumimos.

Otro fenómeno claro que tendemos a olvidar, es que las estimaciones son muchísimo más fiables cuanto más información tenemos sobre las cuestiones que estamos estimando. En proyectos de desarrollo de software, generalmente esto es equivalente a decir que solo podemos tener estimaciones fiable sobre las parte del desarrollo que vamos a abordar en un futuro cercano. Con esto y con el principio de economía en mente (estimar tiene un coste alto, para el que buscamos una rentabilidad), las metodologías ágiles proponen solo estimar el futuro cercano y no poner demasiado esfuerzo en esa estimación. La idea subyacente es que realizar una estimación aporta mucho, pero que refinar mucho una estimación o utilizar métodos muy formales, generalmente costosos en cuanto a tiempo dedicado, no aporta tanto y sobre todo, no es económico desde el punto de vista de la relación entre esfuerzo y resultados. Resumiendo, estimar si, pero lo justo y solo en referencia al futuro cercano.

La siguiente pregunta es evidente, si estimar es inevitable y los métodos formales tradicionales exigen un esfuerzo que no tiene suficiente recompensa, ¿qué nos queda?. Una aproximación a la estimación que está ganando partidarios día a día es Wideband Delphi un proceso de estimación muy ligero y que obtiene unos resultados muy similares a procesos de estimación más pesados o complejos. El proceso es simple y no exige mucha preparación o formación previa.

• Se reúne unas cuantas personas (de dos a cinco). Idealmente se contará con personas que haya trabajado en aplicaciones similares y personas que no, es interesante contar con diferentes perspectivas.
  
• Cada persona contará con una descripción general de la cuestión a estimar y quien mejor la conozca expondrá de viva voz sus conocimientos sobre la misma.
  
• Cada persona presente en la reunión de estimación realizará y anotará su estimación sin colaborar con los demás. No se mostrará aun esta estimación al resto de participantes.
  
• Un facilitador revela los cálculos de manera anónima y seguidamente, tiene lugar un debate sobre las suposiciones en que se basan los cálculos. Quien lo desee puede revelar cual fue su estimación.
  
• El paso 3 se repite hasta que los cálculos converjan. Lo que se pretende es que cada persona aprende de los demás participantes, actualiza sus estimaciones y proporcione una nueva.

Existen varias variaciones sobre está técnica, por ejemplo hacer publicas las estimaciones de manera simultanea y que, para agilizar, solo los propietarios de estimaciones extremas, la más pesimista y la más optimista, debatan el por qué de sus estimaciones. Desde hace algún tiempo utilizo este método de estimación en un proyecto gestionado con Scrum para estimar y planificar cada uno de los Sprints, y la verdad es que tras el necesario proceso inicial de ajuste, puedo decir que esta funcionando excelentemente.

Hace unos días escribí sobre gestión del riesgo en Scrum. La gestión del riesgo siempre a sido una disciplina vital en la gestión de proyectos del software. Hasta el punto de que, incluso una de las metodologías más populares, MSF, hace de la gestión del riesgo una pieza central de la gestión del proyecto. Con idependencia de la metología usada todo gestor de proyectos responsable debe hacer una gestión del riesgo explicita. Todos hacemos una gestión del riesgo implicitamente en nuestros proyectos, pero hay una diferencia abismal entre esto y hacer una gestión del riesgo explicita. No todos los proyectos necesitan esta gestión explicita pero en los proyectos en lo que es necesaria es vital hacerla a fondo y hacerla bien. En gestión de riesgos está todo inventado, rara vez se ven avances, innovaciones o nueva documentación interesante. Hace ‘siglos’ que esta disciplina no cambia: detectar los riesgos, evaluarlos, priorizarlos, realizar un plan de mitigación y un plan de contingencia es algo sobradamente documentado y descrito en los textos típicos de gestión de proyectos.

Todos esto viene a cuento porque pululando por internet he encontando un compendio realmente espectacular de patrones relacionados con la gestión del riesgo. Se trata de una colección realmente útil a la hora de identificar y describir los riesgos que pueden acechar a nuestro proyecto. Conocer esta serie de patrones nos puede ayudar enormente a la hora de confeccionar una lista de riesgos y a la hora de plantear como lidiar con ellos.

Los que seguís este blog ya sabéis cuanto me gustán los patrones. La verdad es que los autores ha realizado un labor increible de recolección. Espero que disfruteís esta colección de patrones tanto como yo.

Leo una ‘noticia’ sobre la Campaña Iberoamericana contra OpenXML, el formato abierto de documento  de Microsoft. Nunca me gusta la postura de defender tu visión de las cosas atacando la del contrario. Y la verdad me parece que desde el software libre se está haciendo una política bastante torticera y mal intencionada con el tema de los estandares. No suelo escribir sobre estos temás, pero me parece importante. Explicaré porque.

Los estándares surgieron en el mundo industrial como una simple cuestión de economía. Era mucho más económico especificar tuercas estandar e intercambiables entre sí que utilizar en cada máquina construida una tuerca diferente. La clave es que la forma las tuercas que se usen no añaden valor al producto en el que se usan. El material de la tuerca si puede añadir valor, por eso en este aspecto no está cubierto por el estandar.

Por seguir con el ejemplo de las tuercas (serviría cualquier otro componente mecánico), decir que al contrário de lo que se pueda pensar existen muchos tipos de tuerca estándar: Métrica, Whitworth… Y es que en la industria no se ha hecho un uso ‘político’ de los estándares sino que se ha hecho un uso práctico. Cuando se plantea un estándar en industria lo que más peso tiene para su aceptación, dejando a parte la correción técnica que se suponen, es cual si se trata de la solución más extendida, es lo que se llama un estandar de facto. El estandar de facto a menudo se convertia en el estandar oficial, por una simple cuestión, nuevamente, de ahorro económico. Esto se está obviando en la industria del software y puede ser tremendamente dañino. Siguiendo los parametrós habituales el estandar debería ser el formato de documento de Microsoft, pues es con diferencia el más extendido, pero esto tampoco es buena idea, como comentaré más adelante.

Desde el mundo del software libre (más bien desde las empresas que se aprovechan de este movimiento, pero esto es otro tema), se están promoviendo formatos de documento que no soportan muchas características que el software de Microsoft tiene y que el software libre no tiene o no necesita: objetos incrustados, macros, compatibilidad hacia atrás… Y el único proposito final que se me ocurre para este moviento es dejar a Microsoft fuera del juego de los estandares y utilizar este hecho como arma para ganar mercado. La postura del software libre es egoista cuando menos. Supongamos que cuando se estandarizaron las tuercas, la tuerca Withworth, la más utilizada con diferencia, se hubiese quedado fuera de los estándares. La mitad de la industria hubiese estado fuera de los estandares perdiendose la oportunidad de que muchas empresas se aderiesen a ellos y viesen su enormes ventajas.

Y no nos engañemos, esto no va de estándares, va de Sun, RedHat, IBM y otras contra Microsoft. Al fin y al cabo ellos no tienen una posición fuerte en el mercado de generación de documentos y por tanto el formato que se decida les importa poco, sea cual sea tendrán que implementarlo. Sin embargo Microsoft si tiene un formato de documentos ya funcionando a pleno rendimiento, y sobre todo popular. Y lo mejor que le puede ocurrir a un estandar es que sea popular, por eso tradicionalmente los estandares de facto se han convertido en el estandar oficial. Sin embargo por cuestiones polítcas o de fe, se nos está tratando de convencer de lo contrario y de paso, si se llevan el gato al agua, dejar al 90% del mercado fuera de los estandares.

Otro hecho evidente es que el formato de documento es algo con lo que se puede añadir valor a un producto. Y por tanto algo que puedes usar para competir con tus rivales. Un formato de documento puede ser claramente superior a otro (más compacto, con más características, más facil de programar, más eficiente de transmitir, soportar o no versionado, más sencillo, más flexible etc…). Una tuerca, un rodamiento, un muelle, no es suceptible de ser un elemento que añada valor añadido a un producto de manera significativa, un formato si (¿alguien tiene música en algo que no sea MP3?). Si una fresadora usa tuercas M o W, no es relevante, lo importante es como de buena es la fresadora. Hay estándares para tuercas, tornillos, rodamientos, muelles, latiguillos neumáticos, etc, pero no para las fresadoras ¿por qué?. La cuestión es que en industria se han estandarizado todos los aspectos que no aportan valor añadido, que no son subceptibles de inovación y que por lo tanto todo el mundo va a usar sin problemas pues no afecta a su competitividad de su empresa. Pero el formato de documento no es uno de estos elementos. El formato de documento es clave.

¿Quiere decir esto que estoy en contra de los estandarés de documentos? No. Creo que es muy importante que cualquiera pueda leer cualquier documento. Pero no creo que todos los documentos deban estar en un mismo formato. Los documentos deben estar en formatos públicos y extraodinariamente bien documentados, pero debe haber tantos estandares de documento como se quieran definir. Sino se corre el riesgo de dañar a empresas ya establecidas y lo que es más importante, dañar seriamente la competencia en algo que añade valor. No se puede pensar en construir un estandar y dejar fuera al principal jugador en el campo, pero menos aún se puede tratar de promover que el principal jugador no pueda llevar sus productos a un estandar. La solución no es un estandar de documento único, sino un estandar único que especifique el proceso de definir un estandar de documento. Debemos buscar que núnca haya un documento sin un estandar asociado, pero no es tan importante que todo documento siga el mismo estandar, si se logra mejor, pero no es imprescindible. No todas las fresadoras siguen un estandar, pero si todas tiene unos planos que siguen estándares.

Encorsetar a toda la industria en un estandar de documento es sin duda dañino. ¿Qué pasa si yo quiero, por el motivo que sea, que mi documento sea extremadamente pequeño, o extremadamente ràpido al cargarse, o estremadamente compatible hacia atrás, o legible si se habre con un simple editor de texto? En informatica optimizar un aspecto, supone a menudo dañar otro, por eso son necesarios varios estándares. Cada situación exige que se elija el estándar adecuado según las necesidades. Pero al mismo tiempo es necesario que cualquiera pueda implementar cualquier estándar, como maner de salvaguardar el derecho de acceso a la información por parte de su propietario.

Habrá quien diga que tener varios estandares va a dañar el propio principio fundamental de tener un estandar, y en cierto modo es verdad. Pero sinceramente entre dañar la competencia y dañar los estandares me quedo con esto último. Siempre que se daña la competencia lo que se daña es el bolsillo del consumidor.

Resumiendo, el formato de documento es algo que añade valor a un producto y por tanto algo que no debe ser estandarizado de un único modo.

Termino proponiendo que si veís las cosas como yo firméis a favor del formato de documento de Microsoft y difundaís este post.

Un saludo!