archivo

Archivos Mensuales: junio 2013

Watts Humphrey fue considerado como el padre de la calidad del software por su dedicación a combatir los problemas relacionados con la crisis del software. Hasta tal punto era tal su compromiso (lo consideraba como un compromiso para cambiar el mundo de la ingeniería del software), que en el año 1986 tomó la decisión de unirse al Software Engineering Institute (SEI), instituto federal creado por el Congreso de los Estados Unidos en 1984 para la mejora en el proceso de desarrollo de software, y que dio lugar al modelo SW-CMM, que se puede considerar un precursor de CMMI.

Humphrey llegó al SEI con casi 30 años de experiencia en IBM ocupando puestos de responsabilidad, como por ejemplo los de director de programación y vicepresidente de desarrollo técnico.

En el año 2005 recibió la medalla de honor de tecnología de los Estados Unidos.

La obra de Watts Humphrey es muy amplia. En esta serie de artículos, voy a exponer los que se conocen como sus 6 principios de calidad del software.

Para contextualizar un poco los mismos, Humphrey era un defensor (vino con esa visión desde IBM) de la gestión del software por procesos, con una orientación dirigida a tratar de reaprovechar herramientas, recursos y armonizar el proceso de desarrollo.

Los lectores habituales de mi blog sabréis cuál es mi visión de los procesos: no los rechazo, me parecen interesantes en el sentido de que es necesario establecer unas reglas de juego comunes en los desarrollos de una organización, que sean las mínimas posibles para cumplir ese propósito y permitan adoptar la solución que resulte más apropiada para cada proyecto en el que estemos trabajando.

Desde mi punto de vista los procesos son una herramienta pero no pueden convertirse en una finalidad en tanto en cuanto, no pueden asegurar el éxito en un proyecto.

Me veréis discrepar con su quinto principio, como es lógico, e independientemente de la visión que yo tenga con respecto al desarrollo de software, su opinión debe pesar infinitamente más que la mía.

Existen multitud de variables que pueden echar al traste un proyecto. Una de ellas, tal vez una de las más importantes, es la falta de implicación por parte de la persona designada por el área usuaria para realizar este trabajo.

A veces, no falla la implicación y sí la actitud, cuando el responsable funcional entra en una espiral de ordeno y mando, en la que no se deja aconsejar.

El problema se hace más grande cuando, además de lo anterior, el responsable funcional no asume sus errores de manera que explícita o implícitamente hace que los mismos recaigan sobre el equipo de desarrollo.

Innumerables proyectos han fracasado por estos motivos.

Lo mejor es que desde un principio quede claro cuál es el rol del responsable funcional: definir la línea de desarrollo del producto, estableciendo prioridades y seleccionando las tareas que se hacen en cada momento, es el responsable de coordinar el área usuaria para obtener información adicional en el caso de que sea necesario (que lo será en muchos casos) y es el interfaz de comunicación entre esos usuarios y el equipo de desarrollo (lo cual no quiere decir que los usuarios sean un elemento aislado y que los desarrolladores no puedan comprobar directamente cuáles son sus sensaciones).

Teniendo muy claro que sus decisiones producen un impacto en el proyecto, es decir, si se equivoca a la hora de definir una historia de usuario o si se equivoca en las prioridades, hay repercusiones, en el sentido de que el proyecto tiene un presupuesto limitado y en cada iteración va menguando.

No se trata de que no se pueda equivocar, ya que para eso está el enfoque iterativo incremental y el feedback, sino de que las decisiones que tome las haga con intención, disminuyendo las tentativas orientadas al prueba y error.

Desde un principio hay que definir las reglas del juego y es muy probable, sobre todo para responsables funcionales sin experiencia en la participación en proyectos de desarrollo de software, que haya que ir realizando recordatorios puntuales de las mismas.

Una cosa es que desde un principio queden claras las reglas y otra que el responsable funcional las quiera cumplir. Si pasa de ellas y no se consigue normalizar la situación, no quedará otra que escalar el problema porque de lo contrario el proyecto y el producto serán los principales perjudicados.

Con el objeto de mantener un equilibrio en el proyecto es fundamental gestionar las expectativas, de manera que el responsable funcional no se lleve sorpresas. También, por nuestra parte, es importante que no nos intercambiemos los papeles, es decir, él responsable funcional debe elegir los objetivos de nuestra iteración y él no debe meterse (salvo que requiera alguna aclaración) en el esfuerzo estimado para cada una.

