Planejamento do Processo de Desenvolvimento - LabESOF

1 - Visão Geral

O Agile Short Unified Process - ASUP-LabESOF é um framework hibrido para desenvolvimento de software com base no modelo Scrum e algumas caractarísticas do método Unified Process. O Processo foi adaptado do modelo original do ASUP para atender as características inerentes ao contexto de uma fabrica de software vivenciada em sala de aula.

Portanto, o Processo será adotado para conduzir todos os projetos definidos na disciplina de Laboratório de Engenharia de Software, pois auxiliará aos alunos e ao professor na organização das atividades a serem desenvolvidas.

Figura 1 - Ciclo de Vida do Processo ASUP-LabESOF

2- Composição do Time

Os alunos deverão ser reunir para definir o time que irá conduzir o projeto. Não será aceito aluno mudando de time no decorrer do projeto. Portanto esta definição deverá ser feita com cautela e de forma definitiva.

O time deverá conter até 03 (três) alunos e um 01 (um) professor com os seguintes papeis:

Na apresentação do escopo do projeto todos deverão participar, sem a definição do tech lead, pois esta apresentação não representa uma entrega do projeto.

Serão 08 (oito) entregas parciais e uma final, portanto o time deverá eleger um tech lead para cada entrega parcial, sendo que o rodízio deverá obedecer ao ciclo de 3 (três) em 3 (três) entregas. Ou seja, se elegem o aluno 1 para entrega 1, este deverá estar na entrega 4 novamente, assim repete até a entrega 9.

Para entrega final, o time deverá eleger o tech lead destaque, que irá realizar a apresentação final e também receberá um bônus na nota. Caso o time não entre em acordo em elege o tech lead destaque, ficará a cargo do PM realizar a tarefa.

3 - Software de Gerenciamento de Projetos - Redmine

O software de gerenciamento a ser utilizado será o Redmine, pois permite gerenciar todas as atividades desenvolvidas no projeto. Sendo acessado por meio do domínio http://mauroborges.ddns.net na seção “Redmine”.

O Project Management-PM reunirá com todos os times e juntos criará o projeto dentro do ambiente, bem como a definição das primeiras tarefas. As tasks a serem inseridas no ambiente para cada Sprint será de responsabilidade do tech leads que estará na Sprint Ativa, conforme será demonstrado mais adiante.

O projeto será dividido em 3 (três) seções, conforme abaixo:

4 - Ideação

Dentro da abordagem do Design Thinking, a ideação é a etapa dedicada à formação de novas ideias. Ou seja: após mergulhar em um problema específico, o desafio é efetivamente começar a “pensar fora da caixa” e propor formas de solucioná-lo.

Portanto, após definição do time que irá trabalhar no projeto, porém ainda sem a definição do tech lead, todos os membros do time deverão participar das discussões para entender o problema a ser resolvido.

O time deverá apresentar o escopo do projeto sem entrar nos detalhes de desenvolvimento, apenas a ideia, contextualizando o problema e a solução a ser trabalhada. Para apresentação o time poderá utilizar recursos visuais tais como uma apresentação em power point ou qualquer outro recurso que possa facilitar a transmitir a ideia a ser projetada.

5 - Plano de Projeto - PP

O Plano de Plano - PP será o documento que irá direcionar todo o desenvolvimento do Projeto, nele deverá constar todos os elementos que envolvem o desenvolvimento pleno das atividades do projeto.

Este artefato será considerado a Entrega 1, e contará com um valor de nota a ser apresentado na seção de Distribuição de Notas - DN no final deste documento.

Para compor o PP, os itens abaixo serão considerados obrigatórios. Porém, o time poderá acrescentar algo que não conste no modelo apresentado, caso desejem enriquecer mais ainda o trabalho.

Como este documento será o artefato norteador do projeto, todos os membros do time deverão estar engajados neste, para entender todos os passos que serão desenvolvidos no projeto.

Abaixo os itens que deverão compor o PP:

