A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

SCRUM SCRUM Gregório Baggio Tramontina (RA )

Apresentações semelhantes


Apresentação em tema: "SCRUM SCRUM Gregório Baggio Tramontina (RA )"— Transcrição da apresentação:

1 SCRUM SCRUM Gregório Baggio Tramontina (RA 014864)
O processo SCRUM Gregório Baggio Tramontina (RA ) Ricardo Ribeiro dos Santos (RA ) IC - UNICAMP MO409 1

2 Roteiro Motivação/Foco Metodologia SCRUM Métodos de Controle do SCRUM
Prós e contras Exemplos de utilização Conclusões Tópicos abordados: - Motivação de foco do SCRUM - A metodologia do processo SCRUM - Fases - Atividades em cada fase - Sprints - SCRUM Meetings - Fechamento - Métodos de controle utilizados pelo processo SCRUM - Prós e contras do processo SCRUM - Conclusões IC - UNICAMP MO409 2

3 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 e recursos (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 Para os que suportam o processos SCRUM, o processo de desenvolvimento de software é caótico, ou seja, sujeito a incertezas e várias mudanças durante o processo. Os fatores iniciais presentes no projeto, como os requisitos de usuário, pressões de tempo, competição, qualidade e recursos disponíveis, podem mudar. O grande problema apontado pelos entusiastas do SCRUM para processos lineares, como o modelo em cascata, espiral, ou mesmo as práticas advogadas pelo CMM, é que estes consideram o processos de software como se ele fosse muito bem definido e controlável, deixando pouco espaço para uma adaptabilidade às mudanças que certamente vão ocorrer durante o desenvolvimento do software, causando impactos negativos na produtividade e valor do produto final. Para tentar driblar esses problemas, propõe-se o SCRUM. O SCRUM é um processo de gerência de desenvolvimento de software que tenta levar em conta o caráter evolutivo intrínseco dos fatores do projeto já comentados. Não só aceita que haja flexibilidade às mudanças que vão ocorrer nesses fatores, mas também encoraja a flexibilidade durante o processo de desenvolvimento de software, tentando operar o mais próximo possível do caos, mas usando mecanismos de controle para manter o projeto em ordem. IC - UNICAMP MO409 3

4 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 o desenvolvimento do sistema, em ordem de prioridade Identificação das alterações para implementar o backlog Sprints Plan. / Design Arq. Fechamento O SCRUM tem três fases: (I) Planejamento inicial / Design da arquitetura, (II) Sprints e (III) Fechamento. Em termos gerais, realiza-se um planejamento inicial do projeto, seguindo um modelo linear como o em cascata ou espiral, ou seja, processos bem conhecidos e com entradas e saídas bem definidas. Depois entra-se em um ciclo de sprints, que são o coração do SCRUM. Assim que fatores como tempo, pressão, recursos ou outros, indicam que está na hora de parar o ciclo dos sprints, entra-se em uma fase de fechamento, que também é um processo linear como o planejamento, e objetiva a entrega de uma versão operacional do produto de software. Durante o planejamento / design da arquitetura, faz-se uma análise e projeto iniciais, mas não se analisa nem se planeja demais, já que assume-se que tudo o que foi definido nesta fase pode mudar durante o decorrer do desenvolvimento. Analisam-se também os riscos do projeto, definem-se as equipes de desenvolvimento, e realizam-se estimativas de custos e fixação de prazos para entregas de versões e tarefas, entre outras atividades. A partir da análise e projeto iniciais, cria-se uma lista de atividades, em ordem de prioridade, que devem ser executadas para se chegar ao resultado final desejado do projeto. Essa lista é um conceito importante em SCRUM, e tem um nome especial: backlog. Assim que um backlog inicial é criado, faz-se um design da arquitetura do produto final, que inclui, entre outras atividades, o levantamento das mudanças necessárias para se chegar ao resultado almejado. IC - UNICAMP MO409 4

5 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,... As equipes de desenvolvimento, no processo SCRUM, devem ser pequenas. Encontra-se na literatura recomendações de um máximo entre 6 e 10 indivíduos. Não há papéis bem definidos dentro dessa equipe ,sendo que todos são analistas, projetistas, desenvolvedores e testadores. Mas existe um papel mais importante, que é o do ScrumMaster, responsável por gerenciar a equipe e manter as SCRUM Meetings (vistas mais adiante). Deseja-se manter as equipes pequenas pois a interatividade entre os seus membros deve ser alta. Todos devem ter conhecimento sobre o sistema como um todo, e trocar informações entre si, socializando assim tanto os membros quanto a informação que eles trazem consigo. A fase de desenvolvimento propriamente dita tem seu coração no ciclo de sprints. Ou seja, assim que o planejamento inicial termina, tem-se um sprint após o outro, até que se decida pela fase de fechamento. O sprint é uma fase onde várias atividades são desenvolvidas simultaneamente. No começo de um sprint, uma parte do backlog é alocada para uma equipe. Esses itens do backlog serão trabalhados através de atividades pertencentes a quatro grandes grupos: desenvolvimento, wrap, revisão e ajustes. Muito importante é o fato de que o backlog não muda durante o sprint, ou seja,~não se coloca interferência externa no processo durante um sprint. Os sprints produzem “artefatos”, que podem ser reutilizados no futuro. Esses artefatos são a documentação, o código, ou outros “subprodutos” de um sprint. IC - UNICAMP MO409 5

6 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 Durante o desenvolvimento, definem-se as mudanças que devem ser feitas nos pacotes de software para que a parte do backlog alocada à equipe seja implementada. Depois realizam-se análise, projeto, implementação, testes e documentação dessas mudanças. IC - UNICAMP MO409 6

7 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 Na fase de wrap, fecham-se versões executáveis dos pacotes do software. IC - UNICAMP MO409 7

8 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 Essa fase de revisão é interna ao sprint, quando a equipe se reúne para discutir os problemas encontrados e revisar as funcionalidades implementadas durante o sprint. IC - UNICAMP MO409 8

9 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 Os ajustes são a fase onde o que se apreendeu da fase de revisão é consolidado. IC - UNICAMP MO409 9

10 Metodologia SCRUM Meetings Sprints terminam com uma revisão geral
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 As SCRUM Meetings, ou em uma tradução livre, reuniões SCRUM, são reuniões freqüentes, não raro diárias, e rápidas, da equipe de desenvolvimento, para trocar informações e manter o foco e o controle do processo. Nesta reunião, diz-se que os membros da equipe devem responder a três perguntas: (I) o que você fez nas últimas 24 horas (ou desde a última reunião)?, (II) o que está atrapalhando ou dificultando a conclusão do seu trabalho? e (III) o que você vai fazer nas próximas 24 horas (ou até a próxima reunião). Além de ajudar a manter a ordem do processo, ajuda a manter a equipe unida, consciente do todo do software, e a disseminação da informação. Os sprints terminam com uma revisão geral, onde ocorre uma demonstração das funcionalidades implementadas durante o sprint e uma revisão dessas funcionalidades como um todo. Essa revisão geral inclui os desenvolvedores e pode incluir também os usuários finais, patrocinadores do projeto e gerentes de marketing, entre outros. Novos itens podem ser adicionados ao backlog como fruto dessa revisão. Quando as variáveis de tempo, qualidade, pressões diversas, e recursos, entre outras, indicam o fim do ciclo de sprints, entra-se no fechamento. Nesta fase prepara-se uma versão operacional do produto para ser entregue. IC - UNICAMP MO409 10

11 Metodologia Visão geral
Essa é a visão geral do SCRUM. Nota-se o backlog do produto, e logo após nota-se que uma parte dele é alocada para ser implementada no sprint corrente. Essa parte pode ser novamente dividida entre as diversas equipes de desenvolvimento, cada uma em seu sprint. Logo após vem o ciclo de sprints. A cada 24 horas aproximadamente, durante o sprint corrente, tem- se uma SCRUM Meeting. Ao final de um sprint há a demonstração do trabalho feito no seu decorrer. Fonte: Scrum Website - IC - UNICAMP MO409 11

12 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 Os controles são revisados, modificados e atribuídos a cada reunião de revisão no final de um sprint. Diversos controles para diferentes fases da metodologia e por diferentes membros. Gerentes usam controles para verificar o que foi realizado do backlog Equipes utilizam controles para gerenciar mudanças, problemas IC - UNICAMP MO409 12

13 Prós e Contras - Scrum 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 Prós: - Os curtos períodos entre sprints facilitam a incorporação de mudanças durante o desenvolvimento do produto. - Equipes pequenas possibilitam maior agilidade, maior compartilhamento de informações. - O projeto do produto a ser desenvolvido/atualizado deve permitir a identificação de interfaces bem definidas entre os pacotes (grupos de objetos) para que a atribuição de trabalho às equipes possa ocorrer de maneira independente - É possível adaptar Scrum com outras metodologias, em especial, metodologias que tratam a sistemática de desenvolvimento/implementação do produto. Há alguns relatos do emprego de Scrum juntamente com XP em equipes de desenvolvimento. Contras: - Embora o uso de tecnologias de comunicação possam reduzir a falta de interatividade entre membros de equipes separadas geograficamente, os custos envolvidos com essas tecnologias podem ser proibitivos. De fato, um dos grandes fatores para o sucesso do produto desenvolvido sobre a metodologia Scrum está nas trocas de informações e reuniões presenciais entre os envolvidos com o produto. - Determinadas aplicações necessitam de um maior cuidado no tocante ao projeto e especificação do produto. Scrum procura “restringir” essas etapas e, nesse sentido, pode não ser a melhor escolha para tais casos. - Na maioria dos relatos sobre o uso do Scrum, há um período de adaptação. Muitas empresas enviam gerentes para cursos de ScrumMaster Em Scrum, a ausência de ferramentas específicas é citada como um ponto negativo. a AD software possui uma ferramenta de gerenciamento de equipes mas o culto é alto. Muitos gerentes adotam o Excel e/ou ferramentas XP. - A freqüência com que componentes funcionais devem ser apresentados à toda a equipe envolvida no projeto pode restringir a participação de pessoas pouco experientes. Scrum tem apresentado consideráveis ganhos de produtividade em equipes já experientes no desenvolvimento de determinado produto mas que estavam com problemas no processo de desenvolvimento. Equipes pouco experientes podem ter dificuldades em cumprir os prazos impostos pelos Sprints. IC - UNICAMP MO409 13

14 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 A AG Communication Systems tem utilizado SCRUM desde 1998 em diversos projetos de desenvolvimento de software com sucesso. Resultados da aplicação de Scrum em dois projetos são apresentados no artigo: Rising, L. Janoff, N. S., The Scrum Software Development Process for Small Teams, IEEE Software, ADM e VMARK são fábricantes de software indepentes que se uniram em torno da preocupação sobre os reais ganhos com projetos de software OO. Dessa união surgiram as principais idéias que constituem a metodologia SCRUM. Em 2002 a Trans Canada Pipeline Ltda procurou por consultores de Scrum e XP a fim de unir as duas metodologias no processo de desenvolvimento de softwares. IC - UNICAMP MO409 14

15 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 É argumentado que processos ágeis podem ser valiosos para determinados nichos de desenvolvimento que exigem rapidez e não necessitam de grande atenção nos documentos. O SCRUM trata o produto como uma caixa preta na fase inicial (planejamento) e, à medida que o processo evolui, desmistifica empiricamente (através dos sprints e meetings) os requisitos necessários. A freqüencia das SCRUM Meetings e a participação de pessoas envolvidas com o produto mas que não fazem parte das equipes de desenvolvimento são argumentos a favor do progresso e do compartilhamento de informação. A verdadeira razão dos meetings é justamente possibilitar interatividade entre os membros da equipe e controle sobre o andamento (progresso e dificuldades) do projeto. É sabido que correções futuras podem custar caro. Relatos práticos de uso de Scrum e XP são encontrados na literatura. Consultores argumentam que SCRUM é flexível suficiente para funcionar com outras metodologias. IC - UNICAMP MO409 15

16 Referências Schwaber, K. SCRUM Development Process. 10th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA). ACM/SIGPLAN October, 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 ADM, Inc. Controlled-Chaos Software Development. Disponível em 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 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 , Alghero, Italy, May 2002. SCRUM – Site oficial: Data do último acesso 17/09/2004. O artigo “SCRUM Development Process” foi o primeiro documento publicado sobre SCRUM e descreve detalhadamente a metodologia. O artigo “The Scrum Software Development Process for Small Teams” relata duas experiências da empresa AG Communication Systems com Scrum. O artigo “Limitations of Agile Software Processes” relata interessantes contra- argumentos sobre a limitação de processos ágeis de software. Baseia-se nas características de SCRUM, XP e Crystal. O Web Site é a principal fonte de informações na Web sobre Scrum. IC - UNICAMP MO409 16


Carregar ppt "SCRUM SCRUM Gregório Baggio Tramontina (RA )"

Apresentações semelhantes


Anúncios Google