L2 - El manifiesto ágil

El manifiesto ágil

Lección 2

Ingeniería de Software

Mtro. Adrián Favela

Desarrollar buen software es complicado

• 2/3 de los proyectos se entregan tarde [TATA]

• 1/4 de los proyectos se cancelan [Standish]

• 1/2 de los proyectos se pasan del presupuesto original [Tata, SGR CACM]

¿Por qué es complicado? - Escala.

Los usuarios quieren más funciones con el paso del tiempo.

Importante + Tarde = Desastre

• Allstate se aventuró en 1982 a automatizar todas sus operaciones de oficina. Establecieron la meta a 5 años con un presupuesto de $8 MDD.

• 6 años y $15 MDD después, Allstate puso una nueva meta de tiempo con un prespuesto nuevo de $100 MDD.

Importante + Fallas = Desastre

• Máquina de radiación Therac-25 (“An Investigation of the Therac-25 Accidents”, Leveson)

• El 3 de junio de 1985, una paciente fue sometida a un tratamiento de 10-MeV en el área de la clavícula. Al encender la máquina, ella sintió "un calor tremendo... una sensación ardiente". El área tratada se enrojeció y se hinchó Su dolor se incrementó al punto de que su hombro se "paralizó"

• Sus oncólogos siguieron con el tratamiento con Therac-25. Luego el físico encargado se dio cuenta de que la habían quemado.

• Recibió 100x la dosis apropiada. La paciente demandó al centro.

¡Espera!...

eso significa que necesitamos poder maniobrar rápido un gran barco?

Temas:

• El manifiesto de ágil

• Los 4 valores

• Los 12 principios

El nacimiento de ágil:

• Retardo entre requerimientos

• Empresas, requerimientos y requisitos de clientes cambiaban durante este tiempo de retardo y el producto final no cumplía con las necesidades actuales.

• 2000 - 17 líderes (Jon Kern, Kent Beck, Ward Cunningham, et.al) se reunen en Oregon y luego en 2001 en Utah. Ahí se escribe el manifiesto y los 12 principios

El manifiesto ágil

• We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

• That is, while there is value in the items on the right, we value the items on the left more.

Los 12 principios de Ágil

1) La satisfacción del cliente por medio de la entrega temprana y continua del software.

2) Organizar los cambios en los requerimientos a través del proceso de desarrollo

3) Entrega frecuente de software funcional.

4) Colaboración entre los interesados y los desarrolladores a través del proyecto.

5) Respaldar, confiar y motivar a las personas involucradas

6) Habilitar la interacción cara a cara.

Los 12 principios de Ágil

7) Software funcional es la principal medida de progreso.

8) Procesos ágiles que soportan un ritmo consistente de desarrollo.

9) Atención a los detalles técnicos y diseño favorece agilidad.

10) Simplicidad

11) Equipos auto-organizados animan a buenas arquitecturas, requerimientos y diseños.

12) Reflexiones regulares sobre cómo ser más efectivo.

Multiple Choice

Entonces, podemos concluir que ágil es...

• una filosofía

• una metodología

• una religión

• un proceso de desarrollo de software

Poll

Después de ver tu demo al final de una iteración, el cliente te pide algunos cambios. ¿Qué haces?

• Tenemos un contrato para entregar ciertas funcionalidades y eso es lo que entregaremos.

• Mantener el plan por ahora, cambiar las funciones después.

• Renegociar prioridades, iteraciones, horarios/agenda y presupuesto con el cliente.

• Son sólo cambios pequeños, haz espacio para meterlos.

Multiple Choice

Después de ver tu demo al final de una iteración, el cliente te pide algunos cambios. ¿Qué haces?

• Tenemos un contrato para entregar ciertas funcionalidades y eso es lo que entregaremos.

• Mantener el plan por ahora, cambiar las funciones después.

• Renegociar prioridades, iteraciones, horarios/agenda y presupuesto con el cliente.

• Son sólo cambios pequeños, haz espacio para meterlos.

Poll

En desarrollo ágil es más importante construir software que cumpla con las necesidades actuales del cliente acerca de funciones que sean útiles en el futuro.

