---

• Exponer la evolución de la gestión de proyectos en la industria del desarrollo software.
• Introducir la agilidad y el manifiesto ágil

---

• La industria del desarrollo de software es bastante reciente en comparación con otras industrias.

  • Ley de Moore (entorno muy cambiante)
    • Incremento de la capacidadMilitarización de operación.
    • Miniaturización.
    • Reducción de costes en la producción de hardware.
  • Avance en los sistemas de comunicaciones.

• Da lugar a ordenadores más potentes y portables.

  • Habilita la incoportación de sisstmas más complejos.
  • El desarrollo de software tiene su origen en el ámbito militar.
  • Se extendrió rápidamente a otros ámbitos muy diferentes.
  • Ejecución de proyectos tardía.
  • Con desbordamiento de costes.
  • Sin funcionar correctamente.

• Necesidad de definir unos éstandares para la producción y mantenimiento del software.

  • Ingeniería del Software:

    • Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo y mantenimiento del software.

  • Gestión de proyectos predictiva:

    • Disciplina formal de gestión basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles.

    • Criterios de éxito: obtener el producto definido, en tiempo previsto y con coste estimado.

    • Asume un entorno estable y predecible para el desarrollo del proyecto.

    • Se esfuerza en mantener la planificación, presupuesto y recursos estimados.

    • Desarrollo visto como una secuencia de fases: concepto, análisis de requisitos, diseño, planificación, desarrollo y cierre.

  • Producción basada en procesos:

    • La calidad de los resultados obtenidos va en función de la calidad de los procesos usados en el desarrollo del producto.
    • Desarrollo de diferentes modelos de procesos para la industria del software (ISO 90003, CMMI, etc.).
    • Beneficios que aporta:
      • Repetitividad de los resultados.
      • Escalabilidad.
      • Mejora continua (meta-procesos para mejorar la calidad y eficiencia de los procesos).
      • know-how propio.

• Preguntas a tener en cuenta

  • ¿Los criterios de éxito tuviesen en cuenta algo más que el cumplimiento de fechas y costes?
  • ¿El cliente quiere poner en el mercado antes que nadie su producto y seguir desarrollando su valor y su funcionalidad?
  • ¿El entorno de desarrollo no fuese estable y predecible?

• Agilidad: valor y flexibilidad para trabajar en un entorno cambiante.

  • Agile Alliance
  • Surge como altgernativa a las metodologías formales:
    • Más "pesadas" y rígidas por su carácter normativo.
    • Con fuerte dependencia de planificaciones detalladas.

---

Tiene cuatro pilares o "patas" fundamentales:

1. Las personas y sus interacciones:

   • Los procesos y herramientas mejoran la eficiencia.
   • Sin personas con conocimiento técnico y una actitud adecuada, no se producen resultados.

   

1. El producto funcionando:

   • La documentación sigue siendo necesaria.
   • Es preferible intercambiar opiniones o valoraciones sobre prototipos con alguna funcionalidad.
   • Puesta en producción de un producto con valor desde el principio, con una evolución e incremento de valor en sicesivas iteraciones en el tiempo.

   

1. Colaboración con el cliente

   • El cliente es un miembro más del equipo.
   • Definición continua y másprecisa del producto.
   • El contrato no aporta valor fijo, fija las responsabilidades.

   

1. Respuesta al cambio

   • Ante un entorno posiblemente inestable y cmabiante, es más valioso la capacidad de respuesta que el seguimiento de un plan preestablecido.
   • Anticipación y capacitación.

   

---

La industria del desarrollo del software es bastante reciente en comparación con otra industria ya que esta se enmarca en un entorno muy cambiante tal y como dice la ley de Moore. Esta determina que con el paso de los años sucederá:

• Incremento de la capacidad de operación.
• Miniaturización.
• Reducción de costes en la producción de hardware.

Además los continuos avances en los sistemas de comunicaciones determinan bastante el desarrollo.

Todos estos avances desembocan en ordenadores más potentes, portables además de:

• Habilita la incorporación de sistemas más complejos.
• El desarrollo de software tiene su origen en el ámbito militar (como casi siempre) y en la banca.
• Pero pronto se extiende a muy diferentes ámbitos.

En 1968 se produjo la crisis del software debido a que la ejecución de proyectos sea tardía, desbordamiento e costes y sin funcionar correctamente.
De todo ello nació la necesidad de definir unos estándares para la producción y mantenimiento de software dando lugar a la Ingeniería del Software: Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo y mantenimiento del software La gestión de proyectos predictiva: se define como una disciplina formal de gestión basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles. Su principal criterio de éxito es obtener el producto definido, en tiempo previsto y con coste estimado asumiendo un entorno estable y predecible para el desarrollo del proyecto
Se esfuerza en mantener la planificación, presupuesto y recursos estimados y el desarrollo visto como una secuencia de fases:

