Metodologias Utilizadas

• Scrum
  • Papéis
  • Product Backlog
  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
• XP
  • Pareamento
  • Integração Contínua
• Kanban

Scrum

Papéis

Os papéis desempenhados pelos integrantes da equipe durante a segunda parte do projeto são/foram:

Papel	Descrição	Responsabilidades
Scrum Master	É responsável por ajudar a todos os envolvidos a entender e abraçar os valores, princípios e práticas do Scrum.	Assegurar o Scrum. Resolver conflitos. Facilitar o Daily Scrum. Remover impedimentos.
Product Owner	É o ponto central com poderes de liderança sobre o produto.	Ter contato com o cliente. Priorizar histórias. Validar solução desenvolvida.
Tracker	Acompanha o andamento do projeto nos âmbitos de prazo, custo e qualidade e sugere melhoria dos mesmos.	Coletar e analisar métricas. Garantir qualidade do código. Propor melhorias. Atualizar EVM e Burndown.
Desenvolvedor	É responsável pela concepção, construção e testes da aplicação proposta.	Desenvolver as estórias. Testar as funcionalidades feitas.

Product Backlog

Todas as funcionalidades que serão desenvolvidas durante a Release 2 estão disponíveis no Backlog do Produto .

As funcionalidades estão divididas em User Stories e foram pontuadas com a medida de tamanho Story Point através do Planning Poker.

Sprint Planning

O Sprint Planning será sempre realizada junto ao Sprint Review<,i> e terá duração de no máximo 2hr. Nela serão definidos os papéis da Sprint, quais estórias serão realizadas, o quadro de conhecimentos é atualizado e são geradas as duplas para o pareamento.

Daily Scrum

As reuniões diárias serão feitas conforme o quadro abaixo, tendo seu horário definido pelo Scrum Master da Sprint em questão:

As terças e quintas o daily será presencial na troca de horários entre MDS e GPP. E nos dias restantes será online, não tendo um horário fixo.

Sprint Review

A revisão da Sprint ocorrerá sempre nas reuniões aos Sábados (dia de fechamento da Sprint). Sua duração será de no máximo 2 hr e nela será verificado quais User Stories foram feitas e realizar a adaptação das novas funcionalidades com as antigas.

Sprint Retrospective

A retrospectiva acontece nas reuniões de sábado no dia do fechamento da Sprint, acontece nas duas primeiras horas que é dedicada para finalizar a semana da atual sprint. E a retrospectiva adotada pelo grupo foi de todos os integrantes falarem sobre os pontos positivos, pontos negativos e pontos a melhorar na sprint seguida.

Todos os integrantes escrevem em papéis individuais sua opinião quanto ao desenvolvimento da equipe durante a semana sem se identificar. Depois é lido para todos e discutido os pontos mais citados e planejado as ações de melhoria para a próxima semana.

XP

A Extreme Programming (XP) é uma Metodologia Ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Entre as principais diferenças da XP em relação às Metodologias Clássicas estão o feedback constante, a abordagem incremental e o encorajamento da comunicação entre as pessoas.

Pareamento

Programação em par é uma das práticas mais conhecidas e polêmicas utilizadas pelos que adotam o Extreme Programmin. É sugerido que todo e qualquer código produzido no projeto sera sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado.

Baseadas em um conjunto de práticas coeso que pode ser eficaz em inúmeros projetos. A programação em par é uma destas práticas e tem grande potencial para resolver diversos problemas que afetam os projetos de software, embora não todos, naturalmente. Um dos principais benefícios da programação em par é a permanente inspeção de código que ocorre durante seu uso.

A programação em par é uma forma eficaz de reduzir a incidência de bugs em um sistema. Isso se deve em grande parte às visões complementares que atuam durante o uso dessa prática. Ajudam os desenvolvedores a criarem soluções mais simples, rápidas de implementar e fáceis de manter. Tem uma característica bem marcante quanto ao pareamento: disseminação de conhecimento nas trocas de pares.

Esse conjunto de características faz com que a programação em par acelere o desenvolvimento significativamente. Em função da redução de bugs (e conseqüente redução no tempo de depuração), pressão do par, maior simplicidade das soluções, disseminação do conhecimento, maior confiança nas soluções, entre outros efeitos que a programação em par produz, uma atividade feita em par normalmente é encerrada mais rapidamente que outra feita por um programador solitário.

Integração Contínua

"Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente." Martin Fowler

Integração Contínua tornou-se muito importante na comunidade de desenvolvimento de software e isso provavelmente ocorreu devido ao grande impacto causado pelas metodologias ágeis. Em equipes que adotaram tais metodologias (eXtreme Programming, Scrum, entre outras), integração contínua é um dos pilares da agilidade, garantindo que todo o sistema funcione a cada build de forma coesa, mesmo que sua equipe seja grande e diversas partes do código estejam sendo alteradas ao mesmo tempo.

A grande vantagem da* integração contínua está do feedback instantâneo. Pois a cada commit no repositório, o build é feito automaticamente, com todos os testes sendo executados de forma automática e detectando as falhas. Trás segurança em relação as mudanças: pode fazer modificações sem medo, pois será avisado caso algo saia do esperado.

Kanban

O Kanban lhe ajuda a assimilar e controlar o progresso de suas tarefas de forma visual. É, normalmente, utilizado um quadro branco com alguns pequenos papéis (Post-it) colados, esses papéis representam as suas tarefas, ao termino de cada tarefa o papel é puxado para a etapa seguinte até que a mesma seja finalizada. Ao olhar para um quadro Kanban é fácil enxergar como o trabalho seu e de sua equipe fluem, permitindo não só comunicar o status, mas também dar e receber feedbacks. O Kanban faz você falar sem sequer abrir a boca, ele consegue levar informações que normalmente seriam escritas de maneira rápida, prática e objetiva.

Princípios fundamentais:

1. Visualizar o fluxo de trabalho

2. Limitar a quantidade de trabalho em andamento (WIP)

3. Gerenciar e medir o fluxo

4. Tornar as políticas do processo explícitas

5. Usar modelos para reconhecer oportunidades de melhoria

Referências

• Programação em par

• Integração Contínua e o processo Agile

• Kanban: Do início ao fim!