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.

¿Hace falta que un Tester sepa programar?

Esta es otra afirmación que me ha sorprendido y mucho, y que he oido mucho hablar de ella durante mis muchos años de práctica. A ver. La técnica que suelen usar los bloggers normalmente es plantearlo como una pregunta. Pero en realidad, muchas veces ya se tiene la respuesta, y el post se limita a dar una avalancha de argumentos a favor de su postura. Vamos a intentar dar una vuelta a los argumentos a favor y en contra. Pero ¿porqué programar? ¿porqué no hablamos de otros conocimientos como: UML, arquitectura, lenguajes de programación, herramientas de desarrollo,  herramientas de testing, sistemas, análisis...? Me da la sensación de que esta afirmación viene siempre de gente con un fondo importante en programación, y que por  tanto da mucho valor a este rol (y no digo que no lo tenga), y que sin querer desprecia el resto de roles en el ámbito del desarrollo software.

Dando una vuelta por internet, me encuentro con argumentos a favor y en contra. Pero sorprendentemente, muchos más a favor. Vayamos viéndolos:

A favor:

• ¿Porqué no? He encontrado este argumento, y bueno...no se han roto la cabeza.
• Depende. Vale. Otro argumento bien fundamentado. No en serio, vamos a intentar profundizar sobre éste, ya que soy partidario de él parcialmente. Lo haremos durante el post.
• Todo ayuda. Ahí estoy de acuerdo. Cuanta más formación, mejor. Pero más bien la duda sería: ¿qué es mejor? ¿Que esté formado en programación y desarrollo (específico en lenguaje, en plataforma, en arquitectura...)? ¿O que esté formado en el negocio del cliente, que conozca su forma de trabajo, sus necesidades, su lenguaje específico? ¿Qué debe hacer realmente un tester?
• Para poderle explicar al programador dónde está el fallo, ya que el conocimiento de programación le puede hacer inferir qué problema tiene, y así le ayuda a corregirlos antes. Este argumento me sorprende y mucho. Salvo que el tester sea uno de los programadores, y conozca la arquitectura en detalle, es difícil (por no decir imposible), que el tester sepa qué y porqué falla algo. Estoy de acuerdo, que cuando con nuestra experiencia, los que hemos programado hacemos pruebas, podemos tener sospechas de porqué falla algo. Pero de ahí, a que realmente sea útil esa sospecha, es concedernos un criterio excesivo.
• Para poderle aportar al programador experiencia sobre cómo corregir sus fallos, de forma que su código sea más seguro y fiable. Esta también me ha sorprendido. Entonces qué queremos ¿testers o formadores? Esta es la visión típica de la persona que ha probado mucho, pero también ha programado mucho. Pues claro que tendrás experiencia en fallos/soluciones típicas. Pero es mucho más complicado que eso. Si estamos en un mantenimiento, no vamos a tener tiempo de tonterías: hay que resolver la incidencia para cumplir el ANS (Acuerdo de Nivel de Servicio). Y si no es un mantenimiento, si de verdad tenemos tiempo de ponernos a hablar y discutir con el programador todos y cada uno de los fallos encontrados....yo quiero trabajar en ese proyecto, y lo quiero YA. Aquí se mezclan churras con merinas. De acuerdo que programadores que han hecho mucho testing, son los más adecuados para transferir ese conocimiento. Pero eso no significa que el tester deba hacerlo, porque la forma de corregir los defectos puede depender de la arquitectura específica, y el tester no tiene porqué conocerla. De hecho, en la mayoría de los casos, lo que interesa es presentar un informe de resultados de defectos al cliente y/o al jefe de proyecto. La solución de los problemas, su prioridad, etc., dependerá de muchos factores (y no tiene porqué ser el criterio del tester, y mucho menos del programador).

En contra:

• No debe condicionarse al tester con el conocimiento interno de la aplicación. Las pruebas deben realizarse siguiendo las indicaciones del plan de pruebas. Ahora bien, si no hay plan de pruebas, no hay casos de pruebas, ni datos de prueba, ni resultados esperados…no necesitamos un tester que sepa programar. Necesitamos a Dios.
• El conocimiento de la aplicación (léase documentación, arquitectura, análisis, etc), puede estar obsoleto. Si defendemos las metodologías ágiles, es posible que el tester no cuente con documentación actualizada de “qué hay dentro”. Si aceptamos que esto sea así, ¿cómo vamos a exigirle que entienda algo que seguramente no le sirve? Dejémosle que pruebe lo que debe probar, y que no esté pensando en "lo que hay detrás".
• ¿Debe alguien que se prueba la ropa saber coser? ¿o hacer pantalones, o cortar telas…? ¿Deben los inspectores de calidad de un edificio saber poner ladrillos, etc? ¿Debe un técnico de ITV saber construir un coche? (puede que ni siquiera le haga falta saber conducir)
• Un tester debe ser objetivo. Su resultado es un informe de pruebas. Si su resultado son consejos a los programadores, tendremos a un arquitecto, analista o programador “power”, cuyo tiempo estaría mucho más aprovechado revisando la arquitectura y el código (o formando al equipo), que probando.
• A un programador difícilmente le puede aportar un resultado de pruebas del estilo: "yo creo que te falla la punta de la trócola cuando el cimborrio izquierdo recibe un valor trambostático". Si la conclusión del tester no es objetiva, acabaremos creando una cadena de opiniones que finalmente perviertan el resultado de la prueba, y por tanto, la invaliden. Al programador hay que darle algo objetivo: se da el fallo x cuando en la situación y meto el valor z. Esto es algo repetible y objetivo. Por ejemplo: no le puedo decir: "me parece que en algunos ordenadores el color de fondo es más claro". Sino que si soy un tester debo decir: "en las pruebas X, en el ordenador Z, el color de fondo se ve más claro".  

Yo creo que la conclusión sería ésta:

