Las 10 prácticas ágiles más útiles (I)

Hoy voy a hablar de un tema muy en boga: las técnicas o prácticas ágiles. De ellas, se ha hecho un estudio a expertos profesionales en la materia. El estudio ha sido conducido por Teodora Bozheva, una excelente formadora en algún curso de calidad en el que he tenido el placer de asistir. Podéis ver los datos fuente aquí.

Pero tal como estuve hablando con Teodora, los datos no son más que eso, así que me animé a pedirle permiso para a partir de sus datos, darle una vuelta de tuerca y llegar más a fondo. Vamos con ello intentar responder a varias preguntas no sólo sobre las técnicas agiles, sino también sobre nuestro propio conocimiento de dichas técnicas.

Vamos a partir de los resultados, que podemos ver en la siguiente gráfica:

Lo primero a destacar, es que no hay una diferencia abismal entre los primeros y los últimos en este grupo.
Vamos a ver un poco los más útiles:

• Automated Builds: la compilación automática, forma parte tradicionalmente de los sitemas de integración continua, aunque es perfectamente válido el considerarlo de forma autónoma.
• Continuous integration: el 2º clasificado, viene a confirmar que la automatización de tareas, se sigue considerando una técnica ágil muy útil.

Hagamos un breve inciso aquí para tener en cuenta que los dos primeros clasificados están muy relacionados. De hecho, habrá defensores que lo consideren como uno sólo. Los dos siguientes, están también relacionados, y sí que podrían considerarse técnicas puramente ágiles (mucho más asociadas a las metodologías ágiles que las dos primeras, por ejemplo):

• Daily stand up meeting: la técnica de realizar breves reuniones de pie, diariamente, y de forma informal pero con un objetivo definido de poner en común las tareas en curso de cada uno, y los problemas encontrados o que nos atascan.
• Iteration planning: tradicionalmente vinculado a la programación extrema (Extreme Programming o XP), esta práctica consiste en la ejecución de la iteración: desde el desglose y estimación de las tareas, su asignación, y posterior desarrollo, ejecución de pruebas unitarias, etc., hasta la siguiente iteración.

Algunos puntos importantes a indicar aquí sobre estas dos prácticas: la primera es extremadamente económica de implementar. Cualquier proyecto puede incorporar esta técnica, sin coste ni importantes efectos colaterales (salvo quizás el incremento de visión de los integrantes del equipo). La segunda, sin embargo, exige una involucración más profunda en las metodologías ágiles. Exige por tanto, un cambio significativo en la forma de organizar el trabajo, planificarlo, y reportarlo.

Para terminar hoy, vamos a quedarnos con dos técnicas ágiles, que a pesar de estar incluidas aquí, son en realidad técnicas habituales en cualquier desarrollo de software ("ágil" o no):

• Coding Standards: Se trata de disponer de estándares de codificación  o de desarrollo específicos del proyecto.
• Unit Testing: consiste en la planificación, diseño, programación y ejecución de pruebas enfocadas a probar un único componente o función.

En primer lugar resulta curioso el considerarlos técnicas ágiles. En segundo lugar, son aspectos prácticamente de uso obligatorio en cualquier desarrollo moderno de hoy en día. En cuanto al coste, ambos son elementos costosos de implantar, ya que requieren de formación específica, y en algunos casos, de herramientas específicas tanto para su uso como para su verificación.

Dejaremos para otro día, la segunda parte de este artículo, revisando las técnicas que quedan.

Cuanto antes empieces a codificar más tarde terminará el proyecto

Este proverbio, lo he encontrado en la web de Calidad del Software. Le he dado una leída, y me he dicho: "pero qué pedazo de tontería es ésta".

Pensándolo un poco más despacio...no deja de tener razón. Me explicaré.

En mi experiencia, han sido ya muchos proyectos durante todos estos años en los que aunque se ha hecho el debido análisis y diseño, la presión por parte de la gerencia ha acabado obligando a que "el equipo que vaya echando código, y tú en paralelo ya harás el análisis y diseño". Al final, incluso la planificación iba muy por detrás de la ejecución de actividades.

Esto tiene sus contrapartidas:

