170 likes | 331 Views
SCRUM. SCRUM. Gregório Baggio Tramontina (RA 014864) Ricardo Ribeiro dos Santos (RA 030060). MO409. 1. IC - UNICAMP. Roteiro. Motivação/Foco Metodologia SCRUM Métodos de Controle do SCRUM Prós e contras Exemplos de utilização Conclusões. MO409. 2. IC - UNICAMP.
E N D
SCRUM SCRUM Gregório Baggio Tramontina (RA 014864) Ricardo Ribeiro dos Santos (RA 030060) MO409 1 IC - UNICAMP
Roteiro • Motivação/Foco • Metodologia SCRUM • Métodos de Controle do SCRUM • Prós e contras • Exemplos de utilização • Conclusões MO409 2 IC - UNICAMP
Motivação/Foco • Processo de desenvolvimento de software é caótico • Imprevisibilidade e incertezas fazem parte desse processo • Requisitos de usuário, pressões de tempo, competição, qualidade erecursos (base inicial do projeto) podem sofrer alterações • Problema de modelos lineares (cascata, CMM): assumir o processo como não sujeito a mudanças e incertezas • SCRUM: • Processo ágil de gerenciamento • Leva em conta o caráter evolutivo dessas variáveis • Encoraja flexibilidade no desenvolvimento • Operar o mais próximo possível do caos, mantendo ainda a ordem • Usa um mecanismo de controle para manter o projeto em ordem MO409 3 IC - UNICAMP
Metodologia • Três fases: • Planejamento / Design da Arquitetura • Sprints • Fechamento (Closure) • Atividades durante o planejamento/design da arquitetura • Análise e projeto primários (irão mudar no decorrer do projeto) • Análise de riscos, definição das equipes de desenvolvimento, estimativas de custo e fixação dos prazos • Desenvolvimento de um backlog inicial • backlog: lista de tarefas a serem executadas durante odesenvolvimento do sistema, em ordem de prioridade • Identificação das alterações para implementar o backlog Sprints Plan. / Design Arq. Fechamento MO409 4 IC - UNICAMP
Metodologia • Equipes de desenvolvimento no SCRUM • Pequenas (máx. 6 a 10) • Gerenciadas pelo Scrum Master • Alta Interatividade • Desenvolvimento (Sprints) • Seqüência de sprints • Sprint: Ciclo de trabalho de desenvolvimento • Cada sprint: 1 a 4 semanas • Aloca-se parte do backlog, em ordem de prioridade, para uma equipe • Backlog não muda durante o sprint (não há interferência externa) • Atividades durante os sprints • Desenvolvimento • Wrap • Revisão • Ajustes • Desenvolvimento produz artefatos • Documentação, código, protótipos,... MO409 5 IC - UNICAMP
Metodologia • Equipes de desenvolvimento no SCRUM • Pequenas (máx. 6 a 10) • Gerenciadas pelo Scrum Master • Alta Interatividade • Desenvolvimento (Sprints) • Seqüência de sprints • Sprint: Ciclo de trabalho de desenvolvimento • Cada sprint: 1 a 4 semanas • Aloca-se parte do backlog, em ordem de prioridade, para uma equipe • Backlog não muda durante o sprint (não há interferência externa) • Atividades durante os sprints • Desenvolvimento • Wrap • Revisão • Ajustes • Desenvolvimento produz artefatos • Documentação, código, protótipos,... Definir as mudanças necessárias no software Analisar, projetar, implementar, testar e documentar as mudanças MO409 6 IC - UNICAMP
Metodologia • Equipes de desenvolvimento no SCRUM • Pequenas (máx. 6 a 10) • Gerenciadas pelo Scrum Master • Alta Interatividade • Desenvolvimento (Sprints) • Seqüência de sprints • Sprint: Ciclo de trabalho de desenvolvimento • Cada sprint: 1 a 4 semanas • Aloca-se parte do backlog, em ordem de prioridade, para uma equipe • Backlog não muda durante o sprint (não há interferência externa) • Atividades durante os sprints • Desenvolvimento • Wrap • Revisão • Ajustes • Desenvolvimento produz artefatos • Documentação, código, protótipos,... • Fechar os pacotes modificados • Gerar executáveis dos pacotes MO409 7 IC - UNICAMP
Metodologia • Equipes de desenvolvimento no SCRUM • Pequenas (máx. 6 a 10) • Gerenciadas pelo Scrum Master • Alta Interatividade • Desenvolvimento (Sprints) • Seqüência de sprints • Sprint: Ciclo de trabalho de desenvolvimento • Cada sprint: 1 a 4 semanas • Aloca-se parte do backlog, em ordem de prioridade, para uma equipe • Backlog não muda durante o sprint (não há interferência externa) • Atividades durante os sprints • Desenvolvimento • Wrap • Revisão • Ajustes • Desenvolvimento produz artefatos • Documentação, código, protótipos,... • Interna ao sprint • Apresentação dos resultados entre as equipes • Levantamento e resolução de problemas MO409 8 IC - UNICAMP
Metodologia • Equipes de desenvolvimento no SCRUM • Pequenas (máx. 6 a 10) • Gerenciadas pelo Scrum Master • Alta Interatividade • Desenvolvimento (Sprints) • Seqüência de sprints • Sprint: Ciclo de trabalho de desenvolvimento • Cada sprint: 1 a 4 semanas • Aloca-se parte do backlog, em ordem de prioridade, para uma equipe • Backlog não muda durante o sprint (não há interferência externa) • Atividades durante os sprints • Desenvolvimento • Wrap • Revisão • Ajustes • Desenvolvimento produz artefatos • Documentação, código, protótipos,... • Consolidação das informações apreendidas na fase de revisão: implementação de correções, etc MO409 9 IC - UNICAMP
Metodologia • SCRUM Meetings • Reuniões freqüentes (diárias) da equipe • Rápidas (15/20 min.) de pé! • Desenvolvedores devem responder a 3 perguntas: • O que você fez nas últimas 24h (desde a última reunião)? • O que está dificultando a continuação de seu trabalho? • O que você vai fazer nestas próximas 24h (até a próxima reunião)? • Socialização da equipe e da informação • Sprints terminam com uma revisão geral • Demonstração das funcionalidades implementadas no sprint • Pode incluir os gerentes, desenvolvedores, clientes, patrocinadores,vendedores, gerentes de marketing, etc. • Novos itens podem ser acrescentados ao backlog • Atividades durante o Fechamento • Preparação do produto para a entrega de uma versão operacional • Ocorre quando as variáveis de tempo, competição, recursos, etc,determinam o fim do processo MO409 10 IC - UNICAMP
Metodologia Visão geral Fonte: Scrum Website - http://www.controlchaos.com/about/ MO409 11 IC - UNICAMP
Controles em Scrum • Risco é o controle primordial • Os controles são usados nas diferentes fases do Scrum • Outros pontos de controle na metodologia são: • Backlog • requisitos não obtidos na versão atual do produto • Melhorias/Atualização • itens do backlog que podem estar disponíveis de acordo com os requisitos de tempo, qualidade, competitividade, etc. • Pacotes • objetos que devem ser modificados para implementar um item do backlog • Riscos • constantemente avaliados • Mudanças • alterações necessárias para implementar itens do backlog • Garantia de qualidade está relacionada com os controles realizados MO409 12 IC - UNICAMP
Prós e Contras - Scrum MO409 IC - UNICAMP • Flexível às mudanças de requisitos • Fornece mecanismos de controle para planejar uma atualização de produto e gerenciar variáveis a medida do progresso do projeto • Equipes pequenas = maior compartilhamento de informações • A base da metodologia é a orientação a objetos • Adaptável com outras metodologias • Suporte limitado para ambientes de desenvolvimento distribuído • Desenvolvimento de software safety-critical • Dificuldade de adaptação • Ferramentas específicas 13
Exemplos de utilização de Scrum • AG Communication Systems • Simulador Multiplataforma • Call center • Advanced Development Methods • Softwares para automação de processos • VMARK Software • Ambientes de desenvolvimento de software • Trans Canada Pipeline Ltda • XP@Scrum MO409 IC - UNICAMP 14
Conclusões • Existem escopos bem definidos para o emprego de metodologias de processos ágeis como Scrum • Assume que o processo de desenvolvimento de software é empírico e não-definido • Conhecimento sobre o sistema aumenta com o progresso do trabalho e compartilhamento de informação • Interatividade e controle são as principais características • Factível de ser utilizado com outras metodologias de desenvolvimento de software • Como todo processo, tem prós e contras MO409 IC - UNICAMP 15
Referências • Schwaber, K. SCRUM Development Process. 10th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA). ACM/SIGPLAN October, 1995. • Schwaber, K., Controlled Chaos: Living on the Edge. American Programmer, April, 1996. • Beedle M., Devos, M., Sharon, Y., Schwaber, K., Sutherland, J., SCRUM: An Extension Pattern Language for Hyperproductive Software Development, Pattern Languages of Program Design 4, N. Harrison, B. Foote, and H. Rohnert, eds., Addison-Wesley, Reading, Mass., 2000, p. 637-651. • ADM, Inc. Controlled-Chaos Software Development. Disponível em http://www.controlchaos.com/download/. Data do último acesso 09/09/2004. • Rising, L. and Janoff, N. S. The Scrum Software Development Process for Small Teams, IEEE Software, v. 7, n. 04, p. 26-32 July/August, 2000. • D. Turk, R. France, and B. Rumpe. Limitations of Agile Software Processes. In Proceedings of the Third International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2002), pages 43--46, Alghero, Italy, May 2002. • SCRUM – Site oficial: http://www.controlchaos.com. Data do último acesso 17/09/2004. MO409 IC - UNICAMP 16