O Processo de Desenvolvimento de Software da MGA Sistemas é iterativo e incremental baseado no modelo CMMI-DEV nível 2 e na metodologia SCRUM. Os ciclos de trabalho de desenvolvimento serão caracterizados por ciclos chamados de Sprints conforme abaixo ilustrado:

Em nossa empresa as sprints terão duração semanal e os ciclos de trabalho serão compostos por 4 sprints, tendo então duração de 1 mês. A seguir é apresentado com mais detalhes cada fase do processo de desenvolvimento.

Planejamento do Trabalho

Criação/Revisão do Plano, descrevendo os objetivos e processo a serem seguidos pela equipe de desenvolvimento. São especificados o escopo (aberto), as estimativas, o cronograma e riscos para o Ciclo. São revistas a forma de trabalho quanto às competências, o papel e responsabilidade de cada membro. No planejamento inicial os membros estabelecem, com base no Plano de Padrão de Projeto e o Sistema de Serviço, os critérios de aceite de requisitos, o tratamento das mudanças, os recursos, a configuração e o acompanhamento do ciclo de trabalho. Resultando em um plano de Trabalho que possui Metas, Processo, Equipe e Esforço, Treinamentos, Tamanho, Cronograma, Riscos, Escopo.

Planejamento da Fase (Sprint)

Reunião na qual estão presentes o Product Owner, o Scrum Master e todo o Time, bem como qualquer pessoa interessada que esteja representando a gerência ou o cliente.

As demandas de desenvolvimento para a sprint são apresentadas pelo Product Owner. As demandas são planejadas pelos clientes, através do sistema de chamados na aba de Desenvolvimento > Planejamento.

As demandas são apresentadas para o time, para que todos tenham conhecimento. Elas já entram estimadas.

Resultados

• O Time e o Product Owner definem um objetivo (as Estórias de cada Sistema) para a Sprint, que é uma breve descrição daquilo que se tentará alcançar na Sprint.
• Ata de Reunião de Planejamento da sprint e do ciclo
• Taskboard (quadro branco) com Estórias e Tarefas afixadas, tanto na versão online quanto na física.
• Tickets no sistema de Chamados.

Desenvolvimento

Processo

• Esforço empregado nas Estórias e Tarefas é realizado durante o período de iteração das Sprints.
• São realizadas reuniões rápidas diárias para acompanhamento.

Resultados

• São gerados incrementos para os produtos.
• Atualização do Taskboard
• Atualização do Gráfico de Burndup
• Atualização dos Tickets.

Monitoramento e Controle e Revisões de Marco

• O monitoramento e controle é realizado após cada sprint.
• Os indicadores são analisados e avaliados no monitoramento e controle. Eles estão disponíveis no sistema de chamados na aba Indicadores.
• Os resultados são registrados na ata de fechamento da Sprint, no sistema de chamados.

Encerramento da Fase (Sprint)

Processo

• São apresentados os resultados da sprint e realizado o aceite pelo Product Owner.
• O Time realiza reunião de lições aprendidas.
• Encerra-se a sprint acrescentando um conjunto de features para o produto.

Resultados

• Ata de Reunião de Encerramento da sprint
• Conclusão no sistema de chamados
• Conclusão do Gráfico de Burndup
• Conclusão dos Tickets no sistema de chamados
• Encerramento do Ciclo de Trabalho

Processo

• São apresentados as médias mensais dos indicadores coletados nas sprints do Plano de Trabalho com parecer do SQA, os pontos importantes citados nas reuniões de encerramento das sprints, as metas estratégicas da equipe e o acompanhamento das ações. Todos os envolvidos no ciclo participam da reunião.
• Análise do índice de Satisfação dos representantes: Apresentação das respostas das pesquisas e discussões para melhora o índice caso necessário

Resultados

• Apresentação da Reunião armazenada no Sistema de chamados.

Riscos

• Nos planos de trabalho os riscos são classificados com Probabilidade, Impacto e Nível do Risco;
• Os níveis de Probabilidade e Impacto são classificados em 1 quando é baixo, 2 quando é moderado, 3 quando é Alto;
• O Nível do Risco é a multiplicação da Probabilidade x Impacto ;
• Os riscos são acompanhados no acompanhamento do plano de trabalho de acordo com os parâmetros estabelecidos no Guia de medição - Indicadores ;

Garantia da Qualidade

A garantia da qualidade do processo segue as diretrizes estabelecidas no Guia de medição - Indicadores

Gestão de Dados e Gerência de Configuração

A gerência de Configuração e gestão dos dados do setor de desenvolvimento segue as diretrizes estabelecidas em Gerência de Configuração

Medição e Indicadores

A Medição e Análise do setor de desenvolvimento segue as diretrizes estabelecidas em Guia de medição - Indicadores

Papéis e Responsabilidade

Os Papéis e responsabilidades dos colaboradores são definidas e estão disponíveis em Papéis e Responsabilidades.

