Na minha passagem pela Prefeitura de Praia Grande, quando começamos a adotar o Scrum no desenvolvimento de nossos softwares, dentre os impedimentos que surgiam tínhamos uma constante: nossos famigerados Softwares Legados.
Sistemas antigos, com linguagem obsoleta, os quais não valiam o esforço de serem reconstruídos ou já estavam sendo refeitos dentro de projetos maiores. Softwares que a manutenção era necessária, porém as interrupções constantes, e nem sempre urgentes, demandavam nossa concentração e tempo precioso.
Imaginem um desenvolvedor concentrado em realizar suas tarefas, quando é interrompido para um atendimento pontual, as vezes em outra linguagem, e após retornar irritado com essa situação ter que retomar a concentração das tarefas da Sprint…. Qual o resultado? Impedimentos diários, baixa qualidade, muito retrabalho…
Nossos desenvolvedores então criaram um sistema para tentar equacionar algo que não podíamos deixar de atender. E assim criamos o “Dia de Lixo”.
O que é o “Dia do Lixo”? Considerando que nossas Sprints tinham na época 10 dias úteis, não considerávamos as quartas-feiras “dia útil”. Então a Sprint tinha 12 dias úteis? Não. Nosso trabalho na Sprint acontecia nas segundas, terças, quintas e sextas, a quarta era exclusiva para tratar o Software Legado.
Mas “Dia do Lixo” que nome horrível para falar para o cliente! Verdade por isso antes de oficializamos a nova prática rebatizamos para “Dia de Sustentação”, o qual ficou convencionado que pode ser utilizado inclusive para capacitações, estudos e reuniões fora do projeto.
No início foi difícil pela pressão de nossos usuários, e um certo costume, de serem atendidos imediatamente, porém com muita negociação e empatia conseguimos o apoio de nossos clientes.
Em resumo conseguimos “domar” nosso Software Legado garantindo a produtividade, e principalmente a cadência dos novos projetos, e os impedimentos ficaram restritos a atendimentos extremos, onde o contribuinte estaria pessoalmente aguardando, os quais eram raros.
Outra prática que me deparei foi o do “Bombeiro da Sprint”.
Para explicar vamos imaginar um time com 4 desenvolvedores e muitos, muitos incidentes em produção, a ideia é que a cada Sprint, 1 desses 4 desenvolvedores não participa da Sprint focando apenas na resolução de incidentes ou resolução de causas raiz de incidentes.
As vantagens aqui são que todos em algum momento serão “Bombeiros da Sprint”, logo isso faz com que a qualidade do software seja melhor monitorada pois meu código meia boca de hoje, será meu incidente de amanhã… Além de que a experiência que cada “Bombeiro” passa faz com que sejam trazidas oportunidades de melhoria para o Backlog que podem resolver diversos problemas existentes, mas que ninguém havia percebido antes.
“Isso não é Scrum” alguém pode falar. Ora se os pilares do Scrum são transparência, inspeção e adaptação, e com essas adaptações conseguimos ter sucesso, fiquem a vontade de chamar de outra coisa e criar uma Buzzword nova…
