Categorias

Manifesto Ágil: O Processo de Refining

Durante um projeto de desenvolvimento de software, independente da metodologia ou framework que está sendo utilizada, não é raro que existam pontos de controle onde paramos e olhamos para o futuro, seja breve (dia, semana ou sprint) ou um futuro mais distante (release ou final do projeto). Nesse momento, usualmente planejamos quais os próximos passos de construção do produto. Geralmente isso ocorre no planejamento ou replenishment.

Em alguns processos, durante o planejamento, replenishing ou outro momento de se organizar para o futuro, tende a ocorrer (tende, não é uma regra) a discussão sobre as user stories que precisam ser desenvolvidas. O refining ou grooming (esse último vem entrando em desuso, inclusive o Scrum Guide abandonou o uso da palavra em 2013). Ainda que algumas pessoas realizem tal processo, percebo que em muitos times ainda não está tão clara a sua importância dentro de um projeto.

Inclusive em alguns locais, não há sequer o conhecimento do que seja o refining. Isso é problema? Claro que não! Adoção da agilidade é incremental, ninguém é obrigado a saber todas suas nuances. Então, caso você não conheça o processo, relaxe! Vou ajudá-lo!

Come with me if you wanna live the refining!

Refining é o processo pelo qual realizamos o levantamento e escrita dos cards, de forma a deixá-lo pronto para desenvolvimento. Neste processo, são levantados uma série de questionamentos acerca de negócio, código, critérios de aceite e quaisquer outras informações que sejam relevantes para a construção daquele incremento de produto. O processo de refining é responsável por criar um acordo do que será construído entre os envolvidos. Definindo o escopo das user stories (o que será feito e também o que não será feito).

Já ouvi o seguinte argumento:

Ah, mas já fazemos isso durante o planning na etapa de estimativa! Então o refining é desnecessário!

O que acontece é que durante a etapa de estimativa geralmente ocorre uma discussão acerca da user story, para saber se todos entenderam o que está escrito e aí sim estimar. Entretanto essa discussão aborda somente o card já escrito. E como fica o preparo? Caso o time utilize o momento da estimativa para escrever tudo o que deve estar contido na user story e também estimar, o evento terá uma duração elevada.

Legal, mas qual o momento para essa escrita então? É justamente durante o processo de refining, que acredito deve ser iniciado antes do planning, por exemplo. Para que neste momento a user story já chegue com mais informações para a discussão.

O refining não garante, mas aumenta consideravelmente as chances de uma user story estar bem escrita. E user stories bem escritas são importantes para evitar incertezas no desenvolvimento, evitando interrupções durante a escrita de código, reduzindo o leadtime e aumentando a eficiência do time.

Os benefícios para o time e para o processo podem ser facilmente identificados. Alguns perceptíveis de forma mais rápida são:

  • User stories melhor escritas: como você tem um tempo de preparo maior para escrevê-las, as chances de ter user stories claras, mais informativas e com critérios de aceite melhor escritos é grande;
  • Estimativas mais assertivas: sabemos que estimativas não são prazos, e sim valores aproximados. Entretanto, a assertividade dessa estimativa tende a aumentar, caso você possua mais informações em mãos, com user stories melhor escritas, você melhora as formas de estimar;
  • Menor número de incertezas: com um melhor preparo antes de levar a user story para discussão, você remove incertezas, melhorando o processo, e fazendo com que a funcionalidade seja melhor entendida e que seja mais fácil de identificar e sanar dúvidas.

O processo de refining também é uma ótima maneira de conhecer o negócio, delimitar escopo (o que vai ser feito, e o que não vai ser feito). Além de ser uma excelente forma de manter o alinhamento do time. No refining fica claro para todos o que será construído e como. Sendo assim os silos de comunicação reduzem bastante.