• Verdadero

• Falso

Multiple Choice

En desarrollo ágil es más importante construir software que cumpla con las necesidades actuales del cliente acerca de funciones que sean útiles en el futuro.

• Verdadero

• Falso

Individuos e interacciones

sobre procesos y herramientas

Individuos e interacciones

Es la gente la que responde a las necesidades empresariales y dirigen el proceso de desarrollo.

VS: Si el desarrollo es dirigido por el proceso o las herramientas, el equipo es menos responsivo al cambio y es menos probable cumplir con las necesidades del cliente.



La comunicación es fluida y debe suceder cuando se presenta una necesidad

VS: la comunicación es agendada y requiere un contenido específico.

Software funcional

sobre documentación exhaustiva

Software funcional

Documentación: Especificaciones técnicas, prospectos técnicos, diseño de interfaces, planes de pruebas, planes de documentación y aprobación para cada etapa del proyecto.

La documentación de requerimientos es por medio de historias; suficiente para que un desarrollador comience a construir una función.

Documentación esencial y eficiente.

Colaboración del cliente

sobre negociación del contrato

Colaboración del cliente

La negociación: discusión del cliente y el administrador del proyecto sobre los detalles de las entregas, estableciendo puntos donde los detalles pueden ser renegociados.

Ágil se preocupa por un cliente que esté involucrado y colabore a través del proceso del desarrollo.

Se puede incluir al cliente en ciertos momentos para demos, así como tener un usuario final como parte del equipo atendiendo todas las juntas para asegurar que el software cumple con los requerimientos

Responder al cambio

sobre seguimiento de un plan

Responder al cambio

Method-tailloring: “A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.” 

Metodologías ágiles permiten al equipo modificar el proceso de acuerdo al equipo, en lugar de al revés.

Poll

¿Cuál de las siguientes opciones no representa una estrategia ágil para un proceso de software?

• Usar una estrategia incremental de entrega de producto.

• Solo producir elementos esenciales para el trabajo.

• Eliminar el uso de planeación del proyecto y pruebas.

• Todas las anteriores.

Multiple Choice

¿Cuál de las siguientes opciones no representa una estrategia ágil para un proceso de software?

• Usar una estrategia incremental de entrega de producto.

• Solo producir elementos esenciales para el trabajo.

• Eliminar el uso de planeación del proyecto y pruebas.

• Todas las anteriores.

Procesos ágiles son adaptables al cliente

• Debe medir: Funciones, agenda, presupuesto, prioridades, mercados, cambio y otros elementos internos.

• Fácilmente extensible y adaptable a muchos otros "problemas". mientras puedan ser observados y medidos.

Mitos sobre ágil:

• Ágil es sólo hacking - Ágil enfatiza el producir código funcional para medir progreso precisamente y obtener retroalimentación frecuente de clientes y usuarios.

• Ágil es hacer el menor trabajo posible - Ágil prioriza el tener retroalimentación temprana lo que implica entregables pequeños.

• Ágil es una religión impuesta por consultores. - Ágil tiene fundamentos teóricos y empíricos sólidos.

Poll

¿Sobre qué se itera en ágil?

• Sobre los cambios que quiere el cliente

• Sobre la planeación original

• Lo que tenemos que salga mal

• Las historias de usuario

Multiple Choice

¿Sobre qué se itera en ágil?

• Sobre los cambios que quiere el cliente

• Sobre la planeación original

• Lo que tenemos que salga mal

• Las historias de usuario

Ágil se enfoca en el cliente como un riesgo

• Entendiendo mal al cliente

• El cliente cambia de parecer o de idea.

• Cambios en la empresa

• Competidores, cambios en leyes, etc.

Fuentes de Riesgo

• Complejidad en la tecnología implicada

• Bugs, malentendidos.

• El conocimiento del equipo, habilidad o experiencia

• Disfunción del equipo, enfermedad, etc.

• Fallas de comunicación en miembros del equipo, ausencia en juntas, olvidar subir código.

• Falta de apego al proceso, fallas en pruebas, olvidar fechas de entrega.