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?
-440x264.jpg?x13947)
Neste caso de equipe de manutenção, como você colocaria dentro da Sprint, as urgências que chegar no meio do caminho. Que neste caso quebraria a Sprint.
Oi Ferreria,
claro que não existe uma única solução, e um profissional capacitado pode avaliar o caso da empresa, indicando bons caminhos. O Scrum permite adaptações, mas quanto maiores, mas risco se corre e o auxílio de alguém com experiência e o devido conhecimento ajuda. De qualquer forma, sem interferir muito, há um caminho normal, que é inserir a demanda urgente como uma história extra na Sprint. Se isso for conversado e acertado com o time, não quebrará a Sprint e permitirá o atendimento de todas as necessidades. Isso, conjugado com o uso de Sprints curtas, deve resolver a maior parte das necessidades de manutenção.
Um abraço.
Fiquei com dúvida em alguns pontos, se puderem me responder:
Uma vez que os projetos são de grande complexidade o que faz com que as equipes especialistas acabem sendo criadas, como mitigar o problema de estimativa para as Sprints? uma vez que sem um conhecimento mínimo do projeto, fica difícil para o desenvolvedor estimar e garantir a qualidade do que está fazendo.
Considerando ainda a complexidade do projeto, o que vocês sugerem para resolver o problema da análise?
Lembrando que, uma vez que o projeto é complexo e específico, fica difícil para o desenvolvedor abstrair e compreender todo o necessário para planejar uma sprint. Isso fica mais evidente na criação de um novo projeto de regra de negócio mais complexa.
No texto foi colocado que “casos imprescindíveis inevitáveis … resta-nos a alternativa do cancelamento das Sprints dos projetos de desenvolvimento, em benefício dos projeto de manutenção”. Vocês propõe alguma forma de decisão para isso? ou seria somente um comum acordo entre as partes?
Na questão dos projetos em Manutenção, foi citado que é comum entrar demandas e correções “todas para ontem”. Como estipular prazo de entrega para essas correções considerando uma sprint? Como negociar um incidente junto ao cliente, de forma que ele aceite esperar a conclusão de uma sprint, para que somente então seu item entre na próxima sprint? (no artigo é citado o prazo de 1 semana de sprint, ou seja, em alguns casos uma sprint pode começar e logo em seguida um novo incidente muito importante ser registrado).
Olá, faço parte de um time de sustentação ao ERP – JDEdwards. Iniciamos esta semana as reuniões diárias e a partir do dia 2/4 utilizaremos o Taiga. Meu time conta com 15 pessoas e estamos achando as reuniões bem maçante. Primeiro, porque sempre tem um que quer falar mais e acaba trazendo pontos q entendo não devem ser tratados na reunião e o próprio tamanho da equipe.
Como sugere que posso melhorar as reuniões para que o time não fique desaminado?
Oi Janaína,
de certa forma, você já elencou as soluções na sua pergunta: reduzir o time e se ater ao previsto para cada reunião/cerimônia. Vocês tem Scrum Master? Como ele se posiciona com relação a esses problemas? E o PO? Ele não percebe que a produtividade do time poderia ser melhor? Ninguém enxerga riscos par ao time com essas práticas?
A cerimônia diária deve ser somente para dizer oque fez, vai fazer e se está com alguma dificuldade, a qual inclusive não deve ser sanada no momento da reunião. Alguém com conhecimento para a solução se compromete a após a reunião ajudar quem está com dificuldade.
Quanto ao tamanho da equipe, a sugestão seria quebrar em duas. Existe recomendação para cada time ter de 3 a 9 integrantes, contando inclusive PO, SM e Tester.
Estamos tendo esta duvida na empresa que trabalho, pois, n sabemos se irá valer a pena aderir ao scrum para manutenção de software.
Olá Rafael,
Obrigado pelo seu comentário. Gera sempre dúvida mesmo. Existe aí um esforço inicial de adequação e mudança em algumas práticas que, por vezes, vêm de longa data. Uma sugestão seria começar por um projeto piloto. As vantagens são que os benefícios poderão ser percebidos e as dificuldades evidenciadas, melhorando assim o grau de certeza na sua adoção (transparência). Além disso, em caso de sucesso, isso vai gerar mais confiança quando da extensão da prática para os demais projetos. Se vocês resolverem seguir em frente, e havendo oportunidade, compartilhem conosco essa experiência. Um abraço, Ricardo.