Muchos de vosotros, lectores de este blog y de otros muchos de temática parecida, conoceréis las metodologias de desarrollo ágiles. Sobre todo, la más extendida: SCRUM.

También conoceréis lo que podríamos llamar la manera tradicional en la que los proyectos han sido llevados a cabo, es decir:

  1. Teniendo una descripción detallada del producto final a conseguir
  2. Normalmente se parte de una fecha de entrega impuesta y de coste preestablecido
  3. Se construye un plan de proyecto detallado, con la descomposición de tareas a realizar, la planificación de todas las tareas, recursos implicados, costes, etc. etc.
  4. Una vez planificado, se va ejecutando y controlando las desviaciones del mismo.

Hay escenarios en los que este estilo de gestión de proyectos no es el óptimo. Donde no se dispone de una descripción detallada del producto que se quiere obtener, las condiciones son muy cambiantes con continuos cambios en los requisitos, necesidad de entregas de software cada muy poco tiempo, etc. etc

No es mi intención repasar en este post las características detalladas de ambos tipos de gestión de proyectos (no sé si podría) ni de las diferencias entre ambos. Sin embargo, lo que tengo claro es que no se trata de elegir uno u otro. Creo que como todo, puede haber ocasiones donde encaje mejor una gestión productiva y otras en las que aplique mejor una gestión ágil.

Además creo que muchos de los objetivos de ambos estilos de gestión son comunes. Y para ello, me gustaría repasar los principios es los que se basan las metodologías ágiles, su manifiesto. Los puntos son los siguientes (los comentarios son míos):

  1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor.
    Creo que todos estamos de acuerdo, no podemos entregar software cada seis meses o incluso pasado un año, para descubrir que no es lo que espera el usuario. Por supuesto, esto no implica que no se entreguen otros productos de valor como el manual de usuario, el plan de explotación e implantación, etc, etc.
  2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente.
    Esto es más fácil decirlo que hacerlo, pero debemos cambiar nuestra mentalidad para hacerlo posible. No debemos ver los cambios como el “enemigo” del proyecto, tenemos que aceptar que siempre habrá cambios y demos asimilarlos lo mejor posible. Viéndolos también como una oportunidad de negocio, normalmente cuando más cambios haya más cobrará el equipo de desarrollo ¿no?.
  3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves.
    Esto refuerza el primer punto. No es nada descabellado, incluso en un gran empresa, pensar que hay que entregar software funcionando (en entregas iterativas) al menos una vez al mes.
  4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto.
    Esto sí que lo veo un problema en una gran empresa. Normalmente hay una gran separación organizacional entre ambos mundos. Incluso están físicamente separados.
    Lo más práctico sería que alguien de I.T. hiciese de “representante” del usuario de negocio.
  5. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea.
    Está claro que la motivación y el conocimiento, aunque no siempre, están relacionados con la remuneración del profesional. Esto es un poco difícil de conseguir con el modelo español, que se parece más bien a una factoría de coches, en la que el que trabaja “juntando las piezas” (lo que sería el desarrollador) es el que menos cobra. En esta entrada veréis lo que quiero decir:  ¿qué modelo de desarrollo queremos?
  6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara.
    Siempre que sea posible es mejor aplicar este método ya que es el medio más eficaz para evitar malentendidos. Además es donde se aprovecha mejor la comunicación no verbal y nos ayuda a comprender y empalizar con el interlocutor. 
  7. El software que funciona es la principal medida del progreso.
    ¿cuantas veces nos hemos encontrado con un informe de seguimiento donde se indica que el proyecto está el 80% y realmente no hay nada que se pueda “palpar” o probar?
  8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
    El área de negocio, incluso en las grandes empresas, reclama la entrega continuada y cada poco tiempo de software con funcionalidad que aporte valor a la compañía. Este punto recoge precisamente esta necesidad.
  9. La atención continua a la excelencia técnica enaltece la agilidad.
    Parece de perogrullo que a un desarrollador experto es capaz de producir software de calidad y en menos tiempo. La pregunta es ¿Cómo podemos contar con este tipo de desarrolladores en nuestros proyectos?
  10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.
    Hay que hacer lo tenemos que hacer, ni menos de lo que acepta Negocio ni tampoco más. Tampoco hay que caer en la “ingenieritis” o  en la excesiva complejidad innecesaria (esto es más frecuente de lo que pensamos).
  11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto-organizan.
    Si bien lo veo correcto en general, creo que es de difícil aplicación en grandes organizaciones. Existe en estas una gran especialización con diferentes roles de las que se depende en el desarrollo. Por supuesto hay que trabajar en aligerar estas dependencias y sobre todo eliminar los trámites y las burocracias innecesarias (y con ello las largas esperas).
  12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su conducta en consecuencia.
    Esto es fundamental, hay que establecer un “espíritu” de mejora continua eliminando los desperdicios o trabajos que no aportan nada.

Conclusión:

Viendo estos principios de las metodologías ágiles, creo que no están tan apartadas de los que deberían ser también los principios aplicables en metodologías de gestión productivas (las tradicionales). Creo que en su mayoría deberían ser objetivos del desarrollo de software, independientemente de la metodología usada. ¿Opinas lo mismo?

En Pensando En SOA | ¿qué modelo de desarrollo queremos?

Comparte este artículo:

Share

Anuncios