6. Framework de desenvolvimento para Windows Phone 8
6.1. Metodologia de trabalho a adotar
6.1.2. Development (2)
A Figura 49 apresenta a segunda fase do Scrum, denominada por Development.
Figura 49 Ciclo de vida da fase Development
Esta fase é elaborada por várias sprints com duração de duas semanas, em que cada uma delas é constituída por quatro fases bem distintas:
Product Backlog
Development (2)
Planning Meeting (2.1) Sprint Review (2.3) Sprint Retrospective (2.4) Um dia de trabalho (2.2)Sprint
106
Uma Planning Meeting (2.1);
Vários dias de trabalho (2.2);
Uma Sprint Review (2.3) para demonstração do trabalho desenvolvido;
Uma Sprint Retrospective (2.4).
A primeira sprint deverá ter uma duração maior, de modo a estabelecer a baseline da arquitetura.
As ferramentas necessárias nesta fase do desenvolvimento do projeto encontram-se detalhadas no capítulo 6.2.1.
6.1.2.1. Planning Meeting (2.1)
A primeira reunião de toda a equipa da segunda fase do Scrum denominada por Planning Meeting, deverá ser aproximadamente de quatro horas onde deverá ser para planear as tarefas oriundas das User Stories do Product Backlog previamente priorizadas pelo Product Manager, Product Owner, Scrum Master e business analyst na reunião Backlog Grooming.
De modo a que o planeamento das tarefas seja mais eficiente, deverá ser alimentado pela técnica denominada por Planning Poker.
Como apresentado na Figura 50, todas as tarefas devem ser planeadas de forma a que o esforço para a sua realização esteja dentro do estabelecido pela equipa.
107 Figura 50 Fluxo para definição do Sprint Backlog
Todas as tarefas que não satisfaçam este requisito deverão ser replaneadas.
Assim que o Sprint Backlog estiver completo, deve ser enviado ao Product Owner, para que este o valide:
Se o Product Owner não aprovar as tarefas do Sprint Backlog, deverá reportar as causas à equipa, para que esta consiga atualizar o Sprint Backlog;
Se o Product Owner aprovar o Sprint Backlog, o Scrum Master deverá inserir todas as tarefas existentes dessa lista no JIRA, incluindo as descrições e esforço planeado.
No fim desta fase, deverá ser criado o Burndown Chart no JIRA para controlo e monitorização da sprint.
Caso a equipa não consiga completar o Sprint Backlog no próprio dia, é imprescindível que o faça no dia seguinte, de modo a evitar o atraso da sprint.
Assim que esta reunião terminar, o Scrum Master deverá enviar um email de compromisso a todos os stakeholders do projeto, sendo posteriormente guardado no repositório do projeto, de forma a evidenciar o compromisso da equipa como definido no C&D.
108
6.1.2.2. Um dia de trabalho (2.2)
A Figura 51 retrata o fluxo de um dia de trabalho, indicando as seguintes ações:
Uma Daily Meeting ao início do dia;
Possíveis pedidos de esclarecimento de requisitos devido a uma má especificação ou entrada de Blockers;
Atualização do JIRA e do SVN.
Figura 51 Fluxo de um dia de trabalho
Ao início do dia a equipa deverá reunir-se para fazer a Daily Meeting, liderada pelo Scrum Master. Caso os recursos não estejam juntos presencialmente, devem ser usadas ferramentas de conference call como meio de comunicação.
Com base no estado de cada recurso e do Burndown Chart da equipa, poder-se-á transferir tarefas entre recursos, de modo a não atrasar a sprint. Sempre que possível dever-se-á atualizar o Sprint Backlog.
Ao longo do dia, poderão surgir novos issues com prioridade elevada, denominados por Blockers. Devem ser resolvidos logo após terem chegado à equipa. Por norma se não forem resolvidos terão um impacto enorme no sistema ou no Cliente, podendo assim interromper a sprint.
- Esclarecimento de requisitos
- Atualizar JIRA
- Atualizar SVN
- Troca de tarefas entre recursos
- Garantia da equipa estar sincronizada
- SB atualizado - Validação pelo PO/ PM - Atualizar JIRA
- JIRA atualizado
- Repositório atualizado
Um dia de
trabalho
- Daily Meeting
109 Para resolver um Blocker é necessário que este seja validado pelo Product Owner, para que a equipa o resolva. Caso não tenha informação suficiente para ser resolvido, deverá ser devolvido a quem reportou o issue no JIRA, para que possa detalhar melhor.
Sempre que seja necessário pedir auxílio ao Product Manager para ajustar requisitos, ou pedir ao Product Owner para tomar uma decisão de teor mais técnico, as opções tomadas deverão ser introduzidas no JIRA, para que não haja perda de informação.
No final de cada dia, todos os elementos da equipa deverão atualizar o JIRA, de modo a que o Burndown Chart esteja atualizado para a Daily Meeting do dia seguinte.
Dever-se-á igualmente atualizar todos os artefactos existentes no repositório da equipa, quer estejam nas branches ou na trunk, de modo a atualizar o projeto e todos os documentos que o suportam.
6.1.2.3. Sprint Review (2.3)
Como estabelecido na baseline de verificação, deve-se garantir a viabilidade da realização da reunião de Sprint Review no último dia de cada sprint.
Para se proceder à demonstração (demo) de cada sprint dever-se-á:
Fazer “code freeze” aos componentes a demonstrar;
Preparar a demo com n elementos correspondente a n componentes do projeto;
Elaborar uma reunião entre os oradores;
Enviar uma agenda e convocatória aos stakeholders;
Ter atualizado o documento que identifique todos os ambientes de desenvolvimento e versões dos projetos.
Os componentes a demonstrar deverão ser os mesmos dos que foram preparados até ao “code freeze”.
O final da preparação da demo, deverá ser marcado com uma reunião entre os oradores da mesma, para que possa ser enviada via email, a agenda e convocatória dos respetivos stakeholders, para que estes possam estar presentes e assistir apenas aos projetos onde estão envolvidos.
Durante a execução da demo, deverão ser apresentados os tópicos existentes na agenda previamente enviada, ou seja, todos os requisitos pertencentes ao Sprint Backlog.
110 O Scrum Master deverá ficar responsável por anotar todas as decisões nesta reunião, nomeadamente requisitos aprovados e alterações necessárias a desenvolver, no caso dos requisitos rejeitados.
6.1.2.4. Sprint Retrospective (2.4)
O término de cada sprint deverá ser marcado com uma reunião denominada por Sprint Retrospective. Nesta reunião são discutidos assuntos de carácter mais pessoal, sendo dispensados todos os stakeholders que não sejam constituintes da equipa. Esta reunião deverá ser subdividida em três fases, para que cada elemento da equipa consiga dar a sua opinião:
Na primeira fase são mencionados os aspetos positivos;
Na segunda fase são explicadas as dificuldades sentidas e os aspetos negativos da sprint;
Na terceira fase são mencionadas possíveis melhorias para atenuar as dificuldades sentidas e promover uma melhoria contínua do método utilizado.
Em cada uma dessas fases, o Scrum Master deverá anotar as opiniões mencionadas pelos elementos da equipa, de modo a que sejam disponibilizadas à equipa QAPE como definido no C&D.
A melhoria contínua mencionada anteriormente poderá ser suportada por uma técnica denominada de Five Whys36 de modo a descobrir a origem dos problemas.