Uma ideia muito comum das pessoas é que projetos ágeis não possuem qualquer documentação e por isso, não existe formalização de regras e isso leva a algumas dificuldades como por exemplo: Como estimar testes?
Avançando nesta lógica temos uma eminente tensão entre os próprios profissionais de tecnologia bem como com profissionais de outras equipes.
Como o Scrum resolve isso?
Vou começar pela questão do atrito.
O primeiro valor do manifesto ágil, em tradução livre, diz que: Pessoas e interações são mais importantes do que processos e ferramentas.
O time ideal no Scrum deve conter 6 + ou – 3 pessoas. Resolvendo a equação: de 3 à 9 membros.
Qual a razão disso?
Raramente um time com menos de 3 pessoas consegue ser multifuncional, ou seja, entregar uma atividade desde o “front-end” até o banco de dados. Mais de 9 pessoas raramente são capazes de manterem-se alinhadas através de conversas, sendo assim, depois da nona pessoa, a cada nova pessoa incluida no time um número muito grande de “novos canais de comunicação” são abertos.
As setas na imagem abaixo representam os canais de comunicação presentes em um time com 4 pessoas.
Adicione um círculo à imagem e ligue-o aos já presentes. Esse seriam os novos canais criados quando adicionamos a quinta pessoa ao time.
Muitas vezes os atritos existem entre pessoas que não se comunicam, pois muitos problemas certamente seriam facilmente resolvidos se os envolvidos apenas conversassem.
A comunicação é um dos principais elemento do Scrum. Sem comunicação, sem Scrum!
Mas e se tivermos pessoas que não conseguem trabalhar junto dentro do time?
Neste caso a única coisa que o Scrum te mostrará é que o problema existe, pois provavelmente as atividades que precisarem destas duas pessoas provavelmente apresentarão algum tipo de desvio em relação às demais por causa desta falta de comunicação.
Neste caso eu indico que seja encontrado algum “framework de RH” para resolver este problema. 🙂
Agora vamos à documentação e à estimativa de esforço.
Como eu disse no post Scrum. Gestão do conhecimento e mudanças de escopo, “o conhecimento do produto está todo (passado, presente e futuro) documentado no Product Backlog.” e ele é representado na forma de “Histórias (novas funcionalidades), bugs e Tasks(!)”. Desta forma, a documentação do produto está toda no Product Backlog.
Mas como?
Bom, vamos dividir este assunto levando em consideração cada um dos itens.
Bug: Este item representa um erro em produção. Normalmente tem uma descrição “direta e reta”. Ex: Quando faço X acontece Y porém deveria acontecer Z. Por este tipo de item estar presente em todos os tipos de projetos acredito não existir muita dúvida nem em como documentar, nem em como estimar (Tanto desenvolvimento quanto testes. Neste caso é geralmente muito mais fácil estimar os testes do que o tempo para correção).
Task (!): Qual o motivo de eu usar esta exclamação? É muito comum ver o Product Backlog recheado de Tasks, porém, segundo as boas práticas, um Product Backlog contém Bugs e Histórias. As histórias devem ser quebradas em Tasks, que representam as atividades que a equipe de desenvolvimento precisa trabalhar para atender o objetivo daquela História.
Claro que não existe um impeditivo em usar Tasks, porém, se ela for usada para novos requisitos, é preciso que ela contenha, pelo menos, os “Critérios de Aceitação” daquele item. Vou explicar um pouco melhor sobre isso no próximo tópico.
Histórias: É como o requisitos funcionais e não funcionais são documentados em equipes Scrum. Por isso devem ser considerados como “artefatos de negócios”. As histórias são, em outras palavras, a origem das funcionalidades que serão desenvolvidas pela equipe de desenvolvimento e os critérios de aceitação escritos nelas representa o que é esperado como resultado daquela história, em outras palavras, são os dados usados como base para testes daquela atividade.
Modelo de como escrever uma história:
Eu como <Persona/Cargo> <Ação> <Funcionalidade> para <ObjetivoDaHistória>
Cadastro de Cartão de Crédito:
- Eu como cliente gostaria de cadastrar meu cartão de crédito na loja para realizar minhas compras de forma mais rápida.
Critérios de aceitação:
- Deve ser possível cadastrar todos os tipos de cartão de crédito existentes no site atualmente.
- Para a forma de pagamento Paypal, esta opção não deve ser exibida.
- Esta funcionalidade deve estar disponível tanto na seção “Minha conta” quanto na tela de finalização de pedido.
A história pode, e em alguns casos deve, conter Wireframe, Desenhos de Fluxo ou qualquer outro material para esclarecer o que é esperado dela, porém, o Scrum diz que uma história é um convite para uma conversa, sendo assim ela não precisa prever a exceção da exceção. Durante esta conversa, caso alguma situação seja encontrada a história pode/deve ser modificada e/ou repriorizada. Em situações onde a situação encontrada não afete diretamente o objetivo da história, uma outra história pode ser criada e essa deve ser priorizada pelo Product Owner junto às demais histórias do Backlog do Produto.
Importante: Existem mais coisas a serem levadas em consideração para que uma História seja considerada boa, mas isso falarei em um outro post.
A partir destes dados o membro do time Scrum responsável por Testes, deve ser capaz de estimar o esforço necessário para suas atividades, porém a história deve possuir apenas uma estimativa de esforço e esta deve compreender desenvolvimento, testes e todos os outros critérios que precisam ser atendidos segundo a Definição de Pronto – este também é material pra outro post.
Mas por que tudo deve estar em apenas uma estimativa?
Em poucas palavras, um “Time de Desenvolvimento” no Scrum não conhece outro título que não seja o de “Desenvolvedor”.
O Scrum diz também que todo o time de desenvolvimento é responsável por entregar a atividade. Se o “desenvolvedor” não entregou a tempo para o “testador”, o time todo não entregou a atividade. Desta forma, todos são igualmente responsáveis pela entrega (ou não) das atividades independente de “em qual parte do ciclo de desenvolvimento” elas estavam ao final do Sprint.
Ir para: Ágil. Gestao do conhecimento, escopo, documentação, testes, falhas e mais…