Neste estudo foram abordados os capítulos 9 – 17 do livro “Scrum e XP direto das Trincheiras”.

O primeiro assunto abordado foi a apresentação do sprint, a equipe deve fazer a apresentação do Sprint de algo funcional, não se baseando apenas em telas e conceitos. A apresentação faz com que as equipes tenham motivação para terminar de forma mais rápida o sprint e que equipes diferentes possam interagir umas com as outras.

No caso da retrospectiva, ela é o segundo evento mais importante no Scrum, pois é quando as equipes discutem entre si o que pode ser melhorado nos outros sprints, para não cometer o mesmos erros, sugerindo assim melhorias. Deve ser evitado fazer a retrospectiva em ambiente de trabalho para que não ocorram interrupções.

Quando falamos de Intervalo de Sprint, significa um descanso natural entre os sprints. Esse descanso é chamado de “lab day” que são dias que os desenvolvedores podem fazer o que eles quiserem. Por exemplo, eles podem ler sobre as últimas versões de algumas ferramentas ou APIs, estudar para certificação, discutir temas técnicos com os colegas, participar de um projeto pessoal, etc.

O planejamento de release consiste em prever para o cliente um possível prazo de entrega. Quando surgir problemas deve-se reportar ao cliente, para que ele priorize os pontos mais importantes para que a equipe possa entregar no prazo. Sempre podemos negociar com o cliente. Se a realidade não se adaptar ao plano, então o plano deve adaptar-se à realidade.

Sobre combinar Scrum e XP (eXtreme Programming), podemos dizer que é uma coisa muito vantajosa pelas características do XP como: programação em par, TDD (desenvolvimento orientado as testes), Design Incremental, Integração Contínua, propriedade coletiva do código, Padrão de codificação, Rítmo Sustentável / Trabalho energizado. O Scrum é focado nas práticas de gerenciamento e organização, enquanto o XP dá mais atenção às tarefas de programação mesmo. Aí está o porquê de elas trabalharem bem juntas – elas abrangem áreas diferentes e uma complementa a outra.

Todas esta técnicas no início podem gerar desconforto em algum integrante da equipe, por isso não deve ser nada imposto, deve ser respeitada a opinião de todos.

Como saber que um Sprint está pronto? O Tester é quem dirá que o sprint está finalizado pois ele irá verificar se todas as histórias foram finalizadas e se realmente estão funcionando. Deve-se evitar que o próprio desenvolvedor faça o teste de software, pois frequentemente dizem que algo está pronto quando na verdade não está.

Outra coisa produtiva seria não colocar muitas estórias em um Sprint, pois isso torna-o desgastante, é necessário sempre certificar que será entregue no prazo combinado. Quando uma equipe começa a praticar Scrum é normal os erros e as dificuldades de adaptação do membros da equipe é interessante subdividir as equipes no início da prática até que todos se sintam confortáveis e possam se adaptar facilmente. Com o tempo, as equipes ficarão unidas, tornando-se produtivas.

Embora a prática Scrum diga que o time deve estar sempre junto no mesmo local, nada impede de que a equipe esteja separada geograficamente.  O time deverá decidir a frequência que irão trabalhar a distância (em suas casas ou em outro local). Quando isso ocorrer as reuniões poderão ser feitas através de comunicadores online como o skype por exemplo.

Como disse o próprio autor:

Em geral, pessoal trabalhando em casa não foi realmente um problema para nós.

Voltaremos com o grupo de estudo em fevereiro!

Desejamos a todos um Feliz Ano Novo! Sucesso, saúde e paz!