Fundamentos de Manutenção de Software
9 Processos 🔗
9.1 Introdução 🔗
(em breve)
9.2 Agilidade nas Mudanças 🔗
Atualmente, os processos de desenvolvimento de software mais comuns são ágeis, tais como Scrum, Kanban, XP ou Shape Up. Uma parte do sucesso desses processos se explica pela compreensão que eles tiveram sobre o papel de mudanças em desenvolvimento de software. Ou seja, software, como o próprio nome sugere, é flexível e pode ser adaptado de forma mais simples ou mais barata do que a maioria dos produtos físicos.
Imagine um edifício residencial: é quase impossível realizar mudanças significativas nele depois de pronto. Normalmente, não dá para construir um novo andar ou aumentar o tamanho dos apartamentos. Porém, mudanças e evoluções em software são mais viáveis, pelo menos em linhas gerais. Por isso, na maioria dos sistemas, não vale a pena investir tempo demais em um levantamento de requisitos completo e em um projeto detalhado de um sistema (como ocorre no caso de um edifício residencial). Em vez disso, com software, é mais importante começar, até para entender, na prática, o problema e as necessidade dos clientes. E depois o sistema vai sendo evoluído e adaptado. Em resumo, com processos ágeis, o desenvolvimento é incremental e iterativo, dividido em sprints.
Porém, mesmo com processos ágeis, não é possível mudar de ideia a qualquer momento… Nenhum time de desenvolvimento consegue trabalhar se hoje a prioridade é uma funcionalidade X, mas amanhã ela muda para uma funcionalidade Y. Por isso mesmo, todo sprint deve possuir um objetivo claro, normalmente implementar um conjunto de histórias de usuários. Com isso, mudanças e adaptações podem acontecer, mas apenas entre sprints, como ilustrado na próxima figura. Durante um sprint, os times devem estar blindados contra mudanças. Por exemplo, o Guia do Scrum afirma categoricamente que durante um sprint nenhuma alteração pode comprometer seu objetivo.
Outra mudança importante que veio junto com métodos ágeis foi na organização dos times de desenvolvimento e manutenção. Anteriormente, era mais comum ter times de desenvolvimento e times de manutenção (também chamados, às vezes, de times de sustentação). Ou seja, um time implementava e outro time mantinha. Essa separação, no entanto, gera um problema grave: ela não faz com que o próprio time depois tenha que lidar com as consequências de um desenvolvimento mal feito. Ou seja, o time de desenvolvimento pode não se preocupar com questões de código limpo, comentários, código flexível a mudanças, logging, dívida técnica, etc., tal como vimos nos capítulos anteriores deste livro. O motivo é que esse time vai desenvolver, mas depois outro time será responsável pela manutenção.
Por isso, atualmente, o modelo mais comum de organização de times é baseado em squads. Uma das principais características desses times é sua responsabilidade fim a fim sobre o produto, desde a concepção, passando pela implementação, bem como pela sua manutenção e evolução. Com isso, favorece-se um estilo de trabalho com skin in the game. Então, se o time criar muita dívida técnica, depois caberá também a ele pagar essa dívida.
9.3 Práticas para Manutenção de Software 🔗
9.3.1 Slacks 🔗
Desenvolvimento de software, como qualquer projeto de engenharia, está sujeito a incertezas e riscos que são difíceis de prever inicialmente. Por isso, métodos como XP recomendam incluir uma folga (slack) em cada sprint. Por exemplo, pode-se deliberadamente reservar 20% da duração de cada sprint para realizar atividades como as seguintes:
Terminar a implementação de uma história de usuário que se revelou mais difícil de codificar; ou corrigir bugs que apareceram ao longo do sprint.
Melhorar a qualidade da implementação, por exemplo, refatorar alguma parte do código, deixar o código mais limpo, corrigir problemas arquiteturais, melhorar a documentação, pagar dívida técnica, atualizar dependências, etc.
Estudar e testar uma nova tecnologia que pode trazer ganhos para o projeto, incluindo a realização de protótipos, provas de conceito ou MVPs.
Uma alternativa a slacks é reservar um dia a cada mês (ou a cada n meses) para a realização das duas últimas atividades descritas acima. Nesses dias, normalmente chamados de Hack Days, todos os membros do time focam em uma pauta de trabalho que não visa a implementação de novas funcionalidades.
Slacks ou Hack Days são então práticas que uma organização pode adotar para sinalizar a importância de cuidar da qualidade interna de seus produtos de software. Para isso, a organização entende ser importante ter tempo previamente reservado para tal finalidade.