archivo

Archivos Mensuales: abril 2013

El cono de incertidumbre de Steve McConnell viene a expresar algo que ya sabemos y es que efectivamente se acierta más cuanto más conocimiento tenemos del proyecto, su contexto, sus problemas, de las personas que participan, etc…

Ese conocimiento se adquiere conforme se va desarrollando el proyecto, con el proceso de definición de las historias de usuario, su construcción, el feedback y las retrospectivas. Cualquier otra actividad de carácter teórico puede producir mejores estimaciones, de base no lo niego, pero siempre limitada y siempre menor que la que se adquiere con la experiencia.

Entonces, ¿de qué valen las estimaciones que se realizan en la definición del proyecto y que tienen como objeto asignarle un presupuesto? Para definir un punto de partida e interesa que el mismo no esté muy equivocado, si bien lo realmente importante es la actitud que cliente (sobre todo el cliente) y el proveedor tienen sobre esas condiciones de partida. Si la orientación es al contrato, a su lectura literal, procura acertar (al cliente porque la satisfacción de sus expectativas respecto al producto final dependerá del acierto y al proveedor porque tendrá que prepararse a sufrir y perder mucho dinero).

En cualquier caso es conveniente dedicar tiempo a hacer la mejor estimación posible con la materia prima disponible, teniendo en cuenta que hay que saber cuándo parar porque si se pretende llegar a un conocimiento muy detallado, además del tiempo que se requiere para ello, se estará suponiendo que después la línea de desarrollo va a ir en esa dirección y lo mismo (lo más probable) se van produciendo cambios conforme el usuario vaya teniendo más claro qué es lo que quiere.

Las estimaciones iniciales no van a ser buenas, las finales estarán más ajustadas y no solo es cuestión de conocimiento técnico y funcional, sino que nos habremos dado cuenta de varios errores que se cometen sistemáticamente con las estimaciones (y que no sería de extrañar que los volvamos a repetir en el siguiente proyecto): considerar condiciones ideales, dejarse llevar por el optimismo, ser demasiado permeable a las presiones externas para admitir más capacidad o para producir estimaciones sin un conocimiento más en detalle de la historia de usuario o del requisito, exceso de ambición, etc…

Volviendo al cono de incertidumbre, hay que tener en cuenta que Steve McConnell lo planteó sobre una secuencia de fases que bien podrían ajustarse a un ciclo de vida clásico o en cascada, si bien podría ser extrapolable, al menos conceptualmente a otros enfoques de desarrollo de software.

McConnell señala que las estimaciones iniciales con un conocimiento insuficiente sobre la visión del producto (visión abstracta del sistema a desarrollar) se suelen desviar hasta cuatro veces por encima o por debajo de lo que viene a ser el esfuerzo real. En el momento en que se avanza más en la definición de la visión del producto, la desviación se ajusta hasta dos veces por encima o por debajo. Vuelve a bajar en la definición de requisitos (un 50%) y así sucesivamente hasta la entrega.

Me parece muy interesante la siguiente reflexión de Mike Beedle (traducción libre): “El coraje en Scrum no es algo visible o tangible. Tampoco es una especie de heroísmo romántico. En su lugar, consiste en tener el coraje y la determinación de hacerlo lo mejor que puedas. Es la obstinación de no darse por vencido y cumplir los compromisos. Este tipo de coraje es valiente, no glorioso”.

Beedle lo asocia a Scrum, sin embargo su cita me parece interesante porque refleja una actitud que va más allá de la utilización de una determinada estrategia de desarrollo de software y que desde mi punto de vista es absolutamente acertada: la actitud por intentar cumplir unos compromisos, por hacerlo lo mejor posible, de dar lo mejor de nosotros para conseguir esos objetivos.

Esto supone en primer lugar un compromiso con nuestro, con nuestro equipo y con nosotros mismos de lo contrario como mucho llegaremos a ser cumplidores (incluso con una cierta eficiencia) pero falta el empuje necesario para vencer determinadas resistencias que nos encontraremos en el proyecto y que requieren lo mejor de nosotros mismos, así como la capacidad de levantarse y recuperarse ante las dificultades que vayan surgiendo.

Como comenta Beedle no se trata de sacar la varita mágica y convertir en sencillo lo difícil sino de saber que nos encontramos ante un reto que exigirá lo mejor de nosotros mismos y que para superarlo requerirá mucho esfuerzo. ¿Qué después no es para tanto? Mejor, pero eso no quita que en el siguiente proyecto nos encontremos con mayores dificultades.

No es malo, antes al contrario, es muy positivo tener buenos deseos, ya que supone una declaración de intenciones. El problema lo tenemos cuando las intenciones se quedan solo en palabras, algo que todos sabemos se produce con demasiada frecuencia.

