Modelagem do Processo - Desenho-Grupo2/PlanUp GitHub Wiki
O projeto PlanUP possui entre as suas atividades a modelagem do processo e o subprocesso, estes que serão mostrados e detalhados a seguir:
Figura 1: Modelagem do Processo PlanUp
Clique aqui para visualizar a imagem maior
Figura 2: Subprocesso XP PlanUp
Clique aqui para visualizar a imagem maior
A primeira atividade a ser feito em um projeto é identificar os problemas do mundo real, algo que justifique a realização e elaboração de uma solução que resolva este problema.
Esta atividade é focada em estudar o mercado a fim de encontrar soluções semelhantes a que o projeto será feito. O intuito dessa atividade é encontrar possíveis concorrentes no mercado.
Os temas de investimento é feito após serem feitas as análises de mercado, possibilitando assim encontrar os pontos fortes e fracos em soluções dos concorrentes.
Encontrando os pontos fortes e fracos dos possíveis concorrentes, acha-se assim a chance de melhorar uma funcionalidade bem como adicionar novas funcionalidades ao software. Aqui é debatido com a equipe se os temas de investimento são válidos, caso estes sejam válidos, o processo segue para a próxima atividade. Caso a equipe não concorde com os temas de investimento, a atividade voltará para Identificar o contexto do problema.
Utilizando os artefatos/documentos feitos nas atividades anteriores, agora é hora de ser feito o documento de visão.
Este documento pega como base os artefatos anteriores,os agrupa e faz uma descrição detalhada sobre o produto de software, bem como as partes interessadas e perfil dos usuários e possíveis concorrentes.
Levando em consideração os temas de investimentos juntamente com o documento de visão, são levantados os épicos do software. Os épicos do sistema são os itens grandes demais para serem desenvolvidos nesse momento.
Com os épicos identificados, agora eles devem ser colocados em um documento que os deixe seguro para servirem de base para outros documentos. Caso os épicos estejam de acordo e devidamente validados pela equipe, esse processo segue para a próxima atividade. Caso a equipe não concorde com os épicos que foram escolhidos, a atividade voltará para a de identificar épicos.
Utilizando o documento de épicos como base, agora é detalhar as especificações dos épicos a fim de servirem de base para documento futuros.
Como a primeira atividade do nível de programa, agora será pego o documento de épicos e irá dividir os épicos em funcionalidades menores a serem feitas.
Após separadas as features serem identificadas, elas devem ser documentadas para que sirvam de base para futuros documentos dentro desse processo. Caso as features estejam de acordo e devidamente validadas pela equipe, esse processo segue para a próxima atividade. Caso a equipe não concorde com as features que foram identificados, a atividade voltará para a de identificar features.
Uma das atividades mais importantes deste processo, pois é nela que é feito o documento de arquitetura, que mostra uma visão mais técnica da solução.
Com o intuito de ser um documento mais técnico, voltado principalmente para os desenvolvedores, este documento possui itens como diagrama de casos de uso, o tipo de arquitetura, diagrama de pacotes e restrições da arquitetura.
Com as features perfeitamente documentadas, agora elas devem ser priorizadas com níveis de prioridade para o usuário.
As features priorizadas passam a ser documentadas nesse artefato, que servirá de base para o planejamento das Sprints no nível de time.
É importante verificar se os requisitos funcionais necessários para o desenvolvimento do projeto estão sendo seguidos e se possuem algum problema, tentando assim garantir o máximo de qualidade possível.
Como em todo projeto, este projeto possui datas de entrega, então é necessário planejar cada incremento do software dentro do prazo do projeto.
Neste documento fica documentado as datas de entrega das features, bem como as metas a serem entregues dentro desse prazo.
Nessa etapa do projeto, é necessário pegar o documento de features e separar em mais um nível, com a intenção de separar as features em porções ainda menores, facilitando assim a conclusão da mesma. Um conjunto de user stories compõem uma feature.
Com as user stories detalhadas, o próximo passo é priorizá-las com o objetivo de entregar aquilo que mais entregue valor ao cliente do fim daquela sprint. E com o objetivo de separar com níveis de dificuldade para os desenvolvedores, os mesmos devem se reunir e estimar o nível de cada história. Ao fim dessa atividade, o processo segue para o subprocesso denominado XP.
Utilizando uma das práticas presentes no XP, esta atividade é resumida em os membros se reunirem e separarem duplas de desenvolvidos das features. Essa divisão pode ser feita por níveis de conhecimento ou por afinidade.
É a execução da sprint de desenvolvimento de algum artefato ou storie de usuário.
Este é o último passo no nível de time. Esta atividade tem por objetivo que os gerentes e desenvolvedores do projeto, reúnam aquilo que foi bom ou ruim na Sprint a fim de melhorar cada vez mais, alcançando assim cada vez mais produtividade. Se ainda tiver alguma user storie a ser feita, este processo volta para a atividade de Detalhar User Stories. Se ainda tiver features a serem feitas, este processo volta para a atividade de Priorizar feature. Se ainda tiver épicos a serem feitos, esta atividade irá retornar para Selecionar e Detalhar Épicos. Caso não tenha mais épicos, este subprocesso chega ao fim.