• Si el equipo y el proyecto son pequeños, no te queda otra: no es operativo tener un señor sólo para probar, a no ser que sea un recurso compartido entre proyectos. Aquí normalmente no es que haga falta, es que simplemente este tester tiene también otros roles.
• Si el proyecto es mediano o grande, se hace necesario un tester especializado en esa tarea. Y aquí es cuando es menos significativo que el tester sepa hacer otras tareas.
• Si sólo llevamos un proyecto en la empresa: aquí la visión es otra: necesitas alguien que haga el testing, pero que también te de soporte a más tareas. Además, es más fácil que el tester esté versado en el negocio del cliente, la arquitectura, etc, porque sólo hay 1.
• Si llevamos varios proyectos en la empresa: si el tester se comparte entre varios proyectos, es más difícil que esté puesto en el negocio, en la programación, la arquitectura...ya que pueden ser muy diferentes. Si el tester no se comparte entre varios proyectos, sino que hay uno por proyecto, entonces sí que es posible que aporte algo más.

Defectos de Scrum (I)

Recientemente se habla mucho de las ventajas de las metodologías ágiles, y en concreto de SCRUM. Sin embargo, aunque todos tenemos claro que no existen "balas de plata" que nos permitan solucionar las cosas como si cual varita mágica se tratasen, no se oye hablar apenas de los defectos de SCRUM.

¿Ah, pero es que tiene defectos? 
Pues claro. No existen metodologías todoterreno al 100% Vayamos viendo algunos. No con ánimo de decir: "mirad lo malo que es SCRUM" sino más bien "tened en cuenta esto en caso de que aplique a vuestros proyectos". Al final, lo importante es saber detectar los riesgos y mitigarlos adecuadamente.

1. En general, dificultad de aplicación en grandes proyectos.
2. Se requiere de un “agile champion”, experto en la metodología que monitorice su cumplimiento.
3. Parte del paradigma consiste en usar el método “tal cual”, evitando adaptarlo a la empresa (supuestamente esto saca a la luz problemas en la metodología de desarrollo existente). Claro, si por otro lado arrancamos con el método ya adaptado a la empresa, es posible que no estemos aprovechando las ventajas de la metodología ágil.
4. Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio de entrega cerrados por contrato
5. Presupone que los requerimientos cambian, pero no de forma que el cliente acepte un diseño funcional/técnico.
6. Presupone que el equipo está muy formado y motivado
7. Presupone que el cliente está muy involucrado en el desarrollo, participa de forma activa y continua, y revisa frecuentemente el avance de la funcionalidad conforme salen a la luz los sprints. Esto sin embargo no parece producirse en la mayoría de nuestros proyectos: el cliente participa, pero no hasta el punto de dedicar tiempo y recursos para revisar pequeños avances en el desarrollo.
8. Presupone que el cliente no exige ni necesita toda la documentación que manejan actualmente las empresas y que las diversas normativas internacionales requieren.

Parece que hay muchas, y así es. Pero esto 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.

Para ver la segunda parte de este post, puedes hacer clic en este link.

Más de 1000 visitas

Pues vaya, ya hemos superado en este blog las 1000 visitas (quién lo iba a decir). La verdad es que un blog dedicado a guardar mis memorias y experiencias, tiene más de un seguidor. Parece que ya es algo más que una bitácora personal.

Bueno, vale, he tenido que dar dinero a la gente por leer mi blog, y he llegado a usar anuncios de páginas eróticas desviadas a este blog para conseguir visitas. ¡Eh, que no, que era broma! A ver si la voy a liar por hacer la gracia...

Pues me alegro mucho. Si de verdad sirve de algo, estará bien que la gente tenga en cuenta mis opiniones (ojo, he dicho en cuenta: como siempre, y como dirían en aquella serie "expediente X"...la verdad está ahí fuera...).

Yo lo seguiré disfrutando mientras lo escribo. Espero que tú, amigo lector, disfrutes también (estés de acuerdo, o en contra de mis reflexiones). Saludos.

¿Cómo se mide la calidad?

... O más bien debería ser más específico: ¿cómo se mide la calidad del software?

Parece ser que la calidad es el atributo favorito a la hora de ser incluído en propuestas y propaganda variada de los productos software, pero nunca nos hemos preguntado ¿qué es la calidad? ¿cuánta calidad tiene? ¿Si no puedo medir la calidad de un producto para qué me sirve que lo pongan en un folleto o hablen de él los comerciales? (si hasta los terremotos tienen una medida universal gracias al señor Richter).

Hace poco leía un blog y me sorprendía la frase: "no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no calidad". Por desgracia para el mundo del desarrollo de software, no es así. Claro que se puede ahorrar calidad. Simplemente, eliminando las actividades que le aportan y aseguran esa calidad.

¿Dónde está la calidad?:

• En arquitecturas conocidas, probadas y para las que se han obtenido datos de experiencias (buenas prácticas, problemas a evitar, cómo mejorar en el futuro, etc.) Es lo que se conoce como mejora continua.
• En las metodologías de trabajo conocidas y probadas. Y no sólo hablo de desarrollo. También de repositorios de documentos, tener claro quién es el responsable de qué...El tener el control de qué hay, dónde está, cómo acceder a ello, y cómo usarlo.
• En las pruebas del software antes de la entrega al cliente.
• En las pruebas del software en la implantación.
• En las auditorías de calidad.
• En las auditorías internas del equipo de desarrollo.
• En las revisiones entre pares (sí, sí, las Peer Review famosas).

¿Cómo medir la calidad? Pues midiendo la calidad de nuestro proceso de desarrollo:

• Calidad del análisis: ¿cuántos requisitos se han modificado? ¿cuántos se han añadido? ¿cuántos se han eliminado?
• Calidad del diseño: ¿cuántos cambios se han producido en el diseño técnico?
• Calidad de la arquitectura: ¿cuántos cambios de arquitectura se han producido?
• Calidad del desarrollo: ¿cuántos defectos se han detectado en pruebas unitarias?
• Calidad de las pruebas: ¿cuántos defectos ha detectado el cliente en producción vs defectos encontrados en pruebas en general? ¿cuál es el ratio nº defectos encontrados vs horas invertidas en pruebas?

¿Y la calidad del producto? Pues aunque está relacionado, tendríamos otros factores:

