Mês: setembro 2013

Levantamento de requisitos e SCRUM

Introdução

Um dos posts mais visitados no blog, já bem antigo, é sobre levantamento de requisitos.

Neste post, eu falo um pouco das técnicas que usava para levantar bons requisitos, sempre com uma visão muito focada em metodologias fortemente apoiadas em documentos.

O objetivo deste post é mostrar como a visão ágil me fez pensar de forma diferente em relação a requisitos.

Por que levantamento de requisitos?

Neste ponto, continuo mantendo meu ponto de vista do artigo anterior. Não adianta sair construindo algo que não se sabe exatamente o que é e ainda acredito que a grande maioria dos problemas na área de desenvolvimento de software está em compreender de forma errada os requisitos.

As técnicas de elicitação de requisitos servem para promover o exercício e o entendimento da necessidade do cliente antes de sair construindo.

No meu ponto de vista, nada disso muda nas metodologias ágeis.

As críticas à documentação exaustiva de requisitos

Todas as vezes que eu tentava implementar a filosofia descrita no artigo anterior sobre levantamento de requisitos, sempre sofria algumas críticas. As mais comuns eram:

  • Como você tem certeza que documentou tudo?
  • Como você tem certeza que nada vai mudar?

Minhas respostas mais comuns sempre foram: você não tem certeza que documentou tudo, mas vamos pensar que você conseguiu cobrir 70-80% das necessidades. É bem melhor do que os 0% que tinha antes.

Sobre as mudanças, não existe certeza. A técnica apenas permite melhor rastreabilidade das mudanças. Sempre que um requisito muda, o exercício de replanejar e rediscutir o escopo deve ser realizado.

A receptividade à mudança no modelo Waterfall

Quando trabalhamos no modelo waterfall, geralmente todo o levantamento de requisitos vem antes. No início do projeto, mas após ser dada a data do final do projeto. Sabemos que temos, por exemplo, 2 meses pra levantar requisitos, que o projeto deve ser entregue em 6, mas ainda não fizemos um levantamento exaustivo de requisitos.

Nessa fase, fazemos o levantamento exaustivo e colocamos num grande documento, ou em um grande conjunto de casos de uso e pedimos a validação do cliente. O cliente valida, muitas vezes sem se aprofundar nos documentos e sem ver absolutamente nada construído.

Começamos a fase de construção e geralmente quando começamos a mostrar algo funcionando para o cliente, já estamos próximos do fim da fase de construção, ou no início da fase de homologação.

Não é raro neste momento observamos a reclamação clássica do cliente: “preciso de mudanças, porque quando vemos o software materializado é que começamos a entender o que realmente precisamos”.

Isso gera um tamanho desconforto na equipe. O desconforto ocorre porque o exercício de mudança no modelo cascata é muito grande. Sempre que um requisito muda, deveríamos rever o cronograma e renegociar o prazo. Toda mudança no cronograma deveria passar por esse ciclo de reestimar, reamarrar todas as dependências das atividades e renegociar um prazo, mas tudo isso é tão lento e as mudanças são tão constantes no escopo dos projetos que é muito fácil perder o controle. Acabamos deixando a maioria das coisas registradas como “issues” ou “melhorias” que ou entrarão numa fase 2, ou acabam sendo construídas no meio da fase de teste.

O que acontece é que a data final, cravada em pedra. raramente muda e as mudanças de escopo são absorvidas ao custo de um alto stress e baixa qualidade.

Trabalhando por contrato

O grande risco que se corre ao utilizar uma documentação de requisitos extensa é trabalhar por contrato. Na prática, o cliente pede uma mudança e logo a equipe aponta: Mas nós fizemos o que está no documento e você aprovou.

Na minha opinião, é justo. A equipe fez o trabalho dela, mas o cliente é atendido desta maneira?

Qual é nosso objetivo? Não errar ou atender o cliente?

Incertezas

A grande sacada do SCRUM está em lidar melhor com as incertezas. E existe algo mais incerto do que um projeto de software? A maioria dos novos softwares desenvolvidos são inovações tecnológicas, uso de tecnologias modernas, implementar um novo processo, uma nova forma de trabalho.

