Autor	Data
Fabíola Fleury	24/03
Josué Nascimento	25/03
Josué Nascimento	26/03
Rodrigo Oliveira	26/03
Josué Nascimento	29/03
Josué Nascimento	04/04

Para construção do processo utilizado pela equipe durante a disciplina, foram estudadas diversas abordagens de desenvolvimento de software para que fosse possível a seleção de atividades e artefatos que sejam congruentes ao contexto referido a disciplina de Arquitetura e Desenho de Software. Logo, o processo apresenta-se com uma abordagem mista, com características tanto de metodologias ágeis quanto de tradicionais. A seguir, são explicadas sucintamente as abordagens consultadas.

O RUP é um processo de desenvolvimento de software criado com o intuito de apoiar o desenvolvimento de projetos Orientados a Objetos, fornecendo uma forma sistematica para obter vantagens no uso de UML. Para a discipina utilizaremos os seguintes aspectos do RUP:

• Modelagens de Caso de Uso: Representa uma possível utilização do software produzido através da representação de um ator, que pode ser uma pessoa ou um software. No contexto da disciplina será utilizado para a modelagem das features.

• Diagrama de Pacotes: É um diagrama UML que mostra a estrutura do projeto a nível de pacotes. No projeto da disciplina utilizaremos o diagrama de pacote para representar o pacotes existentes no projeto de uma forma mais alto nível, demonstrando seus relacionamento com os demais pacotes.

• Diagrama de Classe: É um diagrama UML que mostra a estrutura existente no projeto a nivel de classes e inteface, mostra suas características, restrições e relacionamento. No contexto da disciplina utilizaremos os diagrama para representar as classes do projeto, seus metodos atribultos e relacionamentos com as demais classes.

• Diagrama de Sequencia: O diagrama de sequencia descreve uma interação concentrando-se na sequencia de mensagens trocadas, juntamente com as especificações de ocorrência correspondentes nas linhas de vida.

Scrum é uma metodologia ágil utilzada para gestão de projetos de software, para a gerência do projeto na disciplina de Arquitetura e Desenho de Software utilizaremos os seguintes pontos.

• Sprints: Sprints são as interações de entrega das atividades propostas no projeto, no contexto da disciplina essas interações terão duração de 7 dias.

• Scrum Master: O Scrum Master procura assegurar que a equipe seja capaz se entreguer o que for planejado, além de assegurar que a equipe siga os rituais do Scrum. Para a disciplina, o Scrum Master será um cargo rotativo entre os membros da equipe de desenvolvimento e será definido ao inicio de cada Sprint.

• Product Owner: É a pessoa a qual define os itens que compõem o Product Backlog. O product Owner nesse Projeto será uma posição exercida pelo integrante do Grupo Pablo Diego.

• Scrum Team: O Scrum Team é a equipe de desenvolvimento. No contexto da disciplina o Scrum Team será composto pelos membros do grupo do projeto.

• Sprint Plannig Meeting: É a reunião onde estão presentes as partes interessadas no projeto onde são priorizadas as funcionalidade a serem entregues ao final da interação. Para a disciplina as partes interessadas que participarão da reunião se resume ao time de desenvolvimento e o Product Owner.

• Sprint Backlog: É a lista de tarefas que a equipe desenvolvimento se compromete a entregar até o final da Sprint, onde é tarefa do Scrum Master manter atualizado. Para a disciplina, o Sprint Backlog irá se concentrar na ferramenta ZenHub e disponibilizada no repositório do grupo.

• Sprint Retrospective: O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. Para a disciplina, será feito no fechamento da Sprint onde todos os membros da equipe de desenvolvimento deverão estar presentes para ressaltarem os pontos negativos e positivos que ocorreram.

• Sprint Review Meeting: Reunião realizada ao final de cada Sprint onde o Scrum Master mostra para a equipe de desenvolvimento os resultados alcançados, demonstrando as funcionalidade que foram entregue naquela interação. Para a disciplina, essa atividade será executada pelo Scrum Master ao qual foi definido ao inicio da Sprint conscientizando a equipe de desenvolvimento do progresso do trabalho.

• Daily Scrum: São reunião realizadas diariamente entre os membros da equipe de desenvolvimento, afim de conscientizar a equipe do que cada membro realizou no dia anterior. Para a disciplina, essas reuniões serão realizadas presencialmente as segundas e sextas e de forma remota no outros dias.