• Tiempo que lleva el cliente usando el producto. En mi opinión no es significativo. Por razones varias, el cliente puede verse obligado a usar un pésimo software. Realmente el problema está en la competencia y en el precio. Si es suficientemente barato un software alternativo, poco importará la calidad de nuestro software, es probable que el cliente acabe actualizándolo por otro distinto, si los costes encajan.
• Satisfacción del cliente. Bueno, volvemos a la cruda realidad. ¿Quién es el cliente? ¿El director general? ¿el que compró el software? ¿El jefe de departamento que lo usa? ¿Los usuarios finales? Al final, la satisfacción es difícil de medir. Bueno, para eso podéis leer mi anterior blog sobre encuestas de satisfacción.
• Número de fallos en producción. Realmente no sólo es una medida de calidad del software, sino de su proceso de desarrollo.
• Número de clientes. Pues ahora mismo se me ocurren unos cuantos ejemplos de software vendido por millares (por no decir millones), y de calidad pésima. Al final, el número de clientes lo deciden una serie de factores ajenos a la calidad: precio, esfuerzo comercial, renombre de la marca comercial, etc.
• Número de años en uso. Uf. Por esa regla de 3, tendríamos que el software hecho en cobol en los años 80 debía de ser de calidad asombrosa, porque se ha usado hasta hace muy poco, o sigue en uso. A la hora de la verdad, este factor no depende de la calidad, sino de la competencia, de la facilidad de actualizar el producto. Si encontramos repuestos de ruedas, las cambiaremos fácilmente. Si no encontramos repuestos, pues...habrá que fastidiarse y seguirlos usando (independientemente de su calidad).

Lo importante es destacar que no tendremos calidad del producto basándonos únicamente en tener equipos de personas buenas y maravillosas, todos senior y super-motivados, y blah, blah. La calidad se consigue a través de un método, proceso y control. Quien confunde el control con desconfianza en el equipo, tiene un problema (y más vale que se lo haga mirar).

El siguiente link está en la línea de lo que digo, aunque hay varios argumentos en los que no estoy 100% de acuerdo (ojo, no digo que él esté equivocado):
http://geeks.ms/blogs/msierra/archive/2008/08/25/_BF00_C_F300_mo-se-mide-la-calidad-en-el-software_3F00_.aspx

Los 7 secretos del éxito.

Tras este pretencioso titular, encontramos siete recomendaciones para ayudarnos a establecer el éxito en nuestro trabajo, proyectos, etc. Aviso a navegantes de que si os parece rayante, os animo a leer el artículo original (url al final), y entonces me decís. Ale, ahí vamos.

Ya es hora de enterrar la idea de que el éxito, en cualquier profesión, es el resultado de suerte, oportunidad y esfuerzo. No hay nada más equivocado que esto. Pensad en ello. ¿cuántos profesionales conocéis que trabajen increíblemente duro, dedicando jornadas interminables, y no consiguen el éxito? El esfuerzo, tiene un papel en el éxito, pero el esfuerzo por sí solo no te va a hacer destacar. ¿Dónde se encuentra pues el catalizador del éxito?

1. Empieza por conocer con detalle lo que quieres.
Las personas de éxito, tienen muy claro en qué consiste el éxito que desean conseguir. Es la única forma de poder enfocar sus esfuerzos en su consecución.

2. Visualízate consiguiendo los resultados deseados
Los grandes ganadores se ven a sí mismo ganando cada día. Visualizar, es el camino a materializar lo deseado.

3. El éxito viene a través de una confianza férrea en tí y en tus capacidades
Los ganadores creen en su éxito, y esto acaba volviéndose realidad. Un error típico suele ser el creer que si se van obteniendo suficientes capacidades durnate nuestra carrera profesional, llegará el éxito. Sin embargo, la formación y la adquisición de capacidades no garantiza el éxito. Lo lo que lo garantiza está en el hecho de creer en él.

4. Los top-performes hacen las cosas como si ya hubieran alcanzado los objetivos que realmente quieren.
Los ganadores piensan, trabajan, hablan, juegan y hacen todo como la persona que quieren ser. Eso significa en enfocarse en las tareas como si ya hubiéramos estado donde queremos estar.

5. Toma la total responsabilidad de tu destino
¡Los ganadores obtienen resultados! No se trata de dar respuestas, de ofrecer EXCUSAS. Los ganadores no pierden de vista sus objetivos, y simplemente los cumplen.

6. Construye asociaciones de alta dependencia
Nadie en el mundo actual logra el éxito por sí solo. Simplemente hay mucho que entender y las situaciones cambian constantemente. Las personas de éxito siempre dedican más tiempo a otras personas de éxito. Se atraen. Van a los mismos eventos,  comen en los mismos restaurantes, juegan juntos al mismo deporte... Elige tus relaciones sabiamente.

7. Aporta valor por encima del que solicites
Hazte la pregunta: “¿Cómo puedo aportar más calidad? ¿Qué puedo hacer para hacerlo mejor?" Los ganadores siempre aportan un valor mkuy superior del que piden a cambio.

Fuente: http://build-business.info/seven-secrets-of-top-performers/

Personal Brand Online

Como respuesta a toda la fiebre de estar conectados y crear una "marca personal" online, Dilbert ataca de nuevo como sólo él puede hacerlo. Nuestra tira cómica favorita se sigue superando. Podéis seguirla como siempre en www.Dilbert.com

Hay otro problema que vengo observando recientemente, y es que en la práctica, hoy en día hay mucho más interés en aparentar, y tener una "marca personal", que realmente realizar ningún tipo de aporte. Es por eso que encontramos tantos blogs, twitters y facebooks repetitivos y amiguismos por doquier.

De ingeniería y programación

Leo un artículo, que me recuerda un antiguo mito, que sigue siendo una poderosa lacra en nuestra vida de desarrolladores de software...¿o debería decir ingenieros de software?

El problema es que se quiere evitar el uso de técnicas de ingeniería, el uso de la aproximación científica y el acopio metodológico tradicionalmente asociados al término ingeniería. Sin embargo, no son pocos los que se apuntan al carro de usar la coletilla "ingeniero" en su título o en su actividad, y defienden lo que una ingeniería debe ser (o al menos lo que ellos quieren que sea, acorde con sus expectativas).