SLA

Os SLA definidos para os tipos de serviço que a MGA atende estão disponíveis por cliente em Guia de medição - Indicadores

Metodologia Ágil

O principal objetivo é obter um produto rapidamente e com qualidade. Se caracterizam por um gerenciamento de projeto em que um líder de time esteja frequentemente organizando, inspecionando, apoiando e garantindo que o time esteja bem, ao mesmo tempo que os resultados do projeto de software vão atendendo as necessidades do cliente.

Para este projeto o Scrum é o modelo Ágil adotado pela empresa.

SCRUM

O nome SCRUM é derivado de uma jogada de rúgbi, onde todo o mesmo time avança como apenas uma unidade, trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola pra um e para outro, visando o trabalho em equipe.

O Scrum é um processo de desenvolvimento iterativo e incremental para gerenciamento de projetos complexos.

Propõe uma abordagem para lidar com cenários de mudanças.

E parte da ideia de que a análise, projeto e desenvolvimento possuem elementos imprevisíveis, assim o Scrum adota mecanismo para gerenciar o imprevisível e controlar riscos tendo como resultado flexibilidade, adaptabilidade e confiabilidade.

Possui uma coleção de valores imprescindíveis para o desenvolvimento de projetos de sucesso:

- Transparência e Comunicação

- Colaboração e Confiança

- Busca da melhoria contínua

- Humildade e Coragem para vivenciar os valores e para aprender e mudar

- Mudança de paradigma

- Comprometimento e Excelência

- Ritmo e Disciplina

- Simplicidade e Priorização

O SCRUM tem três partes principais em seu modelo: Papéis, Cerimônias e Artefatos. Todas são utilizadas no que chamamos de ciclo de desenvolvimento, ou seja, o Sprint. Cada Sprint possui suas fases e utiliza destes papéis, cerimônias e artefatos para alcançar seu objetivo final.

Pair Programming(Programação em Par)

Consiste em dois programadores trabalhando juntos num mesmo computador, compartilhando código, idéias e soluções.

Um deles, escreve código , enquanto o outro, o observador, analisa cada linha de código que é digitado, verificando erros e pensando sobre o projeto global.

Após um tempo pré determinado os programadores invertem os papéis, o que estava observando passa a escrever o código, dando sequencia para a implementação.

A programação em pares aumenta a qualidade do software e contribuiu no modo cooperativo de trabalho, que inclui dar e receber de ambos os parceiros, amplia a comunicação da equipe de desenvolvimento, gera menos retrabalho.

Outras vantagens incluem o fato de que, quando duas pessoas têm diferentes especialidades, essas habilidades são transferidos, ou seja, ajudam a nivelar o conhecimento.

Planning Poker

Planning Poker auxilia o Time na estimativa de histórias e tarefas de forma rápida, precisa e divertida. É a avaliação do tamanho de uma história, ou seja, quanto tempo isso vai durar, quanto trabalho será necessário para implementar,qual sua complexidade, como é caro.

Participam: Scrum Master(facilitador) e TIME.

A ideia do Planning Poker é permitir que todos os membros do time de desenvolvimento que estão comprometidos na implementação do Sprint participem colocando a sua visão de complexidade para que juntos possam chegar a um indicador de complexidade comum para o time.

Os pontos utilizados são parecidos com a sequencia do Fibonacci: 0, 1, 2, 3, 5, 8, 13, 20, 40 e é acrescentado (?) que significa "Eu não tenho absolutamente nenhuma idéia", a carta de zero significa "essa história já está feita" ou "esta história é praticamente nada, apenas alguns minutos de trabalho", e assim por diante.

É utilizado normalmente na planning, onde cada membro recebe as cartas do Planning Poker, as histórias são apresentadas, uma a uma e as dúvidas do time são sanadas, cada membro seleciona uma carta, e após todos mostram o número escolhido e confere-se os números das mesmas para ver se deu tudo igual ou ocorreu divergências. Em caso de divergência cada membro pode argumentar o que o levou a pensar diferente dos demais e nesse momento pode usar os argumentos que justifique aquele item ser mais complexo ou mais simples, e cada membro que ficou na dúvida pode propor uma nova votação e/ou mudar o seu voto para mais ou para menos conforme o novo entendimento da questão. E quando o consenso estiver estabelecido é que aquele tamanho será atribuído na história.

Esta forma de estimativa já foi utilizada, porém atualmente os P.Os estimam e apresentam os tickets já estimados.

Daily Scrum (Reuniões Diárias)

Essa reunião tem como objetivo trabalhar o autogerenciamento da equipe.

Devem participar da reunião todos os membros do Time, e o Scrum Master da equipe.

Reunião de quinze minutos (para ser rápida, deve ser feita com todos os membros em pé diante do Quadro de Tarefas).

Melhoram a comunicação.

Servem para atualização do burndown (deve ser feito um rodízio, cada dia um membro da equipe faz atualização, para manter toda equipe focada).

