Os requisitos podem ser dinâmicos em um projeto, mas, independentemente disso, deve haver um acordo sobre quando algo está pronto.
Em projetos clássicos, a definição de pronto é simples e ela está no grande contrato. Quando a lista de cada um dos requisitos, exatamente como definidos no início do projeto, é atendida, o projeto está pronto. Não importa se alguma coisa mudou no meio do caminho ou se o cliente está satisfeito ou não.
Mitch Lacey, autor de The Scrum field guide: practical advice for your first year (Addison-Wesley, 2012), considera a definição de pronto tão importante que dedicou um capítulo inteiro de seu ótimo livro a isso. Faço a mesma coisa aqui!
O biólogo inglês Rupert Sheldrake questiona as constantes universais (como a velocidade da luz, o valor universal da gravidade, o número de Avogadro), discute sua variabilidade no tempo e acha que seus valores não podem, simplesmente, ser arbitrariamente escolhidos.
O segundo costumava ser definido como 1/86.400 de um dia solar médio, mas hoje é definido em termos da frequência da luz emitida por um tipo particular de excitação de átomos de césio-133. Um segundo é 9.192.631.770 vezes o período de vibração dessa luz. Entretanto, desde 1983 o metro é definido em termos da velocidade da luz, ela mesma fixada por definição.
Richard Sheldrake em The Variability of Fundamental Constant: Do physical constants fluctuate?
(Fonte: http://www.sheldrake.org/experiments/constants/)
Ou seja, até as constantes são questionáveis, mas eu e você temos de concordar com o quanto vale um metro e seus múltiplos para podermos indicar, de maneira viável, o caminho que devemos percorrer para chegarmos à casa um do outro. Dessa forma, o melhor seria não falar sobre a “definição de pronto”, mas um acordo sobre o que é o “pronto”.
Os métodos ágeis reconhecem que os requisitos de um projeto são, naturalmente, dinâmicos. Takeuchi e Nonaka falam (estou parafraseando) sobre a “navegação no espaço do projeto”, em que o rumo da navegação é corrigido, em direção a um objetivo, cada vez em que muda o território ou as condições de navegação. Dessa maneira, o acordo sobre o “pronto” deve ser uma forma de composição entre o alcance do objetivo final e os vários pequenos “prontos” que são atingidos até tal alcance. É preciso, também, entender que a própria natureza evolutiva de um projeto e das necessidades de seus usuários pode tender a tornar alguns projetos eternos. Nesse caso, um “pronto” pode ser o do acordo que define o momento entre a passagem do projeto do estado de “em desenvolvimento” para o estado de “em evolução”, mas já beneficiando os usuários.
Um projeto pode, também, evoluir na forma de um “roadmap”, literalmente, um mapa da estrada, com um conjunto de funcionalidades apresentadas em cada uma das paradas na estrada, caracterizando vários “pronto até o momento” ou “pronto na versão X”. No refinamento de um Product Backlog para um projeto extenso ou evolutivo, é necessário estabelecer pontos de corte para esses “pronto na versão X”.
Dependendo do desejo dos patrocinadores, dos clientes ou das condições do mercado, o momento do “pronto” pode ser decidido com auxílio de um tempo limite (o produto tem de ser lançado em até três meses, ou se perde o espaço para os concorrentes) ou de uma funcionalidade estratégica essencial (esse é o recurso matador que tem de estar desenvolvido, sem o qual o produto não pode ser lançado).
Um dos grandes projetos de desenvolvimento que coordenei foi o do Sagu, um software para a gestão acadêmica e administrativa para instituições de ensino patrocinado pelo, na época, Centro Universitário Univates. O limite, nesse caso, era o tempo. O sistema predecessor, evoluído a partir de soluções simples para desktops, adequado para o uso em rede, já dava sinais de limite em sua capacidade e, certamente, não aguentaria a carga gerada pelo processamento do vestibular de inverno do ano 2000. Ou seja, a data do “pronto” estava dada e a questão era formatar o cronograma de desenvolvimento de forma que as funcionalidades essenciais estivessem prontas até a data limite.
Outro sistema desenvolvido inicialmente para a Univates, o Gnuteca, tinha como requisito que atendesse a todas as características de um sistema fechado, então utilizado pela biblioteca da instituição. Além de oferecer todos os recursos do sistema anterior, o Gnuteca deveria ser 100% aderente ao padrão de catalogação MARC21 e oferecer a possibilidade de reserva e renovação de livros através da web. Nesse caso, os recursos (e não o tempo) foram determinantes na definição do “pronto”.
É muito mais fácil e recomendável, porém, chegar a um acordo de “pronto” para as tarefas definidas por User Stories atômicas, bem contidas e testáveis (INVEST, SMART). Na elaboração dessas User Stories já devem ser deixados bem claros (muitas vezes, de forma explícita no próprio texto da história) os seus critérios de teste e aceitação. E, em sua codificação, os desenvolvedores devem criar os testes automatizados junto ao código funcional (de preferência, elaborar o teste até antes de escrever o código).
Reveja essa User Story:
“Como um jogador, quero capturar peças do adversário cercando-as em uma linha (horizontal, vertical ou diagonal) com dois de meus peões [peão | peça adversária | peão].”
Estão bem claras aqui a condição de teste e a aceitação por parte do usuário. No código, porém, o programador precisará ter o cuidado de permitir que o usuário apenas mova o peão de acordo com as regras, verificar se é possível o movimento para a casa desejada (ver se não está ocupada por outra peça, por exemplo) e verificar a ocupação das casas laterais para determinar uma condição de captura. O hábito de pensar nas condições de teste durante o desenvolvimento ajuda a evitar situações em que o usuário venha a experimentar uma condição de erro, comprometendo a aceitação.
Assim, a definição do “pronto” pode ser um conjunto de acordos que vão da atomização das tarefas de desenvolvimento de cada história contemplada dentro de um Sprint, passando pelo aceite dessas histórias quando entregues ao Product Owner ao final de cada Sprint e contemplando a lista de histórias que formam o Product Backlog integral (ou o que se decidiu que contemplaria uma “versão” do produto a ser entregue ao usuário final).
Cada User Story, antes de chegar na Sprint Review (sua demonstração ao Product Owner) deve estar verificada pela definição de pronto da equipe. Algumas sugestões que podem constar da definição de pronto são as seguintes:
- o código que permite a realização da história está dentro dos padrões de codificação acordados pela equipe;
- o código foi revisado entre o par de desenvolvedores que o escreveu e ao menos por outro integrante da equipe;
- o código está disponível no ambiente de homologação do sistema de controle de versões;
- o código está coberto pelos testes acordados pela equipe (unitários, de integração, de aceitação, de interface etc.);
- a funcionalidade foi testada pelos membros da equipe;
- a funcionalidade foi testada e validada por um potencial usuário externo à equipe;
- a suíte de teste de todo o sistema completo foi executada e o novo código não causou nenhuma falha do sistema.
A definição de pronto deve ser melhorada e ampliada na medida em que a interação entre a equipe e o Product Owner amadurece, na sequência dos Sprints. Quando o Product Owner não aceita uma determinada história, isso pode ser um sintoma de que faltou algo a ser considerado na definição de pronto. Procedimentos automatizados de checagem podem, também, eliminar itens da definição de pronto: uma checagem automatizada do padrão de codificação, por exemplo.