Vemos habitualmente en blogs y artículos, la defensa de frases como "construir software no es como fabricar coches o casas". Normalmente los argumentos ofrecidos intentan separar el mundo de la ingeniería tradicional, con el de la construcción del software (aquí he evitado explícitamente el uso del término ingeniería del software). Lo peor de todo, lo que resulta más flagrante, es que se pretende apoyar el uso y efectividad de las metodologías ágiles como resultado de todo esto. Las técnicas ágiles están ahí, y son tan buenas como adecuadas en la situación concreta en que de buenos resultados. Pero eso no convierte en ciertos los argumentos.

Veamos algunos argumentos:

•  Los coches se fabrican en serie. Son todos iguales. El software es siempre distinto. Falso: realmente, al construir coches, es exactamente igual que en el software. Tenemos máquinas, robots y técnicas de ingeniería para tratar de que todos los coches salgan parecidos, pero es inevitable que todos salgan realmente distintos. Donde entra la ingeniería, es en tratar de que todos sean razonablemente parecidos, dentro de unos márgenes.
• La ingeniería es para fabricar "en serie", "como churros", al contrario que el software, que es siempre distinto. Falso: la mayoría de creaciones en el mundo de la ingeniería son únicas: puentes, pasos elevados, máquinas, mecanismos, etc. La visión de la ingeniería enfocada a la producción en serie es una manipulación enfocada única y exclusivamente a crear la ilusión de que la ingeniería y el software son radicalmente distintos.
• Las ingenierías clásicas precisan mucho de un diseño previo a la construcción, el disponer de los planos del arquitecto siempre antes de empezar el edificio. Falso: ¿es innecesario el tener las especificaciones de lo que hay que construir? Por supuesto que podemos construir casas sin planos, sin cimientos, etc. Eso no significa que la experiencia recomiende lo contrario.
• Los planos para construir son precisos. Falso. Existe una cosa en ingeniería llamada tolerancias. Significa simplemente que como las cosas se construyen de forma más o menos artesana, existen unos límites razonables entre lo que el ingeniero o proyectista desea, y los resultados reales obtenidos por la persona que realiza la tarea. Esto significa que el ingeniero desea un resultado, pero es consciente que al llevarlo a la práctica habrá desviaciones. Los planos pretenden que estas desviaciones, estén "contenidas". Además, los planos no son siempre tan precisos, puesto que muchas veces se deja en manos de quien fabrica, algunas tomas de decisiones, siempre que no se altere el resultado deseado.
• En el software, al contrario de la ingeniería, es casi imposible que no cambie el diseño. Falso al compararlo con la ingeniería. En ésta, incluso al fabricar coches (que nos parecen todos iguales aunque esto no sea así), las especificaciones cambian durante la creación de las máquinas que van a servir para construir los coches, durante la instalación de esas máquinas, pero es que también durante la vida del modelo de coche. Esto se ve incluso en las casas: los planos cambian durante la construcción (e incluso después).
• El sueño de construir software como en una cadena de montaje no es realista. Inexacto: no tiene nada que ver la fabricación en serie con el tema a tratar. Una cadena de montaje es un resultado de aplicar prácticas de ingeniería, pero no es la ingeniería. Realmente una cadena de montaje sería un software de creación de software (como puede ser Genexus). Alguien ha construído la cadena de montaje, que esa sí es el fruto del trabajo de ingeniería. Existen aplicaciones que son "fábricas de software", y que sí que tienen siempre el mismo resultado para los mismos datos y situaciones de entrada (de hecho mucho más que los coches en el caso de la fábrica, que como hemos visto, no son nunca iguales).

¿Qué ocurre entonces? ¿Estamos diciendo pues que son exactamente iguales la construcción del software y la ingeniería tradicional? Pues va a ser que no. Lo que significa es que la construcción del software no debe prescindir de una herramienta fundamental como son las técnicas de ingeniería, la planificación, etc. Por supuesto que podemos hacerlo. Como es posible hacer cualquier cosa. Pero vivimos en un mundo en el que no es despreciable el obtener resultados predecibles y controlados (dentro de unos márgenes, claro. Todo tiene su tolerancia). Las empresas necesitan prever los gastos que van a tener, porque normalmente (y digo normalmente), los empleados no estamos construyendo software sólo por amor al arte, sino que exigimos una remuneración a cambio. Y una remuneración fija. A ver si ahora vamos a inventar el cobro del sueldo "iterativo", basado en las funcionalidades que hemos completado.

El día en que la premisa fundamental sea tener un producto en el mercado a toda costa...habremos perdido una parte esencial de nuestra profesión.

Procrastinación (III): la multitarea

(fuente de la imagen: DevianArt)
Y no hay dos sin tres. Tras el éxito de los dos primeros artículos sobre la procrastinación, me he animado a un tercero, a ver si dejamos el tema cerrado de una vez.

Actualmente encontramos una tendencia de hacer muchas cosas a la vez. Nos gusta ser "multitarea", y nos sentimos orgullosos de ello. Pero...¿esto es realmente así?

Hay muchos detractores de esta supuesta multitarea, y entre ellos, existen muchas personas que aseguran que las personas que realmente se sienten multitarea, realmente se encuentran en uno de estos dos escenarios:

• Una tarea real y muchas distracciones
• Varias tareas, cuyo nivel de prioridad y atención cambian a lo largo del día.

En el fondo, cuando estamos haciendo varias cosas a la vez, lo que en realidad ocurre es que estamos procrastinando. Estamos restando la atención de una tarea principal, quizá la que realmente es prioritaria y la que tenemos que resolver.

Para realmente ser multitarea, el truco está en hacer una sola cosa a la vez, enfocando adecuadamente nuestro tiempo y esfuerzo en ella. Una adecuada planificación de las tareas durante el día, será la única forma en que realmente podamos invertir adecuadamente nuestro tiempo, y llevar a cabo varias tareas "a la vez".

