- Cualquier proyecto de desarrollo de sistemas debe manejar el cambio, no intentar impedirlo. Intentar impedir el cambio (en el entorno, en las especificaciones, en el equipo de trabajo), es similar a buscar la fuente de la eterna juventud.
- Muchas organizaciones necesitan adoptar marcos que les permitan, entre otras cosas, darle visibilidad a la ejecución de proyectos, delimitar responsabilidades, ser predecibles y construir una historia que pueda ser explotada con el objeto de saber donde deben mejorar.
La primera conclusión me hace mirar con simpatía las metodologías ágiles (debo -admitir que solo conozco XP) y la segunda me hace pensar en la necesidad de un marco formal y más riguroso, al estilo CMMI (que no es exactamente un metodología, sino un marco ). Un prejuicio ( el marco más comunmente usado para tomar decisiones ) me decía que no se podía estar a la vez de un lado y del otro: o sos ágil y desordenado o sos lento, paquidérmico, y eso sí, muy ordenado.
Conforme fui conociendo más de CMMI y XP, el prejuicio se fue debilitando ( es notable cuan perniciosa es la información y el conocimiento para la supervivencia de los prejuicios ), y hasta encontré que el SEI ya lo había contestado (no es exactamente CMMI, sino CMM, pero es una lectura recomendable).
Como sabemos, CMMI establece los famosos cinco niveles, con áreas de procesos en cada una de ellas. Cada área de proceso tiene objetivos específicos y prácticas específicas para cumplir sus objetivos. XP, por su parte, consiste en una serie de buenas prácticas asociadas al desarrollo del software.
Ninguna de estas es, como dirían los americanos del norte, rocket science: se trata de sentido común y lecciones aprendidas por la industria durante muchos años, llevadas al extremo en el caso de XP.
XP y CMMI, punto por punto …
… o más o menos, simplificando las áreas de proceso de manera caprichosa, vamos a recorrer las similitudes:
Requerimientos: CMMI plantea dos areas relacionadas con requerimientos en los niveles dos y tres: gestión de requerimientos y desarrollo de requerimientos, con foco en la elicitación, definición, verificación, validación y control de los requerimientos. XP plantea integrar un usuario o representante del usuario (como un jefe de producto) al equipo, con el objeto de que sea él mismo quien defina sus requerimientos, esté disponible permanentemente para consultas y pueda dar feedback sobre la implementación de los requerimientos luego de cada release.
Planificación y control: con XP estamos planificando continuamente: antes de cada iteración se recolectan requerimientos (‘user stories’, para XP), lo que se explica con la metáfora del carrito de compras: se recolectan user stories hasta colmar la capacidad del carrito (o sea, la capacidad de trabajo del equipo). La planificación es explícita (se seleccionan las user stories a implementar en cada release) y se actualiza continuamente, se estima el esfuerzo requerido para cada story y se planifica cada iteración antes de comenzar. El avance de cada iteración se monitorea durante las stand up meetings. La métrica de project velocity (la suma de la estimaciones de las stories implementadas en la iteración) proporciona una idea de la performance del equipo de trabajo. El avance global del proyecto se mide de forma muy conveniente por la cobertura funcional, es decir, por el porcentaje de user stories implementadas.
Quality Assurance, Validación y Verificación: la práctica de pair programming, la propiedad compartida del código y la integración continua refuerzan el foco de XP en QA. El código es verificado dado que se programa en pares que se verifican muamente. Más aún, se pueden incorporar al proceso de integración continua herramientas de verificación estática. XP hace foco en los test unitarios (toda clase o componente debe tener sus test unitarios) y los test de aceptación, que pueden ser perfectamente automatizados.
Gestión de la configuración: las releases sucesivas y cortas requieren una gestión de la configuración importante, aún cuando XP no lo mencione explicitamente: sin una adecuada gestión de la configuración, las prácticas de releases cortas, propiedad compartida de código e integración continua son imposibles.
Gestión de Riesgos: si bien XP no incorpora una práctica específica de gestión de riesgos, la integración continua, la disponibilidad permanente del usuario y las iteraciones cortas son, en definitiva, las políticas de mitigación para los riesgos más frecuentes en los procesos de desarrollo de software. Asimismo se recomienda acomodar las stories más problemáticas en las primeras releases para tener tiempo de corregirlas, lo que ayuda a mitigar los riesgos más comunes en los proyectos de desarrollo
Métricas y Análisis de las métricas: o existe en XP una práctica específica de análisis de métricas, pero el proceso produce métricas que pueden ser analizadas para identificar áreas de mejora. Las métricas como project velocity, bugs encontrados, cobertura de los test, errores de integración son producidas por el proceso y las herramientas que lo soportan.
Donde comenzamos a diverger
Existen algunas divergencias entre CMMI y XP, en particular, en áreas de proceso que adquieren mayor importancia conforme el número de integrantes del equipo de trabajo crece.
No existe ninguna práctica en XP asociada a las areas de proceso con foco en la organización, que tienden a asegurar la adherencia de toda la organización al proceso y encausar las actividades de mejora en toda la organización.
XP no posee ningún foco en estructurar guías de arquitectura al inicio del proyecto, lo que puede ser necesario para equipos grandes que trabajen en un desarrollo desde cero y no en mantenimiento. Esto último puede corregirse implementando primero las user stories más significativas desde el punto de vista de la arquitectura y que sirvan como molde, pero aún así, en determinados contextos la documentación de diseño puede ser necesaria ( en otros, puede ser absolutamente innecesaria y contraproductiva).
La práctica del refactoring continuo puede no ser extensible a grandes equipos, donde sea difícil mantener la visión global del producto a construir, o, al menos, donde es complicado que todo el mundo la tenga.
Mis personalísimas conclusiones
XP propone unas cuantas ideas que cualquier equipo de desarrollo que no quiera verse inmerso en un gran quilombo haría bien en seguir, como la planificación continua, el monitoreo de avance en virtud de lo que se hizo y no de lo que se supone que falta, el testing, tanto unitario como de aceptación, el diseño simple y el no tratar de resolver problemas que uno no tiene hoy.
De todas maneras, puedo pensar en contextos donde implementar XP en todo su esplendor sería peligroso: en los proyectos llave en mano, donde se asume de antemano un compromiso en tiempos y costos, no solo no tendremos a un cliente sentado aquí para que nos diga que quiere, sino que no podemos soportar el cambio continuo (tenemos que ganar dinero). Por otra parte, un compromiso inicial en tiempos y costos requiere un entendimiento inicial de todos los requerimientos, y un cambios en estos últimos podría significar un cambio en los primeros aspectos. En estos casos, seguimos sin poder anular el cambio, pero podemos saber cuando ocurre, por qué ocurre y que cambios adicionales (en tiempo y costos) se generan por un cambio en los requerimientos y el marco de CMMI nos ayuda a hacerlo.
Creo también que conforme el equipo crece en tamaño se necesita más foco en los aspectos organizacionales de la metodología, la gestión y el diseño y arquitectura
En definitiva, como dice el artículo del SEI linkeado más arriba, la postura extrema de XP requiere un management competente, y en eso se enfoca CMMI, por lo que un enfoque que complementario entre XP y CMMI puede ser valioso.
Fuentes:
Extreme Programming from a CMM Perspective, Mark C. Paulk
Planning Extreme Programming, Kent Beck
Extreme Programming Explained, Kent Beck
No comments:
Post a Comment