# Scrum e trabalho em equipa Responsabilidades, objetivos, artefactos, eventos e padrões para entregar incrementos úteis. Página: https://resumos.rgo.pt/cadeiras/es/scrum/ 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](https://resumos.rgo.pt/cadeiras/es/gestao-projetos/#velocidade-e-previs%C3%A3o). 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](https://resumos.rgo.pt/cadeiras/es/padroes-scrum/), com a origem no livro de padrões e a relação com a comunicação da equipa. ## Exercícios Um botão terminado A história mostra o botão pedido e satisfaz o seu cenário principal. A Definition of Done exige testes de autorização, que falham. Pode integrar o incremento como Done? Pista Compara critérios da história com critérios comuns de qualidade. Solução Não está Done. No Sprint acompanhado, a história de consulta ficou neste estado: cenário principal passa, teste de autorização falha. A equipa precisa de corrigir a autorização e voltar a verificar. O comportamento específico e a Definition of Done complementam-se. * **Sim, porque satisfaz o cenário principal..** Os critérios específicos não substituem a qualidade comum exigida. * **Não, porque ainda não satisfaz a Definition of Done..** Um item tem de respeitar o comportamento acordado e o padrão de qualidade comum. * **Sim, se o Product Owner quiser mais pontos..** A qualidade não deve diminuir para fazer caber trabalho. Erros frequentes Não transformes Done numa decisão por votação que ignora critérios de qualidade. [Voltar à explicação](https://resumos.rgo.pt/cadeiras/es/scrum/#artefactos-e-objetivos) Um pedido a meio do Sprint O objetivo é confirmar reservas sem sobreposições. A meio do Sprint pedem fotografias nas salas. Como deve a equipa decidir? Pista O objetivo comum importa mais do que acrescentar um cartão. Solução A equipa esclarece valor e esforço com o Product Owner face ao Sprint Goal de confirmar sem sobreposições. Se fotografias ameaçarem a confirmação correta, ficam no Product Backlog para decisão futura. Pode ajustar o âmbito sem reduzir a qualidade. Trabalho incompleto regressa ao backlog e não transita automaticamente. Confere a tua resposta: * Avaliei o pedido face ao Sprint Goal e à capacidade. * Propus conversa entre Developers e Product Owner. * Mantive qualidade e possibilidade de adiar o pedido. Erros frequentes Não acrescentes trabalho automaticamente. Também não afirmes que qualquer alteração durante o Sprint é proibida. [Voltar à explicação](https://resumos.rgo.pt/cadeiras/es/scrum/#uma-altera%C3%A7%C3%A3o-durante-o-sprint)