Aquí os mostramos las empresas que a fecha de 15 de Diciembre de 2011 se encuentran evaluadas en España en CMMI.

Organizaciones Españolas Certificadas en CMMI

El interés por el agilismo ya está creado, los conceptos y prácticas ya se explican en una multitud de libros, cursos e información en internet. Sin embargo, a más de una década del Manifiesto Ágil sigue sin ser suficientemente atendido el desafío que implica la implantación efectiva de métodos ágiles en una organización. Las dificultades para implantar metodología ágiles comienzan a ser evidentes [1,2,3] y aunque los cursos y certificaciones CSM siguen en aumento, estas iniciativas no parecer ser la solución.

Hasta ahora, se ha promovido el “purismo” en cuanto a la aplicación de los principios y prácticas ágiles, el “todo o nada”, el “ser o no ser Ágil”, “el aplicar o no Scrum”, etc. Sin embargo, en la realidad de cada producto (relación con el cliente, dominio de aplicación, tecnología, composición del equipo, etc.) es muy difícil, y puede que imposible, aplicar cada uno de los elementos (roles, prácticas y artefactos) propuestos por Scrum y/o XP, o por otra parte, aplicarlos en su máximo nivel de profundidad.

Tomemos por ejemplo el rol Cliente en XP o Product Owner en Scrum. El Product Owner define y ordena el Product Backlog (el trabajo pendiente asociado al producto) teniéndolo preparado para cuando se realice la planificación. Este Product Owner está altamente disponible para el equipo (in-situ). El Product Owner es una única persona y representa a todos los otros posibles stakeholders, así es su responsabilidad resolver requisitos o prioridades en conflicto. En XP es el cliente el que escribe las Historias de Usuario y define las correspondientes pruebas de aceptación. Obviamente si no tenemos un cliente con estas características no podremos aplicar Scrum o XP puristamente, ¿sería correcto decir que estamos usando Scrum o XP si no se cumple con dicha definición de Cliente o Product Owner, aunque estemos aplicando otros elementos ágiles?. Tal como se suele interpretar Scrum, probablemente no nos calificarían como un equipo Scrum, y en el caso de XP probablemente podríamos tener el calificativo de equipo XP, dependiendo de qué otras elementos estemos aplicando y en qué medida.

El purismo en la aplicación de Scrum o XP ha marcado distancia con los métodos tradicionales, lo cual es positivo en términos de tener referencias claras de uno y otro enfoque. Sin embargo, desde la perspectiva de implantación dicho purismo como estrategia de cambio para un equipo de desarrollo representaría una revolución hacia métodos ágiles. Esto puede ser ideal y deseable en ciertos contextos, pero en muchos otros es claramente inviable, o incluso podría llevar al equipo hacia un estado de decepción y/o frustración.

¿Qué alternativa tiene un equipo para el cual no es posible hacer dicha revolución? ¿debe esperar hasta que tenga condiciones más favorables para embarcarse en el agilismo? ¿debe resignarse a que el agilismo no es para ellos? ¿qué tan importante es poder calificarse como equipo Scrum o XP?
Sí, existe otra alternativa, esa es implementar el agilismo con una estrategia de evolución. El equipo no tendría que esperar y en un corto plazo podría estar ya aplicando ciertos elementos ágiles e iniciando un camino de mejora continua hasta donde pueda y le interese llegar respecto del agilismo. Los elementos del agilismo deberían actuar como una “lista de deseos” un punto de referencia hacia el cual se intenten dirigir los cambios de proceso. No hay por qué obsesionarse en tener la calificación Scrum o XP, lo realmente importante es que el equipo asimile los cuatro principios del agilismo (del Manifiesto Ágil) e incorpore los elementos ágiles que le aporten mayor valor, y que a su vez puedan ser efectivamente aplicados en un contexto y momento determinado.

Esta estrategia evolutiva requiere un diagnóstico del contexto del producto-equipo-cliente para determinar un punto de partida razonable, que debería tener ciertos mínimos. No basta con que el equipo esté motivado y convencido de los cuatro principios del Manifiesto Ágil. Estos mínimos elementos, en mi opinión son: implantar un proceso iterativo e incremental con entregas frecuentes y una gestión del Product Backlog.

¿Existen herramientas para gestión de proyectos software que apoyen está estrategia evolutiva?. Aunque la recomendación es demasiado cercana , hasta donde llega mi conocimiento sólo nuestra herramienta TUNE-UP permite dicha evolución, es decir, permite al equipo poder situarse en un punto de partida y luego ir modificando su forma de trabajo, llegando, si se desea, a cumplir totalmente con Scrum o XP. TUNE-UP puede ser configurada fácilmente para alinearse con dicho punto de partida.Los workflows de TUNE-UP pueden modificarse fácilmente para reflejar las mejoras de proceso, evolucionando el conjunto de actividades y la estructura de roles, en cualquier momento.

Las principales características de TUNE-UP son:

• El Dashboard más completo para el seguimiento de cada versión
• Funcionalidad específica para apoyar la gestión del Product Backlog
• Múltiples ayudas para la selección correcta del trabajo que debe realizar un participante
• Soporte para Kanban, Scrum y Scrumban
• Gestión simultánea de varios productos y versiones
• Soporte para equipos cross-functional y auto-gestionados. Scrum de Scrums
• Test-Driven Requirements Engineering: TDD basado en Pruebas de Aceptación
• Mensajes y reuniones en el contexto de unidades de trabajo
• Workflows flexibles y fácilmente configurables
• Gestión de Requisitos integrada con desarrollo iterativo e incremental
• Alertas y notificaciones de eventos
• Gestión de documentos asociados a ítems, incluyendo control de versiones

+ información en www.tuneupprocess.com

[1] Agile’s Teenage Crisis?, Philippe Kruchten.
[2] “Scrumbut and Modifying Scrum”.
[3] “Flaccid Scrum”, Martin Fowler.

El sotware y sus aplicaciones conforman una nueva industria a nivel mundial. Pero, ¿es igual fabricar software que fabricar un coche o una casa?

Desarrollar software no es igual que hacer un puente. De hecho, en el informe  Chaos Report del Standish Group dice que un 45% de las características del software en producción no se utilizan. Además de lo que en ocasiones ocurre con algún aeropuerto, los puentes y caminos suelen usarse en un 100%.

Por todo ello, consideramos importante desmitificar la idea de que un software y un coche pueden “ni remotamente” construirse con la misma filosofía.

Os invitamos al I Seminario sobre mitos en el sotware: la evolución de software organizado por la Escuela Técnica Superior de Ingeniería Informática (E.T.S.I.I.) de la Universidad Rey Juan Carlos en el marco de la Semana de la Ciencia 2011.

• Fecha: viernes 11 de noviembre de 16 a 17 hs.
• Lugar: Universidad Rey Juan Carlos – Campus de Móstoles. ¿Cómo llegar?
• Ponentes: D. Javier Garzás , Profesor Titular URJC, D. Emanuel Irrazábal Profesor Asociado URJC.
• Información y Reserva (aforo limitado): Sofía de Roa, Tel.: 91 488 8548, E-mail: sofia.deroa@urjc.es