Por ejemplo, actividades paralelas habituales como atender facebook, el correo, twitter, linkedin, etc., no son más que ladrones de tiempo, y fuentes de procrastinación. Lo mejor es establecer horarios específicos para atender estas tareas. Eso de estar permanentemente encima de la casilla de actualizar el email es una locura.

¿Que queremos seguir llamándonos multitarea? Adelante. Después de todo, nos engañamos con cosas peores en esta vida.

PMO: Introducción

Uno de mis últimos proyectos está siendo mi participación en una PMO. Vamos a ver qué es.

Una PMO es una Oficina de Gestión de Proyectos (las siglas vienen del inglés Project Management Office).

Este es el primero de una serie de artículos sobre PMO:
PMO I - Introducción
PMO II - Descripción
PMO III - Ventajas de una PMO
PMO IV - Inconvenientes de una PMO

Para qué sirve una PMO
Si ya tenemos un jefe de proyectos, ¿para qué podemos querer una PMO? ¿Acaso supone más burocracia y simplemente es otro nivel por encima del jefe de proyecto?
Las responsabilidades de una PMO y de un jefe de proyecto son muy diferentes. Una PMO da respuesta a una serie de cuestiones que se plantean en las empresas y que un jefe de proyecto no proporciona:

• ¿Cómo alinear los proyectos con los objetivos de la organización?
• ¿Cómo medir de forma uniforme los proyectos en mi organización? ¿Cómo mido su valor, su coste, su rendimiento en términos homogéneos?
• ¿Cómo controlo los riesgos de alto nivel, o los riesgos que afectan a varios proyectos?
• ¿Cómo controlo las dependencias entre proyectos?
• ¿Cómo priorizo los proyectos conforme a los objetivos organizativos?
• ¿Cómo gestionar la capacidad y el cambio en los diversos proyectos?
• ¿Cómo detectar los proyectos con mejor y peor desempeño? ¿Cómo reaprovechar las mejores prácticas de los proyectos con mejor desempeño? ¿Cómo evitar los problemas de los proyectos con peor desempeño?

Lo normal es que si vamos a implantar una PMO, pensemos en los siguientes grupos de procesos:

• Seguimiento de proyectos
• Comunicación
• Gestión del conocimiento
• Gestión de proyectos y recursos

Hasta aquí una breve introducción. Dejemos para otro día el detallar las actividades y procesos de una PMO. Nos vemos.

Nueva Dotnetmania

La revista DotNetMania, ahora es DotNetMania+
Han migrado de web, a una nueva url: http://www.dnmplus.net/

Además, por tiempo limitado, tendrán sus contenidos abiertos, aunque ya están preparando ofertas para suscriptores.

Se trata de un portal orientado a programadores, arquitectos en tecnologías .Net, e incluyen novedades, artículos, cursos, vídeos, entrevistas, todo ello enfocado al mundo .Net.

¿Cuándo se puede dar por terminado un proyecto?

Vaya. Esta vez he dejado pasar unos cuantos días desde mi último blog. Y es que mi últimos proyectos me estaban absorbiendo por completo.

Vamos a tratar un tema que tanto en las metodologías, como en los distintos entornos de trabajo, siempre se da por supuesto, y se deja un poco al azar. Y es que ¿tenéis claro cuándo se puede cerrar un proyecto?

Parece algo trivial, ¿no? Cuando el proyecto se termine...se habrá acabado y por tanto, se cierra. Pues no.Vamos a introducir algunos conceptos para entender de qué hablamos:

• Cierre: se denomina cierre de un proyecto, al final del desarrollo. En realidad, el desarrollo no termina cuando se produce la subida al entorno de producción. Un desarrollo termina...cuando así lo determina el contrato. Y es que por contrato (y así lo suelen recoger las metodologías), se incorpora un período de soporte distinto del de mantenimiento. Se le suele llamar soporte post-implantación (aunque el nombre puede variar según la metodología que tratemos).
• Soporte: como acabamos de comentar, se llama soporte al período posterior a la puesta en producción (el Go-Live en tecnologías SAP). El soporte lo realiza el mismo equipo de desarrollo, y aunque sus actividades suelen ser similares a las de mantenimiento, existen diferencias con la fase de mantenimiento. Por ejemplo, no aplican los ANS.
• ANS: acrónimo de "Acuerdos de Nivel de Servicio". Son las condiciones de servicio que por contrato, estipulan la forma de colaboración entre el proveedor del servicio y el contratista. Suele incluir penalizaciones y/o bonificaciones en función de varios parámetros como pueden ser el tiempo de respuesta, la calidad del servicio, etc.
• Mantenimiento: es la fase del ciclo de vida del software que tiene lugar tras el cierre (no tras la puesta en producción). Tras la puesta en producción, hay un período de soporte en el que el proveedor del desarrollo software ha estabilizado la solución, se produce el hito del cierre, y después, el inicio de la fase de mantenimiento. Esta fase de mantenimiento la puede llevar a cabo un proveedor distinto del de desarrollo (otra empresa diferente).

Y tras este rodeo de explicaciones, volvamos al tema. Tras el desarrollo, hay un período de soporte, normalmente de tiempo limitado. Pero...¿debemos dejar que un software erróneo, inadecuado o inestable pase a la fase de mantenimiento? ¿Cómo sabe el cliente que el producto que ha recibido y que ya está en producción, está como para dar salida al proveedor de desarrollo? Recordemos que es en este punto cuando suele terminar de cobrar el proveedor de desarrollo. El cliente no querrá terminar de pagar por un producto hasta que este no esté correcto, pero...¿qué entendemos por correcto?

Es en esta situación, en la que un proceso de cierre entra en acción, definiendo una serie de parámetros que permitan de forma cuantitativa identificar si la solución desarrollada está Ok o no. No se trata de que no tenga errores. De eso, ya se encarga el mantenimiento que se hace tras el cierre del proyecto. Se trata de demostrar estabilidad y madurez tanto en la solución desarrollada, como en su implantación.

