Recentemente, houve um problema interessante colocado em um fórum de discussão de gestão de projetos. O autor da pergunta fez a seguinte pergunta –
“Entrei recentemente em uma empresa e em um dos projetos em que estou envolvido, temos esta equipe Scrum que tem um backlog misto (Histórias e Bugs). O objetivo desta equipe é consertar bugs urgentes e quando eles não estão (não acontece com frequência :)) eles devem trabalhar no incremento do produto.
Entretanto, esta equipe não funciona corretamente e estou disposto a mudar esta estrutura de equipe (acreditando que estas atribuições mistas não estão ajudando o desempenho da equipe + não estão correspondendo às iterações Scrum), fazendo com que a equipe trabalhe exclusivamente na correção de bugs, e deixando o incremento do produto para outra equipe (que já faz isso, mas em uma proporção maior).
Minha pergunta é: Estou perdendo algo que poderia fazer esta equipe trabalhar melhor e manter esta estrutura de suporte de aplicação + incremento de produto enquanto usa Scrum?
Se não, então acredito que transformarei esta equipe em uma equipe exclusiva de suporte de aplicação e usarei Kanban no lugar.”
Esta é uma situação muito comum! As equipes de software frequentemente administram os produtos – e isso significa que se espera que eles construam novas funcionalidades para o produto, bem como que corrijam os defeitos informados no produto. Dependendo do contexto da equipe e do produto, eles podem ter que fazer reparos urgentes com frequência para resolver problemas do cliente enquanto trabalham em melhorias regulares do produto também. Frequentemente, especialmente em um ambiente Scrum, pode ser difícil combinar a cadência de fazer ambos. Esta também foi a situação aqui – e o que segue é minha resposta, que o autor da pergunta aceitou como a resposta válida para sua situação!
Não culpe as pessoas – culpe o sistema!
Quando alguém diz “esta equipe não funciona corretamente”, temo que talvez não tenham identificado a origem exata do problema. Será porque os membros da equipe têm problemas de multitarefa entre as histórias dos usuários e os defeitos? É porque seu gerente não está estabelecendo a prioridade correta com frequência suficiente? Há políticas explícitas definidas sobre como eles devem selecionar o trabalho que fazem no dia-a-dia? Eles compreendem o impacto de não atender à demanda de valor suficiente (histórias de usuários ou novas funcionalidades) enquanto gastam todo o seu tempo com a demanda de falhas (defeitos)?
Outro aspecto é – por que existem tantos defeitos, em primeiro lugar? Que práticas de engenharia e automação precisam ser implementadas para reduzir o número total de bugs e melhorar a qualidade do código? Se você não está fazendo um desenvolvimento orientado a testes e insistindo na automação de todos os casos de teste, incluindo todos os defeitos encontrados, talvez isso seja algo que você precise implementar primeiro.
Estas são algumas questões de alto nível que precisam ser abordadas para que a equipe “trabalhe corretamente”.
Na Digité, nos últimos 15 anos, tentamos múltiplas abordagens para manter as equipes motivadas, tomar posse de seus produtos e entregar em uma base consistentemente previsível – tanto do ponto de vista do cronograma como da qualidade. Nossa crença é que não só não é justo fazer com que uma equipe trabalhe apenas com defeitos enquanto outra equipe trabalha em todas as coisas novas e legais, como também é uma má prática de gerenciamento/engenharia. Uma equipe precisa possuir o produto (ou alguma parte dele, dependendo do tamanho total) e trabalhar totalmente nele – tanto nas novas funcionalidades quanto nos defeitos. Isto lhes dá a propriedade total do produto – e eles nadam ou afundam com ele. Isto lhes dá um conhecimento muito melhor do código para entender por que e onde os defeitos estão ocorrendo e o que pode estar causando. E bem administrado, faz com que tenham muito mais orgulho do seu trabalho e da sua mão-de-obra.
Nem Scrum OU Kanban. Scrum e Kanban!
Em vez de tentar decidir “Kanban ou Scrum?”, eu recomendaria, de fato, que você aplicasse Kanban em cima de suas práticas atuais de Scrum. Essa é a definição fundamental de Kanban. Não é um substituto do Scrum, mas uma forma de melhorar quase todo processo que você possa estar utilizando. No caso do Scrum, muitas pessoas chamam a mistura resultante de Scrumban. Aplique isso em seus processos atuais para identificar gargalos e problemas – e resolva esses problemas.
Apenas para compartilhar nossa abordagem, temos uma situação um pouco semelhante à sua. Temos 3 produtos diferentes, e temos equipes de produtos que possuem cada um e fazem todo o trabalho – novas funcionalidades e correção de defeitos – para seus produtos. Não somos uma oficina Scrum, e sim temos um período de 4-5 semanas razoavelmente bem definido, no qual fazemos novos lançamentos. Utilizamos nosso próprio produto para gerenciar nosso roadmap e nosso trabalho de desenvolvimento. O Roadmap é gerenciado em um quadro Kanban “upstream”, onde fazemos nossos temas -> épicos -> decomposição de histórias de usuários para o quadro “downstream” de Desenvolvimento. Todos os defeitos ou relatados pelo Suporte/Clientes OU encontrados internamente durante revisões de código, execuções de automação ou validação manual são diretamente registrados na coluna Pronto do quadro de Desenvolvimento. Espera-se que o diagrama abaixo lhe dê uma imagem completa.
À medida que os membros da equipe terminam o que estão trabalhando atualmente (Kanban desestimula o multitarefa), eles pegam novos trabalhos da fila Ponto com base na prioridade que é discutida na Daily todos os dias. É claro, defeitos críticos ou de alta prioridade têm prioridade sobre tudo o resto. Entretanto, tentamos garantir que sempre haja uma boa mistura de novas funcionalidades sendo trabalhadas também.
Tentamos equilibrar entre um calendário de lançamento previsível e o tamanho geral do lote para manter as coisas gerenciáveis. Todas as novas funcionalidades e correções de bugs são implantadas em um servidor interno de preparação contínua – e este é nosso “servidor de produção interno” onde executamos todas as outras funções, incluindo suporte e marketing, etc. – o que é uma ótima maneira de identificar quaisquer erros que possam escapar (quase zero) e quaisquer problemas de usabilidade. E, como eu disse, implantamos uma versão SaaS a cada 4-5 semanas, com todo o trabalho concluído nesse tempo.
Eu recomendaria que você experimentasse isto para analisar sua situação geral e usar Kanban efetivamente para descobrir todos os gargalos de seu processo para uma melhoria geral gradual em sua operação. Isso seria ótimo para a moral e produtividade de sua equipe. Isso pode significar fazer o seguinte –
- Estudar o padrão geral de demanda em sua equipe e decidir se você trabalha com um quadro de Desenvolvimento – ou se você também usa um quadro upstream para lidar melhor com o trabalho recebido com seus stakeholders.
- Definindo um fluxo de trabalho que reflita a maneira como sua equipe trabalha e mapeando todas as etapas do fluxo de valor, para que você possa estudar completamente quais destes podem ser gargalos, e por que sua equipe está gastando tanto tempo com defeitos. A métrica de eficiência do fluxo de trabalho do Kanban destaca o tempo de espera que é construído em todos os nossos fluxos de trabalho – seja entre as transferências ou a espera de entrada externa ou outras questões do gênero!
- Definindo limite de WIP em sua fila Pronto para diferentes tipos de trabalho (histórias de usuários vs. defeitos) para que certa capacidade seja sempre dedicada a novas funcionalidades.
- Observe seus processos de desenvolvimento e opções de automação para reduzir os níveis gerais de defeitos.
Estes são apenas pontos iniciais – você, é claro, tem um quadro muito mais detalhado de sua situação! À medida que a equipe começa a analisar seu processo regularmente, surgirão diferentes soluções que você precisará experimentar.
—
Se você está administrando uma equipe de suporte de aplicação e já enfrentou situações semelhantes, eu adoraria saber que tipo de soluções você já tentou e quais funcionaram!
Mahesh Singh
Co-fundador, Treinador/Coach Kanban Credenciado
Minha resposta foi originalmente postada em resposta a uma pergunta aqui –
https://pm.stackexchange.com/questions/23245/scrum-for-kind-of-application-support-team/23260#23260