• Concepto
• Análisis de requisitos
• Diseño
• Planificación
• Desarrollo
• Cierre

Producción basada en procesos la calidad de los resultados obtenidos va en función de la calidad de los procesos usados en el desarrollo del producto. Esto aporta ciertos beneficios como repetitividad de los resultados, escalabilidad, mejora continua (meta-procesos para mejorar la calidad y eficiencia de los procesos) y Know-how propio.
Sin embargo , en este mundo, hay mas elementos que tener en cuenta que las fechas y los costes y los entornos no son estables ni predecibles. De esto nacen la gestión de proyectos ágil que se basan en el valor y flexibilidad para trabajar en un entorno cambiantes (como alternativas a la fuerte dependencia de las planificaciones detalladas de las metodologías formales).

Valoramos más a los individuos y su interacción que a los procesos y las herramientas.
Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero en trabajos que requieren conocimiento tácito, sin personas con conocimiento técnico y actitud adecuada, no producen resultados.
Los procesos deben ser un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. algunos defienden que se pueden conseguir maravillosos resultados siguiendo procesos con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación. En este tipo de proyectos es muy importante las interacciones entre personas puesto que aportan distintos puntos de vistas y conocimientos.

El manifiesto ágil solo considera útil la documentación totalmente necesaria. Sabemos que los documentos proporcionan información util y relevante. Además en ocasiones, pueden incluso llegar a ser necesarios por motivos legales. Sin embargo, a la hora de desarrollar un producto software, es mas importante el software en si que su documentación.
Para que nos hagamos una idea, es mucho mas facil anticipar como va a funcionar un producto software si creamos prototipos, vamos haciendo pruebas, etc. que si creamos n documento de requisitos muy detallado antes de empezar, por lo que esto suele ser a menudo una pérdida de tiempo.
Por otra parte, entendemos que la documentación sirve para comunicar información entre los desarrolladores del producto. Sin embargo, la comunicación es mucho mejor si se hace de manera directa, de viva voz e interactuando con prototipos del producto. Además, crea barreras burocraticas entre departamentos y personas.
Por eso, siempre que sea posible, se debe reducir al mínimo indispensable el uso de documentación. Lo ideal es eliminar toda aquella que consuma trabajo sin aportar un valor directo al producto.

La colaboración con el cliente es más que la negociación de un contrato. Un contrato no aporta valor al producto, solo refleja las responsabilidades de las diferentes partes.
Una de las mejores formas de desarrollar un producto es recibir feedback directo a la vez que se desarrolla para así mejorar los requisitos de este, ya que dependiendo del proyecto pueden ser muy inestables. Lo mejor para el proyecto es una implicación y colaboración directa por parte del cliente, no una contractual. A ser posible, esta colaboración debe ser mediante conversaciones cara a cara, de forma que la comprensión entre las dos partes sea óptima y el equipo de desarrollo entienda perfectamente las ideas del cliente para así poder contentarle.

Las estrategias de respuesta al riesgo son las acciones que podemos emplear para minimizar los efectos negativos, y mejorar las oportunidades que afecten a los objetivos del proyecto.

Riesgos Negativos.

• Evitar

  Consiste en eliminar la amenaza, eliminando la causa.

• Mitigar

  Consiste en disminuir la probabilidad de ocurrencia y/o el impacto del riesgo.

• Transferir

  Consiste en trasladar el impacto negativo del riesgo hacia un tercero.

• Aceptar

  En esta respuesta, se aceptan las consecuencias del riesgo, por lo que no se realiza ninguna acción para gestionarlo.

• Escalar

  Esta estrategia se utiliza cuando el director de un proyecto no tiene la autoridad, el conocimiento o los recursos necesarios para gestionar un riesgo.

Riesgos Positivos. Oportunidades
Las estrategias de respuesta positiva al riesgo, aquellas cuyo objetivo es aumentar la posibilidad de que ocurra el riesgo son esenciales.

• Explotar

  En este tipo de respuesta al riesgo, se asegura de que la oportunidad se realice.

• Compartir

  Esta estrategia de respuesta al riesgo,se utiliza en situaciones en las que no somos capaces de aprovechar una oportunidad con nuestros recursos y nos asociamos con otra persona o compañía mejor capacitada.

• Mejorar

  Esta estrategia se utiliza para aumentar la probabilidad y/o el impacto de una oportunidad.

• Aceptar

  Esta estrategia de respuesta al riesgo es común para ambos tipos de riesgos y se utiliza cuando el costo de la respuesta es alto y hay pocas posibilidades de que ocurra.

• Escalar

  Esta estrategia se utiliza cuando hay una oportunidad y no puede gestionarla, ya que carece de la autoridad o el conocimiento para aprovechar esta oportunidad.

Palacio, J. & Ruata C. (2011) Scrum Manager Gestión de Proyectos. Safe Creative.