Scrum : Uma maneira de fazer

Transcrição

1 Scrum : Uma maneira de fazer Rodrigo Wirth Universidade do Planalto Catarinense (UNIPLAC) Caixa Postal Lages SC Brasil [email protected] Abstract. This paper presentes a method mainly used to structure agile software developmentteams, this method is Scrum. Recommendation are presented that Scrum offersthese recommendations are in the formo of participants roles, atifacts and process definitions. How Scrum can be adapted to various projects kinds, is shown as example of Scrum acycle in software desing, showing a way of doing Scrum. Resumo. Esse artigo apresenta um método ágil utilizado principalmente para estruturar equipes de desenvolvimento de software, esse método é chamado Scrum. São apresentadas as recomendações que o Scrum oferece, essas recomendações estão em forma de papéis para os participantes, artefatos e definições de processos. Como o Scrum pode ser adaptado a diversos tipos de projetos, é apresentado um exemplo de ciclo do Scrum em um projeto de software, mostrando uma maneira de fazer o Scrum. 1. Introdução O Scrum é método considerado ágil, ele fornece uma série de recomendações em forma de papéis dos participantes, artefatos e definições de processos. Apesar de o Scrum ter recomendações bem definidas, é possível que ele seja adaptado a realidade das empresas das equipes. Existem várias maneiras de aplicar o Scrum, apenas devemos seguir as suas recomendações, e adaptá-las a nossa realidade. Este artigo apresenta uma maneira de se fazer isso, através de uma breve introdução sobre o Scrum apresentado no capitulo 2, de suas definições no capitulo 3 e da vida de ciclo do Scrum no capitulo O que é Scrum? O Scrum é um método ágil utilizado principalmente para estruturar as equipes e o processo do desenvolvimento de um software. A pesar de ser mais comumente usado em desenvolvimento de software, o Scrum pode ser adotado para estruturar qualquer projeto que tenha uma ou mais equipes, e que os membros dessas precisem trabalhar juntos na busca de um objetivo. Os métodos ágeis, ou seja, não apenas o Scrum tem como objetivo organizar o desenvolvimento de um projeto, para que com agilidade o objetivo seja alcançado de forma rápida, simples e eficaz. Segundo Abrahamssom et al. (2002) para alcançar seus objetivos, os métodos ágeis são projetos, para produzir a primeira entrega em semanas e alcançar feedback rápido, criar soluções mais simples para se ter mais facilidade em alterações que precisem ser feitas, melhorar a qualidade projeto constantemente para que as próximas iterações possam ter menos custo, e testar constantemente para encontrar os defeitos o quanto antes, diminuindo o custo com as correções necessárias.

2 3. Definições O método Scrum cita algumas definições a respeito dos papéis dos participantes do projeto, dos artefatos utilizados para organização das tarefas e dos processos que auxiliam os participantes produzirem os artefatos. Mesmo tendo seus conceitos bem definidos, o Scrum pode ser adaptado para a realidade de cada empresa, como por exemplo, a criação de novos papéis que sejam necessários em um determinado momento do projeto. 3.1 Equipe O Scrum recomenda que se trabalhe com equipes entre 6 e 9 integrantes, o que não significa que é impossível de se trabalhar com menos ou mais pessoas. Porém empresas que adotaram o Scrum em equipes maiores, relatam que houve uma grande dificuldade em integrações e relacionamento. Conceitualmente, a divisão dos recursos humanos em equipes que adotam o Scrum é feita em três papés (Figura 1): Product Owner, Scrum Master e o Scrum Team (Marçal et al., 2007). Figura 1. Participantes do Scrum Marçal et al. (2007) define os papéis da seguinte maneira: Product Owner: é o dono do produto, geralmente o cliente ou alguém que represente um cliente. Tem a responsabilidade de dizer o que é o produto e suas características, tais como funcionalidades. A definição de prioridades também é sua responsabilidade. Scrum Master: é o responsável por aplicar as práticas do Scrum e as demais definidas para o projeto, ele deve ajudar a equipe à ser funcional e produtiva. Acompanhar as tarefas em andamento, e ajudar a equipe resolvendo os empecilhos que ocorram no decorrer do desenvolvimento. Scrum Team: é a equipe responsável por desenvolver o projeto. A equipe de ser disciplinada e auto-gerenciada, e todos terem um objetivo comum. 3.2 Artefatos Os dois principais artefatos do Scrum chamam se: Product Backlog e Sprint Backlog. O Product Backlog contém o que deve ser desenvolvido no sistema, e o Sprint Backlog o que deve ser desenvolvido na iteração atual e como está o andamento dessa iteração.

