As histórias que entram para o KanBan são as do Sprint Backlog, definidas na primeira reunião, com a presença do Product Owner e detalhadas na segunda reunião, com o Scrummaster e a equipe do projeto, como já mencionamos anteriormente. Imagine que as histórias escolhidas para o primeiro Sprint são as representadas na Tabela 6.3.
Tabela 6.3 – Primeiro Sprint Backlog do aplicativo GiftWizz
| ID | História | Pontos |
| 5 | Como usuário, no momento de meu cadastro no sistema, quero optar por permitir (ou não) o acesso a meus dados em redes sociais (dados pessoais, lista de amigos, likes, posts), para gerar estatísticas que permitam que eu receba boas sugestões de presentes para meus amigos. | |
| 1 | Como usuário, sempre que eu desejar presentear alguém, usando qualquer dispositivo, quero receber a melhor sugestão para agradar o presenteado. |
Está claro que, tecnicamente, é necessário um desdobramento destas histórias em outras menores, ou tarefas técnicas. A história que possui o identificador 5, que foi movida para o topo do Product Backlog e agora começa a ser desenvolvida no primeiro Sprint, pode conter os seguintes itens:
5.1 Implementação de login através da API (interface programável) da rede social.
5.2 Implementar a requisição de autorização de acesso aos dados do usuário (lista de amigos, likes, posts).
5.3 Implementar busca de informações públicas dos amigos do usuário.
5.4 Armazenar localmente os dados para o treinamento da rede neural de sugestões de presentes.
5.5 Cadastrar uma base de 100 possíveis presentes para treinar a rede neural.
O mesmo acontece com a história identificada pelo número 1:
1.1 Permitir ao usuário a seleção de amigos, em sua rede, que deseja presentear.
1.2 Usar a rede neural para sugerir o presente.
Essas tarefas podem ser anotadas no verso das notas adesivas das histórias originais ou escritas em novas notas, substituindo as originais no KanBan.
A figura 6.4 é mais um recorte de nossa conhecida Figura 4.2 e ilustra exatamente o que deve acontecer dentro de um Sprint típico.
Durante o Sprint, a equipe deve estar totalmente protegida de qualquer interferência externa. O Scrummaster deve garantir que todos os seus componentes tenham recursos necessários ao desenvolvimento de seus trabalhos, mas jamais permitir que histórias adicionais (existentes no Product Backlog ou novas) sejam incluídas no Sprint em andamento. A equipe pode, ela mesma, fazer o refinamento das tarefas com as quais está trabalhando, mas com a atenção do Scrummaster, que deve evitar que “lampejos de criatividade” tragam para o Sprint coisas que estão fora de seu escopo, comprometendo as entregas prometidas ou seu tempo de execução, dois pecados mortais no Scrum. De maneira geral, o refinamento do Product Backlog deve ser sempre no sentido de aumentar a qualidade da “pequena vitória” a ser entregue ao final do Sprint, acelerar algum desenvolvimento ou promover uma colaboração ainda maior da equipe, aproximando-a do ideal do Ba (leia sobre isso no Capítulo 4, na Seção “Como montar uma equipe Scrum”).
Figura 6.4 – O Sprint em andamento
É normal que, em seus primeiros Scrums, a equipe sinta-se um pouco “estranha” com a falta de hierarquia entre seus membros e sua ampla liberdade na escolha das histórias a serem desenvolvidas e dos meios que utilizarão para concluí-las. O Scrummaster, como um removedor de obstáculos e responsável pela atenção aos ritos e artefatos do Scrum, deve entender essa “estranheza” como um dos obstáculos a serem removidos.
Peter Salus, linguista, historiador e autor, dentre outros, dos livros A Quarter Century of Unix e Casting The Net, não acredita na hierarquia como algo necessário para a organização do trabalho em uma equipe. Quando foi contratado no início dos anos 1990 para trabalhar na Matrix, uma empresa que media mundialmente o fluxo de tráfego na Internet, pediram que Peter definisse qual seria o cargo que deveria ser colocado em seu cartão de visita. Peter escolheu “Chief Knows-it-All”, CKIA, o Chefão Sabe-Tudo, ao mesmo tempo uma brincadeira com os cargos de CEO (Chief Executive Officer), CIO (Chief Information Officer) e o, então, recente CKO (Chief Knowledge Officer), em uma demonstração explícita de que Peter entrara na empresa para ajudar a todos os demais com o seu destacado conhecimento.
Pequenos acessórios motivadores ajudam a quebrar o gelo nos primeiros Scrums e, no decorrer do tempo, auxiliam novos membros a entrar no ritmo de uma equipe já mais entrosada com o processo. Uma boa ideia é a de Peter: permitir que cada pessoa escolha o próprio título que vai em seu cartão de visita ou criar um cargo único para todos os participantes de um projeto e mesmo de uma empresa.
Um Scrummaster experiente logo detecta, também, dentro de uma equipe, quais são os que já participam bem do processo e quais precisam de um empurrãozinho. A reunião diária do Scrum é um bom momento para isso. Você já sabe o que acontece nela: é o momento em que são feitas as três perguntas:
- O que você fez ontem?
- O que você fará hoje?
- Quais os obstáculos que impedem (ou podem impedir) seu trabalho?
Durante a reunião, as tarefas anotadas nas notas adesivas, no quadro KanBan, são atualizadas e movidas apropriadamente entre as suas colunas. Como todos acompanham diariamente o trabalho conjunto, podem surgir questões que os próprios membros da equipe possam resolver entre si, e é comum surgir a colaboração de um membro na tarefa de outro e um aumento crescente na sinergia que levará à entrega de um excelente incremento de produto, uma pequena vitória notável que encantará o cliente.
O Burndown Chart, que você também já viu ao final do Capítulo 4, “Visão geral do Scrum”, serve como um alerta constante do consumo do tempo disponível até o final do Sprint. Em Referências, ao final do livro, você encontra modelos online prontos para a utilização.
A Figura 6.5, outro recorte da Figura 4.2, mostra o que acontece ao final de cada um dos Sprints que compõem um projeto Scrum.
Um projeto Scrum gera, no Product Owner e nos demais patrocinadores do projeto, uma expectativa por “algo funcional” ao final de cada Sprint e é isso que, de fato, deve ser obrigatoriamente entregue. O resultado final é construído a partir dessas pequenas vitórias incrementais, demonstráveis, nas quais o valor do projeto é percebido.
Figura 6.5 – Ritos finais de cada Sprint
Assim como no início do Sprint, em que há uma reunião com a presença do Product Owner e outra apenas com a equipe e o Scrummaster, no final do Sprint acontece algo similar. Em uma primeira reunião, a Sprint Review, a equipe apresenta o incremento desenvolvido durante o Sprint para o Product Owner e, eventualmente, para representantes dos demais patrocinadores do projeto, que comentarão, criticarão e, certamente, agora com algo nas mãos, um pedaço a mais daquilo que desejam, terão mais elementos para descrever ainda melhor o que querem, refinando o Product Backlog. Isso é perfeitamente normal, o desejo é qualificado a partir do momento em que se passa a ter algo real com o que experimentar. Você pode perguntar-se, nesse ponto, como fica a estimativa original e a determinação do que garante o escopo do projeto. Já dissemos anteriormente que planos e sistemas devem ter agilidade para acompanhar as mudanças, não para servirem de obstáculos a elas.
A reunião seguinte, Sprint Retrospective, só com a equipe e o Scrummaster, é uma discussão sobre o que deu certo, o que deu errado, como o Product Owner e a equipe de patrocinadores poderiam ficar mais encantados, quais os processos que ainda podem ser otimizados nos próximos Sprints, enfim, quais as boas lições aprendidas em todo o Sprint. Se desejar, a equipe pode decidir por convidar o Product Owner para a retrospectiva, algo que me agrada bastante. Agora começa tudo novamente, até que todos os Sprints, que levam incrementalmente à entrega final do projeto, tenham sido concluídos.
