Scrum - Projetos Ágeis e Pessoas Felizes

Todo bom projeto começa com o pleno entendimento, por parte da equipe de desenvolvimento ou do fornecedor de soluções, daquilo que o cliente realmente deseja. Isso deveria ser trivial, simples, mas deixou de ser a partir do surgimento e do domínio das tecnologias da informação e comunicação. Passamos a ter, de um lado, o usuário e, do outro, o conhecedor da tecnologia. O usuário precisa de uma solução, mas não domina a tecnologia. Quem domina a tecnologia, por outro lado, muitas vezes desconhece a real necessidade do usuário.

Um dos textos de Platão descreve um diálogo entre Sócrates e Íon, o rapsodo. Em certa parte do texto, Sócrates discute com Íon um poema de Homero, quando o pai recomenda ao filho cuidado em uma corrida de bigas. Um cocheiro entenderia muito melhor esse texto do que um médico, ou um arquiteto, concordam os dois.

Ao dominarmos uma tecnologia, não podemos ter a pretensão de entender integralmente o negócio ou as necessidades de nossos clientes. Ainda que nos esforcemos ao máximo para isso, é o cliente que detém essa compreensão, devendo ser o soberano na tomada de decisões sobre a solução que deseja, mesmo que não entenda nada da técnica a ser usada na construção dessa solução.

Anteriormente, neste livro, ao falar sobre Extreme Programming, já mencionei User Stories, ferramenta que envolve o cliente e o fornecedor/desenvolvedor na descrição da solução. Mike Cohn, autor da clássica apresentação sobre Scrum, que traduzi para o português, é também autor de um dos melhores livros sobre User Stories: User Stories applied. Resumindo ao extremo, as User Stories permitem àqueles que conhecem a técnica da construção de uma solução (linguagem de programação, ferramentas, bases de dados) guiar quem necessita dessa solução no exercício de descrevê-la de forma simples e concisa.

David Churchville, autor do livro Agile Thinking – Leading Successful Software Projects and Teams, em seu blog, nos dá excelentes dicas para escrever boas User Stories. Elas devem ter o usuário, aquele que necessita da solução, como o foco da história. Não se deve mencionar na história algo como “melhorar a indexação da tabela de pedidos”. Isso será grego para um usuário leigo, mas um analista de base de dados entenderá dessa forma quando ler na linguagem do cliente: “aumentar a velocidade na impressão dos relatórios de pedidos”. David ainda diz que boas User Stories são perfeitamente explicáveis em 30 segundos, entre um andar e outro, em um elevador. Cada história deve “caber” no trabalho a ser executado em uma Sprint pela equipe de desenvolvimento e deve ser facilmente testável (Kent Beck diz que uma história deve poder ser desenvolvida em meio dia ou um dia): o cliente deve poder acompanhar o desenvolvimento do sistema lendo a User Story que ajudou a escrever.

Usando dois acrônimos em inglês, Bill Wake, do xp123.com, completa com mais boas dicas: INVEST in Good Stories and SMART Tasks.

INVEST vem de Independent, Negotiable, Valuable, Estimable, Small, Testable. Cada User Story deve ser – o máximo possível – independente de outras histórias. Aquilo que ela descreve deve ser perfeitamente negociável entre o fornecedor e o cliente (de fato, ela deve poder ser traduzida, posteriormente, em um plano de trabalho ou contrato de serviços). O cliente deve perceber o valor da User Story tanto como apoio à compreensão na construção da solução quanto na percepção do resultado de seu investimento na mesma. E, como já mencionei, cada história deve ser pequena e testável. Para o Product Owner, a história é o roteiro do teste de aceitação da mesma na Sprint Review (reunião de Revisão do Sprint).

SMART vem de Specific, Measurable, Achievable, Relevant, Time-boxed. Quando auxiliamos o cliente na construção de User Stories, devemos ter em mente que elas serão atendidas, na construção da solução, com a realização de uma série de tarefas. Ao entendermos como devem ser as tarefas, saberemos orientar melhor o desenvolvimento de cada história. Cada tarefa deve ser específica, contida em si, bem definida e também independente. A tarefa deve poder ser medida para que o esforço para o seu atendimento possa ser efetivamente avaliado. Obviamente, temos de ser capazes de traduzir as histórias em tarefas que possam ser realizadas. Cada tarefa deve ser relevante à história, e se, na definição das tarefas, uma delas parecer não estar relacionada com a história (uma tarefa acessória não prevista inicialmente), então a tarefa ou a história devem ser revistas.

Agora, as User Stories devem ser escritas mesmo antes de se chegar ao Product Backlog e, posteriormente, a sua decomposição nos Sprint Backlogs? Eu defendo que sim, por muitos motivos.

•    Como já falei antes, o fornecedor ou desenvolvedor da solução pode dominar a tecnologia, mas não necessariamente o negócio do cliente para o qual está oferecendo uma solução. Sentar com o cliente, com o usuário, e ouvi-lo é uma atitude humilde que prova o quanto você quer entender do negócio antes de propor qualquer coisa. Cobrar ou não por essa fase inicial de aprendizagem é algo que deve ser acordado entre o cliente e o fornecedor. Minha opinião é a de que isso deve, sim, ser cobrado e, no caso de a venda do projeto ser concretizada, o valor investido pode até ser, posteriormente, descontado. Questões de dimensionamento e investimentos em um projeto serão abordadas brevemente, mais adiante, no Capítulo 8, “Estimativas de tempo, esforço e investimento”.

•    As entrevistas individuais, com os potenciais usuários do produto a ser desenvolvido, desvendam muitas coisas que mesmo o Product Owner (o dono do Product Backlog, principal responsável pelo produto) desconhece. Detalhes operacionais que podem estar diretamente influenciando no alcance de metas estratégicas da empresa e que ainda não foram pensados de forma sistêmica. São esses detalhes que podem dar a direção no desenvolvimento de “pequenas vitórias”, apresentadas na forma de protótipos prematuros, que podem fazer a fundamental diferença positiva na “compra” do Scrum como atitude de desenvolvimento.

•    A escrita das User Stories ajuda na descoberta das principais “dores” a serem atendidas, facilitando a priorização do que será desenvolvido.