Actualidad / Certificaciones / Formación

El agilismo no siempre es la mejor opción

por certificacionpm

Aunque parece claro que la dirección de proyectos en cascada no siempre es la mejor solución para todo tipo de proyectos, clientes y culturas de empresa, la atracción que a veces nos provoca, por lo menos a mí, la gestión de un proyecto de forma ágil, requiere también un ejercicio de reflexión antes de abrazarla.

En algunos escenarios simplemente no es factible utilizar el enfoque de desarrollo ágil: la estructura no facilita la toma de decisiones a la velocidad adecuada, el personal no está motivado para afrontar un cambio de este tipo, la cultura de empresa es contraria… A veces un cambio en las metodologías a utilizar debe reflejarse en un cambio estructural, cultural, etc… que es posible no estemos preparados para asumir.

Debemos de estar preparados para detectar cuando estos cambios metodológicos necesitan de un cambio estructural, porque éste será probablemente mucho más costoso y laborioso que un cambio metodológico.

A continuación presentamos un extracto de nuestro curso de preparación Scrum que trata sobre este tema.

«El desarrollo ágil, si bien es apropiado para un amplio espectro de casuísticas, no lo es para algunos tipos de proyectos y tiene algunos puntos débiles que conviene tener en cuenta a la hora de llevar a buen puerto los proyectos.

  • El grado de definición e incertidumbre inicial condiciona la metodología a emplear.

El propio carácter de los proyectos de software, en general nos inclina a decir que la mayoría de los estos proyectos son susceptibles de gestionarse de forma ágil, dado que es muy laborioso definir totalmente un proyecto software al comienzo del mismo, lo que inevitablemente conduciría a cambios, especificaciones mal entendidas, errores… que conducirán a su vez, a iterar sobre el producto para refinarlo.

Dicho esto, existen ámbitos en los que la criticidad del software en cuestión no permite ensayos de ningún tipo y necesite una especificación total anticipada de los escenarios a afrontar: no es lo mismo desarrollar el software de una red social en la web que el software que gobierna el aterrizaje de una nave en la luna, sobre todo en cuanto a la tolerancia a fallo y las repercusiones de este fallo. En estos escenarios la especificación del sistema será más larga y costosa y parece razonable que necesita una fase de especificación mayor que otros.

  • Especificaciones vs agilismo

Se podría objetar que si necesitamos especificaciones, entonces no estamos haciendo desarrollo ágil, y esto mismo sirve para procesos, documentación… En este caso podemos razonar que los principios ágiles tampoco desechan los procesos como inútiles, ni la documentación… Simplemente valoran más las personas frente a los procesos y el software funcionando frente a la documentación (etc…) pero utilizando éstos cuando realmente aportan valor de cara al cliente o usuario final.

  • La estructura de la organización

Existe otro condicionante muy importante a la hora de utilizar este tipo de metodologías: la organización. Existen organizaciones en las que la estructura altamente jerarquizada y la cultura propia de la empresa hacen que no sean el mejor escenario para un desarrollo ágil. Las decisiones se ralentizan, lo que hace que la concreción del software sea costosa y larga, lo que atenta directamente contra la iteración necesaria dentro de un proyecto ágil.

  • Flacid Scrum

Otro problema que suele aparecer a la hora de adoptar un enfoque ágil es el de las prácticas técnicas. Existen casos de adaptación al uso de Scrum con buenos resultados durante los primeros Sprints (o períodos definidos para proporcionar incrementos de valor y que veremos más adelante) que se transforman en el tiempo en problemáticos dado que los equipos no son capaces de mantener el ritmo de desarrollo, ya que el código que se ha producido es difícil de mantener.

Este fenómeno se ha denominado por algunos autores “flacid Scrum”, literalmente “Scrum flácido” o “Scrum flojo”, en referencia a que se centra solo en las prácticas de gestión y no en las prácticas técnicas. También es cierto que Scrum se centra en dichas prácticas de gestión, pero no deben de olvidarse las prácticas técnicas que se definen por ejemplo en XP, también tratada a lo largo del curso.

  • Imponer el desarrollo ágil

La mejor manera de hacer fracasar un proyecto ágil es imponiendo el método de trabajo. Dado que las personas y sus capacidades son el eje central del desarrollo ágil (recuerde que por encima de los procesos y las herramientas) debemos aprovechar estas capacidades escuchando qué tienen que decir y teniendo en cuenta esta opinión. En algunos casos y organizaciones esto simplemente no es posible, porque no es la política de la dirección o por otras razones, con lo que una implantación de métodos ágiles será un fracaso, dado que se estará obviando uno de sus principios básicos.

  • Colaboración con el cliente

Otro escenario donde el desarrollo ágil no será una buena elección es aquel en el que el usuario o cliente (en definitiva quien demanda el desarrollo del producto o la construcción del software) no está dispuesto a colaborar en el formato que se solicita dentro de un desarrollo ágil. Recordemos que vamos a necesitar su apoyo y disponibilidad de una manera bastante intensiva dentro de las reuniones periódicas que llevamos a cabo, además de otros momentos puntuales en los que su colaboración será requerida para aclaraciones concretas. Si no tenemos disponibilidad por parte del usuario, el proyecto no debe tener este formato ágil, dado que en muchos casos encontraremos impedimentos importantes si no contamos con esa colaboración.

  • Tamaño del proyecto

Los proyectos grandes son siempre más difíciles de gestionar que si son más pequeños, por lo que seguramente es mejor idea elegir un proyecto pequeño si estamos empezando con el desarrollo ágil. Aún así, existen experiencias dentro del mundo ágil de proyectos exitosos grandes, tanto en duración (varios años) como en personas involucradas (+100), por lo que no debe de ser un impedimento definitivo para utilizar este tipo de desarrollo, teniendo en cuenta la complejidad añadida que no es lineal sino más bien exponencial.

  • Experiencia

Cualquiera que sea la actividad que desarrollamos, probar cosas nuevas implica cometer errores, los cuales pueden evitarse si alguien con experiencia en el campo en el que nos estamos introduciendo nos ayuda. El caso de las metodologías ágiles no es una excepción y probablemente solucionaremos algunos problemas mejor y más rápidamente si alguien con experiencia nos ayuda en la implantación de dichas metodologías.

  • Adaptación al entorno

Inevitablemente, toda incorporación de los métodos de desarrollo ágiles a un entorno determinado terminarán con un grado de adaptación al entorno. Hemos comentado algunos de los problemas habituales a la hora de hacer una implantación ágil: los perfiles disponibles, la estructura jerárquica de la organización, la experiencia del equipo e incluso su motivación para probar cosas nuevas…

Lo importante en todo caso es no perder de vista los principios ágiles. Si simplemente nos quedamos con las reuniones y el “modus operandi” sin llegar a entender los razonamientos que sustentan estas prácticas es muy posible que nuestra implantación ágil sea muy poco exitosa y muy poco ágil, dado que nos quedaremos en una versión descafeinada y carente de fundamentos de lo que realmente debería haber sido.

 


 

Extracto del Curso de Gestión Ágil con Scrum.

Otorga: 50 PDUs
Modalidad: online
Duración: 2 meses
Experiencia real: incluye entrevista con Tutellus 

Para más información: http://www.certificacionpm.com/productos/scrum/

 

 

 

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.