3 O Product Backlog é onde ficam as histórias de usuário, ou seja, o que tem que ser implementado no sistema. Essas histórias podem ser armazenadas em meio eletrônico, ou até mesmo em fichas como mostra a figura 2, essas fichas podem ser usadas nas reuniões de planejamento das iterações. É responsabilidade do Product Owner organizar as histórias de forma prioritária, para que sejam desenvolvidas no decorrer das iterações. O Product Backlog é o coração do Scrum. É aqui que tudo começa. O Product Backlog é basicamente uma lista de requisitos, estórias, Coisas que o cliente deseja, descritas utilizando a terminologia do cliente (Kniberg, 2007). Figura 2. Ficha de uma história Seguindo o modelo apresentado pela figura 2, cada história de conter um nome, uma descrição do que se fazer, uma descrição de como demostrar que a história está funcional, a importância e a estimativa. a) Nome: tem o propósito de dar uma ideia do que se trata a história, não deve ser muito longo. b) Notas: sobre o que a história trata, o que é preciso fazer para desenvolver a história. A partir disso serão descobertas as tarefas necessárias. c) Como demostrar: deve informar como pode ser demonstrado que a funcionalidade/história está funcionando. d) Importância: utilizado pelo Product Owner para definir as prioridades das histórias. Os valores definidos não podem ser considerados medidas, são apenas para definir a prioridade das histórias, assim, não é correto dizer que uma história com importância 30 tem o dobro de prioridade que uma história com importância 15. e) Estimativa: este item só deve ser preenchido na reunião de planejamento da iteração, é um campo que será preenchido em um consenso do Scrum Master e da equipe. Geralmente representa a estimativa de tempo em pontos por história. Para se entender o Sprint Backlog, é preciso primeiro entender o que significa um Sprint no Scrum. Um Sprint representa cada iteração realizada no processo do Scrum. O Sprint Backlog contém uma série de artefatos e características, que permite um gerenciamento do Sprint. Assim como o Product Backlog, o Sprint Backlog pode ser feito de forma eletrônica, mas na maioria dos casos é utilizado um quadro, como mostra a figura 3. No quadro temos todas as histórias que serão desenvolvidas no Sprint (Iteração), as tarefas que serão feitas para cada história (papéis amarelos), um gráfico de burdown, e

4 histórias que serão desenvolvidas nos próximos sprints. No capitulo 4 é apresentado o ciclo de um Sprint e a utilização dos artefatos do Sprint Backlog. 4. A vida de um Sprint Figura 3. Quadro de Sprint Backlog Para se iniciar um Sprint é preciso se ter um Product Backlog, com as suas histórias organizadas de forma prioritária, sem isso não se deve iniciar um Sprint. O primeiro passo em um Sprint é o se planejamento, isso é feito através de uma reunião chamada de Reunião de Planejamento. Depois da reunião deve ser iniciado o Sprint Backlog, e esse deve ser atualizado durante o decorrer do Sprint. Durante o Sprint devem ser feitas reuniões entre a equipe todos os dias, essas chamadas de Reuniões Diárias. No final do Sprint deve ser feita uma apresentação dos resultados. E por fim, antes do inicio de um novo Sprint é feito a retrospectiva do Sprint. 4.1 O Product Backlog está pronto para o Sprint? Podemos definir que um Product Backlog está pronto com algumas perguntas: a) O Product Backlog existe? Ou seja, temos história para trabalhar? b) Existe apenas um Product Backlog e um Product Owner para o produto? c) Todas as histórias estão priorizadas em uma escala de importância? Caso algumas dessas perguntas sejam respondidas de forma negativa, é preciso que o Product Owner revise o Product Backlog até que todas as perguntas sejam respondidas de forma positiva. Iniciar um Sprint, ou seja, fazer a reunião de planejamento com um Product Backlog mal definido pode ser o primeiro passo para que o Sprint venha a falar. 4.2 Reunião de Planejamento Nessa reunião é onde se define o que vai ser feito no Sprint, deve se definir um objetivo para o Sprint, a lista de membros que vão participar da equipe responsável pelo Sprint, o Sprint Backlog, a data para a apresentação e o horário e local da reunião diária. Além da equipe, o Product Owner também deve participar da reunião. Alguns Product Owners tentam evitar a perda de algumas horas na reunião, argumentando que as suas definições estão em um documento que pode ser usado na reunião. O motivo pelo qual ele

