Scrum
Last updated
Was this helpful?
Gitbook
Last updated
Was this helpful?
Na primavera de 2000, líderes da comunidade de se reuniram para discutir as práticas do XP. Durante essa reunião também foi debatido a relação entre o XP e os até então chamados Método Leves.
Esses tais de Métodos Leves eram os que hoje conhecemos como , DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming entre outros.
Essa relação foi discutida pelo fato dos métodos leves e do XP estarem na contra-mão dos até então métodos pesados. Ou seja, eles possuíam uma abordagem mais leve e menos burocrática.
Como consequência dessa discussão foi concluído que o XP era melhor como um método especifico, porém com espaço comum entre ele e os métodos leves. Foi dessa conclusão que , conhecido como Tio Bob, resolveu criar um encontro para as pessoas interessadas em Métodos Leves.
Muitas pessoas foram contactadas porém apenas 17 estavam presente em fevereiro de 2001 em um resort de ski nas montanhas nevadas de Utah.
Durante essa reunião um grande consenso sobre como deveriam ser os métodos de desenvolvimento de software foi criado. E foi batizado como O Manifesto do desenvolvimento de Software Ágil, no qual chamamos de Manifesto Ágil.
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
Discussões diárias de status com a equipe de desenvolvimento;
A discussão diária na qual cada membro da equipe de desenvolvimento responde às seguintes perguntas:
O que fiz desde ontem em direção a meta?
O que estou planejando fazer até amanhã em direção a meta?
Existe algo me impedindo de atingir meta?
Transparência no planejamento e desenvolvimento;
Reuniões frequentes com os stakeholders (partes interessadas no projeto) para monitorar o progresso;
Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" não necessariamente significa "produzir mais".
Eficaz com:
Prazos apertados
Requisitos Mutáveis
Urgência do Negócio
A Sprint é o ciclo básico do Scrum. Ele tem um período pequeno, geralmente uma ou duas semanas, no máximo 1 mês. Antes de cada Sprint é feita uma Sprint Planning Meeting, em que são decididas quantas e quais coisas serão feitas ao decorrer da Sprint. Idealmente todas as tarefas escolhidas devem estar feitas ao fim dela. No fim da Sprint é realizada uma Sprint Review Meeting, em que é apresentado o resultado da Sprint e são revisados pelos interessados no projeto. A partir desse feedback é criada a próxima Sprint. Esse processo é repetido até o produto estar pronto.
Engenharia de Software (6º Semestre)
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (, Janeiro-Fevereiro ). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em , incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka. Em , Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares em todo o mundo.
A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.
