Desenvolvimento versátil com Scrum

Hoje vou escrever sobre a equipe de desenvolvimento no Scrum. Este artigo faz parte de uma série, sendo assim recomendo que leia os artigos anteriores, caso não tenha acompanhado. São eles: Scrum no Burndown, Product Owner Dita as Regras e Scrum Master: “Agile Man”.

O grupo de profissionais de tecnologia encarregados de entregar um produto utilizável e que potencialmente incrementa o produto “pronto” ao final de cada Sprint, é chamado de Equipe ou Time de Desenvolvimento.

Somente estes integrantes podem criar incrementos, sendo estruturados e autorizados pela organização para elaborar e gerenciar seu próprio trabalho. Esta sinergia gerada pelo grupo aumenta a eficácia do trabalho como um todo.

Imagem via Shutterstock

A equipe deve ser pequena o bastante para se manter ágil, sem burocracias e grande o suficiente para completar o trabalho dentro dos limites da Sprint de maneira autônoma. Sugere-se uma equipe não menor do que 3 integrantes e nem maior do que 9 integrantes. Equipes muito pequenas podem encontrar restrições de habilidades, criando obstáculos para entregar o produto. Equipes muito grandes exigem muita coordenação e acabam se tornando burocráticas demais para atender o conceito ágil. O Product Owner e Scrum Master não fazem parte da contagem de integrantes da equipe de desenvolvimento.

Caracterizando a Equipe

Vou conceituar a Equipe de Desenvolvimento, segundo o que determina o Scrum, mas quero me adiantar a respeito das customizações que sempre podem ser feitas para ajustar um detalhe ou outro às necessidades de cada empresa. Esta é uma das maiores vantagens que vejo no Scrum.

Auto-gerenciáveis. Ninguém (nem mesmo o Scrum Master) interfere em como a Equipe de Desenvolvimento interpreta o Product Backlog em incrementos de funcionalidades potencialmente utilizáveis. A elaboração do Product Backlog foi de responsabilidade do Product Owner, portanto, tudo o que é necessário para atender o projeto está devidamente listado e, em alguns casos, priorizado. Eventuais esclarecimentos serão feitos através dos Eventos Scrum que vou explicar em detalhes ainda neste artigo;
Multifuncionais. Possuem todas habilidades necessárias para criar um incremento funcional do produto. Sendo assim, tratando-se de desenvolvimento de sistemas, a equipe deve possuir membros que detenham os conhecimentos para analisar, arquitetar, programar, modelar, testar, apresentar e homologar;
Não existem títulos para os profissionais. Isto significa que não há distinção entre os profissionais da Equipe. Em outras palavras, não existe o DBA, programador, arquiteto, analista ou qualquer outro papel. Todos são Desenvolvedores e igualmente responsáveis pela entrega do incremento utilizável dentro da Sprint. É o que mantém a unicidade da Equipe;
Não contém subequipes. Conceitualmente não há uma divisão de tarefas dentro da Equipe de Desenvolvimento. Todos devem ter as mesmas capacidades e independência para realizar uma tarefa do início ao fim. Isto garante a entrega do incremento sem depender de um indivíduo. Este é um conceito onde abro uma discussão adiante, mas, por hora, vamos nos manter na esfera conceitual.

Customizações aceitáveis na Equipe

Muito bem, acima conceituamos a Equipe de Desenvolvimento, segundo o que determina o Scrum. Agora vamos situar com a nossa realidade nas carreiras de TI.

Sabemos que aplicar integralmente o conceito dos dois últimos itens seria praticamente impossível dentro da árvore de especializações existente em TI. Muitos projetos implicam em questões de infraestrutura, abordam bancos de dados extremamente complexos, requer especialidades Geo-espaciais e assim por diante. Sendo assim, com as experiências obtidas durante as implantações, existem algumas formas de lidar com estas questões.