5 deve participar na reunião é que as definições das histórias podem sofrer alterações, e essas alterações devem ser discutidas cara a cara entre a equipe e o Product Owner. Uma tática que pode ser usada, caso o Product Owner resista a não participar da reunião é indicar um membro da equipe para representa-lo durante a reunião, e avisa-lo que esse substituto terá todos os poderes de Product Owner na reunião, inclusive mudar as prioridades e definições das histórias. Essa tática fará com que o Product Owner repense na possibilidade de participar da reunião. A reunião se inicia com o Product Owner apresentado o objetivo à ser alcançado pelo Sprint. Esse objetivo deve ficar claro para toda a equipe, para que possa trabalhar para alcança-lo. Caso o Product Owner não tenha um objetivo, é preciso que o Scrum Master auxilio a encontra-lo, uma maneira é fazendo a pergunta, Por que estamos desenvolvendo esse Sprint?. Além da equipe o objetivo deve ser claro, para que pessoas externas entendam o que esperar do Sprint, inclusive o cliente, caso esse não seja o Product Owner. Após a definição do objetivo, o Product Owner apresenta o Product Backlog, ou seja, as histórias que ainda não foram desenvolvidas. Nesse momento começa a se iniciar a definição de quais histórias incluir no Sprint, as tarefas de cada história. A figura 4 mostra de forma simples quais histórias incluir, as histórias estão ordenadas de forma prioritária no Product Backlog, e deverão ser passadas para o Sprint Backlog quantas forem possíveis desenvolver no período de tempo do Sprint. O tamanho dos retângulos representa a complexidade da história, ou seja, da uma ideia de proporção de tempo entre uma história e outra. Figura 4. Histórias do Product Backlog para o Sprint Backlog As histórias que serão desenvolvidas no Sprint são definidas pela equipe, que é coordenada pelo Scrum Master para fazer o calculo de estima de tempo (4.2.1), o Product Owner não pode influenciar isso, a não ser na prioridade das histórias. Tendo o tamanho do Sprint, é preciso definir a data da apresentação. A data da apresentação deve ser enviada para todos, inclusive para as outras equipes, para que se possível todos assistam a apresentação. O local e horário da reunião diária também devem ser definidos durante a reunião, e deve ficar bem claro para toda a equipe a importância da participação de cada membro da equipe na reunião (4.4).