Es muy complicado ambas cosas, que el desarrollador no se meta a product owner y que el product owner no discuta la duración seleccionada para cada tarea, en su afán de tratar de que se asuma la mayor cantidad de trabajo posible, olvidando o ignorando que el cumplimiento de los compromisos se ve muy perjudicado cuando la capacidad del equipo de proyecto está sobresaturada.

Lo primero se resuelve aceptando cuál es el verdadero rol del equipo de desarrollo (una cosa es aconsejar y otra definir la línea de desarrollo) y la segunda con mucho diálogo y con la consolidación de una relación de confianza.

Es más difícil solucionar lo segundo que lo primero, de hecho, será complicado que con relativa frecuencia no se nos pidan explicaciones por tal o cual estimación, aceptemos que esto será así, dando las explicaciones que sean oportunas.

Otra circunstancia que puede darse es que tengamos en la pila de producto historias de usuario suficientes para completar la capacidad de trabajo del sprint, pero que muchas de ellas no se consideren prioritarias o lo sean bastante menos que otras que todavía no se han terminado de definir por completo, pero sobre las que se sabe que durante el período de ejecución del sprint van a terminar de completarse y que va a haber tiempo para abordar algunas de ellas.

No se trata en este caso, no tanto de no poder esperar sino de tratar de conseguir siempre el mayor valor posible del producto con respecto a la cantidad de esfuerzo invertido. Lo fácil sería tomar la decisión de trabajar sobre las historias de usuario que están definidas, incluso en muchos casos será la decisión acertada, pero no podemos cerrarnos a la posibilidad de que en determinadas circunstancias lo aconsejable sea dejar la pila de sprint abierta con una capacidad reservada para la realización de estas tareas.

En este caso, hay que anticiparnos con el objetivo de no desperdiciar capacidad de trabajo, de manera que si finalmente no da tiempo de definir algunas historias de usuario, se opte por trabajar con las que están definidos.

¿Y por qué no se han tenido definidas esas historias de usuario antes? Pues porque no siempre se puede, por mucha voluntad que le ponga el product owner o el equipo de desarrollo. Lo mismo uno y otros han tenido que dedicar su esfuerzo en otros objetivos del proyecto que hasta ahora han sido más prioritarios o el product owner ha tenido que consultar con terceros determinadas decisiones que le trascienden y cuya resolución se mueve en unos tiempos distintos al del proyecto y sus sprints.

Tener la pila abierta de esa manera es poco ortodoxo, lo sé, pero cada proyecto tiene sus propias circunstancias y en base a ello tanto el product owner como nosotros tenemos que tomar decisiones, con fundamento, con intención, evitando la arbitrariedad, siempre pensando en lo que más conviene al proyecto y al producto y con la mente abierta a hacer excepciones puntuales o no tan puntuales sobre la estrategia que venimos aplicando.

Hemos visto que un motivo puede ser la resolución de incidencias, bien porque no se ha previsto capacidad para resolverlas o incluso haciendo la previsión porque su volumen y/o complejidad, lo supera. No es la única circunstancia que nos puede llevar a modificar el alcance del sprint pero en cualquier caso, el product owner debe participar en la decisión como responsable de la línea de desarrollo del producto.

Otro posible motivo puede ser que el mismo product owner, una vez pactado el alcance del sprint, quiera que se trabaje sobre una historia de usuario no contemplada inicialmente. La experiencia del product owner resulta esencial para determinar si efectivamente es tan necesario ese cambio, porque supondrá una variación de los compromisos definidos, ya que para que una historia de usuario entre, otra u otras tienen que salir.

Lo de la experiencia lo digo no solo por su capacidad de acertar o no, sino por el hecho de que el desarrollo necesita estabilidad (siempre que sea posible y las circunstancias lo permitan) y los cambios de criterio no ayudan a conseguirla y, además, hay que tener en cuenta que los sprints son de corta duración y que el tiempo de espera para afrontar la tarea o tareas no contempladas no será excesivo.

También es posible incrementar la capacidad del equipo pero sabemos que las circunstancias que se tienen que dar para que eso sea efectivo son muy especiales, ya que generalmente este tipo de estrategias para conseguir objetivos a corto plazo no suele dar buenos resultados. ¿En qué casos puede funcionar? Reduciendo la capacidad de trabajo dedicada a la corrección de incidencias o incluyendo personas que por algún motivo han salido del proyecto no hace mucho tiempo y que controlan la tecnología, la infraestructura de desarrollo y determinados aspectos del negocio.