Equipe de Desenvolvimento Dinâmica: a formação da Equipe será de acordo com o contexto técnico exigido pelo Product Backlog ou até mesmo por uma Sprint específica. Neste caso, a equipe é composta por membros fixos e membros que serão incorporados à Equipe quando uma especialidade for requisitada. Este dinamismo deve ser conduzido de maneira transparente e organizada, procurando concentrar a utilização do especialista em um período previamente determinado (1 Sprint, 4 Sprints ou até mesmo por todo Product Backlog). Este especialista pode até mesmo ser um profissional terceirizado, contratado temporariamente para colaborar ou ser um especialista da própria organização que presta suporte a todas as equipes;
Equipe de Desenvolvimento Dedicada: a Equipe é formada por profissionais especialistas em uma determinada área de negócios da organização e somente atendem demandas desta área. A Equipe é planificada pela expertise e composta por diferentes especialistas técnicos afim de manter sua autonomia. Organizações grandes tendem a adotar esta prática e criam Equipes dedicadas à Controladoria, Finanças, Vendas e nichos muito específicos como Logística, Rastreamento, Seguro Vida, Seguro Auto, Seguro Saúde e assim por diante;
Equipe Especialista: na minha opinião é a prática mais difícil de ser aplicada no Scrum mas, infelizmente, em algumas organizações onde a resistência é muito grande, antes de condenar o Scrum, torna-se uma alternativa válida. As equipes são formadas de acordo com sua capacitação técnica, ou seja, existe uma passagem de bastão de tarefas entre as equipes dentro de um único Sprint. Sim, isto mesmo, Sprint dentro de outro Sprint. Um exemplo clássico é quando a organização tem a cultura de centralizar todas as solicitações relacionadas a banco de dados das equipes de desenvolvimento de sistemas para o setor de Administração de Dados. Não abrem mão nem mesmo para o ambiente de desenvolvimento e isto torna todo o trabalho menos ágil. Então criamos a Equipe de AD, Equipe de Testes, Equipe de Infraestrutura e Equipes de Desenvolvimento, por exemplo. O Sprint principal é da Equipe que se relaciona com o Product Owner (Equipe de Desenvolvimento) que faz solicitações para as demais equipes que, por sua vez, têm seus próprios Sprints para atender as solicitações de todas Equipes de Desenvolvimento. Na minha opinião é uma bagunça “organizada” e muito instável, podendo levar o Scrum ao caos. Considerando que o Scrum trabalha com estimativas, uma equipe sempre vai interferir no andamento da outra, comprometendo o Sprint Backlog.

Neste último caso o Scrum Master é sobrecarregado porque precisa garantir que o Scrum seja aplicado e mantido em todo o processo. Algumas vezes a organização opta em implementar mais de um Scrum Master, aumentando o quadro de gerenciamento do processo que acaba se tornando complexo demais, burocrático e nada ágil.

O cenário que mais me agrada e que se adapta melhor à TI, sem dúvida é o cenário que gastei menos linhas para explicar! Sim, vejam que fica simples trabalhar com o cenário 2 e, quando necessário, trabalhar com o cenário 1 é uma boa e funcional alternativa.

Sprint e seus Eventos

Todo o trabalho da Equipe de Desenvolvimento é realizado dentro de uma Sprint.

Sprint é um time-boxed de um mês ou menos, dependendo das necessidades do projeto. Uma Sprint nunca deverá ser prorrogada ou antecipada, uma vez determinada sua duração. É o coração do conceito Scrum e permitir alterações em durações de uma Sprint implica em remeter o Scrum ao cenário caótico existente antes da sua implantação, ou seja, não justificaria sua própria existência.

Iterações mais dinâmicas e eficientes acontecem com Sprints semanais e quinzenais (mais complexas). Caso haja algum imprevisto que impeça a entrega dentro do período determinado, vale diminuir o escopo da Sprint em comum acordo com o Product Owner e garantir uma entrega funcional, se possível. Exceto quando não houver mais sentido na entrega por mudanças das regras pela organização, mudanças de mercado ou algo semelhante que torne o produto a ser entregue obsoleto.

Quanto maior for o período da Sprint, maior será a probabilidade de mudar a definição, aumentar a complexidade e, consequentemente, o risco. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês, ou seja, quanto menor a Sprint, menor será o risco de amargar o custo de um insucesso.

Somente o Product Owner pode cancelar uma Sprint. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens incompletos são reavaliados e colocados de volta no Product Backlog.

Planejamento da Sprint

Configura-se por uma reunião com todo o Time Scrum. Quando me refiro ao Time Scrum, digo Product Owner, Scrum Master e Equipe de Desenvolvimento.

Esta reunião tem um time-boxed de 8 horas ou 1 dia de trabalho para uma Sprint de 30 dias. Proporcionalmente, este evento é menor para Sprints mais curtas. Basicamente ocorre nesta reunião:

Product Owner expõe as necessidades da área de negócios, esclarece dúvidas da Equipe de Desenvolvimento e propõe um objetivo;
Equipe de Desenvolvimento discute o que pode ser entregue e realiza um prévio levantamento dos requisitos funcionais e técnicos;
Scrum Master garante o entendimento entre as partes dentro do tempo estipulado;
Equipe de Desenvolvimento levanta eventuais dificuldades para que o Scrum Master seja o mediador das soluções;
É determinado o escopo da próxima Sprint a ser executada.

São considerados nesta reunião Product Backlog, o mais recente incremento do produto e a capacidade da Equipe de Desenvolvimento através do último desempenho. Diante da proposta do Product Owner, a Equipe de Desenvolvimento seleciona os itens do Product Backlog a serem desenvolvidos, estabelecem a meta a ser cumprida e o que define o produto como “pronto” junto ao Product Owner.

