1. SCRUM
1.1. Roles
1.1.1. Product Owner
1.1.2. ScrumMaster
1.1.3. Equipo de desarrollo
1.1.4. Stakeholders
1.1.5. Administradores
1.2. Daily Scrum
1.3. Scrum de Scrum
1.4. Sprint Planning Meeting
1.5. Sprint Review Meeting
1.6. Sprint Retrospective
1.7. Beneficios
1.7.1. Flexibilidad a cambios
1.7.2. Reducción del Time to Market
1.7.3. Mayor calidad del software
1.7.4. Mayor productividad
1.7.5. Maximiza el retorno de la inversión (ROI)
1.7.6. Predicciones de tiempos
1.7.7. Reducción de riesgos
1.8. Documentos
1.8.1. Product backlog
1.8.2. Sprint backlog
1.8.3. Burn down chart
2. Xtreme Programming
2.1. Caracteristicas
2.1.1. Desarrollo iterativo e incremental
2.1.2. Pruebas unitarias continuas
2.1.3. Programación en parejas
2.1.4. integración del equipo de programación con el cliente
2.1.5. Corrección de todos los errores
2.1.6. Refactorización del código
2.1.7. Propiedad del código compartida
2.1.8. Simplicidad en el código
2.2. Roles
2.2.1. Programador
2.2.2. Cliente
2.2.3. Tester
2.2.4. Tracker
2.2.5. Coach
2.2.6. Consultor
2.2.7. Big boss
3. DSDM
3.1. Involucrar al cliente es la clave
3.2. El equipo del proyecto debe tener el poder
3.3. entrega frecuente de productos
3.4. entregar un sistema que satisface las actuales necesidades de negocio
3.5. El desarrollo es iterativo e incremental
3.6. Todos los cambios durante el desarrollo son reversibles
3.7. alcance de alto nivel y los requerimientos deberían ser base-lined
3.8. Las pruebas son realizadas durante todo el ciclo vital del proyecto
3.9. La comunicación y cooperación entre todas las partes interesadas en el proyecto
3.10. Ningún sistema es construido a la perfección en el primer intento
3.11. La entrega del proyecto debería ser a tiempo, respetando presupuestos y con buena calidad.
3.12. DSDM solo requiere que cada paso del desarrollo se complete lo suficiente como para que empiece el siguiente paso
3.13. técnicas de Desarrollo y Gestión del proyectos están incluidas
3.14. DSDM puede ser usado también en proyectos de ampliación de sistemas TI actuales o incluso en proyectos de cambio no relacionados con las TI.
3.15. Evaluación de riesgos debiera centrarse en entregar función de negocio
3.16. entrega de productos más que la consecución de tareas
3.17. La Estimación debería estar basada en la funcionalidad del negocio
4. Lean software development
4.1. Eliminar los desperdicios
4.1.1. Código y funcionalidades innecesarias
4.1.2. Retraso en el proceso de desarrollo de software
4.1.3. Requisitos poco claros
4.1.4. Burocracia
4.1.5. Comunicación interna lenta
4.2. Ampliar el aprendizaje
4.3. Decidir lo más tarde posible
4.4. Reaccionar tan rápido como sea posible
4.5. Potenciar el equipo
4.6. Crear la integridad
4.7. Ver todo el conjunto
5. Rational Unified Process
5.1. Adaptar el proceso
5.2. Equilibrar prioridades
5.3. Demostrar valor iterativamente
5.4. Colaboración entre equipos
5.5. Enfocarse en la calidad
5.6. Elevar el Nivel de Abstracción
5.7. Principales características
5.7.1. Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
5.7.2. Pretende implementar las mejores prácticas en Ingeniería de Software
5.7.3. Desarrollo iterativo
5.7.4. Administración de requisitos
5.7.5. Uso de arquitectura basada en componentes
5.7.6. Control de cambios
5.7.7. Modelado visual del software
5.7.8. Verificación de la calidad del software
5.8. Fases
5.8.1. Proceso
5.8.2. Soporte
5.9. Artefactos
5.9.1. Inicio
5.9.2. Elaboracion
5.9.3. Contruccion
5.9.4. Transicion