Olá pesoal!

Vou iniciar esse post com essa pergunta do título que é recorrente ou, no mínimo, bastante discutida no nosso dia a dia Scrum.

Recentemente, um de nossos clientes, com quem desenvolvemos um trabalho de capacitação e implantação do Scrum no seu processo de desenvolvimento de software, levantou essa questão.

Eles gerenciam um extenso portfólio de projetos desenvolvidos e em desenvolvimento. As requisições de manutenção de todos os tipos (corretivas, adaptativas e evolutivas) são encaminhadas pelas áreas de negócio, por múltiplos canais, com grande frequência e sempre, é claro, todas para ontem.

Em razão do conhecimento dos projetos propriamente ditos e das tecnologias empregadas, há também uma dependência específica entre desenvolvedores e esses projetos.

É evidente que comprometemos aí a multidisciplinaridade da equipe.

Pretende-se que, com o tempo e gradativamente, a equipe responsável pela manutenção seja capaz de atender a qualquer requisição de qualquer um dos projetos de manutenção. Assim, o atendimento pode ser mais adequado à disponibilidade e possibilidades da equipe, beneficiando diretamente às áreas de negócio demandantes. Mas, enquanto isso não acontece temos que conviver com essa restrição.

Para completar, como um complicador final, esses mesmos membros da equipe de manutenção constituem as equipes de desenvolvimento dos novos projetos.

E aí! E o Scrum para manutenção de sistemas? Podemos usar?

Yes, we can!” Tanto o estado da arte quanto o estado da prática nos mostram que sim, nós podemos usar. É justamente sobre isso que falo nesse post.

Inicialmente, lembramos do papel do Scrum em “fazer transparecer a eficácia relativa das suas práticas de desenvolvimento para que você possa melhorá-las”. Lembramos também dos seus famosos pilares de sustentação: a transparência, a inspeção e a adaptação, a seguir enfocados, não necessariamente nessa ordem.

 A adaptação

Ela nos fala do “ajuste do processo ou do material sendo processado”, o que tem tudo a ver com essa nossa necessidade. Adotamos aqui o Scrum com algumas modificações.

Inicialmente, definimos um projeto de manutenção e organizamos um backlog de histórias relacionadas às requisições de manutenção. A primeira dificuldade encontrada foi definir alguém como Product Owner, em nível hierárquico tal, que pudesse estabelecer as prioridades no backlog e realizar as reuniões de revisão com a ajuda dos Product Owners de cada projeto.

Vamos lembrar que o relacionamento aqui continuou sendo de muitos para muitos, entre os projetos e os desenvolvedores, na eterna “guerra do estica e puxa”.

Vencida essa etapa definimos o time box das sprints em uma semana, somente para o projeto de manutenção, em razão da dinâmica evidenciada nas prioridades das requisições. Para melhor entendimento, a tentativa aqui foi de empreender uma mudança cultural, diminuindo a frequência dos incêndios diários para incêndios semanais, com uma forte esperança de melhoria dessa realidade, como veremos mais à frente.

Dividimos, também, o tempo de trabalho semanal das pessoas entre os projetos de desenvolvimento e de manutenção. Demos a cada membro da equipe a liberdade de auto-organização para realização de suas tarefas nos seus projetos. Isso já foi resultado de um ponto discutido numa das retrospectivas.

Buscamos aí um cálculo mais realista da velocidade das equipes em cada projeto, reduzindo o seu desgaste e assumindo compromissos de entregas mais tangíveis.

A inspeção

Já a inspeção nos fala que “os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam se detectadas”.

Para que a frequência de inspeção necessária não exceda a tolerância do processo à inspeção, assumimos o compromisso de rever a cada sprint o timebox de uma semana que foi inicialmente definido, até garantir que esse é, de fato, o mais adequado para o projeto. Não deixamos de considerar “a habilidade e a aplicação das pessoas em inspecionar os resultados do trabalho”, e os outros tópicos que já mencionamos sobre a cultura organizacional, a frequência das requisições e a dinâmica das prioridades.

A transparência

Por fim, sabemos que “a transparência garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados. Quando alguém que inspeciona um processo acredita que algo está pronto, isso deve ser equivalente à definição de pronto utilizada”.

Em termos de adaptação, formalizamos os conceitos de histórias preparadas e prontas, na tentativa de reduzir ao máximo o vai e volta de uma mesma história para o backlog.

Além disso, antes de cada sprint, nas reuniões de planejamento, o Product Owner, o Scrum Master e a Equipe estarão de acordo e decidirão no que as equipes irão trabalhar durante a próxima sprint. A diferença é que isso agora está sendo feito com base nas prioridades, nas estimativas e num cálculo mais realista da velocidade das equipes em cada projeto, preservando a sanidade dos Scrum Masters e melhorando a qualidade das entregas.

Ressaltamos que, em casos imprescindíveise inevitáveis, resta-nos a alternativa do cancelamento das sprints dos projetos de desenvolvimento, em benefício dos projeto de manutenção.

Só que nesse caso, os prejuízos dessa medida, ficarão “transparentes” para todos os Product Owners e Stakeholders de tais projetos.

Bem pessoal, nos próximos posts, prometo falar um pouco mais de como estamos nos saindo e de mais usos do Scrum e práticas diárias nesses projetos, mesmo que negativas.

E você? Tem alguma experiência ou comentário que queira compartilhar conosco?