Personalmente soy partidario de tener pilas de sprints cerradas porque eso quiere decir que se han trabajado las historias de usuario y que se dispone de toda la materia prima necesaria para ejecutar el proyecto. Además representa predecibilidad, con lo complicado que resulta eso en el desarrollo de software, ya que es el reflejo de una serie de compromisos del equipo de desarrollo con respecto al product owner dentro de la capacidad de trabajo que se puede asumir.

Para darle un tratamiento a las incidencias soy partidario de la existencia de personas, fuera del alcance del sprint, que se encarguen de ellas (no quiere decir que sean personas que específicamente se encarguen de esto, ya que podría ser válida la decisión de reservar una capacidad concreta del equipo de proyecto sobre el total para la realización de estas tareas). De esta forma, el cumplimiento de los compromisos no se debería ver afectado por la resolución de las incidencias (aunque esto es teórico porque una incidencia mal corregida o de gran impacto puede afectarle).

En el caso de que no llegasen incidencias en número y complejidad que consuman la capacidad disponible, siempre se puede aprovechar ese tiempo para trabajar sobre el sprint y ayudar al cumplimiento de los compromisos, además de realizar otro tipo de tareas que pueden resultar positivas: refactorizar código para reducir deuda técnica, realización de testing, automatizar pruebas, hacer mejoras sobre la infraestructura de desarrollo, etc…

Pero independientemente de que mi preferencia sea esa, soy de la opinión de que siempre hay que estar abierto a las circunstancias que se puedan producir en el proyecto y que si hay que abrir la pila de sprint, hacerlo.

Dependerá de si prefieres utilizar prácticas de Scrum o de Kanban, o de incluso si utilizas prácticas de ambas.

En el mundo real, es complicado ser muy ortodoxo con las metodologías y no es cuestión de ser más o menos disciplinado, ya que puedes tener unas ideas concretas sobre qué prácticas aplicar y después que las propias circunstancias del proyecto que te obliguen a cambiar sobre la marcha.

Sí que es conveniente trabajar sobre una idea pero es necesario ser flexible cuando las circunstancias lo aconsejen. De lo contrario estamos poniendo a la metodología sobre el producto y sabemos quién sale perdiendo cuando eso sucede.

Scrum parte de la idea de tener pilas de sprint cerradas. ¿Qué hay que corregir incidencias? No podemos ponernos una venda en los ojos cuando son críticas (si no lo son, se podría esperar a una de las siguientes iteraciones y contemplarlas como una tarea más dentro de la pila). Ante esta situación se puede renunciar a alguna de las historias de usuario comprometidas y dedicar el tiempo a solucionarlas o se ha podido prever la existencia de una o varias personas fuera del sprint dedicadas a hacer este tipo de tareas y que durante o al final del sprint (mejor cuanto antes) sincronizan o integran su trabajo con la línea base del producto.

En el ejemplo anterior, en una de las posibles soluciones, le hemos quitado la llave a la pila de sprint y sustituido una o más historias de usuario por una o más incidencias de carácter crítico (realmente se trata de una decisión a tomar en la que el carácter crítico de la incidencia puede influir más o menos) y no pasa nada, no por ello somos menos diligentes con la metodología, simplemente se han dado unas circunstancias y nuestra decisión, acertada o no, ha sido esa.

En el caso de un equipo QC, su funcionamiento se puede orientar perfectamente a un procedimiento: recibo una entrega en un formato determinado, hago las tareas de verificación y devuelvo unos resultados. Se puede ser ajeno al conocimiento del producto y del proyecto (se trabaja sobre la documentación escrita por el equipo de desarrollo). Por eso muchas organizaciones que se dedican a prestar este servicios, tienden a crear factorías de testing, ya que el modelo encaja perfectamente, y de esta forma pueden ofrecer precios todavía más competitivos porque “da igual” que la persona que vaya a trabajar sobre la entrega conozca el producto.

Después la pericia de los técnicos QC les puede hacer llegar más lejos, ya que pueden hacer testing exploratorio y aplicar otro tipo de técnicas que les permitan que la detección de defectos sea más efectiva.

Un aspecto a tener en cuenta en el QC es que parte de su ahorro de costes es provocado por un incremento de los costes de desarrollo del producto porque el nivel de detalle de la documentación entregada (sobre todo la relativa a las pruebas) tiene que ser superior al necesario para suplir el desconocimiento del negocio y del producto por parte de los técnicos QC.

Este aspecto no se tiene en cuenta generalmente a la hora de implantar este tipo de servicios y es muy importante porque para valorar la efectividad de la implantación de un QC es necesario evaluar sus resultados frente a los costes directos (los del propio equipo del QC) como los indirectos (los que ocasiona en los proyectos).