• Es necesario dar una visión (funcional), que aunque incompleta, permita al equipo "saber hacia dónde va". Esto obliga a que al menos, esté completada esa visión en el análisis funcional. Es decir, no basta con solamente poner los requisitos (historias de usuario en Scrum) que vayan a empezar de forma inmediata.
• Aunque creamos saber "hacia dónde va" nuestro desarrollo, no todo puede hacerse en base a "bloques independientes". Muchas veces, aceptamos que el software evoluciona en cuanto a sus requisitos (véase SCRUM). Sin embargo, estamos ciegos al pensar que la arquitectura del sistema no va a cambiar también. Y aquí es donde los desarrollos iterativos chocan con la triste realidad de tener que incorporar en cada iteración (o release), un gran esfuerzo en integrarse con lo existente, y probarlo todo otra vez.
• El tamaño importa: en un desarrollo pequeño, estos comentarios pueden ser de escasa importancia. El esfuerzo en "asentar" un software sin análisis o diseño o arquitectura, puede ser despreciable. Conforme el tamaño del software aumenta (y es importante identificar muy al principio el tamaño del software), todo esto cobra importancia de forma exponencial.
• Muchas veces se olvida que la documentación de análisis, diseño y arquitectura son parte de los entregables. ¿Por qué? Simplemente porque realizar el mantenimiento de una aplicación, basándose solamente en los comentarios que nos han dejado los antecesores, es un suicidio. Queda muy bien lo de "yo no necesito documentar, ya que dejo buenos comentarios". Esta frase es muy típica de la gente poco experimentada, que apenas ha hecho mantenimientos, o los ha hecho de aplicaciones con poca trayectoria.

Esta frase tampoco tiene porqué ser tomada a la inversa: si vamos retrasando la programación, llega un punto en que la definición ya está casi cerrada. Es absurdo que pretendamos tener el 100% de la documentación cerrada para empezar a programar. Hay que evaluar la madurez de lo que tenemos, y controlar los riesgos de que cambien las cosas.

A este respecto, nada mejor que contar con la experiencia de un buen analista y un buen arquitecto que cierren los puntos clave, un jefe de proyecto experimentado que coordine la aprobación y seguimiento de esta documentación inicial....y a partir de ahí, versionar esa documentación.

La desgracia, es que muchos programadores (por no decir todos), se sienten cómodos aplicando cambios al código. Pero no actualizando la documentación conforme esos mismos cambios. Además, esto se ve agravado con el hecho de que los jefes de equipo y proyecto no fomentan actualizar esa documentación. Así que dada esta escuela de comportamiento, seguimos fomentando las malas prácticas.

Y ojo, no se trata de tocar la documentación con cada línea de código. Si sabemos qué se ha tocado, bastaría juntar cada 2, 3 o 4 semanas de desarrollo, los principales cambios técnicos y funcionales, y dedicar un rato a que algunos documentos no se desfasaran. También aquí hay que ser pragmáticos, si el entregable principal es el documento funcional, apliquemos ahí el mayor esfuerzo. Si es el técnico, pues lo mismo.

Hablemos de estándares

Los estándares, en el mundo del software, son uno de los facilitadores más sencillos que existen. Sin embargo, tienen muchos detractores y están muy mal vistos por colectivos que ven en el desarrollo del software un medio de expresión, un "arte", y que están en contra de las normas y directrices.

Las normas y directrices ayudan a luchar contra las diferencias que presentan los distintos componentes de un proyecto:

• Diversidad cultural
• Creencias
• Niveles de conocimiento
• Años de experiencia
• Personalidad
• Barrera idiomática
• Jerga Profesional

¿Y qué deberían cumplir estas normas, reglas o estándares?

• Simples, fáciles de entender
• Si es posible, incluir ejemplos de uso, y demostración de su utilidad práctica
• Los estándares no pueden ser extensos. Nadie va a recordar un documento de 200 hojas.
• Los estándares pueden ser muchos. Por ejemplo, si en nuestra empresa se programa en 20 lenguajes, puede haber una mini guía o estándar por cada uno.

Recomendaciones:

