Uma sprint é um período de tempo fixo durante o qual uma equipe de desenvolvimento trabalha em funcionalidades específicas de um projeto. Nesse texto iremos falar o básico sobre incrementos, artefatos e possíveis impedimentos na sprint.

Criando o incremento
O incremento no Scrum é a soma de todos os itens completados do backlog do produto durante uma sprint, junto com incrementos de sprints anteriores. Ele representa uma nova versão do produto com funcionalidades adicionadas, sendo revisado em reuniões de revisão da sprint para fornecer valor aos stakeholders. O incremento deve obrigatoriamente atender à definição de pronto, garantindo que esteja alinhado aos padrões de qualidade estabelecidos pelo time Scrum. Além disso, é essencial que os desenvolvedores possam autogerenciar seu trabalho, decidindo como realizar suas tarefas de maneira eficaz.

Radiadores de informação
Os radiadores de informação são ferramentas visuais fundamentais para a gestão ágil de projetos, criados por Alistair Cockburn para promover a transparência e facilitar a comunicação entre equipes e stakeholders. Esses artefatos são expostos em locais visíveis, como paredes, e incluem elementos como Scrum Task Boards, gráficos de burndown, registros de riscos, métricas de velocidade e mais. Eles permitem uma visão panorâmica das atividades, eventos e progressos do projeto, garantindo que todos tenham acesso fácil às informações necessárias para tomadas de decisão informadas e para manter o alinhamento contínuo entre os envolvidos.

Scrum board
O Scrum Board, derivado do Kanban, é uma ferramenta essencial no método ágil para visualizar e gerenciar o progresso das tarefas do backlog do produto. Organizado em colunas customizáveis como "A Fazer", "Em Andamento" e "Pronto", permite que o time acompanhe visualmente o estado atual de cada item. A prática de limitar o trabalho em andamento ajuda a manter o foco e a concentração, garantindo que poucas histórias sejam iniciadas de uma vez e todas sejam concluídas antes de novas começarem. Além das colunas principais, o quadro pode incluir elementos como gráficos de burndown, metas da Sprint, backlog de impedimentos e raias específicas para diferentes tipos de trabalho. Essa estrutura promove a transparência, a eficiência e facilita a gestão ágil do projeto.

Daily scrum meeting
A reunião diária do Scrum, também conhecida como Daily Scrum, é uma prática essencial para acompanhar o progresso e planejar as atividades do time nas próximas 24 horas. Realizada com um timebox de 15 minutos, esta reunião visa otimizar a colaboração e a performance ao revisar o trabalho desde a última reunião e identificar os próximos passos. Os desenvolvedores respondem a perguntas como "O que eu fiz desde a última reunião?", "O que farei até a próxima reunião?" e "Quais são os impedimentos?". É uma reunião exclusiva para o time de desenvolvimento, embora o Dono do Produto e o Scrum Master possam participar se também forem desenvolvedores. Após a reunião, os membros frequentemente se reúnem para discussões detalhadas ou replanejamento. Essa prática melhora a comunicação, identifica impedimentos, promove decisões rápidas e mantém o progresso da Sprint transparente.

Como atualizar o andamento do projeto?
A atualização do andamento do projeto no Scrum pode ser realizada através do quadro de tarefas durante a reunião diária. Cada membro da equipe descreve o que foi feito desde a última reunião e o que planeja fazer até a próxima, adicionando post-its para novas tarefas ou atualizando estimativas de prazo conforme necessário. Alguns times têm o Scrum Master fazendo essas atualizações, enquanto outros preferem que cada pessoa atualize o quadro antes da reunião. Após a reunião, o progresso é visivelmente registrado no quadro, e é crucial atualizar diariamente o gráfico de burndown para manter a transparência do progresso da Sprint. A rastreabilidade pode ser melhorada tirando fotos diárias do quadro de tarefas, embora seja importante avaliar o valor real dessa prática para o projeto.

