Metodologia - estudeplus/docs GitHub Wiki

Definição da metodologia

A equipe optou por trabalhar com a metodologia OpenUp, pois essa metodologia engloba aspectos fundamentais do princípio ágil, garantindo um fluxo de entrega contínua possibilitando assim que a validação dos incrementos de software sejam validados constantemente. Além disso o OpenUp propõe artefatos essenciais para a definição de uma arquitetura de software estável e coerente.

Para apoiar o gerenciamento do projeto como um todo, o grupo também fará uso do Quadro Kanban, para poder acompanhar a execução das tarefas durante o decorrer do ciclo da iteração.

E para auxiliar a atividade de desenvolvimento e garantir uma qualidade nas entregas o grupo utilizará a metodologia Extreme Programming(XP). As boas práticas propostas pelo XP que serão adotadas pela equipe são:

  • Small Releases: Sempre quando iterações são concluídas deve ser entregue um novo incremento de software para ser validado pelo cliente. Isso permite que alterações nos requisitos sejam detectados mais cedo.

  • Integração contínua: Validar de forma automatizada a integridade do código através da execução de testes unitários e de integração.

  • Pair Programming: Duas pessoas trabalhando lado a lado para garantir que o conhecimento seja dissipado e fortalecer a propriedade coletiva do código.

Gerenciamento da equipe

Execução:

Tendo em vista que o processo OpenUP precisa de um certo amadurecimento da equipe, tanto para a forma de desenvolvimento quanto para atribuição de tarefas, fazendo com que a comunicação da equipe, entre eles, seja bastante ativa em aplicativos de comunicação (como o Telegram) para sanar dúvidas e ajudar outros membros o quanto antes. Haverá alguns encontros com periodicidade semanal, de forma presencial ou remota, a fim de alinhar e manter o grupo sempre informado sobre os próximos passos, como por exemplo para definir a Sprint seguinte.

Ferramentas e Métodos:

Embora o OpenUP seja livre de ferramentas vamos utilizar algumas no qual a equipe esteja familiarizada para auxiliar a questão de gerenciamento. Além de aplicativos de comunicação e das reuniões utilizaremos o ZenHub, advindo do Kanban, para explicitar a equipe como vem andando alguns processos; Hangout, para possíveis reuniões não presenciais; Google Drive, para salvar e manter rastreabilidade de alguns documentos que são pertinentes tanto ao grupo quanto ao projeto; GitHub, para salvar de forma progressiva o desenvolvimento e a documento do estado atual da aplicação.

Papéis da equipe:

No primeiro momento, devido principalmente a maturidade e familiaridade da equipe com alguns papéis, não será atribuído nenhum tipo de papel para os membros da equipe. Doravante se houver a inevitabilidade de designar papéis entre os membros, este será feito.

Iterações:

As iterações que o grupo adotou serão as de Sprints definidas como a duração de uma semana onde seu fim marca a tomada de decisão para manter ou trazer novos critérios que serão acordados entre a equipe por meio de reunião, onde será avaliado a importância, necessidade, conveniência e prioridade de algum critério que venha a fazer parte do escopo da equipe.

Público alvo e Clientes:

Tendo em vista que a equipe de desenvolvimento da aplicação é composta por alunos que vivenciam esse cotidiano e fazem parte do conjunto que possui interesse de usufruir da aplicação. Além da visão como desenvolvedores e de alunos, é possível a realização de testes de usabilidade para levantar requisitos que interessam a comunidade de alunos da Universidade facilmente, por estar no mesmo ambiente.

Gerenciamento de código

Visto que surgirão incrementos de software ao fim de cada Sprint é necessário definir um padrão e um conjunto de ferramentas e processos que serão encarregados de manter a qualidade do entregável.

Políticas do repositório

Para manter o padronização do repositório onde será gerido o código foram criados os seguintes artefatos:

Integração e deploy contínuo

Será utilizado o processo de integração e deploy contínuo para assegurar a qualidade do incremente de software a ser entregue ao fim de cada ciclo de desenvolvimento. Foi escolhida a ferramenta Gitlab CI/CD para executar o processo de CI e CD de forma automatizada.

Artefatos

Foram escolhidas 7 artefatos, que serão gerados à medida que o desenvolvimento evolui.

Esses artefatos serão gerados nas seguintes fases:

Iniciação

  • Documento de Visão
  • Lista de riscos
  • Plano de iteração
  • Glossário
  • Protótipos

Elaboração

  • Protótipos
  • Modelo de design
  • Esboço de arquitetura

Construção

  • Casos de testes
  • Design
  • Implementação

Transição

  • Release
  • Casos de testes

Documento de Visão (Iniciação)

Esse artefato contém a definição da visão das partes interessadas do produto a ser desenvolvido, especificada em termos de necessidades e recursos das partes interessadas. Ele contém um esboço dos requisitos previstos para o sistema.

Lista de riscos(Iniciação)

Esse artefato é uma lista de riscos conhecidos e abertos ao projeto, classificados em ordem de importância e associados a ações específicas de mitigação ou contingência.

Glossário(Iniciação)

Esse artefato define termos importantes usados no projeto. Esses termos são a base para uma colaboração eficaz com as partes interessadas e outros membros da equipe.

Caso de uso(Iniciação)

Esse artefato captura a sequência de ações que um sistema executa, produzindo um resultado de valor observável para aqueles que interagem com o sistema.

Protótipos(Iniciação/Elaboração)

É utilizado para explorar e/ou validar o design da interface com o usuário.

Casos de testes(Construção/Transição)

Esse artefato é a especificação de um conjunto de entradas de teste, condições de execução e resultados esperados, identificados com a finalidade de fazer uma avaliação de algum aspecto particular de um cenário.

Esboço e refinamento do documento de arquitetura(Elaboração)

Este artefato descreve o contexto para o desenvolvimento de software. Ele contém as decisões, fundamentos, suposições, explicações e implicações da formação da arquitetura.

Referências