-
Notifications
You must be signed in to change notification settings - Fork 1
Descrição do Processo
| Autores | Data | Descrição | Versão |
|---|---|---|---|
| Maria Luiza | 05/09/2018 | Iniciando descrição dos processos (2.1 ao 2.6) | 0.0.1 |
| Adrianne Alves | 05/09/2018 | Descrição dos processos 2.10 ao 2.14 | 0.0.2 |
| Maria Luiza | 06/09/2018 | Descrição dos processos 2.7 ao 2.9 | 0.0.3 |
| Adrianne Alves | 06/09/2018 | Descrição dos processos 2.14 ao 2.18 | 0.0.4 |
| João Pedro Pereira | 09/09/2018 | Inclusão da nova atividade 2.14 | 0.0.5 |
| Adrianne Alves e Maria Luiza | 22/11/2018 | Adição da metodologia | 0.0.6 |
- Introdução
- Metodologia
-
Tarefas do processo
3.1. Definição do escopo
3.2. Definição das tecnologias do projeto
3.3. Elicitação de requisitos
3.4. Definição de features
3.5. Elaboração do Design/Arquitetura do Sistema
3.6. Definição do Product Backlog
3.7. Planejamento da Release
3.8. Planejamento da Sprint
3.8.1. Definição do Sprint Backlog
3.8.2. Pontuação das histórias do usuário
3.8.3. Definição de critérios de aceitação
3.8.4. Definição de pares de execução
3.9. Desenvolvimento
3.10 Garantia da Qualidade
3.11 Realização de Daily Meeting
3.12 Revisão de Sprint
3.13 Retrospectiva da Sprint
3.14 Gerenciamento de Mudança de Requisitos
3.15 Execução do pipeline de entrega
3.16 Correção de Erros
3.17 Publicação da Release
3.18 Execução das Tarefas de Integridade
3.19 Disponibilização da Nova Versão Para o Usuário
Após o desenvolvimento do modelo do processo a ser seguido pelo time, foi realizado um esforço para a descrição das atividades definidas. As alunas Adrianne e Maria Luiza, em posse do diagrama, descreveu ou definiu cada uma das atividades e subprocessos elaborados, de acordo com o contexto a ser desenvolvido, mas o documento foi revisado pelos demais membros. A divisão encontra-se presente na ata de reunião e o resultado desse execicio encontra-se abaixo.
Esta tarefa define o escopo do projeto, o qual é definido o tema que será feito no projeto, bem como a plataforma que será desenvolvida, seja Web ou Mobile. O artefato gerado por esta tarefa é o Documento de Visão, o qual auxilia na Elicitação de Requisitos.
Esta tarefa define qual a tecnologia que será utilizada no projeto.
Esta tarefa elicita os requisitos do projeto, por meio de técnicas de elicitação de requisitos. Os artefatos gerados nessa tarefa são Léxico, 5W2H, RichPicture e Protótipo. Estes artefatos auxiliam na Elicitação de Features.
Esta tarefa define as features, que são funcionalidades, a fim de mapeá-las em alto nível do projeto, gerando um artefato de Features.
Esta tarefa define a arquitetura e o design do sistema como um todo, a fim de estar de acordo com os padrões arquiteturais, podendo retornar a esta atividade enquanto os artefatos não estiverem de acordo com os padrões. O artefato gerado com essa tarefa é o Documento de Arquitetura.
Esta tarefa define o Product Backlog, onde se encontram todas as funcionalidades e tarefas que a equipe deve realizar durante o desenvolimento, no formato de uma "lista", que é o artefato gerado nessa tarefa. O Product Backlog auxilia no Planejamento da Sprint e na Revisão da Sprint.
Esta tarefa planeja a Release, onde ocorre o lançamento de uma nova versão do Software, neste planejamento são priorizadas as Features que serão lançadas em cada Release, além da definição das datas que cada Release será lançada.
Esta tarefa define o Sprint Backlog, onde se encontram todas as funcionalidades e tarefas que a equipe deve realizar durante a Sprint, priorizando as histórias do Product Backlog.
Esta tarefa pontua as histórias de usuário que serão inseridas na Sprint, onde a equipe pontua com os números de Fibonnacci de acordo com a dificuldade da história e o tempo que será gasto para executá-la.
Essa atividade refere-se às condições utilizadas pela equipe para checar se uma estória pode ser considerada como concluída ou não. Será elaborado um template com os critérios para serem checados a cada pull request enviado. Esses critérios considerarão aspectos de integridade e padronização dos pull requests.
A definição dos pares se dará por meio da observação das habilidades de cada indivíduo, de modo a montar duplas homogêneas para a passagem de conhecimento. A partir de então serão alocadas as estórias para cada par.
Esta tarefa desenvolve de fato das histórias planejadas para a Sprint, o qual as funcionalidades serão implementadas, via código.
A garantia da qualidade é uma atividade concomitante ao desenvolvimento e à realização dos encontros diários. De maneira geral, ela marca o esforço da equipe em realizar a aplicação de testes no código gerado, assim como acompanhar os pull requests enviados para incorporá-los à branch develop. Isso porque a estratégia adotada pela equipe é desenvolver o projeto a partir dessa branch e só após o fim da release incorporar à master, onde estará o código estável da aplicação.
É preciso salientar que essa iniciativa deve-se a preocupação com a qualidade do produto gerado e a necessidade de garantir o desenvolvimento contínuo. Dentre os testes previstos a serem aplicados, estão : Testes unitário e testes de aceitação, o mínimo para definir que uma funcionalidade foi concluída. No que diz respeito a revisão dos pull requests, a equipe utilizará um checklist contendo aspectos como : descrição clara do que que foi incorporado, associação à tags, se passou pelos testes, comportamento esperado e comportamento obtido.
Daily Meeting é um dos rituais mais importantes do scrum pois permite a rápida reação à mudanças e empecilhos que possam surgir durante uma sprint. No que diz respeito ao processo modelado pela equipe, o Daily meeting será realizado de fato diariamente, mas não presencial, devido às limitações de disponibilidade dos membros, mas contará com o apoio de um bot integrado ao slack. As perguntas feitas pelo bot serão: O que você fez no dia anterior? O que fará hoje? Existe alguma dificuldade ou empecilho?
Essa atividade consiste em realizar um balanço geral das estórias que haviam sido alocadas para uma sprint e as que foram de fato concluídas, demonstrando a existência de possíveis dívidas. Além disso, será possível visualizar de maneira mais pontual a atuação de problemas que tenham acontecido por meio das estórias não concluídas, estas voltarão para o product backlog . Como o esperado, o insumo desse exercício é o backlog do produto e o resultado dessa atividade, em conjunto com a Retrospectiva é um documento de resultados da sprint.
A etapa de restrospectiva da Sprint, na metodologia empregada, também é oriunda do scrum e configura uma atividade muito importante pois permite à equipe visualizar brechas para aumento da produtividade. Dessa maneira, nessa atividade os membros se reunirão por meio de hangouts e discutirão os aspectos positivos e negativos da sprint, procurando levantar formas de melhorá-los. Assim, a equipe utilizará da métrica de burndown para acompanhar o desempenho ao longo das sprints.
A atividade será realizada com a finalidade de verificar a necessidade de inclusão de novos requisitos ou mudança dos requisitos elicitados anteriormente.
Essa atividade englobará o processo de integração de todo o código desenvolvido, a fim de sondar se está ocorrendo sem problemas. A priori, a equipe utilizará o travis para automatizar a execução. De maneira geral, nesse passo é que será estabelecido se os objetivos para publicação da release foram cumpridos, ou seja, se as funcionalidades separadas para a release estão adequadamente integradas e em funcionamento.
Atividade que ocorre após a execução do pipeline de entrega, caso tenham se manifestado erros. É uma etapa iterativa que serve de apoio à execução com sucesso do pipeline de entrega, de maneira que quando deixa de ser requisitado, possibilita a publicação da release.
Nessa etapa será gerada a tag da release, versionando a entrega de parte do software, como o planejado. Estar nessa atividade pressupõe que não há erros na aplicação, nem na integração entre as funcionalidades. Assim, é gerado um incremento do software como saída desse processo.
Etapa subsequente a publicação da release que consiste na execução de tarefas que checam a integridade da aplicação, considerando a tecnologia Django que será utilizada. Assim, serão realizadas traduções, migrações e verificações de serviços como logs e caches.
A etapa final de todo o processo pressupõe a entrega ou disponibilização de uma nova versão do software para o usuário final. Assim, a atividade seria uma versão oficial para a utilização do software atualizado.