6 4.2.1 Calculo de estimativa de tempo O calculo de estimativa de tempo tem dois passos: definir a velocidade estimada das histórias; calcular quantas histórias podem ser desenvolvidas no Sprint. A velocidade é a medida de trabalho realizado, a velocidade estimada é a velocidade proposta na reunião de planejamento, e a velocidade real a velocidade no final do Sprint, calcula com as histórias que foram concluídas 100%, a figura 5 ilustra a diferença entre os dois tipos de velocidade. A velocidade é medida em pontos por história. Figura 5. Velocidade estimada e real A diferença entre a velocidade estimada e a velocidade real pode ser usada para refinar a velocidade estimada para o próximo Sprint. Uma história que ficou pela metade, ou quase completa não é considerada na velocidade real, o Scrum propõe que apenas histórias prontas tem valor. Para calcular a velocidade estimada podemos usar dados dos Sprints passados, e refiná-los de acordo com a necessidade. Se estivermos no primeiro Sprint, precisamos calcular a velocidade. A primeira coisa que precisamos fazer é calcular a quantidade de homens-dia que temos disponíveis para o Sprint. Vamos considerar que o Sprint tenha 3 semanas, ou seja, 15 dias e que a equipe tenha 4 membros, sendo eles, Rodrigo, Raul, Luís e Lourenço. Rodrigo e Raul irão trabalhar os 15 dias, Luís estará em viagem na primeira semana do Sprint e Loureço já avisou que tem um compromisso de 2 dias durante o Sprint. Assim (tabela 1) podemos dizer que Rodrigo e Raul trabalharam 15 dias, Luís 10 dias e Lourenço 13 dias, e por fim que temos um total disponível de 53 homens-dia para o Sprint. Membro da Equipe Dias disponíveis Rodrigo 15 Raul 15 Luís 10 Lourenço 13 Total 53 (homes-dia) Tabela 1. Calculo de homens-dia Com o valor de homens-dia disponíveis temos que calcular a quantidade de pontos por historia disponíveis para o Sprint. Um ponto por historia é um valor que representa uma aproximação ao valor de homens-dia ideal para o Sprint. Para calcular isso pode ser usado um conceito chamado fator de foco. Kniberg (2007) diz que o fator de foco é uma estimativa de como a equipe é focada. Um fator de foco baixo, pode significar que a equipe espera ter muitas interferências ou percebe que suas próprias estimativas de tempo são otimistas. A maneira mais confiável de se determinar o fator de foco é fazendo uma análise nos históricos dos últimos Sprints. Se não existirem históricos, ou seja, se for o primeiro Sprint

7 Kniberg (2007) sugere um fator de foto de 70%. Esse número pode estar totalmente fora da realidade da equipe, mas no decorrer dos próximos Sprints o fator foco será refinado, esse refinamento deve ser feito em todos os planejamentos de Sprint. Com o valor de homens-dia e fator de foco definidos, podemos calcular a velocidade estimada do Sprint. Esse calculo é feito através da formula da figura 6. No nosso exemplo tempos 53 homens-dia e um fator de foco de 70%, logo nossa velocidade estimada é de 37 pontos por história. Figura 6. Calculo de velocidade estimada Tendo a velocidade estimada, agora precisamos incluir no Sprint uma quantidade de histórias que não ultrapasse quantidade de pontos por história disponíveis. Para isso é preciso definir a quantidade de pontos de história para cada história. A quantidade de pontos de história das histórias representa o campo estimativa da figura 2, e deve ser definido pela equipe, sem influência do Product Owner. Todos devem dar a sua opinião de estimativa, um problema que se encontra aqui é que após o primeiro membro da equipe revelar a sua opinião sobre a estimativa, os outros membros tende a se influenciar e opinaram por estimativas próximas a primeira. Para evitar esse problema Mike Cohn propôs o Plannig Poker (4.2.2). Após definir a estimativa das historia, deve se pegar de forma prioritária, as histórias do Product Backlog e incluir no Sprint Backlog, uma vez que a soma das estimativas das historias não ultrapasse a velocidade estimada do Sprint. A figura 7 apresenta as histórias que foram para o Sprint Backlog, seguindo nosso exemplo que tinha uma velocidade estimada de 37 pontos por história, notem que a soma das estimativas das histórias ficou em 36 pontos por história, o importante é não ultrapassar a velocidade estimada do Sprint. Figura 7. Escolhendo histórias para o Sprint Backlog

