Una fábula

(Imagen: El Greco - Fábula)

Érase una vez un proyecto de software, y como es muy común con los proyectos de software, estaba bastante atrasado.

A pesar de todas las horas extras que habían empleado Hugo y Paco- los desarrolladores- y las muchas horas extras que emplearían, terminar el proyecto en la fecha acordada parecía imposible. Y los programadores se lo dijeron a su Jefe:

- Jefe, sólamente trabajando 48 horas al día podríamos terminar esto a tiempo

El Jefe , que era el que había hecho la promesa de terminar al cliente, se puso a pensar como solucionar esta situación, dado que parte de su trabajo era quedar bien con el cliente. Fue entonces que tuvo una brillante idea:

- Muchachos, vamos a pedirles a Pepe y Toño que les den una mano.

Fue entonces que Pepe y Toño pasaron a formar parte del equipo de Hugo, Paco y el Jefe. Pepe y Toño eran programadores bastante capaces, pero dado que eran nuevos en el proyecto necesitaban cierta orientación para ponerse al corriente.

Por esto, Hugo se tomó un día en explicarles a Pepe y Toño en que consistiá la aplicación, y los problemas que ésta iba a solucionar. En ese día, hubiera podido avanzar el 20% de lo que faltaba por hacer, pero se dedico a ilustrar a Pepe y Toño.

Paco por otra parte, se tomo un día también para explicarles la arquitectura de la aplicación, los estándares que estaban siguiendo y las librerías que se estaban usando. De no haber tenido que hacer esto, hubiera avanzado un 30% más de los pendientes del proyecto.

Después de estos dos días de capacitación, Pepe y Toño se pusieron a programar. Pero como aún estaban frescos - y Hugo y Paco no eran buenos profesores- dejaron unos cuántos bugs que Hugo y Paco tuvieron que reparar. Esto les tomó un día a los dos, en el que hubieran construido el 50% de lo que necesitaban hacer si no hubieran tenido que reparar bugs.

Llegó la fecha prometida, y para sorpresa del Jefe, el proyecto todavía no estaba listo.

Moraleja: "Añadir mano de obra a un proyecto de software que se encuentre atrasado hace que se atrase aún más". Este es el enunciado de la Ley de Brooks para el desarrollo de Software, propuesta por Fred Brooks en su libro The Mythical Man Month (de 1975!! Desde entonces ya se sabe esto xD). Dicho de otra manera por el propio Brooks, "Nueve mujeres no pueden hacer un bebe en un mes". Casi todos los Jefes que conozco desconocen este principio, así que el objetivo de este post es educarlos xD. Pueden encontrar más en Wikipedia, o en este excelente artículo de Joel Spolsky

Los mandamientos del desarrollo de software

Buceando en la web me topé con el artículo "Frequently Forgottenn Fundamental Facts about Software Engineering" de Robert L. Glass, en las que el autor enumera los que él considera los "teoremas" básicos a tener en cuenta al momento de construir software, y que lamentablemente parece que nadie considera. El listado que menciona lo realizó en base a su experiencia profesional y muchas de los principios que menciona han sido violentados en mi compañía, y a veces por mi persona. Paso a enumerar los que me llamaron la atención, junto a unos apuntes de mi parte:

• Los buenos programadores son por lo general 30 veces mejores que los programadores mediocres. Dado esto, no se debe escatimar en los salarios de los programadores buenos, dado que siempre producen más de lo esperado

En una compañía en la que estuve, empezaron a reemplazar Analistas Programadores (gente con experiencia) por practicantes (novatos o "trainees"), bajo la excusa de reducir costos y aumentar la productividad -más programadores con menos presupuesto-. Lógicamente, un practicante demoraba 2 semanas en hacer lo que un AP podía hacer en un día, así que no creo que les haya resultado beneficioso.

• El uso de una nueva herramienta o técnica reduce la productividad de los programadores y la calidad del producto inicialmente. Se obtienen beneficios una vez superada la curva de aprendizaje.

El arquitecto de donde trabajo es bastante "creativo", y constantemente incluye nuevas tecnologías en las aplicaciones que desarrollamos. El documentarnos sobre la tecnología nos toma como una semana, y cuando nos ponemos a desarrollar definitivamente lo hacemos más lento que con tecnologías más familiares. Pero ver cosas nuevas siempre es divertido xD.

• El mejorar un atributo de calidad generalmente perjudica a otro atributo de calidad. Por ejemplo, el mejorar la eficiencia perjudica la flexibilidad a cambios de la aplicación.

Se me viene a la mente el uso de procedimientos almacenados en base de datos: disminuyen el tiempo de respuesta pero te hacen imposible el cambiar de DBMS. Como dicen por ahí, nada es gratis en la vida.