• Plannig Poker: Forma utilizada para mensurar a dificuldade das histórias, sendo utilizada sendo empregado valores para elas segundo a serie de fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 21. No contexto da disciplina de Desenho de software utilizaremos os seguintes pontos para as historias 1, 2, 3, 5, 8, 13, 21

O Scaled Agile Framework (SAFe®) ajuda as empresas a enfrentar os desafios significativos de desenvolvimento e fornecimento de software e sistemas de classe corporativa no menor lead time sustentável. É uma base de conhecimento on-line, livremente revelada, de padrões de sucesso comprovados, para pessoas que estão construindo os softwares e sistemas mais importantes do mundo. O SAFe sincroniza o alinhamento, a colaboração e a entrega para várias equipes ágeis. Escalável e configurável, o SAFe permite que cada organização o adapte às suas próprias necessidades de negócios.(Safe)

• RoadMap: É um cronograma baseado nas features do projeto, onde se é possivel mapear o tempo de execução de cada featura levando em consideração a duração do projeto. Na disciplna utilizaremos a o RoadMap para gerencia o projeto com base nas feature em função do tempo do projeto.

• Níveis de Requisito: Utilizaremos os níveis de requisito apresentados pelo SAFe (Épico -> Feature -> História), para uma melhor rastreabilidade e consequentemente um melhor gerenciamento dos requisitos do projeto.

• Spikes: Representam atividades onde membros da equipe devem ganhar conhecimento para realizar atividades a a que eles foram propostas, basicamente se remete a incertezas do projeto. No contexto da disciplina esse tipo de mecanismo será utilizado para historias nas quais os membros da equipe encontre necessidade de ficar maior parte do tempo estudando do que realizando a atividade em si, história que forem spikes deverão ter ao seu card no ZenHub a tag spike e também não será exigido que ao final da sprint a história seja entregue mas deveram ser compartilhado o conhecimento adquirido com os membros da equipe caso não seja finalizada.

• Lean Bussines Case: É um templete de como se deve documentar os epicos do projeto, esse templete pode ser encontrado aqui

O Kanban é um estrutura popularmente usada em desenvolvimento de software ágil, onde os itens do trabalho são representados visualmente em um quadro, conhecido com quadro Kanban. Este quadro que é dividido em comumente em 3 colunas To-Do, Doing e Done, onde cada uma das colunas representa um estado da atividade durante a elaboração, essas atividade são descritas em cartões (cartões Kanban), nos cartões são designados o que deve ser feito na atividade e quem é o responsável por executar essa atividade. Para a disciplina utilizaremos tanto o Quadro Kanban, quanto os cartões para organização das atividades e mapeamento de quem está as executando. Os cartões Kanban serão as Issue utilizadas no ZenHub e deverão ter as seguintes informações:

• Nome.
• Caso seja algo referente a documentação deve ter o nome do documento referido no titulo.
• O membro(s) a qual a atividade foi designado.
• Os critérios para ela ser considerada finalizada.
• Tags existentes no ZenHub para identificar do que se trata a atividade.

O quadro kanban estara disponivel no ZenHub onde todos os membros da equipe de desenvolvimento terão acesso. O nosso quadro kanban será composto pelas seguintes colunas To-do, Doing, Review e Done.

• To-do: Atividade para ser realizada, essas atividades poderão ser entregue de histórias de usuário, fazer ou atualizar as documentações relativas ai projeto.

• Doing : Descreve que atividade já foi realizada.

• Review : Atividade atribuida ao Scrum Master para ver se a atividade será aceita como completa ou se tera que passar por alguma modificação para ser considerada finalizada.

• Done : A atividade passou por revisão e foi aceita como finalizada mediante aos critérios de aceitação.

SCALED AGILE. SAFe® 4.0 Introduction Overview of the Scaled Agile Framework® for Lean Software and Systems Engineering​. A Scaled Agile, Inc. White Paper July, 2018.

Schwaber, Ken, and Mike Beedle. Agile software development with Scrum. Vol. 1. Upper Saddle River: Prentice Hall, 2002.

Scrum. Disponível em http://www.desenvolvimentoagil.com.br/scrum/. Acesso em 24/03/2018.

Kruchten, Philippe. The rational unified process: an introduction. Addison-Wesley Professional, 2004.

RUP UML. Disponivel em https://www.uml-diagrams.org/. Acesso em 25/03/2018