• Mantener vivos los estándares. Pocas cosas hay peores que dejar las cosas en el olvido. Las tecnologías evolucionan, y los estándares están muy relacionados con las tecnologías del momento. Es por eso que los documentos donde se recojan los estándares han de estar actualizados constantemente. Las actualizaciones han de estar disponibles, y la gente ha de conocer de forma clara el motivo de la actualización. 
• Evitar actualizaciones muy frecuentes: por ejemplo, que sólo los proyectos nuevos a partir de una fecha utilicen la última versión de los estándares. No hay peor cosa para la gente que esté en un proyecto, que la distraigan cambiando las normas. Bastante cambian ya los requisitos, los hitos, las entregas, etc., como para que encima cambie la forma en que hacemos las cosas en el día a día.
• Realizar formaciones. De nada sirve dar a la gente al principio del proyecto un documento para que se lo lea. Tampoco será muy útil tratar de castigar o penalizar a quien no lo siga. Mucho más práctico será realizar cursos periódicamente, que además de sobre los estándares, puede incluir las últimas novedades de la tecnología que se use (esto suele ser mejor reclamo que los estándares en sí).
• Incentivar el uso. Puede aplicarse un incentivo positivo: por ejemplo, dar premios o bonus a los desarrolladores que mejor resultados tengan en los tests relacionados con estos estándares (y mejor si son pruebas automatizadas).
• Penalizar el desuso. Yo en general, estoy en contra de esta práctica, pero habrá quien la vea útil. Es la contraria de la anterior, y consistiría en penalizar a los desarrolladores con peores prácticas (desde el punto de vista de los estándares recomendados).

Pues nada, ahora que sabemos la teoría, dejaremos para un próximo post el ir aterrizando estándares "palpables" para algunas tecnologías. Nos vemos.

Por fin un estándar para las pruebas: ISO 29119

Se está haciendo un importante esfuerzo desde hace ya algún tiempo para estandarizar las pruebas de software. El resultado de esto es el estándar ISO/IEC 29119 Software Testing, que todavía no está terminado, sino que se encuentra en revisión pública de la versión borrador. El portal de trabajo se encuentra en: http://softwaretestingstandard.org/, donde encontraréis información actualizada del estado y contenido.

¿Qué pretende este estándar?
Su objetivo es recopilar la terminología, procesos, documentación y técnicas para todo el ciclo de vida de pruebas del software.

¿Cuál es su contenido?
El contenido está estructurado (actualmente a fecha 12-12-2011) en cuatro partes:

• Parte 1: Definiciones y Vocabulario
• Parte 2: Proceso de Pruebas
• Parte 3: Documentación de Pruebas
• Parte 4: Técnicas de Pruebas

¿En qué se basa?
Se basa en las principales normas que actualmente son los referentes de esta área:

• BSI (British Standards Institution): BS 7925-1, Software Testing: Part 1-Vocabulary y BS 7925-2, Software Testing: Part 2-Software Component Testing.
• IEEE Std. 829, Software Test Documentation y IEEE Std 1008, Software Unit Testing, IEEE Std 1012-1998 Software Verification and Validation y IEEE Std 1028-1997 Software Reviews.
• ISO/IEC 12207, Software Life Cycle Processes, ISO/IEC 15289, System and Software Life Cycle Process Information Products y ISO/IEC TR 19759, Guide to the Software Engineering Body of Knowledge

Sistemas de Gestión de Proyectos con Software Libre

Presentado por el PMI Spain Barcelona Chapter, y presentado por el ponente José Moro, va a tener lugar una charla (webminar) con el título "Sistemas de Gestión de Proyectos con Software Libre", el próximo jueves 15 de Diciembre de 2011.

Tenéis toda la información en: link. Fuente: publicado por el propio José Moro en Linkedin.

A modo de resumen, la agenda presentada es la siguiente:
1. ¿Necesitamos un sistema de gestión de proyectos?
2. ¿Qué le pedimos a nuestro sistema de gestión de proyectos?
3. Quiero uno, ¿por dónde empiezo?
4. Aspectos a tener en cuenta a la hora de seleccionar el sistema de gestión de proyectos
5. Conclusiones

Chistes de Testers

Os traigo unos chistes que me han parecido buenísimos, y que están relacionados con el mundo del testing. Los que hayáis trabajado en testing, espero que os guste. Los que no...no os vendría mal dedicar algo más de tiempo a probar vuestros propios productos! . Fuente: Link.