No modelo cascata, partimos do princípio que sabemos tudo de antemão. É algo como querer prever o futuro. Uma grande verdade é desprezada durante o decorrer do projeto: As pessoas aprendem sobre o domínio de negócio, sobre o produto durante o projeto.

Se logo durante as primeiras entregas, conseguimos identificar que muitas das premissas tanto de negócio quanto de TI estavam erradas, por que insistimos em continuar pelo mesmo caminho? Por que não aproveitamos esse feedback para corrigirmos a rota?

Como o SCRUM lida com incertezas

Quando fazemos uma estimativa de complexidade (planning poker) para entregar uma estória, não temos lá muitos detalhes sobre o que de fato ela faz, tampouco como construiremos ela.

Quando essa história entra numa sprint, é que começa o trabalho de levantamento de requisitos, porém, ele é específico para aquela história, para aquela funcionalidade. Não é um exercício longo e extenso para todo o projeto. Se nesse momento, observamos que a estória não está madura o suficiente para ser construída, temos a chance de repriorizar, ou mesmo de definir a meta da sprint como um protótipo ou uma prova de conceito para definir uma melhor abordagem para lidar com esse requisito.

Neste momento, as mesmas técnicas utilizadas para a elicitação de requisitos podem ser usadas, porém, o foco é somente para aquela estória.

Muitas pessoas confundem e acham que o modelo ágil significa desprezar toda a técnica e a documentação e sair aplicando um eXtreme Go Horse. Na verdade o que a metodologia propõe é um constante exercício de valor e priorização: O que é mais importante ser feito primeiro? O que retorna mais valor para o cliente?

Se percebemos que o que retorna mais valor para o cliente é o requisito mais incerto, devemos sim começar a construí-lo primeiro, para rapidamente ajudarmos o cliente a materializar a idéia e assim dar o conforto necessário para continuar a construção ou partir para uma abordagem diferente.

Com isso, entrega-se dentro do horizonte de uma sprint um produto funcionando e a melhor materialização dos requisitos existentes, dadas as restrições de prazos e recursos. Para a próxima sprint, qualquer alteração é bem-vinda. Os requisitos são revistos, são aprimorados e o feedback é constantemente utilizado para construir um melhor produto. Dessa forma, o SCRUM aproveita o aprendizado que ocorre durante o projeto.

Que artefatos usar para documentar?

Particularmente eu acho uma documentação de produto mais valiosa do que uma documentação de projeto. Qual a diferença entre as duas coisas?

A documentação de produto, descreve como o software, a aplicação funciona. Ela é mantida e evolui junto com o software. A documentação de projeto, geralmente um caso de uso, representa o que precisa ser feito naquele projeto. Terminou o projeto ela tem pouco valor, porque a linguagem nela utilizada está muito longe de ser uma documentação de sistema.

O ponto é, se os ciclos são extremamente curtos (2 a 4 semanas) pra fazer um produto funcionando, precisamos de uma documentação de projeto?

Muitas vezes documentações simples e rápidas como protótipos feitos à mão, uma descrição da funcionalidade na página wiki é mais que suficiente para atingir o objetivo da sprint.

A prática que acho válida é sempre manter em cada sprint atividades para realizar a documentação de produto, ou seja, pegar as principais abstrações e questões técnicas e documentar e também criar o manual do usuário para a nova funcionalidade construída. A melhor ferramenta pra isso na minha opinião é a Wiki, por sua natureza rápida e colaborativa.

Conclusão

A única certeza que eu tenho em projetos de software é que os requisitos mudam. Continuo achando que as técnicas de elicitação de requisitos são importantíssimas para construir software com melhor assertividade, mas defendo que a documentação não deve ser mais importante do que software funcionando.

A própria filosofia de constante inspeção e receptividade às mudanças ajuda a mitigar o risco dos requisitos mal levantados, da documentação ambígua e da dificuldade de comunicação nos projetos. O principal benefício, na minha opinião, é utiliza o aprendizado que ocorre durante o projeto.

A ausência de “time boxes” na metodologia waterfall e o trabalho por contrato ajudam a perpetuar e insistir em requisitos que já não traduzem a necessidade do usuário, contribuindo para a criação de um ambiente de trabalho de conflitos e desprezando todo o aprendizado que é adquirido durante um projeto.

Anúncios