Scrum e trabalho em equipa

A equipa quer que um estudante consiga garantir uma sala livre. Tem duas semanas e mais histórias do que consegue concluir. Scrum organiza o trabalho em Sprints, intervalos fixos de um mês ou menos, com um objetivo comum e um incremento utilizável. No fim, a equipa inspeciona o resultado com os interessados e adapta o trabalho seguinte.

Transparência, inspeção e adaptação

Scrum usa decisões baseadas no que se observa. O estado do trabalho tem de ser compreensível, a equipa tem de o inspecionar e tem de adaptar o plano quando necessário.

Um cartão marcado “concluído” que ainda não passou pelos testes esconde informação. Uma reunião diária que identifica um bloqueio mas não muda o plano produz observação sem adaptação. Compromisso, foco, abertura, respeito e coragem ajudam a comunicar problemas e a agir sobre eles. Os materiais da cadeira juntam a confiança a esta base: uma equipa que esconde problemas não fornece dados verdadeiros para inspecionar.

Responsabilidades da equipa

A Scrum Team reúne as competências necessárias para criar o incremento. É autogerida: decide internamente como organizar o trabalho.

• O Product Owner responde pelo valor do produto e pela gestão do Product Backlog. Ordena o trabalho e comunica o objetivo do produto, podendo colaborar com outros sem transferir a responsabilidade.
• Os Developers planeiam o Sprint, constroem um incremento utilizável, respeitam a Definition of Done e adaptam o trabalho diariamente.
• O Scrum Master ajuda a equipa e a organização a compreender e aplicar Scrum, melhora a eficácia da equipa e promove a remoção de impedimentos.

O Product Owner não escolhe unilateralmente a quantidade de trabalho que os Developers conseguem concluir. O Scrum Master não distribui todas as tarefas como um chefe de projeto. Os Developers incluem as pessoas necessárias para produzir o incremento, não apenas quem escreve código.

Artefactos e objetivos

O Product Backlog é a lista ordenada e evolutiva do trabalho necessário ao produto. O seu compromisso é o Product Goal, o objetivo de longo prazo que orienta as escolhas.

O Sprint Backlog junta o Sprint Goal, os itens escolhidos e o plano para os realizar. É um plano dos Developers e muda à medida que aprendem. O objetivo dá uma razão comum ao trabalho, por exemplo “permitir a um estudante garantir uma sala livre”.

O Increment é um passo utilizável em direção ao Product Goal. O seu compromisso é a Definition of Done, a descrição comum da qualidade necessária para considerar o trabalho concluído. Vários incrementos podem surgir durante um Sprint.

Na aplicação, a Definition of Done pode exigir testes das regras de reserva, revisão, integração e documentação atualizada. Os critérios de aceitação de uma história descrevem o seu comportamento específico. Uma história com o botão correto, mas que falha testes de segurança obrigatórios, não está Done: os dois têm de ser satisfeitos.

Estar Done não exige esperar pela Review para entregar. Um incremento pode ser disponibilizado antes do fim do Sprint. A Review serve para inspecionar e adaptar, não é uma autorização obrigatória para publicar.

Um quadro do projeto pode separar as colunas Done e Accepted para acompanhar o feedback do Product Owner. Essa convenção de gestão não substitui a Definition of Done, nem torna a aprovação do Product Owner um compromisso adicional do Scrum Guide. Da mesma forma, uma Definition of Ready pode ajudar a equipa a discutir se um item está suficientemente entendido para ser escolhido. É uma prática complementar, não um artefacto obrigatório de Scrum, e não deve impedir conversas nem transformar o backlog numa especificação totalmente fechada.

Eventos

O Sprint é o evento que contém os outros quatro. Um novo Sprint começa assim que o anterior acaba. Estes limites de duração, ou timeboxes, evitam adiar indefinidamente a inspeção.

Evento	Decisão ou aprendizagem pretendida
Sprint Planning	Por que vale a pena o Sprint, o que pode ficar Done e como o realizar
Daily Scrum	Adaptar o plano dos Developers para atingir o Sprint Goal
Sprint Review	Inspecionar o incremento com stakeholders e adaptar o futuro do produto
Sprint Retrospective	Melhorar a qualidade e a forma de trabalhar

Para um Sprint de um mês, o Planning dura no máximo oito horas, a Review quatro e a Retrospective três. Nos Sprints mais curtos, estes eventos costumam ser mais curtos. O Daily Scrum dura 15 minutos em qualquer duração de Sprint. É uma oportunidade para coordenar o próximo trabalho, não um relatório obrigatório ao Scrum Master. A Review também não é apenas uma apresentação de slides: usa o produto e informação relevante para decidir o que fazer depois. A Retrospective olha para o processo e a colaboração.

O refinamento do backlog esclarece, divide e estima itens conforme necessário, sem constituir um evento formal adicional de Scrum.

Um Sprint acompanhado do início ao fim

Acompanhamos um Sprint de duas semanas com o objetivo de permitir a um estudante garantir uma sala livre.

1. Planning. O Product Owner ordena o backlog. Os Developers escolhem reservar sala livre e consultar disponibilidade, considerando cerca de 20 pontos concluídos por Sprint recente, a disponibilidade das pessoas e os riscos de integração. A velocidade, trabalho concluído por iteração, é detalhada em gestão de projetos. Registam o plano no Sprint Backlog com responsáveis apenas quando o trabalho começa.
2. Execução e Daily. No dia três, a integração com a API de horários bloqueia a consulta. No Daily de 15 minutos, a equipa move duas pessoas para desbloquear esse item em vez de abrir mais cartões, concentrando ajuda para concluir um item em vez de começar trabalho novo. Atualiza o plano sem mudar o Sprint Goal.
3. Incremento. No dia oito, reservar sala livre cumpre critérios da história e Definition of Done: regra atómica no servidor, testes de sobreposição, revisão e documentação. Consulta cumpre os critérios funcionais mas falha um teste de autorização, por isso não está Done e não conta como incremento.
4. Review. A equipa demonstra a reserva com duas tentativas concorrentes, uma confirmada e uma recusada. O docente pede cancelamento antes do início. O Product Backlog recebe essa história nova e reordena prioridades.
5. Retrospective. A equipa regista que a espera por revisão atrasou a consulta. Decide experimentar revisão diária em par no próximo Sprint, com medida do tempo até à primeira revisão.

O Product Backlog muda com o feedback. O Sprint Backlog muda com a aprendizagem diária. O Increment só cresce com trabalho Done.

Uma alteração durante o Sprint

O Sprint Goal é “reservar uma sala sem criar sobreposições”. Surgem pedidos para adicionar fotografias e cores aos cartões. Os Developers e o Product Owner podem renegociar o âmbito, mas não devem introduzir uma mudança que ponha o objetivo em risco nem baixar a qualidade para fazer caber mais itens.

Se descobrimos que o cancelamento completo é demasiado grande, podemos adiar esse item e proteger a confirmação correta; o trabalho incompleto regressa ao Product Backlog para ser reconsiderado, sem contar como incremento Done nem passar automaticamente para o Sprint seguinte sem nova decisão. Só se o objetivo do Sprint se tornar obsoleto pode o Product Owner cancelar o Sprint; um desvio numa tarefa não torna essa decisão obrigatória.

Padrões de trabalho em equipa

Os comportamentos deste Sprint, equipa estável, itens pequenos, previsão pelo trabalho recente, ajuda concentrada para concluir, informação visível e melhorias com resultado observável, seguem padrões praticados na cadeira. Estão reunidos em padrões de trabalho em equipa, com a origem no livro de padrões e a relação com a comunicação da equipa.