Optimistic Developer: The glass is half full
Pessimistic Tester: The glass is twice as big as required

Optimistic Developer: This code hasn’t yet been tested. It’s not known if it has any bugs.
Pessimistic Tester: This code hasn’t yet been tested. It’s not known if it works.

Optimistic Developer: We are 90% done.
Pessimistic Tester: We don’t know when we’ll be done, if ever

Optimistic Developer: We will refactor the code to make it better
Pessimistic Tester: They are throwing out the working code and replacing it with an unknown quantity

Optimistic Developer: I only changed one line of code
Pessimistic Tester: The entire system must be retested

Optimistic Developer: The code is the design
Pessimistic Tester: There is no design

Optimistic Developer: We’ll fix those bugs later, when we have time
Pessimistic Tester: We never have enough time to fix the bugs

Optimistic Developer: This build is feature complete
Pessimistic Tester: The features exist; some are completely broken

Optimistic Developer: Anything is possible, given enough time
Pessimistic Tester: Everything has flaws, and given enough time I can prove it

Optimistic Developer: Of course it will work
Pessimistic Tester: It might work, but probably won’t

Optimistic Developer: One last bug fix, and we can ship tomorrow
Pessimistic Tester: Fixing this one bug will likely lead to two more

Optimistic Developer: Stop finding bugs, or we’ll never be done
Pessimistic Tester: Stop creating bugs, so I can find them all

Optimistic Developer: There’s no need for more tests
Pessimistic Tester: Let’s just run a few more tests to be sure

Optimistic Developer: There is no I in TEAM
Pessimistic Tester: We can’t spell BUGS without U

Optimistic Developer: That’s an “undocumented feature”
Pessimistic Tester: That’s a bug

Optimistic Developer: I like to build things
Pessimistic Tester: I like to break things

Optimistic Developer: Sure, we can use the Beta version of this component in Production
Pessimistic Tester: We should wait until version 2.1

Top Mantra de los Arquitectos (I)

Estaba leyendo uno de mis autores favoritos (Dino Esposito), con su "Microsoft .NET: Architecting Applications for the Enterprise", y entre otras muchas perlas que conviene leer y que os recomiendo encarecidamente, contiene un pequeño resumen de 10 magníficas perlas (mantras en su libro), que no por sencillas, son menos importantes en nuestro trabajo. Vamos a darles un repaso:

Mantra #1: "Depende". Ademas de ser una respuesta socorrida para aquellos que no tienen ni idea, por desgracia es también una respuesta de los más experimentados. Pues sí, depende. Depende de la situación, del contexto. Las decisiones arquitectónicas son sólo eso: decisiones basadas en la experiencia y en el conocimiento del proyecto, del cliente y del equipo de desarrollo. Basándose en los tres anteriores, hay que elaborar la lista de soluciones para cada una de las facenas de nuestra solución arquitectónica.

Mantra #2: "Los requisitos son Dios". He querido explícitamente no hablar de ellos en el mantra anterior, y es que los requisitos, aun formando parte de la especificación del proyecto, son mucho más importantes que el proyecto en sí para el arquitecto. No es fácil adaptar las cosas al equipo (si es que conseguimos un equipo estable de trabajo), como tampoco lo es adaptar la arquitectura al cliente (si es que conseguimos la colaboración del cliente, y si dicha colaboración es fructífera). Al final, los requisitos son la verdadera guía del proyecto. Cambiarán, por supuesto que cambiarán. Pero al final, es la labor inicial de análisis y el enfoque acertado de dichos requisitos, lo que marcará el éxito del proyecto. Los arquitectos sólo se limitarán a proporcionar la infraestructura tecnológica, las decisiones de comunicación, etc., para adaptarse a dichos requisitos.

Mantra #3: "Programar una interfaz". De nuevo, los requisitos (en este caso de interfaz), van a ser la directriz principal de los desarrolladores. Sin interfaces, el código no tiene forma de prosperar. Serán sólo líneas de código sin un objetivo (como echar ladrillos al aire con la esperanza de que formen la pared tal y como se proyectó).

