Scrum - Planejamento de releases e a priorização do backlog, uma histórinha

Por Cesar Brod

Data de Publicação: 10 de Dezembro de 2014

Enquanto reviso meu livro Scrum - Guia Prático para Projetos Ágeis, revivo alguns dilemas que enfrentei em seu lançamento. Eu ainda quero que o livro seja ágil, curto, direto ao ponto e, ao mesmo tempo, que reflita a minha própria vivência e aprendizagem sobre esse framework, que prefiro chamar de um conjunto de atitudes para a construção de excelentes produtos com equipes formadas por pessoas felizes.

Aliás, para quem ainda não sabe dessa história, depois de algumas conversas com vários amigos para decidir o título do livro, optei por um sugerido pelo Rubens Queiroz, aqui do Dicas-L: Scrum - Projetos Ágeis e Pessoas Felizes. Meu editor, o outro Rubens, o Prates, achou que, com esse título, o livro acabaria em prateleiras reservadas aos esotéricos ou de auto-ajuda. Confesso que gostaria muito de ter o feedback desses outros leitores também! :-)

Para mim o mais difícil sempre é decidir o que cortar fora em um texto. Qual é o essencial a ser mantido e o que é, simplesmente, descartável. Acredito que aprendemos mais dentro de contextos e que pessoas e interações são mais importantes que processos e ferramentas, como reza o Agile Manifesto. Essa é a principal razão pela qual meus cursos sobre métodos ágeis têm, no máximo, uns 30% de conteúdo fixo. A outra parte é construída a partir da troca de experiências pessoais e profissionais entre os participantes e histórias que posso trazer de minha experiência com agilidade, iniciada em 1989 com o presente que recebi do Jim Wild: o livro The Mythical Man-Month, do Fred Brooks Jr.

Quando planejamos releases para um produto - o que os clientes experimentarão em cada entrega "pública" do mesmo -, priorizamos e refinamos o seu Product Backlog, o grande desafio é justamente esse: saber o que deixar de fora. Falarei, mais uma vez, do desenvolvimento do Sagu, o sistema aberto de gestão acadêmica que teve seu desenvolvimento iniciado no final de 1999 e que hoje, mantido pela Solis, pertence a todos e é disponibilizado através do Portal do Software Público Brasileiro.

Nota: Estranhamente, a grande maioria das instituições públicas de ensino ainda preferem pagar licenças para soluções proprietárias em vez de fomentar a geração de emprego e renda em seu entorno, desenvolvendo mercados para seus próprios alunos, mas isso já foi tema de outros artigos. Felizmente, já são dezenas de universidades brasileiras - boa parte delas privadas - que apostam no modelo de conhecimento livre e sustentam o desenvolvimento do Sagu.

O Product Owner do Sagu era o professor e mestre (formal e de fato) Eloni Salvi, na época pró-reitor administrativo e financeiro do Centro Universitário Univates. Economista, Eloni sabe que não é o software usado que constitui o diferencial competitivo de uma instituição de ensino, mas a qualidade dos docentes e a boa relação com os discentes (pessoas e suas interações mais importantes que processos e ferramentas). Desde o princípio o Sagu foi desenvolvido sob o escrutínio de muitos e, mesmo antes de sua entrada em produção, criamos o Sagu Workshop (maio de 2000), onde dividimos com 30 pessoas, de todo o Brasil, o código de um sistema ainda embrionário.

Das várias conversas que tive com o Eloni, lembro de várias que foram fundamentais para o meu aprendizado. A Univates tinha um sistema que já contemplava sua gestão: ele era desenvolvido com Visual Basic for Applications (VBA) usando uma base de dados MS Access. Nas primeiras reuniões com os usuários, o requisito trazido como o mais importante era o de que o Sagu deveria contemplar absolutamente tudo o que o sistema anterior contemplava. Como Product Owner, o Eloni dizia que esse era o requisito da preguiça e que, de fato, mais da metade do que o sistema anterior contemplava não era utilizado e que, da outra metade, a maior parte poderia ser melhorada se processos antigos fossem simplificados.

Os releases do Sagu eram definidos na forma de grandes temas e eles refletiam diretamente o valor de negócio para a instituição. O primeiro tema foi o Vestibular. O Eloni dizia que, sem trazer alunos para a instituição, a mesma não tinha razão de ser. Em 2000 a Univates já oferecia a inscrição no vestibular através da internet, além de publicar a lista de aprovados da mesma forma. Vale lembrar que, em 2000, a cidade sede da Univates, Lajeado, possuia um dos maiores índices de conexões domiciliares à internet em todo o Brasil.