Impedimentos
impedimentos no contexto do Scrum são necessidades que o time não pode resolver autonomamente. O Scrum Master é responsável por remover esses impedimentos para garantir o fluxo contínuo do trabalho. É crucial que o time identifique corretamente o que constitui um impedimento real, pois muitas vezes problemas podem ser resolvidos internamente pela equipe sem necessidade de intervenção externa. Exemplos comuns de impedimentos incluem falta de dispositivos para testes, problemas com equipamentos, ambiente de trabalho inadequado, indisponibilidade do Product Owner, interrupções por parte da gerência, entre outros. A prática comum é adicionar uma coluna de impedimentos ao quadro de tarefas para rastrear e resolver esses problemas de forma transparente e eficiente.

Bugs x Backlog do produto
Para controlar erros reportados no incremento liberado, duas estratégias principais podem ser utilizadas:
1. Incluir bugs no backlog do produto: O Product Owner cria histórias de usuário para bugs, priorizando os mais graves para serem tratados na reunião de planejamento da Sprint. Eles são tratados como qualquer outra história do backlog.
2. Alocar tempo específico fora da Sprint para correção de bugs: Neste caso, parte do tempo da equipe é reservado para correções, sem comprometer todo o tempo no desenvolvimento de novos itens. Pode-se reservar horas semanais para correções ou até alocar pessoas dedicadas exclusivamente para essa tarefa.

A escolha entre essas estratégias depende das necessidades específicas da equipe e das demandas do projeto em cada Sprint.

Débito (dívida) técnica

Débito técnico refere-se a implementações ou soluções que não foram realizadas da melhor forma dentro do trabalho esperado. Isso pode incluir falta de cobertura de testes, componentes incompletos, falta de padronização de código, entre outros problemas. As causas para acumular débito técnico podem incluir decisões como design antecipado, sacrificar qualidade para cumprir prazos, implementar funcionalidades não previstas, falta de conhecimento técnico, complexidade do projeto, escolha inadequada de tecnologia, entre outros fatores.

A dívida técnica pode ser classificada em quatro quadrantes: consciente e intencional (sabe-se do problema, mas não se resolve), imprudente e intencional (decide-se deliberadamente deixar o problema para depois), imprudente e não intencional (não se percebe o problema até que seja tarde demais), e consciente e não intencional (agora se reconhece que poderiam ter sido tomadas decisões diferentes). O ideal é minimizar a dívida técnica, preferencialmente mantendo-a nos quadrantes onde há consciência dos riscos assumidos.

Escaped defect
Também conhecido como defeito que escapou, refere-se aos problemas de software que passam pelos processos de teste e controle de qualidade da equipe e são descobertos pelos clientes ou usuários finais. Esses defeitos podem prejudicar a confiança do cliente no fornecedor de software e são geralmente encontrados fora das etapas planejadas de validação. É crucial implementar mecanismos para analisar e mapear esses defeitos, além de adotar estratégias como testes unitários, testes integrados, automação e técnicas do TDD (Test-Driven Development) para minimizá-los no futuro. Essas estratégias geralmente são aplicadas durante a definição de pronto do software.

Integração contínua e refatoração
A integração contínua envolve integrar automaticamente partes de um projeto o mais frequentemente possível, geralmente a cada uma ou duas horas. Isso permite detectar falhas de integração rapidamente, em vez de esperar até o final do projeto (método cascata, Big Bang). É fundamental ter um sistema de controle confiável para gerenciar essas liberações, pois muitas vezes elas vão diretamente para o cliente. As vantagens incluem facilitar a entrega de incrementos reais ao final das iterações ou sprints e evitar problemas de integração de última hora.

A refatoração é o processo de revisar o código para melhorar sua estrutura interna sem alterar seu comportamento externo. O objetivo é manter o código limpo e bem estruturado, o que facilita sua manutenção futura. Essa prática também ajuda a reduzir o débito técnico ao dedicar tempo para melhorar continuamente a qualidade do código.

No próximo e último texto da série sobre o gerenciamento de projetos ágeis iremos abordar sobre como é possível monitorar o progresso e como entregar um incremento para o projeto.