8 4.2.2 Planning Poker O Planning Poker é uma técnica para se definir a estimativa das histórias. Como isso é responsabilidade da equipe, cada membro recebe um baralho (figura 8) com 13 cartas com valores que representam a estima em pontos por história. Além das cartar com valores existem três cartas extras: 0 significa que a história já foi feita ou é tão pequena que leva apenas alguns minutos para ser feita;? significa que o membro não faz ideia da estimativa; xicara de café significa: estou cansado demais, vamos fazer uma pausa?. Figura 8. Baralho de Planning Poker Para se fazer a estimativa de uma história, cada membro escolhe uma carta com o valor da sua estimativa de tempo e coloca virada para baixo, após todos escolhem as cartas são reveladas simultaneamente, isso evita a influencia entre membros na definição de estimativa. Se houver uma grande diferença entre as estimativas, a equipe conversa e faz novas rodadas, até que as estimas entrem em um nível de consenso aceitável, e a estimativa da história esteja definida. 4.3 Iniciando o Sprint Backlog Após a finalização da reunião de planejamento, o Scrum Master deve criar literalmente o Sprint Backlog. Uma maneira de se fazer isso é através de um quadro de tarefas, apresentado na figura 3. O quadro de tarefas é divido em três colunas: Não Iniciado, Iniciado e Pronto. Além disso, tem também um lugar para o objetivo, um gráfico de Burndowm (4.4.1), itens não planejados e um campo chamado depois. Na coluna Não Iniciado ficam as histórias e tarefas que ninguém está trabalhando, na coluna Iniciado as tarefas que alguém está trabalhando hoje e na coluna Pronto as histórias e tarefas que estão prontas e que ninguém mais vai trabalhar. No objetivo deve estar o objetivo do Sprint definido na reunião de planejamento, para que no decorrer do Sprint a equipe não perda o foco em alcançar esse objetivo. O gráfico Burndown mostra o como está o desempenho do Sprint comparado à velocidade estimada. Em itens não planejados deve ficar as tarefas que aparecerem durante o Sprint, e que não foram identificadas na reunião de planejamento. E no campo Depois as histórias com mais prioridade que não foram incluídas no Sprint. A figura 9 mostra um quadro de tarefas do decorrer de um Sprint. Esses são os campos que o Scrum propõe, porém podem ser adicionados ou removidos campos de acordo com o contexto da empresa, equipe ou projeto. Mas antes de adicionar um novo campo, é importante pensar bem se isso é realmente necessário, ou se apenas aumentará a complexidade do quadro de tarefas, sem trazer nenhum beneficio para o processo.

9 4.4 Reuniões Diárias Figura 9. Quadro de tarefas no decorrer do Sprint A reunião diária deve ser feita rigorosamente do horário e local que foram definidos na reunião de planejamento. O melhor lugar para fazer a reunião é à frente do quadro de tarefas. A equipe toda deve estar presente, todos devem ficar de pé e a reunião não deve passar de 15 minutos. Na reunião cada membro da equipe deve passar para o demais o que fez ontem e o que fará hoje, de acordo com essas informações o Scrum Master deve atualizar o quadro de tarefas, isso pode ser feito durante a reunião, ou imediatamente após o final da reunião. Os itens não planejados também podem surgir durante a reunião. Após o final da reunião o Scrum Master deve calcular, e atualizar o gráfico de Burndown, como essa é uma tarefa apenas do Scrum Master, a equipe não precisa perder tempo e pode voltar aos seus lugares. Algumas equipes podem sofrer com atrasos dos membros para a reunião, se isso acontecer pode se definir uma punição para quem se atrasar. Um método usado é ter um pote de moedas, onde quem se atrasar ou faltar deve depositar um valor estipulado, com o montante pode-se comprar lanche para a equipes por exemplo. Com certeza o valor deve ser simbólico, nada que possa afetar a vida financeira de um membro da equipe Gráfico Burndown O gráfico de burndow apresenta uma linha de queda do esforço estimado por dias trabalhados no Sprint. A figura 10 mostra um gráfico de um Sprint com velocidade estima de 70 pontos por história e 3 semanas de duração (15 dias), não são considerados os finais de semana. Nesse gráfico podemos ver que no inicio do Sprint (1 de agosto) foi estimado que tinha 70 pontos por história para se fazer. Esse é o valor da velocidade estimada do Sprint. Em 16 de agosto foi calculo que ainda havia em esforço de 15 pontos por história para fazer. A linha tracejada comparada a linha de queda de esforço mostra que a equipe está no ritmo estimado do Sprint. A linha de queda deve ser atualizada todo o dia após a reunião diária pelo Scrum Master.

