- 1

¿Qué veremos en este curso?
01:48 - 2

Ser ágil define el comportamiento de un equipo
01:47 - 3
La definición de Agile y su importancia en el equipo de trabajo
01:15 - 4

Los valores del Manifiesto para el Desarrollo Ágil de Software
02:40 - 5
Los 12 Principios del Manifiesto para el Desarrollo Ágil de Software
01:09 - 6

Estructura, roles y responsabilidades de los equipos ágiles
09:31 - 7
Glosario
02:57
Los valores del Manifiesto para el Desarrollo Ágil de Software
Clase 4 de 30 • Introducción a las Metodologías Ágiles 2017
Contenido del curso
- 11

Herramientas de Monitoreo
05:36 - 12

Administra tu proyecto de software utilizando JIRA: un issue y project tracking
14:23 - 13

Cómo enfrentar problemas o cambios en el negocio y mantenernos ágiles
06:28 - 14

Estimaciones, capacidad y velocidad de equipos
14:00 - 15

Priorización de tareas
04:32 - 16

Métricas
04:56 - 17

Releases
05:35
Desarrollar software es difícil. Pero organizar un equipo de gente para que desarrollen software a veces es aún más difícil.
A principios de los años 90s predominó la Metodología en Cascada para el desarrollo de software, seguida posteriormente por la que se basaba en Prototipos de software. Estas metodologías tenían el principal problema de que hasta el final del desarrollo, el cliente no podía ver el producto.
El manifiesto ágil es un documento con más de 15 años (creado en el 2001) que reúne principios y prácticas/procesos para crear productos de software de una mejor manera.
Sus autores comienzan diciendo sus valores:
Descubrimos mejores formas de desarrollar software haciéndolo y ayudando a otras peronsas a hacerlo. Y se ha concluido que, si bien los elementos de la derecha son valorados, se valoran aún más los de la izquierda:
- Individuos e interacciones sobre procesos y herramientas: confiar en las habilidades de cada miembro del equipo, valorar sus conocimientos y experiencia que pueda aportar, establecer una comunicación eficiente entre los miembros del equipo
- Software funcionando sobre documentación extensiva: pequeñas porciones de funcionalidad junto al código exclusivamente necesario para correr esas funcionalidades
- Colaboración con el cliente sobre negociación de contratos: una comunicación permanente y transparente con el cliente, en la cual el cliente transmitirá lo que espera del proyecto y el equipo siempre responderá con lo que se ha completado hasta el momento.
- Respuesta ante el cambio sobre seguir un plan: mientras más pasa el tiempo, lo que se entrega al cliente cada vez es más grande, cambiando sólo lo necesario.
¿Ya conocías este documento? ¿Lo has aplicado a alguno de tus proyectos? ¿Te pasó alguna vez que en tu equipo prefirieron negociar un contrato antes que la colaboración con el cliente? ¿O si prefirieron algún proceso o herramienta por sobre algún miembro del equipo?