Normalmente, en todas las metodologías, la forma de realizar verificaciones (peer review, auditorías, milestone reviews, etc) es mediante checklists de control. Sin embargo, estas checklists de control no suelen incluir factores cuantitativos. Aquí es donde las métricas suelen venir al rescate, incorporando factores cuantitativos.

ASP.NET MVC (II) Ventajas

Vamos a continuar con esta serie de posts sobre ASP.NET MVC. Puedes ir también a los artículos 1 y 3.

¿Qué ventajas nos ofrece este modelo MVC en ASP.NET?

• Es extensible
• Es amigable con SEO (las url son muy sencillas, e implementan las acciones y parámetros de forma natural, facilitando su acceso mediante buscadores) y REST
• Nos da un enorme control sobre la salida
• Nos da un enorme control sobre el flujo
• Nos separa de forma natural las responsabilidades
• Facilita la prueba de nuestras aplicaciones de formas que en el mundo WebForms no podríamos ni imaginar.
• Se sigue basando en todo el framework existente ASP.Net (masterpages, membership, etc.)
• Se integra con el funcionamiento natural de la web, sin metáforas que nos acaben complicando la vida en cuanto tratamos de realizar cosas más complejas
• Estabilidad y fiabilidad: se basa sobre el más que probado framework asp.Net, e integra casi cualquier elemento que nos pueda hacer falta
• Facilita los cambios (sí, esta vez de verdad, de forma muy superior a como se facilita en las aplicaciones N-tier)
• Facilita separar el trabajo de los diseñadores, que pueden editar directamente la capa de presentación, sin tener que pasar como ocurre con Silverlight con herramientas específicas de diseño.
• Se integra de forma natural con jQuery

¿Debemos migrar las aplicaciones Webform existentes?
No. Para nada. En todo caso, habría que evaluar si los problemas y cambios que nos solicitan en el mantenimiento de las aplicaciones antiguas, nos justifican el cambio.
Lo que sí es cierto, es que la migración a MVC ofrece de forma exponencial unos enormes beneficios de cara al mantenimiento.

Así no se puede trabajar

Esto no es serio. Así no se puede trabajar. Hoy traigo un mensaje (cuadro de diálogo) de Microsoft Powerpoint, que me ha hecho desear asesinar a alguien. Esto no está sacado de ningún sitio web, ni na. Lo he sufrido en mis carnes. Aún sigo sin saber el motivo ni la información perdida. El mensaje es:

Para los que no estéis puestos en inglés, os traduzco lo que pone tal y como lo he sentido:

• Powerpoint ha encontrado contenido en este fichero, que no entiende.
• Por tanto, Powerpoint ha decidido borrar este contenido, y no se puede recuperar. Ole, ole y ole tus...pues eso.
• Te interesaría revisar esta presentación POR SI ACASO detectas algo cambiado o borrado

Pero si no es mía la presentación! Pero qué narices me está contando! Pero cómo voy a saber si algo falta o no! Y ni siquiera puedo contactar con su autor!!!!!

Queridos desarrolladores de Microsoft Powerpoint: GRACIAS. Gracias por hacerme sentir idiota. Gracias por dejarme alucinado con mensajes tan retorcidamente creativos.
En fin, que así no se puede trabajar.

Chuck Norris Exception

He encontrado en este link esta pequeña perla (aunque me suena, quizás sea vieja):

Instalación

$ npm install ChuckNorrisException

Uso

var ChuckNorrisException = require('ChuckNorrisException');

var imFeelingLucky = true;
try {
  if (imFeelingLucky) throw new ChuckNorrisException();
} catch (e) {
  // FAIL: You cannot catch a ChuckNorrisException
}

Si intenta lanzar una ChuckNorrisException resultará en un fallo y se cerrará su programa.
¿El motivo? Porque usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
Los siguientes errores se producirán si se intenta tamaña estupidez.

• Usted no lanza a Chuck Norris....Chuck Norris le lanza a Usted!!!
• Chuck Norris escribió "Hola Mundo" una vez...y se llamó Unix.
• Chuck Norris le pateará el culo asíncronamente

Original: http://criso.github.com/ChuckNorrisException/

Lloremos una gran pérdida

Bueno, hoy 13 de Octubre, hemos de llorar una gran pérdida para el mundo del desarrollo de software. Su contribución ha sido incalculable, ya que ha influido en muchísimos aspectos técnicos que aún están en boga hoy en día, tantísimos años después.

NO, no me refiero a Steve Jobs (también, recientemente fallecido, y contra el que nada tengo).

Me refiero a Dennis Ritchie, autor que ha influido en más de una generación de universitarios (no sólo informáticos), a través de su casi obligatorio título "El lenguaje de programación C" de Kernigan & Ritchie. Algún otro título suyo, también resultó de lectura obligatoria en la universidad, como aquel sobre Unix, ya que por otra parte, este señor fue COAUTOR del sistema UNIX. Sí, sí, el que aún se sigue venerando como fuente de Linux y otros dialectos.

Descanse en Paz

Novedades en el ASP.Net Framework 4.0

No sólo de MVC vive el hombre, así que antes de que llegue la siguiente versión de Visual Studio y otro nuevo Framework, vamos a repasar algunas de las novedades que llegaron en la última versión del .Net Framework 4.0 para ASP.Net.

• Nuevas propiedades en controles para mejorar la gestión del ViewState. Ya no sólo se gestiona a través de la  propiedad [EnableViewState].
• Mejoras en la cache: opción de compresión en las caché "Out-Of-Process" y nuevas opciones de customización de caché mediante la creación de custom providers. Esto puede ser especialmente útil en entornos con poca memoria.
• Nuevas opciones para renderizar el código html mediante las buenas prácticas de accesibilidad recomendadas, evitando tablas, estilos inline, etc. Para ello, los controles existentes (como el control menu), han incorporado nuevas opciones de renderizado. Entre otras, la propiedad [IncludeStyleBlock] (true/false), ahora permite habilitar o inhabilitar la inclusión del bloque de estilos inline, tal y como se hacía en el framework 3.5.
• Nuevas opciones para facilitar y automatizar el nombrado de elementos HTML (los IDs), que hasta la versión del framework 3.5 eran prácticamente imposibles de predecir. Es decir, el framework los nombraba de forma que no facilitaba la inclusión de código Javascript, ya que éste necesita predecir los nombres de los elementos HTML a los que se quiere acceder.
• Validación de peticiones extensible. En el framework 4.0 se validan todas las peticiones, aunque es posible configurar el comportamiento y extender el comportamiento mediante validación de cabeceras, URL, parámetros, etc.
• AJAX: soporte para jQuery de serie de Microsoft, soporte para plantillas de lado cliente.
• Disminución del tamaño de los web.config
• Query Extenders
• Expresiones HTML nuevas para codificación: <%: %>
• RedirectPermanent
• Despliegue automatizado de aplicaciones Web con transformación de configuraciones.

