Agile project management with Scrum
Sliger, Michele
Como citar este artigo:
Sliger, M. (2011). Agile project management with Scrum. Paper presented at PMI® Global Congress 2011—North America, Dallas, TX. Newtown Square, PA: Project Management Institute.
Resumo
O Scrum é uma das metodologias ágeis projetadas para orientar as equipes na entrega iterativa e incremental de um produto. Muitas vezes referida como “uma estrutura de gestão ágil de projetos”, seu foco está no uso de um processo empírico que permite às equipes responder rápida, eficientemente e efetivamente a mudanças. Os métodos tradicionais de gestão de projetos corrigem os requisitos em um esforço para controlar o tempo e o custo; Scrum, por outro lado, corrige tempo e custo em um esforço para controlar os requisitos. Isso é feito usando caixas de tempo, cerimônias colaborativas, uma lista de pendências de produto priorizada e ciclos de feedback freqüentes. O envolvimento do negócio em todo o projeto é crítico, pois o Scrum depende muito da colaboração entre a equipe e o cliente ou representante do cliente para criar o produto certo de forma enxuta. Este artigo fornece uma visão geral do Scrum e seu uso na gestão de projetos.
O que é Scrum?
Devemos primeiro ser claros sobre o que o Scrum não é. Há um equívoco comum que Agile é Scrum. Embora o Scrum seja de fato ágil, não é o único método de implementação de princípios ágeis. Scrum é simplesmente uma das muitas abordagens ágeis para o desenvolvimento de projetos e produtos. Outros métodos incluem Extreme Programming (XP), Crystal, desenvolvimento orientado a recursos, DSDM Atern, e assim por diante. Todos esses métodos aderem ao manifesto ágil e seus princípios associados. Uma metáfora útil seria pensar em Agile como sendo sorvete, enquanto Scrum, XP, Crystal, etc, são todos simplesmente sabores diferentes, como chocolate, morango, baunilha. Eles são todos ágeis, eles são todos bons, e muitos podem ser usados em combinação.
Simplificando, o Scrum é um método ágil de entrega de resultados iterativos e incrementais que usa feedback frequente e tomada de decisão colaborativa.
História
Scrum é baseado em um paper escrito, em 1986, por Hirotaka Takeuchi e Ikujiro Nonaka para a Harvard Business Review intitulado “o novo jogo de desenvolvimento de novos produtos.” Neste artigo, os autores usaram o esporte do rugby como uma metáfora para descrever os benefícios de equipes auto organizadas no desenvolvimento e na entrega inovativos do produto. Jeff Sutherland, Ken Schwaber e Mike Beedle tiraram as ideias deste artigo, incluindo a metáfora, e aplicaram-na ao seu campo de desenvolvimento de software. Eles chamaram seu novo método Scrum, após o termo de rugby que descreve como as equipes formam um círculo e ir para a bola para colocá-la em jogo novamente. Quem primeiro aplicou este método na Easel Corporation, em 1993, foram Schwaber e Beedle. Eles escreveram sobre suas experiências em seu livro “Agile Software Development com Scrum”, em 2002. Depois o livro de Schwaber “Agile Project Management com Scrum” em 2004, incluiu o trabalho que ele tinha feito com o Primavera.
A estrutura do Scrum
Schwaber refere-se ao Scrum como uma estrutura e não uma metodologia. Isso se deve principalmente às conotações em torno da metodologia da palavra, que muitos inferem como prescritivas na natureza. Por outro lado, o Scrum simplesmente fornece uma estrutura para entrega, mas não lhe diz como fazer práticas específicas, deixando isso para a equipe determinar. A figura 1 mostra a estrutura básica do Scrum.
Figura 1. A estrutura original do Scrum
O projeto começa com uma visão clara fornecida pelo negócio, e um conjunto de características do produto ou do projeto em ordem de importância. Essas características são mantidas pelo cliente ou seu representante (aqui referido como Product Owner PO). Uma caixa de tempo comumente referida como uma iteração ou Sprint, é a quantidade definida de tempo que a equipe tem para concluir os trabalhos selecionados. Sprints são geralmente de uma a quatro semanas de duração, e ele é mantido ao longo da vida do projeto, de modo a estabelecer uma cadência. A equipe seleciona itens da lista de pendências do projeto, que possa ser concluída no sprint, e cria uma lista de recursos e tarefas para a reunião de planejamento de Sprint.
Feita a reunião, a equipe se compromete com as pendências do Sprint e as tarefas começam. Durante esse tempo, no Sprint, a equipe deve estar protegida contra interrupções e mudanças e pode se concentrar em atender as metas do Sprint. Nenhuma alteração na lista de pendências do Sprint é permitida; no entanto, a lista de pendências do projeto pode ser alterada para os próximos Sprints.
Durante o Sprint, a equipe verifica diariamente uns com os outros na forma de uma reunião de 15 minutos conhecida como Daily Scrum. A equipe está em um círculo e cada membro menciona o que foi feito no dia anterior, o que planeja fazer hoje, e o que está ficando em seu caminho.
No final do Sprint, a equipe apresenta o trabalho que concluído ao PO e reúne comentários que afetarão o que eles devem trabalhar no próximo Sprint. Eles também têm uma retrospectiva para aprender a melhorar. Esta reunião é crítica, pois seu foco está nos três pilares do Scrum: transparência, inspeção e adaptação.
Papéis e Responsabilidades
Há apenas três funções no Scrum: o Scrum Master, o PO Product Owner e a equipe.
O Scrum Master é o guardião do processo e o protetor da equipe. Eles removem obstáculos, facilitam a comunicação da equipe, mediam discussões dentro da equipe e negociam com aqueles externos à equipe. Acima de tudo, eles existem para servir à equipe.
O PO representa a voz do cliente e tem autoridade para tomar decisões sobre o produto. Essa pessoa possui a lista de pendências do produto e é responsável por comunicar a visão para a equipe e definir e priorizar itens da lista de pendências. O PO trabalha com a equipe em uma base diária para responder a perguntas e fornecer orientação sobre o produto.
A equipe é constituída por, cerca de, sete especialistas que são, conjuntamente, responsáveis pela entrega do projeto e do seu produto. Eles possuem as estimativas, fazem compromissos para execução das tarefas e relatam o status diário entre si no Daily Scrum. Eles se auto organizam, o que significa que a estrutura aparece sem intervenção explícita do exterior. Em outras palavras, a equipe define o “como”, enquanto o PO define o “que”.
A aplicação do Scrum
O Scrum é aplicado seguindo um conjunto de rituais. Os rituais de Scrum incluem a reunião de planejamento de Sprint, o Daily Scrum, a revisão de Sprint e a retrospectiva de Sprint. O trabalho se desenvolve em sprints.
Reunião de Planejamento de Sprint
A Sprint Planning, como é conhecida, é realizada no primeiro dia de cada Sprint. O Scrum Master, Product Owner e Time devem estar presentes. O PO apresenta o conjunto de recursos que gostaria de ver concluído no Sprint (o “que”), em seguida, a equipe determina as tarefas necessárias para implementar esses recursos (o “como”). As estimativas de trabalho são revistas para ver se a equipe tem tempo para concluir todos os recursos solicitados no Sprint. A partir daí a equipe se compromete com o Sprint. Caso contrário, as tarefas de prioridade mais baixa voltam para a lista de pendências do produto ou projeto, até que a carga de trabalho seja adequada ao time no Sprint.
Acompanhando o progresso
Uma vez que a Sprint Planning está completa e a equipe fez um compromisso, a equipe começa a rastrear seu progresso usando quadros de informações altamente visíveis. Estes quadros incluem o burndown chart e o painel de tarefas.
O painel de tarefas é usado pela equipe para rastrear o andamento das tarefas para cada recurso. As colunas mínimas usadas são “fazer”, “fazendo” e “feito”. As equipes terão sua reunião diária frente ao painel de tarefas e moverá itens em toda a placa ao afirmar o que fizeram ontem, o que planejam fazer hoje e quais obstáculos eles estão enfrentando. A figura 2 apresenta um exemplo de quadro de tarefas para um projeto de desenvolvimento de software.
Figura 2. Exemplo de Quadro de tarefas no Scrum (cortesia da Mountain Goat Software)
O Burndown Chart mostra a linha de tendência da quantidade de trabalho deixado para fazer no Sprint. O eixo x é o número de dias na Sprint e o eixo y é o número de horas para todas as tarefas que foram definidas na reunião de planejamento de Sprint. Durante os dias do Sprint, a linha que indica a quantidade de trabalho deixada a fazer deve tender para baixo a zero, no último dia do Sprint. A figura 3 exemplifica um Burndown Chart de Sprint.
Figura 3. Exemplo de Burndown Chart por Sprint
O progresso do Sprint é rastreado usando o Burndown Chart, o painel de tarefas e o Daily Scrum. Em combinação, essas três coisas podem fornecer uma imagem clara do que está sendo trabalhado, o que está concluído, o que ainda está para ser feito, ou não será concluído no tempo, e que pode estar impedindo a equipe de atender o Sprint e/ou objetivo.
Revisão de Sprint
No final do Sprint, a equipe convida o PO para uma reunião de revisão de Sprint onde as tarefas que foram concluídas no Sprint são entregues e o feedback é solicitado. O PO mantém o controle dos comentários e o incorpora conforme necessário na lista de pendências do produto.
Uma vez que a revisão esteja completa, apenas a equipe (sem o PO) conduz uma retrospectiva para determinar o que eles fizeram bem que eles desejam continuar fazendo, o que eles tiveram desafios e quais as recomendações fazem para o que virá. Um plano de ação é criado e esses itens são implementados ao longo do próximo Sprint, e revisados para eficácia na próxima retrospectiva de Sprint.
Planejamento de Liberação (Release)
O planejamento de release também faz parte do Scrum e é uma maneira de fazer planejamento de mais longo prazo para diversos sprints. Isso geralmente é feito trimestralmente, e os resultados do trimestre não tem que ser uma liberação para o cliente, mas pode simplesmente ser uma versão interna que confirme a integração das atividades. A figura 4 mostra como o planejamento de releases se encaixa com o restante da estrutura do Scrum.
Toda a equipe participa da reunião de planejamento de release, onde o PO apresenta as características que ela gostaria de ver concluídas no trimestre. A equipe fornece estimativas (mesmo que grosseiras) das tarefas que podem ser feitas em quais Sprints. O planejamento de release pode ser orientado a recursos (quantos sprints serão necessários para concluir esse conjunto de tarefas?), orientado por tempo (quantas tarefas podemos esperar ter completado neste prazo?) ou orientado por custos (dado este orçamento, o que é a nossa agenda e o que teremos feito antes de ficar sem dinheiro?).
Figura 4. Planejamento do Release no Scrum
Alguns exemplos de Scrum
Scrum é comum em projetos de desenvolvimento de software e inúmeros exemplos podem ser encontrados através de pesquisa simples do Google.
Escrevendo um livro empregando Scrum
Minha colega Stacia Viscardi e eu usamos o Scrum para gerenciar nosso projeto de livro. Nossa lista de pendências de produtos consistiu nos capítulos que queríamos escrever para o gerente de projeto de software ágeis, em ordem de prioridade com base em consultas de clientes. Por exemplo, porque parecíamos ter muitas perguntas sobre a gestão de escopo e muito poucas sobre suprimento, o capítulo sobre escopo estava no topo da lista de pendências, enquanto o capítulo de suprimento estava próximo ao final.
Realizou-se uma reunião de planejamento de versão e moveu os itens de lista de pendências para páginas de flip chart que representavam nossos sprints, que eram um mês de comprimento. No início de cada Sprint, nós seguramos uma chamada para falar sobre os capítulos que estaríamos escrevendo, definir metas e expectativas, e nos comprometermos. Durante o Sprint, nós fazíamos um check-in, conjunto, várias vezes por semana. À medida que completamos os capítulos na Sprint, era feita uma troca para obter feedback e, em seguida, incorporar esse feedback na cópia final. Nossas revisões de Sprint consistiram em uma revisão final dos capítulos, e todas as mudanças adicionais terminaram acima na lista de pendências do produto a serem planejadas no Sprint seguinte.
Como éramos apenas nós duas, nós tivemos e intercambiamos diversos papéis e responsabilidades. Para uma seção do livro, eu fui o PO, e eu tinha autoridade sobre o recurso final. Para outras seções, Stacia teve esse papel. Nosso Scrum Master era nosso editor, mesmo que ele não percebesse isso. Ele pouco executou as responsabilidades de um Scrum Master, no entanto, ele nos lembrou de nossos prazos, removeu os obstáculos para nós, e deu-nos a assistência e ferramentas que precisávamos para fazer o nosso trabalho.
E não fomos só nós usando o Scrum para escrever livros. Lonely Planet usa Scrum em seu desenvolvimento de guias de viagem, “antes do Scrum, o desenvolvimento de um livro foi muito sequencial e exigiu muitos handoffs e demorou um longo tempo para obter um livro fora da concepção à publicação. Agora eles envolvem todos os jogadores necessários para colocar um livro juntos (escritores, artistas gráficos, editoração eletrônica, marketing, editores, etc) e desenvolver incrementalmente capítulo por capítulo do livro, seguindo o framework Scrum (“Scrum para projetos não-software”, 2010).
Usando Scrum em uma empresa de Venture Capital
Jeff Sutherland é assessor sênior da OpenView Venture Partners, uma empresa de capital de risco sediada em Boston, MA. Em 2010, ele escreveu um artigo para a conferência internacional do Havaí sobre ciência de sistemas intitulada transformação organizacional com Scrum: como um grupo de capital de risco obtém duas vezes mais feito com metade do trabalho que descreve como o OpenView usa o Scrum na gestão de seu Portfólio.
As equipes da OpenView usam Scrum em projetos “em gestão, vendas, marketing, finanças e suporte ao cliente para empresas de portfólio”, além de empurrar o Scrum para suas empresas de portfólio (Sutherland, 2010, p. 1). Em um exemplo de uso do Scrum, a equipe do Labs usa sprints de uma semana para executar projetos de valor operacional para suas empresas de portfólio, realizar due diligence e institucionalizar seus recursos de valor adicionado.
Quando a equipe do Labs implementou inicialmente o Scrum, o aumento da visibilidade em projetos em andamento os fez perceber que vários dos projetos eram realmente de baixo valor. Como resultado, eles cortaram 30 por cento de seus projetos, o que gerou espaço para projetos mais de alto valor e permitiu que eles se concentrassem e terminassem esses projetos. Na verdade, essa clareza de foco e o limite da quantidade de trabalho em andamento em um Sprint ajudaram a equipe a se tornar mais produtiva, já que os projetos deixaram de ser arrastados durante longos períodos de tempo, pelo trabalho simultâneo. A equipe já dobrou sua produtividade e está “em seu caminho para a segunda duplicação da produtividade” como eles continuam a se adaptar (Sutherland, 2010, p. 8).
Scrum na igreja
Rev. Arline Sutherland trabalha como um pastor provisório para a Igreja Unitarian Universalist. Ela também é a esposa de Jeff Sutherland, um dos cocriadores de Scrum. Em 2009, num paper para a conferência Agile2009 intitulada “Scrum na igreja: salvando o mundo um time de cada vez”, Rev. Sutherland descreveu suas experiências usando Scrum em igrejas em Massachusetts, Connecticut, Flórida, Delaware, e Virgínia.
Scrum é usado principalmente por funcionários do escritório e voluntários para “manter o motor funcionando” e em “novas iniciativas” (Sutherland, 2009, p. 3). Diversos projetos nas áreas de pastoral, crianças e jovens, desenvolvimento de membros, justiça social, música, instalações, finanças e captação de recursos foram gerenciados utilizando Scrum.
Várias adaptações foram feitas em cada instância para acomodar as necessidades dos membros da equipe e as restrições de seu ambiente. Por exemplo, era impossível manter os stand-ups diários em pessoa com mais de metade da equipe segurando os trabalhos do dia. Assim, o Skype foi usado desde os mais idosos (já avós) até antigos membros, menos tecnologicamente sofisticados” (Sutherland, 2009, p. 4).
Vale a pena notar que Sutherland descobriu “que cada vez que o Scrum é introduzido em um sistema ele tem que ser adaptado” (Sutherland, 2009, p. 4). Originalmente desencorajado que suas implementações do Scrum nunca pareciam corresponder ao ideal de “Scrum real”, ela rapidamente percebeu que os benefícios da mudança adaptativa genuína incluíam a adaptação do próprio Scrum.
O que aconteceu com…?
Como esta é apenas uma visão geral do Scrum, espera-se que o leitor possa possa ficar com várias perguntas sem resposta. Nesta seção, vamos olhar para as três principais perguntas mais frequentemente feitas por aqueles novos para Agile e Scrum, em seguida, deixarei algumas palavras finais sobre onde encontrar mais informações.
O que aconteceu com o cronograma e outros documentos?
Os gráficos de Gantt não são normalmente usados em projetos Scrum. Burndown Chart (Burndown de Sprint e Burndown de lançamento), quadros de tarefas, backlogs, planos de Sprint, planos de release e outros gráficos de métricas são usados em vez disso, para comunicar o andamento, o status e as previsões. Existe uma variedade de ferramentas ágeis de gestão de projetos para fornecer esse tipo de relatório, incluindo plug-ins para o Microsoft Project.
Os únicos artefatos que o Scrum requer são a lista de pendências do produto, Sprint Backlog, burndown de lançamento e Burndown de Sprint. Todas as outras formas de documentação são deixadas à equipe para decidir. Uma regra aproximada diz que se o artefato agrega valor e o cliente está disposto a pagar por ele, então o artefato deve ser criado. Artefatos criados porque “é na lista de verificação” ou “nós sempre fizemos isso” são itens que devem ser considerados para eliminação com o uso do scrum. Os documentos necessários para questões de governança (auditorias, contabilidade, etc.) ainda devem ser criados, mas muitas vezes podem ser simplificados.
O que aconteceu ao Gerente do Projeto?
O gerente de projeto geralmente se torna o Scrum Master. Este não é sempre o caso e há muitas permutações diferentes da transformação. Por exemplo, um gerente de projeto que tenha atuado como um especialista em domínio ou assunto pode estar melhor posicionado como o PO. Ou um gerente de projeto que dirige uma equipe de mais de 50 pessoas pode permanecer nesse papel e se concentrar em tarefas gerais do projeto, como compras e negociação de contratos, enquanto as equipes de Scrum no projeto (lembre-se, uma equipe de Scrum tem 7 +/-2 pessoas, então um projeto de 50 pessoas será feito com 6-10 equipes de Scrum) cada um tem seu próprio ScrumMaster. Neste cenário, o gerente de projeto auxilia os Scrum Masters na coordenação, estratégia e remoção de bloqueios.
O que aconteceu ao uso de tarefas detalhadas e estimativas de tarefas para gerar projeções?
A estimativa e o planejamento tradicionais usam um método bottom-up, onde todos os requisitos devem ser totalmente definidos, com tarefas então criadas e estimadas com base nesse escopo fixo. A estimativa e o planejamento ágeis usam um método de cima para baixo para prever. Estimativa grosseira no nível da tarefa é feito, muitas vezes, usando uma técnica chamada de Poker Planning, com estimativas dadas em pontos usando a sequência de Fibonacci. As equipes determinam sua velocidade em pontos, ou seja, quantos pontos em média a equipe pode concluir em um Sprint. O custo por ponto é determinado calculando os salários carregados da equipe para o período x, dividindo-o pelo número de pontos concluídos no período x. Depois de ter a velocidade média da sua equipe e uma lista de pendências de produto estimada, você pode prever marcos de projeto e datas de conclusão, bem como o custo por ponto e, portanto, prever o custo do projeto.
Um parágrafo não pode fazer justiça a este tópico. Existem livros inteiros escritos sobre este tópico. Um excelente livro com conselhos práticos sobre como fazer a estimativa usando o Poker Planning e previsão usando velocidade e pontos é ágil estimativa e planejamento por Mike Cohn.
Palavras Finais
O Scrum é uma estrutura ágil de gestão de projetos que ajuda as equipes a entregar produtos valiosos, iterativa e incrementalmente, enquanto inspecionam e adaptam continuamente o processo. Os membros do PMI Project Management Institute encontrarão que podem implementar o Scrum e ainda estar de acordo com o guia a para o corpo de conhecimento de gerenciamento de projeto (PMBOK® Guide) — quarta edição, como ambos defendem uma abordagem de Plano-De-Check-Act para gestão de projetos.
Esta foi uma breve visão geral do Scrum e, como tal, não abordou muitas áreas adicionais de interesse, como roteiros de produtos, estimativa usando pontos, histórias de usuários, mapas de história e assim por diante. Essas práticas ágeis são frequentemente usadas em conjunto com o Scrum, assim como outras metodologias, como Kanban e XP. Recursos adicionais sobre estes tópicos estão disponíveis on-line, muitos de graça. Uma lista de leitura abrangente pode ser encontrada em http://www.scrumsense.com/resources/books para aqueles interessados em mais em profundidade de aprendizagem.
Referências
Cohn, M. (2006). Agile estimating and planning. Upper Saddle River, NJ: Pearson Education, Inc.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® Guide) (4th ed.). Newtown Square, PA: Project Management Institute.
Schwaber, K. (2004). Agile project management with Scrum. Redmond, WA: Microsoft Press.
Schwaber, K., & Beedle, M. (2001). Agile software development using Scrum. Upper Saddle River, NJ: Prentice Hall.
Scrum for Non-Software Projects. (2010). Retrieved from http://groups.google.com/group/scrumalliance/browse_thread/thread/cd0691005d55ed3b
Sutherland, A., Sutherland, J., & Hegarty, C. (2009, August). Scrum in church: Saving the world one team at a time. Paper presented at Agile2009 Conference, Chicago, IL, USA.
Sutherland, J., & Altman, I. (2010, January). Organizational transformation with Scrum: How a venture capital group gets twice as much done with half the work. Paper presented at the Hawaii International Conference on Systems Science, Koloa, Kauai, Hawaii, USA.
Takeuchi, H., & Nonaka, I. (1986, January-February). The new new product development game. Harvard Business Review, [Reprint 86116].