O Scrum é um método de trabalho para equipes pequenas e tempos curtos de desenvolvimento de projeto. Você trabalha com uma grande equipe e projetos que duram anos? Sem problemas, divida as pessoas em equipes menores (entre cinco e nove pessoas) e seu projeto em subprojetos. O Scrum trabalha com o conceito de Sprints, períodos curtos de tempo (uma a quatro semanas) dentro dos quais o projeto progride. Os requisitos dos projetos são trabalhados em uma lista de histórias a serem desenvolvidas (Product Backlog).
As reuniões com as pessoas da equipe devem ser diárias e não devem durar mais do que 90 segundos por pessoa e nem mais que 15 minutos no total. Nelas deve-se discutir o acompanhamento das histórias levadas para dentro do Sprint (Sprint Backlog) e, preferencialmente, cada história deve ser desenvolvida em um dia (se levar mais de um dia, a história deve ser subdividida em outras). Isso se faz para manter as coisas tão simples quanto possível. Quando aumenta a complexidade, aumentam as dúvidas e o ruído na comunicação, o que atrasa o projeto e põe os resultados em risco.
O Scrummaster é o principal responsável por garantir a aplicação da metodologia, é o “padre” da igreja do Scrum. A tarefa primordial do Scrummaster, porém, é a de remover obstáculos, independentemente de sua natureza.
Uma equipe Scrum terá membros com especialidades variadas, de acordo com a necessidade do projeto. Todos trabalham na equipe em tempo integral (com a rara exceção dos membros que executam tarefas acessórias ao time, mas que devem estar comprometidos com o projeto). Os membros da equipe discutem entre si e se autogerenciam.
Não há níveis hierárquicos dentro de uma equipe. Em um projeto, os membros da equipe são constantes e, especialmente dentro de cada Sprint, eles jamais devem ser substituídos.
A principal razão de dividir as entregas de um projeto em Sprints é justamente a questão de manter o controle sobre as surpresas. Dentro do período do Sprint, uma parte do produto será projetada, codificada, testada e entregue ao cliente. Nesse período não serão admitidas mudanças de requisitos, pois isso ampliaria o tempo de desenvolvimento. Ao final do Sprint, porém, podem ser revistas as histórias e uma nova lista de tarefas pode ser criada para a adequação do produto dentro de um novo Sprint. Isso tende a fazer com que os requisitos passem a ser cada vez mais bem definidos e a codificação para o atendimento desses requisitos seja cada vez mais refinada. As partes acabam chegando a acordos de requisitos mínimos e imutáveis, com os quais todos se comprometem pelo período de um Sprint.
A lista de histórias do produto (Product Backlog) é a lista de tudo o que é necessário ao projeto (independente do número de Sprints que o compõem). Ela deve contemplar o que no Extreme Programming chamamos de User Stories (se não lembra disso, volte ao Capítulo 3, Seção 3.1). Se no Extreme Programming dissemos que as User Stories eram Use Cases “diet”, na lista de histórias elas são ainda mais enxutas. Na medida do possível, os itens da lista devem contemplar o que o cliente (ou o usuário) deseja, opcionalmente junto às tarefas necessárias para atender a esses desejos, de forma bastante sintética.
As histórias são priorizadas de acordo com o que o Product Owner (aquele que está “pagando” pelo produto, ou seu único representante) deseja. Isso deve ser feito da forma mais simples possível, permitindo a busca textual por histórias em um documento que possa ser acessado e alterado por todos os membros do projeto. Um quadro branco com notas adesivas ou um wiki ou uma planilha servem para isso (veja na Tabela 4.1 o exemplo de um Product Backlog). O importante é que essa lista seja clara para você e para os membros de sua equipe. A forma como ela é implementada não é o mais importante.
Com o Product Backlog em mãos, agora ele pode ser subdividido em versões (ou releases). Como você já imaginou, o Sprint Backlog é a lista de histórias que serão contempladas dentro de cada Sprint por uma determinada equipe. Nada impede que você subdivida as histórias entre equipes distintas e tenha Sprints diversos ocorrendo simultaneamente, ainda que isso adicione uma sobrecarga para a garantia da comunicação entre as equipes.
Use temas para dar o nome a cada uma das versões a serem entregues ao cliente, ao usuário final. No desenvolvimento do aplicativo GiftWizz, da empresa gaúcha de mesmo nome, feito por uma equipe Scrum da Sysvale Softgroup (sysvale.com), as histórias contemplavam um sistema que iria sugerir o melhor presente para um amigo com base em informações coletadas em redes sociais. Assim, a primeira versão, ainda não pública, tinha como tema “Integração com redes socias”, já que tudo o que seria desenvolvido posteriormente dependia dessa construção.
A lista de histórias relativa aos Sprint Backlogs que atendem a essa versão incluía a obtenção da permissão do usuário para que o sistema acessasse e usasse seus dados para, posteriormente, permitir que ele pudesse receber sugestões de presentes. Decisões técnicas sobre a implementação dessas histórias e sua posterior subdivisão em tarefas são tomadas na reunião de planejamento do Sprint (Sprint Planning), com a presença da equipe Scrum, do Scrummaster e do Product Owner.
A Tabela 4.1 mostra o Product Backlog inicial criado para o GiftWizz. Ao longo do desenvolvimento, claro, esse Backlog foi melhorado através do Product Backlog Refinement (o refinamento do Product Backlog), um assunto sobre o qual falaremos no Capítulo 9.
Tabela 4.1 – Product Backlog inicial do aplicativo web GiftWizz.com
| Usuário |
| Como usuário, sempre que eu desejar presentear alguém, usando qualquer dispositivo, quero receber a melhor sugestão para agradar o presenteado. |
| Como usuário, sempre que eu receber um presente, usando qualquer dispositivo, quero ter a opção de dar uma nota, de forma anônima, ao presente recebido a fim de que as sugestões sejam melhoradas. |
| Como usuário, quero optar, a qualquer momento, por receber informações de lojas reais ou virtuais que tenham o presente que possa agradar o presenteado. |
| Como usuário, quero optar, a qualquer momento, por receber um cupom de desconto que me permita adquirir o presente que possa agradar o presenteado. |
| Giftwizz |
| SPRINT 1Como Giftwizz, no momento de cadastro do usuário, quero ter a permissão do mesmo para o acesso a seus dados em redes sociais (dados pessoais, lista de amigos, likes, posts), para gerar estatísticas que me permitam inferir boas sugestões de presentes para ele e para seus amigos. |
| SPRINT 1Como Giftwizz, no momento de cadastro do usuário, quero ter a permissão do mesmo para, opcionalmente, ter o direito de postar mensagens em seu lugar a fim de divulgar o aplicativo. |
| Como Giftwizz, a cada vez que o usuário o utiliza, quero fazer perguntas que permitam enriquecer minha base de dados sobre o seu perfil, para inferir boas sugestões de presentes para ele e para seus amigos. |
| Como Giftwizz, em intervalos predeterminados, quero perguntar aos usuários qual presente recomendariam, a partir de uma lista, a um de seus amigos nas redes sociais. |
| Como Giftwizz, a todo momento, quero descobrir relacionamentos em minha base de dados que permitam sugerir presentes. |
| Como Giftwizz, quero ter acesso às operações dos lojistas que me permitam saber quais cupons foram convertidos em compras, a fim de calcular o percentual dos donos do produto e gerar relatórios aos lojistas e donos do produto. |
| Lojista/Empresa |
| Como lojista, a qualquer momento, quero ter acesso à lista de presentes sugerida pelo GiftWizz para poder oferecer produtos ao sistema. |
| Como lojista, quero receber relatórios do GiftWizz, exibindo as vezes em que meu produto foi sugerido e os cupons emitidos. |
| Como lojista, devo dar acesso ao GiftWizz de maneira que o sistema saiba quais cupons foram convertidos em compras. |
| Como lojista, apenas quando uma venda via cupom do GiftWizz for efetuada, quero gerar um pagamento ao mesmo para seguir me beneficiando do sistema. |
| Como empresa, quero poder efetuar cadastro através de email no GiftWizz, para (como um usuário) poder receber sugestões de presentes para um funcionário. |
| Como empresa, quero poder usar o GiftWizz para receber sugestões de presentes para um grupo de funcionários. |
Repare que, no caso do GiftWizz, as histórias foram agrupadas por “persona” (usuário, lojista, o próprio assistente de inteligência artificial Giftwizz). Eu prefiro que, na medida do possível, o “sistema” nunca apareça como personagem. Reconheço, porém, que isso facilita, em muitos casos, o entendimento do que precisa ser desenvolvido pela equipe.
Note também, ainda na Tabela 4.1, que algumas histórias já foram identificadas e separadas para serem desenvolvidas durante o primeiro Sprint. Elas serão movidas, então, para o primeiro Sprint Backlog. No Capítulo 6, você verá que esse Backlog evoluiu durante o Sprint Zero (falaremos mais sobre ele no Capítulo 11).