Este post es de resumen, desde luego que lo que tocaría es ahora ir tocando todos y cada uno de estos temas. Algunos, como el nuevo soporte de jQuery, son apasionantes. A ver si le puedo sacar algún ratito y podemos detallar si no todo, alguno de ellos. De todas formas, antes me gustaría irme quitando también la serie de posts sobre MVC. En fin: pasito a pasito.

El framework CLSA .Net

Lleva ya mucho tiempo esto del CLSA dando vueltas por el mercado.

¿Que cómo lo descubrí? Yo andaba buscando material para frameworks que nos ayudasen a mejorar la metodología de desarrollo en mi empresa actual. El hecho de tener CMMI nivel 3 está muy bien, pero si no das a los equipos de desarrollo formas de trabajar "reales", al final corres el riesgo de convertirte en un teórico de la tecnología.

El caso es que mientras buscaba frameworks de pruebas y modelos de negocio, me encuentro una referencia a CLSA y el señor Rockford Lhotka.

Lhotka es autor de varios libros sobre desarrollo .Net, y autor del framework CLSA que está orientado al desarrollo rápido de aplicaciones. CLSA es un framework que facilita la construcción de la capa lógica de negocios para aplicaciones Windows, Web, orientadas a servicios, y de flujos de trabajo.

CLSA.Net simplifica y estandariza la creación de capas de negocio en .net

La implementación de CLSA para .Net comenzó en 1999, y sigue evolucionando todavía hoy con soporte para Visual Studio 2010, Microsoft .NET 4.0, Silverlight 4, y Windows Phone 7.

¿Porqué la desestimé? En su momento, estuve evaluando la capacidad de este framework para su uso e integración con nuestra metodología .Net, pero me pareció demasiado "customized". Efectivamente promete flexibilidad, pero a costa de hacer el desarrollo muy dependiente de este framework. En absoluto me pareció poco potente ni le encontré fallos significativos en el tiempo que le dediqué, así que os animo a los que estáis evaluando frameworks de este tipo a que le déis una oportunidad.

Esto acaba aquí. Si esperas que te detalle información sobre el uso de este framework sin haber tenido yo experiencia personal real, estás listo. Para eso ya tienes otros blogs. Cuidaros.

ASP.NET MVC (I) Introducción

Introducción
Hoy vamos a ver una introducción a lo que espero sea una larga serie de artículos sobre ASP.NET MVC.
Podéis saltar directamente a las partes 2 y 3
Aquellos que vengáis del mundo Java prácticamente veréis a MVC como un estándar del día a día. Pero en el mundo .Net, no es así.

El problema es que en .Net hemos sufrido de la obsesiva directriz de Microsoft en el sentido de OCULTAR la complejidad y la esencia de las cosas, encapsulándolo todo en nuevas metáforas supuestamente más sencillas. Eso ha funcionado muy bien, consiguiendo en el modelo ASP.NET Webforms una forma relativamente simple de construir aplicaciones Web. Pero no deja de ser una abstracción, una metáfora. Cuando intentamos bajar al nivel del código Javascript es cuando realmente vemos que la metáfora de los WebForms se cae con su propio peso y nos ha estado ocultando una realidad compleja, pero que en otras tecnologías como Java, se maneja de forma natural.

Desde hace ya algún tiempo, ASP.NET MVC se ha introducido como una forma de volver a las raíces, de resolver las dos principales problemáticas que existían en los desarrollos web:

• No ocultar la naturaleza de la web mediante falsas metáforas, que realmente nos complicaban mucho más la vida, como el uso de ViewState, etc.
• Los flujos de las aplicaciones no están integrados de forma natural en las estructuras y arquitecturas de los webforms. Los webforms están diseñados para ser sencillos de implementar desde el punto de vista de los WinForms (pantallas de escritorio). Pero no constituyen una forma natural de implementar y separar la visualización de los datos, de lo que es el negocio.

El modelo MVC ante todo se basa en la estructura del flujo de nuestra aplicación Web. Representa de forma natural una vista por pantalla (o tipo de pantalla), e implementa acciones que no son sino las acciones de nuestras pantallas.

¿Cómo funciona MVC?
El patrón que se usa en MVC de ASP.NET es el de Front Controller.
Al controlador le llegan peticiones, que pasan por un mecanismo de enrutamiento. El enrutador decide qué controlador debe dispararse, ese controlador es el que da paso a las acciones e interactúa con el modelo, dando como resultado una vista.

El enrutamiento se encuentra dentro del espacio de nombres System.Web.Routing. Se trata de un espacio de nombres independiente de ASP.NET MVC, por lo que las personas que utilicen ASP.NET clásico (el de webforms), pueden tener también acceso a ese espacio de nombres.

Enrutado
La esencia de MVC dentro de ASP.NET se encuentra en el enrutado. Para ello, en el archivo Global.asax se define una tabla de rutas, una colección de rutas (RouteTable). Esa tabla lleva una ordenación, y el comportamiento vendrá definido por dicho orden (debe de ponerse el comportamiento más restrictivo siempre antes). Además, este enrutado permite restricciones (por ejemplo, en función de una clase específica definida por nosotros, o bien a través de expresiones globales).