Vale ressaltar que não existe uma métrica que determine, com exatidão, o que será realizado neste período. Scrum trabalha com estimativas baseadas no desempenho da Equipe de Desenvolvimento, entendimento do escopo e prioridades do Product Owner. Quando trabalhamos com estimativas, existe uma margem de erro aceitável que pode variar em 1 dia ou até 2 dias, se a Sprint for entregue completa. O valor da entrega completa é muito maior, pois trata-se de um incremento utilizável, ou seja, poderá ser colocado em produção imediatamente após a entrega.

Reunião Diária

É um evento time-boxed de 15 minutos para que a Equipe de Desenvolvimento sincronize as atividades das próximas 24 horas. Normalmente é mantida no mesmo horário e local para facilitar a realização do evento. Basicamente são colocadas as seguintes questões:

O que eu fiz ontem para contribuir com a Equipe no atendimento da Sprint?
O que eu farei hoje para contribuir com a Equipe no atendimento da Sprint?
Vejo algum obstáculo que impeça a mim ou a Equipe no atendimento da Sprint?

É uma inspeção diária do progresso em direção ao atendimento da Sprint. Este evento melhora a probabilidade de identificar eventuais desvios e permite correções pontuais sem perda de tempo significativa.

Somente integrantes da Equipe de Desenvolvimento participam da reunião diária (e, eventualmente, o Scrum Master), garantindo que todos estejam a par do andamento por igual e permite rápidas tomadas de decisão para garantir o cumprimento da meta.

Reuniões com o Product Owner podem ser requisitadas ao Scrum Master que promoverá o evento, mas não se pode misturar com a reunião diária.

Revisão da Sprint

Esta é uma reunião time-boxed de 4 horas para uma Sprint de 30 dias. Proporcionalmente, este evento é menor para Sprints mais curtas.

Todo o Time Scrum está presente para uma apresentação informal do produto a ser entregue. A apresentação do incremento destina-se a motivar, obter comentários e promover a colaboração, considerando os seguintes elementos:

Além do Time Scrum, podem participar Stakeholders que o PO considere importantes;
Equipe de Desenvolvimento apresenta o trabalho que está considerado “pronto” pelos requisitos do PO;
PO esclarece os itens “prontos” e quais não foram “prontos”, além de apresentar implicações, quando for o caso;
Equipe de Desenvolvimento expõe eventuais dificuldades obtidas durante a Sprint e discute como isso pode ser evitado na próxima Sprint;
PO discute Product Backlog e projeta prováveis datas de conclusão baseado no progresso até a data (se necessário);
Todo o grupo colabora para extrair dados que irão sugerir a próxima Sprint Backlog.

Esta não é uma reunião para discutir detalhes técnicos, mas para avaliar como foi o andamento da atual Sprint, obter informações importantes para a próxima Sprint e também exaltar o valor agregado do produto entregue.

Retrospectiva da Sprint

Esta é uma reunião time-boxed de 3 horas para uma Sprint de 30 dias. Proporcionalmente, este evento é menor para Sprints mais curtas.

Ocorre após a Revisão da Sprint e antes da Reunião de Planejamento da próxima Sprint. É uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na próxima Sprint. O propósito da Retrospectiva é:

Avaliar como foi a relação entre as pessoas envolvidas, processos utilizados e eficiência das ferramentas aplicadas;
Identificar e ordenas os itens positivos e possíveis melhorias;
Criar um plano para implementar as melhorias no modo que o Time Scrum faz o trabalho.

Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto, adaptando a definição de “Pronto” quando apropriado.
Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima Sprint. A Retrospectiva da Sprint fornece um evento dedicado e focado na inspeção e adaptação, no entanto, as melhorias podem ser adotadas a qualquer momento.

Minha conclusão sobre os Eventos

Inicialmente você pode achar que são Eventos (reuniões) redundantes, mas cada um tem foco muito específico. Todos eventos são importantes para que a organização aprenda a trabalhar da melhor maneira com o Scrum, modelando cada etapa às necessidades, cultura e exigências de qualidade da própria organização. Com o tempo, as pessoas adquirem experiência e lidam com o processo mais facilmente, podendo até mesmo unir Revisão e Retrospectiva em um único evento. Equipes mais experientes fazem isso com muita naturalidade.

Planejamento e Reunião Diária são sempre necessários ao processo. A Revisão pode ser feita em conjunto com a Retrospectiva quando o Time Scrum atinge sua maturidade no processo, pois a Revisão é importante para tratar eventuais problemas na entrega da Sprint, enquanto que a Retrospectiva é focada no levantamento dos pontos positivos e implementação de melhorias no processo. Por isso costumo unir estes eventos quando o Time Scrum já adquiriu experiência suficiente para tratar tudo em uma única reunião. Isso otimiza ainda mais o tempo e torna o processo mais ágil.

Eu havia prometido falar a respeito das ferramentas neste artigo, mas acabei me estendendo além do que imaginei. Vou deixar as ferramentas e artefatos para um artigo exclusivo que nos permitirá uma abordagem mais detalhada sem causar cansaço na leitura.

Abraço e até o próximo artigo!

Publicado Originalmente em: Blog Andrey Kurka