5.1 - Introdução

💡
Apresentar uma introdução relatando o que o documento irá apresentar.

5.2 - Visão Geral do Sistema

a. Objetivo Geral

💡
Deve resumir e apresentar a ideia central do trabalho, descrevendo também a sua finalidade.

b. Objetivos Específicos

💡
Apresentar em forma de itens os resultados que se pretende alcançar alinhados ao objetivo geral.

c. Resumo da solução

💡
Nesta seção, apresentar um resumão da solução a ser adotada, se é web ou mobile, como será gerenciada e organizada.

5.3 - Product Backlog - Histórias de usuários - Nível de negócio

💡
Para esta seção, o time deverá compor um grupo de histórias de usuários no formato Scrum, ou itens em forma de Requisitos Funcionais e Não Funcionais. O time poderá definir o formato a ser seguido para compor o documento.

5.4 - Diagrama de Casos de Uso

💡
Este artefato será obrigatório e deverá ser elaborado com bastante cuidado, pois é por meio deste que será representado a ideia em forma de funções que serão trabalhadas.
💡
Para facilitar a apresentação do Diagrama de Casos de Uso, o time poderá separar em várias cenas para um melhor entendimento e organização das funções.

5.5 - Diagrama de atividade ou BPMn

💡
Para esta seção, a depender do tipo de projeto a ser desenvolvido, este artefato poderá ser eliminado, caso o PM julgue que não seja necessário.

5.6 - Identidade Visual

a. Design inicial

💡
Para esta seção, será considero os elementos de design a ser utilizado no site público e telas internas, tais como cores, padrões de botões, tipografia, etc.

b. Logotipo com slogan

💡
Considerar um nome para identidade do projeto, bem como um logotipo com ou sem slogan

5.7 - Arquitetura e Tecnologia a serem utilizadas

💡
Desenhar a arquitetura para representar como será organizado e dividido o sistema, como por exemplo. Monolítico, 2 camadas, 3 camadas, N camadas, etc.
💡
Ao representar a arquitetura, informar quais serão as tecnologias a serem utilizadas em cada camada.

5.8 - Ambiente e Configurações a serem definidas

💡
Esta seção deverá ser representado todos os passos para configurar um ambiente de desenvolvimento conforme arquitetura definida.
💡
Além disso deverá apresentar aproposta de deploy a ser utilizada como todos os passos para ser realizado.

6 - Product Backlog - PB

Este artefato deverá ser entregue junto com o PP, sendo considerado um valor para nota também. Com o Projeto de Pesquisa - PP em mãos e com todos os artefatos desenvolvidos nele, o time deverá orientar e refinar o Product Backlog - PB, representando um cenário com as possíveis Sprints a serem trabalhadas, já com as divisões em épicos ou funcionalidades.

Para este artefato o time deverá apresentar em forma de planilha, pois será apenas um cronograma com o planejamento inicial e estará em seu estágio inicial, ou seja, apenas uma proposta.

7 - Ciclo das Sprints - Eventos

7.1 - A Sprint Ativa

A Sprint Ativa é considerada a sprint que corresponde ao planejamento de entrega conforme cronograma que será apresentado abaixo. Como o evento de Planning e Review acontecem juntos, para o evento Planning a Sprint Ativa será a sprint que se iniciará, e para o Review a Sprint Ativa é considera o encerramento do ciclo da sprint.

7.2 - Planning

O Planning é um evento que ocorre por meio de uma reunião junto ao PM, definindo as tasks que correspondem ao atendimento da Sprint Ativa que se inicia. O time esclarece junto ao PM quem será o tech lead da Sprint Ativa e define as tasks que cada membro irá trabalhar durante o time-box de 02 (duas) semanas. O tech lead deverá renomear a Sprint ativa para uma descrição sintética e que correponde a entrega e criará as tarefas definindo quem serão os responsáveis pelas atividades. Não poderão tem membros sem tasks dentro de uma Sprint Ativa. Caso isso aconteça o tech lead em comum acordo com o time poderá criar tasks em outra sprint ou criar atividades de ambientações e configurçaões.