O segundo release do Sagu foi o Financeiro. Mais uma vez, o Eloni lembrava que, se ninguém pagar e se não se administram bem esses pagamentos, não há como atingir a sustentabilidade da instituição. O terceiro release foi o Acadêmico, com o refinamento das matrículas (que em boa parte já eram atendidas pelo release Vestibular), controles de ensalamento, prerrequisitos, versões de currículos, históricos e demais registros acadêmicos.

Cada release era entregue em três meses, com Sprints de um mês (que horror!). Assim, em nove meses o Sagu já substituia, em grande maioria, o sistema anterior. O tema do release seguinte foi chamado, apropriadamente, de Mata o Velho. O sistema anterior seria, efetivamente, morto. Ele ficou como zumbi, apenas para eventuais consultas, até que ninguém mais usou aquilo, foi feito um backup final e a máquina onde estava instalado ganhou alguma outra utilidade.

O Eloni é um cara extremamente gráfico. Ele pedia que imaginássemos o período até a entrega de cada release como uma kombi descendo uma ladeira em direção a um muro onde, depois dele, havia um enorme precipício. A cada Sprint, devíamos decidir quem é que iríamos salvar da morte antes da entrega do release. Como Product Owner ideal, o Eloni sabia negociar bem, com os usuários do sistema, quais os filhos mais queridos que deveriam ser salvos da morte iminente. Depois que a kombi batia no muro, obviamente, os feridos mais resistentes eram recuperados em releases seguintes. Os incômodos zumbis (eles sempre existem) eram devidamente decapitados.

Em todas as reuniões com os usuários - e, no início dos anos 2000 elas ainda não eram tão ágeis assim - buscávamos questionar se determinadas funções que existiam no sistema antigo eram realmente necessárias. Depois, com o Eloni e a nossa equipe, fazíamos uma apuração daquilo que os usuários solicitavam. É importante lembrar que o Eloni, como todo bom Product Owner, era mestre de seu domínio: a gestão acadêmica. Propositalmente, alguns requisitos que, no escrutínio de nosso PO, eram de pouca ou nenhuma relevância, eram anotados mas não entravam no relatório que devolvíamos aos usuários. Esse relatório era devolvido, por e-mail, a todos os participantes da reunião e, caso alguém não concordasse com algo, poderia se manifestar. Eram raríssimas as manifestações. Requisitos que são realmente importantes são defendidos. Requisitos originados de vaidades ou vontades momentâneas tendem a ser esquecidos e raramente reaparecem no Product Backlog.

Vários releases adiante, chegamos ao tema Protocolo, onde todas as solicitações vindas de alunos, professores ou funcionários ao setor de protocolos e tinham que percorrer vários setores para encaminhamentos, deferimentos (ou indeferimentos) e geração de documentos passariam a ocorrer de forma eletrônica, através do Sagu. Já partíamos do princípio que a simples automação de processos não ideais era o equivalente a acelerar a viagem da vaca para o brejo. Lembro que, na época, a Joice Käfer fez um pair programming com uma funcionária que conhecia bem os processos utilizados. Os diagramas de fluxos foram feitos com o dia e apresentados ao pró-reitor acadêmico que, nesse release, atuou como o Product Owner. É impressionante como a visualização dos processos faz com que eles tendam a ser simplificados e, em vários casos, eliminados.

No desenvolvimento do Sagu, optamos por releases que eram fixados por tempo (três meses cada um) e, dentro de cada tema, priorizávamos o Product Backlog de acordo. Na evolução dos Sprints e com a proximidade da entrega de cada release, fazíamos, com constância, o Product Backlog Grooming, garantindo que no topo dele estariam os itens que, definitivamente, seriam salvos antes da kombi bater no muro. Com os temas principais atendidos, claro, o Sagu passou (e passa) por um processo de aprimoração contínua, com requisitos vindos de muitas outras instituições de ensino onde está instalado.

Acompanhei mais de perto, como gestor de desenvolvimento, o Sagu (e depois o Gnuteca) até 2004. Esse trabalho, porém, foi fundamental para todo o aprimoramento de minha prática com métodos ágeis, com destaque para o Scrum. Gosto de lembrar dessas historinhas para enfatizar que, ainda que o Scrum tenha atingido seu Tipping Point em 2012, a sua prática é aprimorada há tempos. O primeiro Scrum rodou, pela primeira vez, em 1993 e Jeff Sutherland e Ken Schwabber publicaram seu primeiro artigo sobre o assunto em 1995 (ver As Raízes do Scrum). É o aprimoramento dos métodos ágeis e os relatos de sua aplicação que têm reforçado sua adoção. Ainda bem! Afinal, não custa repetir: pessoas e suas interações são mais importantes que processos e ferramentas!