This is an old version of this page. You can view the most recent version or browse the history.

gerenciamento_projeto

| Home | Arquitetura | Banco de Dados | Configuração | Gerenciamento do Projeto | Instalação | Materiais de Estudo | Mockups | Requisitos | Reunioes | Sprints | Time | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

Página de Gerênciamento do Projeto

Sumário:

Termo de Abertura Atualizado

Termo_Abertura.pdf

Identificação dos Stakeholders

EAP

Plano de Comunicação

Aprofundando o conceito para o nosso projeto de tribos:

Tribos

Neste semestre, implementamos uma divisão do time em pequenas tribos de - no máximo - 3 participantes. Cada tribo deve possuir 1 (um) AGES 34 e no máximo 2 (dois) AGES 12. o intuito da divisão em tribos foi de melhorar a comunicação, uma vez que em grandes times esse tende a ser um dos pontos de maior falha.

A tribo funciona como uma mini-equipe, onde será especializada em uma determinada tecnologia, terá autonomia e será auto-organizada. No final dos ciclos de entrega, a tribo deve realizar a prestação de contas da entrega para todo o toda a equipe. A proposta desta metodologia é proporcionar melhor controle e engajamento dos participantes da tribo, unindo as pessoas por suas qualidades e "gaps".

Momentos de organização e feedback

Sprint Planning

Essa é o momento em que a equipe organiza os afazeres para a próxima sprint. Durante o Sprint Planning Meeting, o Product Owner descreve as funcionalidades de maior prioridade para a equipe. A equipe faz perguntas durante a reunião de modo que seja capaz de quebrar as funcionalidades em tarefas técnicas, após a reunião. Essas tarefas irão dar origem ao Sprint Backlog.

* ***Sprint Retro***

Trata-se de uma cerimônia clássica do SCRUM. Neste momento é avaliada a entrega do time para entender o que foi bom logo deve continuar e os pontos de falha para poder ajustar o processo para o próximo ciclo.

* ***Weekly-Time***

Esse cerimônia trata-se da daily proveniente dos métodos ágeis. No entanto há uma pequena adaptação, uma vez que a equipe reúne-se apenas semanalmente, em contraste com equipes de software comuns que tendem a se encontrar diariamente.

* ***Weekly-Tribo***

Essa é uma cerimônia criada pelo time em conjunto utilizando as experiências passadas para propor uma melhoria no processo. Utiliza o conceito de tribo explicado anteriormente, nesse momento há um contato mais personalizado, no qual um membro da equipe mais experiente (AGES III e IV) tem contato com os AGES I e II, podendo ter uma iteração visando a solução de dúvidas técnicas, acompanhamento próximo e feedbacks mais precisos.

Plano de Recursos Humanos

Membros da Equipe

AGES I	AGES II	AGES III	AGES IV
Arthur Testa - Tribo 3	Angelo Cabele - Tribo 1	Gabriel Weich - Tribo 1	Felipe Guedes - Tribo 4
Bruno Oliveira Andrade - Tribo 3	Fabrício Pujol - Tribo 4	Gustavo Jacob de Oliveira - Tribo 2	Homero Oliveira Junior - Tribo 4
Lucas Cardoso - Tribo 3	Igor Sgorla Brehm - Tribo 2	Mateus Haas - Tribo 3
Luiz Eduardo Mello dos Reis - Tribo 1	Jhonata Saraiva Peres - Tribo 2
Roberto Rezende - Tribo 1	Yuri Seixas - Tribo 4

Funções por Nível

	Objetivo	Função	Artefatos
AGES I	• Programação • Testes • Depuração	•Desenvolver código •Auxiliar no desenvolvimento dos Mockus •Auxiliar nas documentações do Wiki •Executar testes funcionais	•Código desenvolvido e salvo no GIT •Relatórios das Sprints •Relatório de Andamento •Relatório Final
AGES II	•Análise de Requisitos •Projeto de Banco de Dados •Programação	•Apoio a AGES I •Desenvolver código •Refatorar código •Fazer o levantamento dos Requisitos. •Desenvolver e documentar o banco de dados (ex: diagrama ER) •Toda a documentação técnica dever estar na Wiki	•Mockus dos frontend •Banco de dados Collections(Entities) ScriptSQL •Página na Wiki de Documentação •Relatórios das Sprints •Relatório de Andamento •Relatório Final
AGES III	•Testes e verificação •Projeto de software •Arquitetura de •software	•Apoio a AGES I e II •Desenvolver o Setup para o projeto. •Desenvolver ou Revisar toda a arquitetura. •Toda a documentação técnica dever estar na •Wiki	•Segurança •Rotas de Backend (Arquitetura funcional) •Objects – Backend API •Methods – Backend API •Arquitetura Não Funcional •Diagrama de Pacotes / Componentes (Arquitetura de software) •Diagrama de Deploy •Documentação sobre aplicação de Design do Projeto •Análise dos principios SOLID •Code Review •Página na Wiki de Documentação •Relatórios das Sprints, Andamento e Final
AGES IV	•Gerenciamento de projetos •Aprofundamento de outras competências desenvolvidas no curso •Portfólio de conclusão de curso	•Apoio a AGESI, II e III •Planejamento das Sprints •Criação das User Stories junto aos •Stakeholders •Controle das tarefas do time (exemplo via trello) •Motivação do Time •Controle do Processo da AGES •Desenvolvimento do Plano de Gestão do Projeto •Toda a documentação da gestão do projeto dever estar na Wiki	•Termo de Abertura (Atualização) •Identificação dos Stakeholders •EAP •User Stories •Cronograma •Plano de Comunicação •Plano de Recursos Humanos •Identificação dos Riscos •Plano de Respostas a Riscos •Página na Wiki de Documentação •Relatórios das Sprints , Andamento e Final