Poderão ter tasks da sprint anterior que irão compor a sprint ativa, conforme definido na Review da Sprint entregue.

7.3 - Distribuição das tasks

Como já mencionado o tech lead da sprint ativas será o responsável por criar as tasks dentro do ambiente Redmine. A distribuição das taks é de reponsabiliade do tech lead, porém é de suma importância a participação de todos e a concordância de todos os membros do time.

Poderão ter tasks atribuidas a um membro do time, porém, outro membro poderá trabalhar na mesma tarefa também.

Será facultativo a definição de tempo estimado para as tasks, porém o registro de horas trabalhadas pelo membro do time em cada task será obrigatório, pois irá representar quanto cada membro debruçou para vencer a task, além de representar o relatório no final do projeto.

O Autor da tarefa a ser criada deverá ser sempre o tech lead, para representar no relatório de sprint definido no redmine.

7.4 - Review

O evento de Review acontece por meio de uma reunião antes na reunião de Planning, pois o Review representa a Entrega da Sprint ativa que se encerra. A entrega deverá ser conduzida pelo tech lead da Sprint Ativa e será computado um valor de nota para ela.

Na entrega o tech lead deverá reportar se todas as tasks definidas na Planning foi realmente realizadas. Caso alguma task não tenha sido vencida, esta poderá compo a próxima Sprint que será a sprint ativa e deverá ser considera na reunião de planning.

8 - Resumo do Cronograma das Entregas - Time Box

Figura 2 - Cronograma das entregas 2-2024

9 - Distribuição de Notas - TDN

As notas serão distribuidas em dois segmentos, sendo o primeiro para compor os valores a serem validados nas entregas conforme cronograma acima. Para o segundo segmento será adotado o esquema de gamefication conforme será demonstrado abaixo.

9.1 - Notas validadas nas Entregas

Descrição Valor Data
Entrega 110 Pontos26-27/08/2024
Entrega 25 Pontos09/09/2024
Entrega 35 Pontos23/09/2024
Entrega 45 Pontos07/10/2024
Entrega 55 Pontos21/10/2024
Entrega 65 Pontos04/11/2024
Entrega 75 Pontos18/11/2024
Entrega 85 Pontos02/12/2024
Apresentação Final15 Pontos16/12/2024
Total de Pontos60 Pontos

Observações: Será considerado o valor máximo caso o time realize a Review e Planning conforme acordado, e será avaliado a Sprint Ativa de Entrega. Caso o PM verifique que não houve comprometimento no processo de desenvolvimento da Sprint Ativa o PM poderá atribuir a nota que corresponde a nível de entrega e comprometimento do time.

9.2 - Notas validadas para gamefication

ItemDescriçãoValorData
1Sistema em funcionamento em conformidade com os itens apresentados nos artefatos do projeto10 Pontos16/12/2024
2Sistema devidamente implantado no domínio acordado junto ao PM10 Pontos16/12/2024
3Tech Lead destaque 10 Pontos16/12/2024
4Bonus de Presença10 Pontos16/12/2024
Total de Pontos40 Pontos

Observações: Para o item 1 será avaliado se o projeto foi entregue dentro do que foi planejado e modelado. Para o item 2, o time deverá propor soluções de deploy para colocar o sistema on-line e disponível de forma pública. No item 3 o time deverá eleger o tech lead destaque para receber o bonus, ou caso não entrem em acordo o PM fará a escolha. Para o item 4, o aluno receberá o valor total caso tenha assiduidade plena, ou seja, sem nenhuma falta, caso o aluno tenha falta, será descontado 1 (um) ponto para cada falta nas aulas que correspondem a 4 (quatro) horários e 0,5 (meio) ponto para cada falta em aulas de 2 horários, até seu saldo esgotar.

Topo