Es fácil hablar y escribir, mucho más difícil actuar.

Para Mary Poppendieck: “Un enfoque disciplinado para la resolución de problemas hace que un equipo pase de los buenos deseos a los nuevos conocimientos a las contramedidas específicas y los resultados permanentes”.

Y es cierto que la actuación requiere disciplina pero también determinación, mucha determinación.

Muchos proyectos fracasan por la falta de determinación y disciplina, perdidos en un sinfín de reuniones, en papeles mareados entre las partes u olvidados como adjuntos en correos electrónicos y en discursos teóricos que pretenden conquistar el mundo pero que tienen menos fondo que una caja de cerillas.

Es muy interesante tener en cuenta a la hora de realizar cualquier tipo de estimación lo que enuncia la Ley de Hofstadter (Douglas Hofstadter): “Siempre se tarda más de lo esperado, incluso cuando tienes en cuenta la Ley de Hofstadter”.

Las estimaciones suelen ser demasiado optimistas incluso en aquellos casos en los que no se cuenta con suficiente conocimiento como para hacerla y/o en aquellos casos donde el tamaño de la historia de usuario, requisito o tarea que se estima es demasiado grande.

Además de la posible falta de información, de la incertidumbre de la tarea o de su complejidad, uno de los principales problemas suele ser también que se suele estimar considerando situaciones ideales: que no nos vamos a encontrar con ningún problema en esta o en otra que impliquen un mayor esfuerzo que el esperado, que la capacidad de trabajo por parte del equipo va a estar disponible tal y como estaba previsto, etc…

¿Se debe creer en las estimaciones? La respuesta es que depende. Si es sobre un conjunto de trabajo moderado, la estimación solo debe ser considerada como una referencia, pero nada más. Tienes la opción de creerla y en base a ella gestionar el triángulo de hierro, más adelante te darás cuenta de que tendrás que renunciar a uno o más de los vértices del mismo: alcance, coste o plazos y/o reducir la calidad final del producto.

Pero incluso en tareas pequeñas, la estimación puede fallar de manera sensible y ponerte en un serio problema a la hora de satisfacer los compromisos del sprint. Una mala estimación siempre hace daño.

Debemos partir de la base de que no es fácil estimar, pero resulta necesario si se quieren definir unos compromisos en un margen de tiempo determinado. Esto hace que se deba mejorar de manera continua los procesos de estimación: reduciendo el alcance de lo que se estima, implicando a maś personas en las mismas, principalmente a los desarrolladores, ya que van a ser ellos los que se enfrentan después a su realización.

Los procesos dan un orden, armonizan actuaciones. Sobre esta base no podemos decir que, en esencia, sean perjudiciales. De hecho pese a que he pasado del amor al desamor con respecto a ellos siempre comento que siguen siendo necesarios pero como background en el que tengan un núcleo mínimo, que sean flexibles y admitan excepciones justificadas.

Cuando se cree que el éxito está tras los procesos es cuando se cae en el error. De ser cierto que aseguran el éxito bastaría con seguir su receta para conseguir desarrollar productos software que satisfagan las expectativas de los usuarios. ¿Alguien cree que si fuera así de fácil existiría hoy día la crisis del software?.

No niego que determinados procesos puedan ser efectivos en condiciones muy específicas pero no creo que en procesos que se consideran martillos de oro o solucionadores universales para todo tipo de desarrollos en todo tipo de contextos.

Cuando un proceso no funciona (en enfoques de desarrollo de software dirigidos por procesos) siempre se le suele echar la culpa al desarrollador: “el proyecto ha ido mal porque no has seguido bien el proceso o porque no se han ejecutado adecuadamente los hitos” o a que el proceso no está lo suficientemente desarrollado lo que da lugar a que se entre en un mayor nivel de detalle y se convierta en una solución más rígida que, por supuesto, funcionará igual de mal o peor (que es lo más posible) que la versión anterior.

La mayoría de los procesos son ad-hoc, lo cual en sí no es malo ni bueno (generalmente las implementaciones de metodologías ágiles suelen ser ad-hoc) pero sí que se debe ser prudente por parte de quien o quienes lo han hecho de considerarlo soluciones universales por mucho que sean el resultado (o se venda así) de años de feedback en proyectos reales.

¿Por qué lo digo? Pues porque la mayoría nos hemos encontrado con las siguientes situaciones: Proyectos que han salido adelante cuando no se ha seguido a rajatabla un proceso que provocaba bloqueos y resistencia y proyectos que han fracasado o que no han tenido el éxito esperado precisamente por seguir procesos rígidos que no se adaptaban a la realidad de los mismos.

Es cierto que no es justo echarle toda la culpa a los procesos cuando algo sale mal (no podemos escondernos tras ellos) pero sí que es verdad que si te exigen trabajar de una manera y no existe flexibilidad tu margen de maniobra queda reducido y se trabaja mucho peor que si tuvieras los pies y las manos liberados.

