Plano de Gerenciamento do Projeto - Software-Design-2017/SSMais GitHub Wiki
Histórico de Revisão
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 24/11/2017 | 1.0 | Abertura do Documento | João Paulo e Allan Nobre |
| 24/11/2017 | 2.0 | Clico de Vida do Projeto | João Paulo e Allan Nobre |
| 24/11/2017 | 3.0 | Monitoramento e Controle | João Paulo |
| 24/11/2017 | 4.0 | Baselines | Allan Nobre |
2.1. Características dos ciclos de vida
2.2. Descrições dos ciclos de vida
O presente documento tem o objetivo de mostrar como será feito o processo de gerenciamento do projeto, assim como o seu ciclo de vida, suas baselines e o monitoramento e controle do projeto para manter a equipe de desenvolvimento alinhada quanto ao gerenciamento do projeto.
Este gerenciamento é considerado como uma “Boa prática”, significando que existe um acordo geral de que os planos de gerenciamento de projeto aumentam a chance de sucesso do software de forma significativa (PMBOK 5º Edição, 2013).
Todos os ciclos de vida podem ser mapeados para a estrutura genérica abaixo (PMBOK 5º Edição, 2013):
-
Início do projeto
-
Organização e preparação
-
Execução do trabalho do projeto
-
Encerramento do projeto
No presente projeto, nós trabalharemos com o ciclo de vida adotada pelos princípios ágeis, utilizando como metodologia de desenvolvimento de software KanBan.
“Em um ciclo de vida adaptativo, o produto é desenvolvido através de múltiplas iterações e um escopo detalhado é definido para cada iteração somente no início da mesma.” (PMBOK 5º Edição Pg. 38, 2013
Os modelos ágeis utilizados descritos na área de abordagem utilizada pelo trabalho explicita bem um ciclo de vida adaptativo, onde temos as múltiplas iterações em que o escopo da iteração é definido sempre ao seu início.
O Kanban é uma estrutura popular usada para implementar o desenvolvimento ágil de software. Ele precisa de uma comunicação de capacidade em tempo real e transparência total de trabalho. Os itens de trabalho são representados visualmente em um quadro do kanban, permitindo que os membros da equipe vejam o estado de cada parte do trabalho a qualquer momento.
O Kanban é um dos métodos de desenvolvimento de software menos prescritivo, se tornando adaptável a quase qualquer tipo de cultura. Ao contrário de outros métodos que forçam uma mudança desde o início, o Kanban busca a evolução, não a revolução.
Uma equipe Kanban concentra-se apenas no trabalho ativamente em andamento. Depois que a equipe conclui um item de trabalho, retira-se o próximo item de trabalho do topo da lista de pendências. O proprietário do produto é livre para priorizar o trabalho na lista de pendências sem interromper a equipe, porque qualquer alteração fora dos itens de trabalho atuais não impactam a equipe. Contanto que o proprietário do produto mantenha os itens de trabalho mais importantes no topo da lista de pendências, a equipe de desenvolvimento tem certeza de que está retornando o valor máximo para o negócio. Portanto, não há necessidade de iterações de extensão fixa que você encontra no Scrum.
A escolha do KanBan pela equipe se deu, principalmente, pela versatilidade dessa metodologia, que permite com que todos os membros visualizem o fluxo de produção rapidamente e identifiquem suas obrigações. Contudo, a utilização do KanBan como metodologia principal requer maturidade da equipe, tanto em questão de auto gerenciamento quanto em trabalhar de forma integrada. Como o time desse projeto vêm trabalhando juntos durante longas datas, e já que o tempo de desenvolvimento desse projeto é bastante limitado, o KanBan se mostrou uma ótima ferramenta para o desenvolvimento desse Framework.
Para melhor entendimento do escopo do projeto, veja o documento de espeficação do framework planejado pela equipe. Este documento pode ser acessado aqui.
O Cronograma do projeto foi limitado pelo tempo de início e entrega do Trabalho 2 da Disciplina de Desenho de Software, de modo que foi divido da seguinte forma:
- 27/10 - 08/11: Preparação e absorção de conteúdos sobre Framework e soluções reutilizáveis;
- 09/11 - 18/11: Iteração 1;
- 19/11 - 26/11: Iteração 2;
- 27/11 - 29/11: Entrega Final;
Para acessar as atividades de cada fase a partir das iterações, basta acessar o KanBan da equipe clicando aqui. As iterações estão mapeadas no Git como milestones, e as atividades como issues.
O monitoramento será realizado pelo próprio grupo até a finalização do projeto. Para a realização do monitoramento e controle das atividades desempenhadas pelos membros será utilizado o KanBan.
Esse monitoramento se dará pelo monitoramento do fluxo dos Cards entre as baias de atividades definidas pela equipe, onde o acompanhamento do fluxo do trabalho se dá de uma maneira altamente visual.
PMI. Um guia do conhecimento em gerenciamento de projetos. Guia PMBOK 5a. ed. - EUA: Project Management Institute, 2013.