Definición de rutas
La definición de rutas se hace mediante patrones. El patrón más común es:
{Controlador}/{acción}{parámetro}
Esto hace que la forma más habitual de navegar en una aplicación MVC sea mediante url's del estilo:
http://misitioweb/controlador/accion/parametro

Para definir una ruta por código sería algo así como:
var route = new Route("{controller}/{action}/{param}",new MvcRouteHandler());
class Route: RouteBase{
     //definición de la ruta
     string Url
     RouteValueDictionary Defaults //valores por defecto
     RouteValueDictionary Constraints //permite definir restricciones
     RouteValueDictionary DataTokens //permite asignar metadatos donde guardar información adicional 
     IRouteHandler RouteHandler
}

Bueno, ya vale para una primera introducción.
Para saltar a la segunda parte de este post, clic aquí.

Refactoritis

Hoy vamos a tratar una enfermidad muy común de los programadores "experimentados": La Refactoritis.

La refactorización se lleva haciendo durante décadas. No es algo nuevo, a pesar de que siempre se cite al bueno de Martin Fowler como referencia, en su libro "Refactoring: Improving the Design of Existing Code". Si no conocéis a Martin Fowler y os dedicáis a la informática, no sé a qué esperáis para leer este libro y saber un poco más de este autor.

La refactorización se define en la Wikipedia como "técnica de la ingeniería del software para reestructurar un código fuente, alterando su estructura interna sin cambiar su comportamiento externo". Es en estos momentos cuando muchos de vosotros estaréis asintiendo con la cabeza y pensando en frases como "pues yo refactorizo mucho o poco", "yo no lo veo una enfermedad", etc, etc.

¿Y qué sería en ese caso la Refactoritis? Pues la podríamos definir como el "trastorno compulsivo que deriva en el uso excesivo de la refactorización del código". Vamos, cuando se le va la mano al programador y no para hasta que ha llegado al final del código, y lo ha dejado todo "a su gusto".

Como hemos visto antes, la refactorización no cambia la funcionalidad. Es decir, no se aporta valor al producto desde el punto de vista de los requisitos. En la metodología SCRUM, estaríamos dedicando horas de trabajo sin implementar ninguna "historia de usuario". En realidad, sería una forma de procrastinación: no hacemos algo que se haya solicitado, sino que estamos haciendo algo que nos gusta o nos parece subjetivamente agradable o necesario. Por supuesto que habrá ocasiones en que sí se ha creado una tarea a realizar de refactorización, pero en esos casos nos deberíamos preguntar si realmente no deberíamos atajar la causa del problema: no generamos código de calidad según estándares, lo que obliga a refactorizar después.

La refactoritis deriva en múltiples problemas. Veamos primero las necesidades que nos pueden llevar a refactorizar el código, y vamos a discutirlas una a una:

• Calidad. Esta suele ser una de las excusas más usadas. Estamos creando calidad, mejorando la calidad. Y como no sabemos medir la calidad, no hay límite para nuestras ansias de refactorizar. Podemos seguir refactorizando hasta que nuestra sensación subjetiva de calidad consuma el tiempo de desarrollo. Algunos autores defienden que el código de calidad es bueno, y que mientras se satisfagan las pruebas unitarias, no pasa nada. El problema, es que las pruebas unitarias no son perfectas, lo que puede derivar en que a pesar de que "todo parece ir bien" tras refactorizar, en realidad estamos introduciendo bugs en el código.
• Mala planificación. En ocasiones, se planifica en exceso. Los programadores cuando se encuentran con que han terminado una tarea antes de la fecha planificada pueden hacer varias cosas. O buscan una nueva tarea, o tratan de llenar el tiempo de la tarea terminada. ¿Cómo? Pues refactorizando: mejorando comentarios, encapsulando, quitando código duplicado, etc.
• Eficiencia. Supuestamente, un código refactorizado es más eficiente. Además, se supone que se entiende mejor y es más claro. Esto último es muy dudoso, ya que es muy fácil refactorizar código y dejarlo de forma que sea muy compleja de entender. En este caso, si no medimos la eficiencia, ocurriría lo mismo que con la calidad. Podemos pegarnos la vida intentando ser más eficientes, que como no se mide esa mejora en eficiencia...no hay límites a nuestra refactoritis.
• Evolución. A veces, cambios en las normas de programación, en requisitos de calidad, etc., hacen que debamos refactorizar el código para que se cumplan las nuevas normas. Debemos recordar que salvo excepciones, el cliente paga por funcionalidades, no por la refactorización del código. Si no tenemos claras nuestras normas de desarrollo...mal asunto.
• Evitar la reescritura de código. Es muy discutible que un código refactorizado sea mejor que un código reescrito. Deben establecerse las necesidades, y evaluar qué solución merece la pena en uno y otro caso. Si refactorizar es la alternativa a la reescritura de código, en realidad tenemos un problema mayor: el mero hecho de plantearnos reescribir el código significa que un tiempo invertido en el desarrollo "va a la basura". Los paños calientes y las vendas no van a ocultar que tenemos un problema mayor.

¿Cuáles son las prácticas que deberíamos aplicar?

• No tocar el código que no se ha solicitado tocar.
• No tocar el código para el que no se han definido pruebas (automatizadas o no).
• No tocar el código sin antes realizar un análisis del coste (horas necesarias) para su refactorización, y definirlo como una tarea. Sólo así podremos controlar el tiempo necesario en rehacer las cosas una y otra vez. No deberíamos dedicar más horas de las estimadas a refactorizar, ni tocar más código del inicialmente identificado. Si no conocemos el alcance de nuestras acciones, no sabemos hacia dónde vamos.
• El código se debe refactorizar ANTES de pasar las pruebas, en la actividad de verificación. Las pruebas son muy costosas (incluso automatizadas), por lo que deberíamos pensar dos veces antes de tocar un código que ha pasado ya las pruebas.
• No tocar el código que afecte a otros desarrollos (en curso o en producción), sin antes hacer una evaluación del impacto y recibir la aprobación correspondiente. En muchas ocasiones, algo que funciona correctamente según las pruebas unitarias, al subirlo a producción ROMPE OTROS DESARROLLOS con los que interactuaba.