10 Figura 10. Gráfico de Burndown Com uma olhada no gráfico qualquer pessoa, principalmente o Scrum Master pode ver dois tipos de sinais de alerta. Na figura 11 um gráfico onde a produção está atrasada, para resolver isso é preciso alguns itens do Sprint Bakclog. E na figura 12 um aleta que a equipe está muito adianta e será preciso adicionar alguns itens ao Sprint Backlog, esses itens devem vir do campo Depois do quadro de tarefas. Essa inclusão ou remoção de itens deve ser discutida entre o Scrum Master e o Product Owner. Figura 11. Quadro Burndwon Alerta Apresentação do Sprint Figura 12. Quadro Burdown Alerta 02 A apresentação deve ser feita preferencialmente no dia definido na reunião de planejamento. Toda a empresa deve estar avisa e incentivada a assistir a reunião. Na reunião deve ser apresentado como o objetivo do Sprint foi alcançado, pode ser apresentado a definição de Como Demonstrar de cada história, isso mostrará que as histórias foram concluídas.

11 A reunião é importante para que a equipe ganhe créditos pela realização, para que as outras equipes aprendam o que a equipe está fazendo, para fazer uma interação entre as equipes, e para motivar a equipe a terminar as histórias, evitando assim histórias 99% concluídas. 4.6 Retrospectiva A retrospectiva pode ser a segunda coisa mais importante no processo (a primeira é a reunião de planejamento), é nela que são discutidos principalmente todos os problemas que ocorreram durante o Sprint. Sem retrospectivas a equipe continuará cometendo os mesmos erros e gerando os mesmos problemas. A retrospectiva pode ser organizada da seguinte maneira. Reserva-se uma janela de 1 a 3 horas, esse tempo é melhorado com a experiência. Deve ter a participação de todos, Product Owner, Scrum Master e toda a equipe. Se reunir em um lugar confortável e tranquilo, onde não aconteça interrupções. No inicio da reunião o Scrum Master mostra o Sprint Backlog e com ajuda da equipe resume o Sprint. Após isso começa uma rodada, onde cada membro da equipe poderá falar o que achou bom, o que achou que poderia ter sido melhor e o que gostaria de fazer de forma diferente no próximo Sprint. Após isso é escolhido, por votação quais as melhorias que serão adotadas para o próximo Sprint, para que haja uma melhoria constante do decorrer dos Sprints. Outro ponto importante é a comparação da velocidade estimada com a velocidade real do Sprint. Se houve uma grande diferença, é preciso avaliar o motivo. Algumas vezes o problema pode não estar no Sprint, mas sim na estimativa feita na reunião de planejamento. Por fim, para saber se a retrospectiva foi válida ela deve ter respondido a pergunta, O que podemos fazer para melhorar o próximo Sprint?. 5. Considerações Finais O Scrum é um método bastante eficaz, porém como qualquer outro deve ser levado a sério. Ele tem uma grande facilidade em adaptação, porém é preciso seguir uma linha e não ficar alterando constantemente, para que se possa amadurecer o processo. É preciso se ter uma boa adequação da equipe, com explicações, treinamentos e principalmente incentivo e encorajamento aos membros mais novos. Referências Abrahamsson, P.; Warsta, J.; Siponen, M.T.; Ronkainen, J. New directions on agile methods: a comparative analysis, IEEE Computer Society, Kniberg, H. Scrum e XP direto das Trincheiras. C4Media Inc, Marça, A.S.; Pereira, P.; Torreão, P. Entendendo Scrum para Gerenciar Projetos de Forma Ágil