Este documento introduce el marco de trabajo SCRUM para el desarrollo ágil de software. SCRUM se basa en iteraciones cortas, equipos interdisciplinarios autogestionados y retroalimentación continua del cliente. Los roles clave son el Product Owner, que representa al cliente, el Equipo de Desarrollo y el Scrum Master, que guía el proceso SCRUM. Las reuniones principales son la planeación del sprint, el scrum diario y la revisión del sprint.

1. Introducción a SCRUM José David Parra Certified SCRUM Master SeniorDevelopmentConsultant jparra@geeksco.com

2. AlgunasVerdadesSobrelasMetodologiasTradicionales Esfuerzoenormedurante la fase de planeación Los documentos no alcanzan a reflejartodos los aspectos de la funcionalidad de la solucion – y finalmentenadie los lee! Los estimadossiempreestanlejos de la realidad (demoras) Largashoras de trabajopara el equipo El PM notiene el control del proceso de desarrollo El resultado final no esexactamente lo quequiere el cliente, o no tiene la calidadesperada

3. Complejidad en los Proyectos Tecnologia Requerimientos Volatiles Prioridad variable Intangibles Imprecisos Gente Usuarios/Stakeholders Equipo de Desarrollo

4. Manifiesto del DesarrolloAgil Individuos e Iteraciones en lugar de Procesos y Herramientas Software funcionando en lugar de documentación completa Interacción del Cliente en lugar de negociación contractual Adaptarse al cambio en lugar de seguir un plan

5. Modelo Waterfall vs SCRUM

6. A Ud. le interesa SCRUM si… Deseamanejarproyectos de alto riesgo Requiere un Proceso Empírico vs. Control Definido del Proceso Estadesarrolllando software “in-house” Tiene requerimientos difíciles de predecir o muy cambiantes Si el objetivo es agregar valor de negocio y no el proceso de desarrollo.

7. Quees SCRUM ProcesoAgil Definido en ‘95 por Ken Schwaber y Jeff Sutherland Definicionviene del Rugby

8. SCRUM es un Proceso… Liviano Iterativo Incremental Descentralizado Adaptativo Enfocado en la Productividad

9. Vision General del Proceso

10. Componentes Roles Reuniones Artefactos

11. Roles en SCRUM Product Owner (PO) Representaa los Stakeholders y Usuarios en el proceso Monitorea el ROI Vozunica del cliente Dueño de la Vision y el Product Backlog Priorización de User Stories Equipo Produce software Unico responsible de la ejecución Descentralizado y auto-dirigido Interdisciplinario TamañoIdeal: 7(+/-2) Scrum Master (SM) Noes un Gerente de Proyectos Vigila el seguimeinto del procesoSCRUM RemueveImpedimentos Stakeholder(s) Representa los sponsors del proyecto (financiación) Users Representa los ususios finales

12. Reuniones Estimation Meeting PO priorizaUser Stories Asignar Story Points a cada User Story en el Product Backlog Release Planning Meeting Definir Release(s) y Sprints Define metas del Release Identificamayoresriesgos Sprint Planning 1 (4h) Definir y entender Sprint Backlog (Que se va a comprometer) La meta del Sprint se define Quienes: Todos Sprint Planning 2 (4h) Diseñar Descomponer Sprint Backlog en Tareas (4 – 16 hrs) Analizarimpacto de nuevos User Stories Quienes: SM y Equipo

13. Reuniones Release Planning Meeting

14. Reuniones Daily Scrum (15m) Quien: SM y Equipo Que se completo el dia anterior Que se va a hacerhoy? Queimpedimentostiene? Sprint Review (4h) Quienes: Equipo, PO y Stakeholders Equipomuestraa los Stakeholders que se terminódurante el sprint Se discuten lo quesalióbien y mal durante el sprint. Sprint Retrospective (3h) Quienes: SM y Equipo Se discutenexperiencias del pasado Sprint (gente, procesos y herramientas) Como hacermasefectivo y placentero el siguiente Sprint?

15. Reuniones Daily Scrum

16. Reuniones Sprint Retrospective

17. Sprint: La Iteración SCRUM Caja de Tiempo: 1 a 4 semanas Construccion incremental de la solucion Solo tareas en el Sprint Backlog Todo el equipotrabaja en lastareasqueconforman un Story, hastaterminarlo Al finalizar, los User Stories en el Sprint Backlog debenestarterminados.

18. Artefactos Vision User Stories Dimensionados en Story Points Product Backlog Priorizado (riesgo, valor y necesidad) Detalleproporcional a la prioridad Dinámico Sprint Backlog Solo el Equipopuedecambiarlasprioridades y estimados de tareas Burndowncharts (Velocity) Release Sprint Entregable

19. Task Board

20. Burndown Charts

21. Herramientas El Tablero (Task Board) Microsoft TFS + Conchango http://scrumy.com

22. OtrosConceptos Velocity Numero de Story Points/Sprint “Level of Done” Debe ser definido en conjunto y comunicadodesde el comienzo

23. FAQs Manejo de Defectos entre Sprints? Definicion de Arquitectura? Proyectos de CostoFijo? Escalando SCRUM? Especializacion en el Equipo? Manejo de Cambios

24. Casos de Exito Salesforce.com Adobe Ariba Google HP Microsoft Motorola Philips SAP Siemens Nokia Sun Xerox Yahoo

25. Gracias!