Mantra #4: "Hazlo simple, pero no simplón". Aquí es donde un arquitecto se la juega. Las soluciones complejas, en las que el arquitecto pretende mostrar su conocimiento (cuando realmente se le ve el plumero de que le falta experiencia), nos llevan de forma inexorable al fracaso. Donde realmente se ve a los mejores profesionales brillar, es con soluciones simples y efectivas. Por desgracia, hay una débil frontera que hace que una solución simple, no se pueda simplificar más sin caer en lo absurdamente simple y escaso.

Mantra #5: "Herencia es sobre polimorfismo, no reutilización"
La herencia constituye un elemento fundamental de la programación orientada a objetos. Que la herencia permite reutilización, es correcto. Pero la reutilización como objetivo, es un gran error. Dicho de otra forma, es mejor escribir una nueva clase específica para la tarea concreta, que heredar de otra que no lo está. Es mejor reescribir de forma enfocada a la solución concreta, que tratar de reutilizar todo formando una oscura maraña de dependencias que de seguro llevará al fracaso (y complicará la vida a los pobres programadores que osen completar la aplicación, y luego mantenerla).

Y bueno, hasta aquí la primera parte de los 10 Top Mantra de los arquitectos. El próximo día...más.

Defectos de Scrum (II)

En un reciente post hablaba de defectos de Scrum. Con este título, yo pretendía destacar los riesgos habituales en proyectos que por el motivo que sean, no encajan con las premisas de estas metodologías.

Vamos a ver a continuación una segunda parte con nuevos supuestos o problemas que presenta la implantación de una metodología como SCRUM, y que tendremos que considerar a la hora de implantarla.

1. En estas metodologías hay entregas frecuentes y estables, lo que supone probar y estabilizar un producto con un número mínimo de funcionalidades. Por desgracia, a pesar de que las metodologías ágiles se presentan como preparadas para el cambio, tienen el mismo problema que las metodologías tradicionales: las funcionalidades de una iteración pueden cambiar en la siguiente. Al final, una iteración es como un mini proyecto: tiene desarrollo, pruebas, un esfuerzo de integración con la funcionalidad existente, y despliegue. Por mucha involucración que queramos tener del usuario, nada impide que las funcionalidades cambien. Si pensáramos eso, entonces ¿porqué cambian en las metodologías tradicionales? ¿Es que allí el usuario nos ignora, no se involucra, va en contra de sí mismo? ¿Es que los analistas de las metodologías tradicionales son unos inútiles, y los de las ágiles unos hachas?
2. Presupone que no es necesaria la férrea gestión de recursos de otras metodologías “clásicas”. El problema está en cómo coordinar pues los desarrollos con la presencia de personal de sistemas, DBA’s, disponibilidad de recursos hardware, etc… El problema es que estas metodologías ágiles se venden desde el punto de vista del programador. Es el cliente el que debe sopesar si necesita o no un manual, una documentación exhaustiva, un seguimiento del proyecto, un control de costes y gastos...no el equipo.
3. Esta metodología no parece estar pensada para equipos de desarrollo dispersos en el espacio o en el tiempo. SCRUM presupone reuniones diarias cortas y presenciales. Presupone una colaboración de los equipos muy integrada. Eso no quiere decir que no se pueda trabajar en remoto. Simplemente, que en el segundo caso, puede haber dificultades adicionales que en pequeños equipos cercanos, no existen.
4. Se habla de que existe incompatibilidad o contradicción entre el uso de metodologías ágiles y que la empresa esté certificada CMMi. (Actualmente, con CMMi en su versión 1.3, esto ya no es cierto). Por desgracia, existen muchas administraciones públicas nacionales e internacionales que exigen a sus proveedores la certificación CMMi (entre otras). El Manifiesto Ágil en que se basan estas metodologías ágiles, habla de valorar más el individuo y el código frente a documentación (por ejemplo). Pero esto no quiere decir, que haya que hacerse lo que quiera el equipo, sino que ante la falta de otras directrices (es decir, si nadie pide documentación), se de mas importancia al código.
5. Los concursos públicos y muchos clientes privados exigen la certificación CMMi de la empresa, pero es raro que un cliente exija una certificación en metodologías ágiles (que por otro lado no existe tal, sino que es la persona quien se certifica ScrumMaster o equivalente). Esto es un problema para las metodologías ágiles, que chocan ante la falta de un auténtico certificado de empresa. La gente va y viene, pero es la empresa la que necesita ganar proyectos.
6. La falta de documentación detallada es un grave problemas en clientes de sectores legal, financiero, público,… y en general en proyectos grandes que requieran posterior mantenimiento, o en los que simplemente el cliente exige la documentación como parte del contrato.
7. En general, los métodos ágiles promueven la iniciativa e independencia del desarrollador (propietario del bloque funcional que está desarrollando), lo que puede derivar en que se implementen funcionalidades asociadas o paralelas NO SOLICITADAS, que terminen retrasando y complicando el desarrollo.
8. También existen problemas en la implantación de grandes clientes en los que varios proveedores interactúen. En estos casos, es muy importante definir documentación que permita la integración entre proveedores, tema que las metodologías ágiles (puras) suelen dificultar.

