GCC244-sobre-organização (3)

Prévia do material em texto

ROTEIRO DE ESTUDOS ORIENTADOS – REO 
GCC244 – Processos de Software 
Profa. Renata Moreira 
ANEXO I – SOBRE A ORGANIZAÇÃO 
- A organização possui um conjunto de produtos que são mantidos e evoluídos. 
- A organização conta com 2 equipes de desenvolvimento: Front-End e Back-End. Cada equipe 
possui 5 desenvolvedores. Além disso, há uma equipe dedicada para atividades de teste de 
integração de sistema, e de regressão. 
- A organização adota a metodologia de desenvolvimento Scrum. 
- É mantido um “Product Backlog” que contém todas as atividades (Histórias de Usuário) 
planejadas para o desenvolvimento do sistema. Estas atividades são categorizadas em: Novas 
Funcionalidades, Melhorias, Correções. 
- As sprints têm duração de 15 dias úteis. 
- O primeiro dia é destinado a Sprint Planning, onde são selecionadas as histórias que irão compor 
o “Sprint Backlog”. Cada história selecionada é dimensionada usando Planning Poker, e o total 
de pontos somados das histórias selecionadas para a sprint determina a “Velocidade Planejada da 
Sprint”. 
- Cada história é decomposta em tarefas de Back-End e Front-End. 
- O último dia da Sprint é dedicado às cerimônias de Sprint Review e Retrospectiva. Na Sprint 
review, os times apresentam o incremento do produto gerado durante a sprint para validação pelo 
Product Owner. As histórias aprovadas, têm seu estado mudado para “Done”. As histórias não 
concluídas ou que não foram aprovadas pelo Product Owner, retornam para o backlog do produto 
para serem replanejadas em próximas sprints. O total de pontos de histórias concluídas com 
sucesso determina a “Velocidade da Sprint”. 
- Durante a sprint, os times de Front-End e Back-End trabalham de forma coordenada para 
desenvolver as histórias. Conforme as histórias são concluídas, estas são integradas ao produto 
para testes de integração, de sistema e de regressão. 
- Para que uma história possa ser apresentada ao Product Owner durante a sprint review, esta 
deve atender a “definição de pronto” da organização, que determina que a história deve: estar 
totalmente implementada (todas as tarefas relacionadas estão concluídas); testes de unidade estão 
disponíveis; foi aprovada em teses de integração, de sistema e de regressão; e deve estar 
devidamente integrada ao produto. 
Problemas e necessidades da organização: 
- Há necessidade de avaliar a produtividade da organização ao longo do tempo. 
- Há necessidade de avaliar a produtividade de cada equipe. 
- Há necessidade de avaliar o aproveitamento de cada sprint, i.e., o comparativo entre a 
Velocidade Planejada e a Velocidade da Sprint. 
- Durante as sprints, surgem tarefas urgentes que não foram planejadas para o Sprint Backlog. 
Isto implica em priorizar estas novas tarefas em detrimento de algumas histórias do Sprint 
Backlog. E como estas tarefas não são dimensionadas (logo não têm Pontos de História 
associados), a Velocidade da Sprint é prejudicada e não reflete o real esforço da equipe. É 
interessante saber a frequência e quantidade destas tarefas não planejadas e o quanto elas 
interferem no planejamento. Também é desejável a definição de regras para as mudanças no 
escopo da sprint. 
- Hoje não há uma maneira objetiva de avaliar quais produtos demandam mais esforços da 
organização. 
 
ROTEIRO DE ESTUDOS ORIENTADOS – REO 
GCC244 – Processos de Software 
Profa. Renata Moreira 
- Hoje não há mecanismos para determinar as histórias que não foram concluídas em uma única 
sprint. Isto causa anomalias no histórico de velocidade da equipe. Além disso, conhecer este tipo 
de dado seria um bom parâmetro para avaliar a eficácia do dimensionamento das histórias. 
- Várias histórias que não atendem a definição de pronto são erroneamente levadas para a Sprint 
Review, gerando esforço desnecessário e prejuízo a moral da equipe. 
- Muitos problemas de conflito e perda de dados acontecem por conta da (falta de) estratégia 
durante a integração do código produzido pelas equipes de Back-End e Front-End, e durante a 
integração de novas funcionalidades ao produto para as atividades da equipe de testes. 
- Não há uma estratégia eficaz para mapear os releases do sistema, de forma que não se sabe em 
que versão um problema surgiu, ou que novas funcionalidades, melhorias e correções foram 
introduzidas. 
- Há necessidade de saber a qualidade do produto em termo de bugs encontrados, no entanto não 
há dados sobre quais bugs foram detectados interna ou externamente. 
- Há necessidade de comparar o esforço da organização em relação a atividades de 
desenvolvimento de novas funcionalidades, correções e melhorias. Além disso, fazer um 
comparativo entre esforço gasto em desenvolvimento, esforço gasto em atividades de teste e 
quantidade de bugs encontrados interna e externamente.