Eliminam outras reuniões.

Identificam e removem impedimentos para o desenvolvimento.

Ressaltam e promovem a tomada rápida de decisões.

Melhoram o nível de conhecimento de todos acerca do projeto.

A reunião diária, deve acontecer diariamente, de preferência no fim ou no início do trabalho.

Durante a reunião, basta cada membro da equipe responder à 3 perguntas:

1.O que fiz desde a última reunião diária?

2.O que irei fazer até a próxima reunião diária?

3.Quais foram meus impedimentos?

Fica visível para os demais membros os problemas enfrentados pela equipe, bem como os impedimentos que cada membro possa ter sofrido.

É o momento onde a equipe demonstra, diariamente, seu comprometimento com o andamento do Sprint e podem alterar seu planejamento para atingir a meta da mesma.

Sprint Planning (Planejamento)

Acontece para planejar a iteração.

Reunião que deve acontecer com horário e data pré definidos.

Participam normalmente dessa reunião: Scrum Master, TIME, Product Owner e eventualmente pessoas interessadas no resultado.

Sua duração depende do tamanho do Sprint.

Consiste em duas partes:

Sprint Planning 1

Durante essa reunião o Product Owner apresenta os tickets do Backlog, descreve as funcionalidades de maior prioridade para a equipe.

A equipe faz perguntas que sejam suficientes para o entendimento e que possam quebrar os tickets em tarefas e após a cerimônia possibilitem a implementação do mesmo.

Coletivamente, o Time e o Product Owner definem o objetivo do Sprint.

O Time estima a complexidade de cada ticket apresentado, utilizando o Planning Poker.

Sprint Planning 2

O time de desenvolvimento revisa, decide e aceita quanto eles podem se comprometer a fazer e entregar no final do Sprint que será iniciado.

Os tickets são subdivididos em tarefas que serão executadas durante o sprint, portanto se julgarem necessário códigos dos programas serão abertos, códigos SQL serão vistos e discussões feitas para repassar o conhecimento. Também é nesse momento que o Time pode selecionar alguns tickets para utilizar Pair Programming(Programação em Par).

Sprint Review (Revisão)

É uma apresentação com o objetivo de demonstrar e revisar as conclusões, todo o time se empenha em realmente ter as tarefas prontas, e todos esperam ver as funcionalidades funcionando.

Time faz apresentação das funcionalidades dos tickets implementados para o Product Owner.

Participam dessa reunião: Scrum Master, TIME, Product Owner e eventualmente pessoas interessadas no resultado.

Durante essa reunião é avaliado o resultado do Sprint.

O Product Owner define se os tickets foram validados, rejeitados, cancelados.

Essa apresentação ajuda a equipe a realmente terminar as tarefas e libera-las.

O Time conhece e aprende o que a equipe está fazendo.

Retrospectiva do Sprint

Após a Revisão do Sprint e antes da próxima Reunião de Planejamento do Sprint, o Time Scrum tem a Reunião de Retrospectiva do Sprint.

Nessa reunião, o time discute os pontos positivos e negativos encontrados no processo de trabalho no decorrer da iteração.

No final da Retrospectiva do Sprint, o Time Scrum deve ter identificado medidas de melhoria factíveis a serem implementadas na próxima Sprint.

Participam dessa reunião: Scrum Master, TIME, eventualmente o Product Owner.

Todos têm permissão para contribuir e discutir idéias.

Contribui para evitar que a equipe cometa os mesmos erros repetidamente.

Product Backlog

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste. Em suma é uma lista dos itens que queremos que o sistema tenha.

Sprint Backlog

O Sprint Backlog é uma lista de tarefas que o TIME se compromete a fazer em uma Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades e o tempo que será necessário para completar as várias funcionalidades, definidas pelo Product Owner.

É alocada uma quantidade de tarefas na Sprint de acordo com as horas disponíveis por cliente. Os chamados possui um tempo estimado e vão sendo alocados até que as horas disponíveis sejam completadas.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas. A estimativa do trabalho que ainda resta a ser feito no Sprint é calculada diariamente e colocada em um gráfico, resultando em um Sprint Burndown Chart.

Burndown

O gráfico de Burnup exibe o total que foi planejado e o quanto a equipe já progrediu para alcançar esse objetivo. Ele é utilizado para medir a entrega do projeto como um todo, permitindo prever se a entrega será feita na data estimada.

Nosso Burnup mostra quanto de entrega a equipe realizou para o time do suporte, que são os responsáveis pelos testes. E em um outro Burnup temos quanto de entrega para o cliente nossa equipe do suporte realizou.

Torna-se possível qual time está ou não realizando as entregas, em qual dia da semana elas estão acontecendo. quantas horas fora do planejamento foram trabalhadas e quantos porcento da sprint entregamos. Todas essas visualizações são possíveis, utilizando filtros de clientes, e sprint.