• La detección y solución de errores representan el 40% de los costos de desarrollo. Por eso es una de las fases más importantes del ciclo de vida del desarrollo.

Yo me arriesgaría a decir que hasta el 50% de los costos.

• De un software -que según un programador promedio ha sido exhaustivamente probado- sólamente se han ejecutado el 55%-60% de sus rutas lógicas. El soporte automático, como analizadores de cobertura, puede elevar este número a 85%-90%. Las pruebas al 100% son imposibles.

Es por esto que el personal de control de calidad no nos cae nada bien. Siempre salen con casos que uno nunca pensaba que se iban dar, y que generan un nada discreto mensaje de error. Aunque como se dice por acá, es mejor que lo vea un tester a que lo vea el usuario xD.

• El software siempre contiene defectos residuales, aún después del proceso de eliminación de errores más riguroso. El objetivo es minimizarlos en número y en severidad.

Y sobre todo, que aparezcan después que se haya terminado la garantía xD.

• Las mayoría de las tareas de desarrollo de software y de mantenimiento de software son las mismas- excepto por la tarea de mantenimiento adicional "Comprender el producto existente". Esta tarea es de suma importancia, y consume casi el 30% del tiempo de mantenimiento. Por esto, se puede decir que el mantenimiento es más difícil que el desarrollo de software.

Bastante cierto... no hay nada más difícil de entender que el código ajeno. Lo digo con conocimiento de causa, que sufrí 1 año dando mantenimiento a aplicaciones que parecían hechas por chimpancés.

• Cuando un proyecto pasa de requerimientos a diseño, la complejidad del proceso de solución produce una exploción de "requerimientos derivados". La lista de requerimientos de la fase de diseño es por lo general 50 veces mayor que la lista de requerimientos original.

Nos pasa todos los días, y ocasiona amanecidas y/o retrasos.

• La mayoría de estimaciones de software se desarrollan al inicio del ciclo de vida. Es decir, ocurren antes de la fase de requerimientos y por ende antes de comprender el problema. La estimación por lo general ocurre en el tiempo inapropiado.

Es por esto que los cronogramas de desarrollo son las artefactos más desatendidos e ignorados que conozco. Los hacen por protocolo, pero a la larga nadie los sigue (al menos en mi compañía). Tal vez cronogramas por iteración, como señala RUP, serían la solución.

Esos son los que me parecen más importantes, y creo que si los jefes de proyecto los leyeran nuestros días serían más llevaderos. A ver que opinan ustedes.

Recetario IBM 839

Este es otro post de Recetario, por lo que podrán inferir que ya obtuve la certificación IBM Certified Solution Designer - IBM Rational Unified Process V7.0. Una vez más, procedo a contarles lo que tuve que hacer para tener este diploma en mi colección.

Si es que son asiduos del blog ya sabrán que venía de obtener la IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2 y me encontraba en búsqueda de otra certificación con orientación a Ingeniería de Software y no tanto a Programación. Había pensado en un momento en la Certified ScrumMaster, pero para obtenerla es requisito haber asistido a un curso -bastante caro- antes de poder de dar el examen; así que mejor opté por la muy accesible certificación RUP de IBM: Un sólo examen y sin pre-requisitos.

Había visto un poco de RUP en la universidad, pero eso fue hace muchos años y mi memoria es bastante frágil, así que el primer paso era conseguirme un libro que refresque esos conocimientos que creía ya perdidos. Buceando en Amazon me topé con The Rational Unified Process: An Introduction de Philippe Kruchten, que viene a ser una guía para principiantes -o para jefes de proyecto, según se vea xD- del proceso RUP. Me leí hasta la última página del libro, y creyéndome ya un Dios en RUP me dispuse a probar suerte con los mocks de Elite Certify, solamente para fracasar y darme cuenta que aún faltaba mucho por leer.

Probando con los mocks me di cuenta que el contenido de las disciplinas de RUP (o sea, lo que había visto en la universidad y lo que había leído en el libro de Kruchten) es sólamente una pequeña parte del examen, y que más de la mitad del mismo trata sobre elementos del proceso y de temas de desarrollo iterativo. Recurrí entonces al material del curso IBM Essentials of the Rational Unified Process V7.0, que ya trataba más a detalle el desarrollo iterativo y los work products del proceso pero aún obviaba los elementos del método y del proceso, por lo que seguía reprobando los mocks que intentaba resolver.