Con las que ya había en el anterior post, parece que hay muchas, y así es. ¿Estoy queriendo decir que SCRUM y en general las metodologías ágiles son problemáticas o difíciles de implantar? ¿O ineficaces? Pues no. Problemas hay en todas partes. Lo que no puede ser es que como veo constantemente en la red, vanagloriemos a las metodologías ágiles como el mantra que nos va a salvar del desastre en que nos han dejado las metodologías tradicionales. Hay que tener en cuenta las limitaciones de dichas metodologías, y saber adaptarlas a los proyectos. Si caemos en el purismo  y tratamos de implantar las metodologías por ellas mismas, estaremos perdiendo de vista los objetivos de los proyectos.

Este post no deja de ser una visión general de riesgos como en cualquier otro proyecto, pero esta vez desde el punto de vista de la metodología.

La eficacia de las encuestas de satisfacción

Un tema que se suele dejar de lado a la hora de controlar un proyecto y tener conocimiento sobre él, son las encuestas de satisfacción.

¿Qué son?

Consisten en solicitar feedback al cliente en relación a un producto vendido o servicio prestado. Existe una normativa asociada, que es la UNE 66176, aunque esto no es muy conocido. La norma se llama “Sistemas de gestión de la calidad. Guía para la medición, seguimiento y análisis de la satisfacción del cliente”.

¿Para qué sirven?

Se utilizan para una adecuada gestión de los servicios prestados, a través de la medición de distintos parámetros de satisfacción, su registro y posterior análisis y seguimiento. Si se supone que nuestros desarrollos tienen al cliente como target, deberemos de medir de alguna forma lo bien que estamos acertando en dicho objetivo.

¿Qué deberíamos tener en cuenta?

• No dejar pasar tiempo entre la prestación del servicio y la encuesta de satisfacción.
• No limitarnos a preguntar al cliente por nuestros servicios, sino cruzar esos datos con las incidencias/reclamaciones recibidas.
• Es posible que haya habido incidencias en el servicio que estén sólo en conocimiento de los distintos departamentos de la empresa (ventas, contabilidad, ingeniería, soporte, calidad, etc.)
• Hay clientes que se resisten a rellenarlas (en concreto, en el sector público es muy complicado). Hay que buscar fórmulas de incentivación (asociar la encuesta a la activación de la garantía, o ofrecer pequeños premios, incluirlo como un entregable obligatorio más por contrato, etc.
• La encuesta de satisfacción no debería hacerse en reunión “cara a cara”, ya que puede influenciar las respuestas.
• Es importante el sponsorship de la dirección. Este apoyo es vital para ayudar a gestionar la resistencia de los clientes a rellenar las encuestas.
• En los servicios prestados a medio-largo plazo, es importante que se haga periódicamente, para permitir la mejora del servicio. Si sólo se hace al final, estaremos actuando reactivamente en lugar de proactivamente.
• Incluso en los servicios llave en mano, es importante evaluar los momentos en que se realiza, para evitar subjetividades y dar tiempo a que el servicio postventa actúe adecuadamente.
• Esta información debe registrarse en los sistemas CRM para la adecuada gestión de la cartera de clientes.