No digo nada nuevo si os comento que las mejores especificaciones de los usuarios van surgiendo conforme se va avanzando en el proyecto y se les empieza a despejar la niebla que se extiende por su visión de lo que debe ser el sistema de información.

En un enfoque clásico, pretender acertar desde una fase de análisis que se encuentra muy lejos del momento en que se va a poner el producto en producción es casi una quimera por mucho que se haya trabajado con prototipos y los desarrolladores conozcan bien al negocio y a los usuarios.

¿Cómo mantener una agenda de plazos y presupuesto si me cambian los requisitos? No se puede salvo que termines reventando al equipo y/o recortando el alcance (y calidad) del sistema de información y aún así probablemente te termines desviando en ambos.

Si nos quedamos con las especificaciones iniciales no se puede esperar un producto con un mayor valor que el que nos ofrecen las mismas porque estamos limitando el valor al no permitir cambios propiciados por el feedback usuario.

Por tanto, no solo nos estamos encontrando con una estrategia de desarrollo de software que se aleja de la realidad de los proyectos sino que, además, su orientación a la agenda, ofrece menos flexibilidad para incorporar valor al producto a lo largo del proceso de desarrollo.

Trabajamos para eso, para desarrollar software que funciona. Pero, ¿de qué se trata eso de que el software funcione?. Cada uno tenemos diferentes perspectivas de las cosas, esta no iba a ser una excepción, por lo que para cada uno el listón puede estar a diferente altura y no necesariamente (dependerá del momento del proyecto, del contexto, de las características del sistema de información, etc…) unos tienen que estar siempre equivocados y otros estar en lo cierto.

Siguiendo un enfoque iterativo incremental vamos a ir liberando diferentes versiones del producto hasta obtener una “versión final” (lo pongo entre comillas porque el software es generalmente objeto de una continua evolución por lo que se puede hablar de versiones finalistas de un proyecto más que versiones finales de un sistema de información).

Independientemente de que desde el primer momento intentemos liberar el mejor software posible (desarrollo con intención) es razonable pensar que en las primeras iteraciones de una aplicación el listón no esté tan alto, sobre todo en aquellos casos donde esas iteraciones no llegan a un entorno de producción o de llegar su uso está limitado a su evaluación y porque la incertidumbre y falta de acoplamiento (al proyecto y entre las personas) en los momentos iniciales hace que se falle más de la cuenta (desarrolladores y usuarios).

No se trata de relajarnos en las primeras iteraciones, no quiero decir eso, sino de entender que no todos los momentos del proyecto son iguales (ni todas las circunstancias). No hay minutos prescindibles en un proyecto porque lo perdido no se recupera y por ese motivo siempre soy partidario de ir con intención siempre sin olvidar y, eso es lo que quiero dejar patente, que como en toda carrera de larga distancia hay que saber regular (y que todas las carreras son diferentes).

Un software que funciona debe satisfacer las expectativas del usuario. Si no satisface sus expectativas tenemos un producto que hace cosas pero no tal y como las quiere el usuario. No se trata de términos absolutos sino que tenemos que tener en cuenta los umbrales, es decir, la liberación de una nueva versión puede que no deje totalmente satisfecho al usuario pero sí supere sus umbrales de satisfacción. Nuestro objetivo será que la “versión final” esté más cerca de la total satisfacción del usuario que de su umbral superior pero eso requerirá mucho trabajo, voluntad por parte de los usuarios para darnos su feedback y diferentes evoluciones del sistema.

Un software que funciona no debe quedarse solo con la parte visible del iceberg. La deuda técnica cuenta y mucho. El usuario no la ve, no la valorará y sin embargo condicionará la mantenibilidad del producto y la disponibilidad del sistema ante futuras evoluciones del mismo. Es posible que haya clientes que no la tengan en cuenta, en cualquier caso soy de la opinión de que los proveedores deben marcar unos estándares de calidad para los sistemas que desarrollan, como elemento diferencial respecto a los que no lo hacen.

Más allá de la deuda técnica se encuentra la mantenibilidad (un concepto más general). Un software que funciona debe ser lo más fácilmente de mantener posible (dentro del contexto en el que se ha realizado el proyecto) y eso va más allá de la deuda técnica pudiendo contemplar elementos documentales si así fuera preciso.

Un software que funciona debe tener también en cuenta aspectos no funcionales. Algunos de ellos están en la parte visible del iceberg (aunque tal vez en la parte de atrás, la que no se ve a simple vista o la que requiere más tiempo para ser descubierta) como por ejemplo el rendimiento o la disponibilidad y otros en la parte no visible como por ejemplo la seguridad.