La solución una vez más vino de los amigos de Javaranch. Un forista que ya había obtenido la certificación recomendaba la web de Hans Admiraal, así que de curioso fui a echarle una ojeada. Hans es un consultor especializado en RUP, y ofrece entrenamiento -lógicamente a un costo- para poder obtener la certificación que estaba buscando. Como "bonus track", Hans a colocado también un documento PDF donde indica que contenidos del Rational Method Composer había que revisar para cubrir todos los temas de la certificación. Yo tenía instalado el RMC desde que me encontraba estudiando para el IBM 833-834, por lo que grande fue mi sorpresa al descubrir que TODOS los temas de la certificación estaban descritos ahí, y a detalle. Seguí al pie de la letra los consejos de Hans y leí lo que él indicó, gracias a eso ya no tuve problemas con los mocks.

Sintiéndome bastante confiado, fui a decirle a la gente de mi trabajo que quería dar la certificación, que me encontraba listo y que esperaba que al tratarse de un partner de IBM me pagasen el examen - como había ocurrido con los exámenes 833 y 834. Contra todo pronóstico, me dijeron que esta vez no podían afrontar el gasto, y que si quería certificarme los 240$ (200$ del examen y 40$ de gastos administrativos de New Horizons) tendrían que salir de mi bolsillo. Habiéndole dedicado ya tanto tiempo a la certificación, no me quedó otra que aceptar, así que este fin de mes mi salario estará más chiquito que de costumbre.

Programé el examen para el martes pasado, me acerqué a las instalaciones de New Horizons para dar el examen y lo aprobé con una calificación que me deja satisfecho. Ahora pienso tomarme otro descanso, y probablemente al certificación que venga sea la IBM Certified SOA Associate, aunque ahora que no es gratis no estoy tan seguro. ¡Hasta otra!

Demostrar valor iterativamente

(Imagen: El Greco - Visión del Apocalipsis)

Este principio explica los beneficios del desarrollo iterativo de software. Un proceso iterativo hace posible acomodarse al cambio, obtener retroalimentación y adaptarla al proyecto, reducir riesgos de manera temprana y ajustar el proceso dinámicamente.

Beneficios

• Reducción temprana del riesgo
• Mayor capacidad de predicción a lo largo del proyecto.
• Confianza entre los stakeholders
  

Patrón

1. Permitir retroalimentación al incrementar el valor para el usuario en cada iteración
2. Adaptar los planes usando un proceso iterativo
3. Aceptar el cambio y administrarlo
4. Atacar los mayores riesgos técnicos, de negocio y de programación tempranamente.
   

Anti-patrones

• Planear todo el ciclo de vida a detalle, controlar las variaciones respecto al plan (esto puede contribuir al fracaso del proyecto)
• Evaluar el estado en los primeros dos tercios del proyecto confiando en la revisión de especificaciones, en vez de evaluar el estatus de resultados de pruebas y demostraciones de software funcionando.

Basado en el navegador de proceso del IBM Rational Method Composer

Colaboración entre equipos

(Imagen: El Greco - La Sagrada Trinidad)

Este principio resalta la importancia de promover uno óptima comunicación entre miembros del proyecto. Esto se logra a través de una organización del equipo apropiada y configurando entornos de colaboración efectivos.

Beneficios

• Productividad del equipo
• Mejor acoplamiento entre las necesidades del negocio y el desarrollo y operaciones de los sistemas software.
  

Patrón:

1. Motivar a la gente para que realice su mejor esfuerzo
2. Crear equipos auto-administrados
3. Promover la colaboración horizontal entre funciones (como analistas, desarrolladores, testers)
4. Proveer entornos de colaboración efectivos.
5. Integrar a los equipos de negocios, software y de operación.
   

Anti-patrones

• Explotar a los desarrolladores, haciéndolos trabajar largas jornadas, incluyendo fines de semana
• Tener gente altamente especializada equipada con las mejores herramientas para realizar su trabajo, con colaboración limitada entre miembros del equipo e integración limitada entre sus herramientas. Se asumo que si cada uno realiza bien su trabajo el resultado será bueno.

Basado en el navegador de proceso del IBM Rational Method Composer

Disciplina: Requerimientos

(Imagen: El Greco - Vista de Toledo)

Propósito

• Establecer y mantener acuerdos entre los clientes y otros stakeholders sobre lo que el sistema debe hacer
• Proveer a los desarrolladores del sistema de un mejor entendimiento de los requerimientos del sistema.
• Definir los límites del sistema
• Proveer las bases para planificar el contenido técnico de cada iteración
• Proveer las bases para estimar el costo y el tiempo del desarrollo del sistema.
• Desarrollar una interfaz de usuario para el sistema, centrándose en las necesidades y objetivos de los usuarios.

Basado en el material del curso PRJ270: Essentials of the Rational Unified Process V7.0