METODOLOGÍAS ÁGILES COMO BENCHMARKING

Las metodologías ágiles evolucionan al ritmo de los vertiginosos cambios en las empresas

Contraste entre metodologías ágiles en las organizaciones

Las metodologías y los modelos de desarrollo de software han ido evolucionando a lo largo del tiempo y, como todo, son víctimas de las “modas” de cada momento.

Por un lado, las empresas requieren que sus proveedores de desarrollo de software adopten metodologías que encajen o sean compatibles con las suyas propias o incluso que dispongan de ellas.

Por otro lado, las Administraciones Públicas son el origen y motor de metodologías de trabajo, porque las han convertido en requisito para participar procesos de contratación. De esta manera pueden servir para restringir el concurso a menos empresas participantes y, en teoría, a los de mayor solvencia técnica o madurez organizativa en sus procesos, que es al fin y al cabo de lo que se trata.

En las organizaciones TIC, la creación de una metodología propia basada en un modelo de referencia como puede ser CMMI (Modelo de Capacidad y Madurez Integrado), pasar un proceso de evaluaciones internas y, finalmente, una certificación como SCAMPI supone un reconocimiento al trabajo interno de calidad, pero además es también una forma de comparar las prácticas de la organización con las de otras. Es decir, un benchmarking respecto a las prácticas de la industria en la que se trabaja.

Todo este desarrollo y aplicación metodológica ha surgido de arriba abajo, es decir, desde las grandes empresas e instituciones hacia sus proveedores de mayor a menor tamaño. Sin embargo, en los últimos años este movimiento se ha visto contrarrestado por otro también vertical pero de abajo a arriba. Es decir, desde las start-up hasta las grandes empresas de desarrollo ágil, con metodologías como Scrum.

En realidad este movimiento está inspirado por el de grandes organizaciones como Toyota y su Lean Manufacturing y tableros Kanban como herramienta de trabajo, pero ha sido  rápidamente adoptada por pequeñas compañías por su orientación a resultados y su mejor adaptación al cambio que otras.

Los conceptos como “ciclo de vida” que tradicionalmente contemplaban sólo el llamado “ciclo en cascada” (Análisis → Desarrollo → Pruebas → Implantación) están conviviendo con otros ciclos de vida con alguna variante y, sobre todo, con los ciclos de vida ágiles como los que se planifican por “sprints” (de 1 semana a 2 meses, dependiendo de los proyectos).

Estos sprints son tratados como pequeños proyectos en cascada en los que se determina al principio qué requisitos se necesitan priorizar según criterios de negocio, se valora el esfuerzo que suponen y, finalmente, se decide cuál se implementa y cuál no en función de la capacidad de trabajo del equipo.

Además, este modo ágil de trabajar incluye un seguimiento diario del estado, una revisión final y un feedback de mejora.

Las #MetodologiasAgiles como reconocimiento al trabajo interno de calidad #benchmarking Clic para tuitear

Este cambio en el paradigma supone algunas mejoras respecto a las metodologías tradicionales como las ya comentadas, pero también algunos problemas entre los que destacan la anarquía en la documentación de los proyectos.  Esto no está determinado en la metodología pero trabajar de esta manera incita a ciertos vicios que es necesario reconducir.

El empuje de estas metodologías ágiles ha sido tal que las metodologías más tradicionales como la que certifica a los PMP (Project Manager Profesional de PMI) para gestión de proyectos en general, o CMMI para proyectos de desarrollo de software en particular, incorporan en sus nuevas versiones estos mecanismos de una u otra manera, ya sea como ciclos de vida que se pueden plantear o como metodologías de trabajo en certificaciones derivadas (PMI-ACP).

En Inycom la adopción de estas metodologías ágiles parte de la solicitud de los clientes así como del convencimiento de una forma de trabajar basada en buenas prácticas de la industria.

La implantación, revisión y reacreditación en metodologías como CMMI supone un esfuerzo a la organización que hay que saber transmitir a todo el personal que forma parte de un proyecto, empezando por la figura del Jefe de Proyecto sobre la que se apoya gran parte de esta capa de gestión, no meramente técnica, pero necesaria para el buen fin de un proyecto.

Por parte de la empresa es necesario definir procedimientos coherentes con los objetivos de la organización y compatibles con el resto de áreas.  Estos procedimientos y las herramientas que se utilizan para dar el soporte deben facilitar ese trabajo y se deben adaptar cuando las circunstancias así lo indican.

Estas herramientas de gestión también han sufrido una importante evolución, no sólo por las “plantillas” en las que se basan si no por la forma en la que se trabaja.  Así, se habla de herramientas ALM (Application lifecycle management) en las que se van integrando tanto las partes relacionadas más con el desarrollo técnico como las partes relacionadas con el seguimiento y la gestión.  Algunas de estas partes son:

• Asignación de tareas, estimación, planificación y esfuerzo
• Gestión del código fuente
• Test, incluyendo pruebas integradas
• Gestión de puestas en producción, incluyendo integración continua
• Documentación
• Informes

La adopción de una herramienta de este tipo también puede condicionar la metodología que se utiliza, por estar más orientada a unos aspectos que a otros.  Lo importante es tener claro la necesidad que se tiene y hasta dónde se puede llegar con las herramientas disponibles y dónde no.  Si se plantea personalizar la herramienta, ello va a suponer cierto trabajo de desarrollo que, normalmente será amortizado rápidamente al ahorrar los costes que supondría realizarlo manualmente de otra manera.  Sin embargo, ello también puede implicar dificultades para actualizar las herramientas, como pasa en general con cualquier otro tipo de aplicaciones TIC open source o comerciales.

Ten claras tus necesidades antes de implantar herramientas que condicionen tus #metodologias... Piensa! Clic para tuitear

Las opciones de soluciones “As a Service” en este punto permiten menor personalización pero tienen mejor cubierta la evolución, que es más transparente.  Se trata de valorar en el despliegue las opciones existentes, las necesidades y el coste del cambio (incluyendo migración de contenido si lo hubiera) para decidirse por la opción que mejor se adapte.