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 SCRUMJosé David ParraCertified SCRUM MasterSeniorDevelopmentConsultantjparra@geeksco.com

2. AlgunasVerdadesSobrelasMetodologiasTradicionalesEsfuerzoenormedurante la fase de planeaciónLos 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 equipoEl PM notiene el control del proceso de desarrolloEl resultado final no esexactamente lo quequiere el cliente, o no tiene la calidadesperada

3. Complejidad en los ProyectosTecnologiaRequerimientosVolatilesPrioridad variableIntangiblesImprecisosGenteUsuarios/StakeholdersEquipo de Desarrollo

4. Manifiesto del DesarrolloAgilIndividuos e Iteraciones en lugar de Procesos y HerramientasSoftware funcionando en lugar de documentación completaInteracción del Cliente en lugar de negociación contractualAdaptarse al cambio en lugar de seguir un plan

5. Modelo Waterfall vs SCRUM

6. A Ud. le interesa SCRUM si…Deseamanejarproyectos de alto riesgoRequiere un Proceso Empírico vs. Control Definido del ProcesoEstadesarrolllando 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 SCRUMProcesoAgilDefinido en ‘95 por Ken Schwaber y Jeff SutherlandDefinicionviene del Rugby

8. SCRUM es un Proceso…LivianoIterativoIncrementalDescentralizadoAdaptativoEnfocado en la Productividad

9. Vision General del Proceso

10. ComponentesRolesReunionesArtefactos

11. Roles en SCRUMProduct Owner (PO)Representaa los Stakeholders y Usuarios en el procesoMonitorea el ROIVozunica del clienteDueño de la Vision y el Product BacklogPriorización de User StoriesEquipoProduce softwareUnico responsible de la ejecuciónDescentralizado y auto-dirigidoInterdisciplinarioTamañoIdeal: 7(+/-2)Scrum Master (SM)Noes un Gerente de ProyectosVigila el seguimeinto del procesoSCRUMRemueveImpedimentosStakeholder(s)Representa los sponsors del proyecto (financiación)UsersRepresenta los ususios finales

12. ReunionesEstimation MeetingPO priorizaUser Stories Asignar Story Points a cada User Story en el Product BacklogRelease Planning MeetingDefinir Release(s) y SprintsDefine metas del ReleaseIdentificamayoresriesgosSprint Planning 1 (4h)Definir y entender Sprint Backlog (Que se va a comprometer)La meta del Sprint se defineQuienes: TodosSprint Planning 2 (4h)DiseñarDescomponer Sprint Backlog en Tareas (4 – 16 hrs)Analizarimpacto de nuevos User StoriesQuienes: SM y Equipo

13. ReunionesRelease Planning Meeting

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

15. ReunionesDaily Scrum

16. ReunionesSprint Retrospective

17. Sprint: La Iteración SCRUMCaja de Tiempo: 1 a 4 semanasConstruccion incremental de la solucionSolo tareas en el Sprint BacklogTodo el equipotrabaja en lastareasqueconforman un Story, hastaterminarloAl finalizar, los User Stories en el Sprint Backlog debenestarterminados.

18. ArtefactosVisionUser StoriesDimensionados en Story PointsProduct BacklogPriorizado (riesgo, valor y necesidad)Detalleproporcional a la prioridadDinámicoSprint BacklogSolo el Equipopuedecambiarlasprioridades y estimados de tareasBurndowncharts (Velocity)ReleaseSprintEntregable

19. Task Board

20. Burndown Charts

21. HerramientasEl Tablero (Task Board)Microsoft TFS + Conchangohttp://scrumy.com

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

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

24. Casos de ExitoSalesforce.comAdobeAribaGoogleHPMicrosoftMotorolaPhilipsSAPSiemensNokiaSunXeroxYahoo

25. Gracias!