Os Métodos Ágeis
Por: AmorimJefferson • 5/1/2023 • Trabalho acadêmico • 1.712 Palavras (7 Páginas) • 87 Visualizações
Atividade individual
Matriz de atividade individual | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Estudante: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Disciplina: Métodos Ágeis | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Turma: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ETAPA 1 – DEFINIÇÃO DO PRODUTO | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Para definição do produto, será utilizado a ferramenta sete dimensões de um produto, com o intuito de alinhar o que será necessário para o desenvolvimento e identificar os critérios de análise e de qualidade, conforme visto na apostila do curso de Métodos Ágeis.
Para garantir um alinhamento e uma visão simplificada do aplicativo, abaixo segue a vision box do projeto, com as principais funcionalidades, conforme visto na apostila de Métodos Ágeis, a realização de uma caixa de produto contendo as principais informações, garante que o produto seja compreendido com maior facilidade. [pic 1] Abaixo será apresentado o elevator speech do projeto, conforme vimos em sala de aula, o elevator speech é um pequeno resumo que define de forma simples e rápida um processo, serviço, organização... Neste caso usaremos para definir o projeto. Elevator speech: Aplicativo que facilita e agiliza os atendimentos dos postos de saúde, possibilitando os usuários da rede pública de saúde acessar de casa as informações dos postos mais próximo a sua residência, tendo visibilidade das agendas dos médicos, possibilitando agendar suas consultas via smartphones, verificar status dos exames, localizar e verificar estoques dos remédios disponíveis na farmácia do posto, amenizando assim o fluxo de pessoas que frequentam presencialmente o local, dando maior agilidade nos atendimentos presenciais e diminuindo o tempo de espera em filas para atendimento. Personas [pic 2]José Augusto Santos tem 69 anos, é carpinteiro aposentando com 1 salário mínimo, casado, reside em Blumenau-SC, tem 5 filhos e 8 netos, seus filhos moram em outras cidades, para José sair de casa, necessita solicitar transporte via app ou depender de caronas de vizinhos. Durante sua vida profissional, José não cuidou da sua saúde, realizou muitos movimentos errados que prejudicaram a saúde de sua coluna, atualmente tem seus movimentos limitados e sente muita dor, frequenta a fisioterapia para amenizar as dores e conseguir manter os movimentos que ainda consegue realizar, utiliza a rede pública de saúde pois não consegue com sua aposentadoria pagar fisioterapia particular. [pic 3]Ana Maria Cardoso tem 28 anos, auxiliar de produção de uma empresa que produz calçados, seu salário é de 2 mil reais por mês, Ana Maria reside em Jaraguá do Sul – SC, é mãe solteira da menina Maria Alice Cardoso, sua filha tem 1 ano e 4 meses de idade e tem saúde frágil, sofre de vários problemas ocasionados por imunidade baixa, Ana Maria necessita usar os postos de saúde com frequencia, devido ser solteira, precisa larga o trabalho para marcar consultas para sua filha, com suas saídas frequentes para marcar e depois ir nas consultas, Ana está com medo de perder o emprego e ficar sem sua renda mensal, sua família e do estado do Pará, Ana está 3 anos sem visitar seus pais. User stories
Mínimo Viável do Produto (MVP) O MPV do projeto, definido entre o PO e a equipe de desenvolvimento, contempla os seguintes itens:
Esses itens do MPV, garantem que o app funcione na versão mais básica, assim gera o mínimo de esforço do desenvolvimento, porém atende os principais objetivo do projeto e pode ser testado pelos usuários, depois de lançado, o MVP será aprimorado com o backlog. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ETAPA 2 – PLANEJAMENTO DAS ENTREGAS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Backlog do Produto Abaixo segue lista do backlog do produto, com as priorizações definidas pelo PO e de acordo com as User Stories que passaram por um refinamento.
O backlog do produto deve ser atualizado no decorrer dos sprints finalizados, podendo surgir novas necessidades dos stakeholders. Valor de retorno para o cliente e o esforço da equipe para cada tarefa. Abaixo segue tabela com o valor de retorno (B.V) para o cliente, sendo que temos duas personas, o peso é de 50% para cada uma delas, cada persona dará uma nota com escala de 0 à 10 para cada tarefa, sendo que 0 significa que não é nada importante e 10 significa que é extremamente importante. O esforço para cada tarefa será definido pelo time de desenvolvimento do produto, uitilizando a escala de Fibonacci (1,2,3,5,8,13). [pic 4] Para o cálculo do ROI, foi considerado uma média simples para o valor, sem necessidade de ser ponderada, pois cada usuário tinha o mesmo peso para as notas, e foi dividido pelo peso do esforço (peso do esforço definido pelo time do projeto). Fatie, descarte e priorize o backlog. Com a somatória dos pesos do esforço, chegou-se ao número 50, com a somatória do B.V, chegou-se ao número 75, sendo assim, ficou definido que o ponto de corte tomando como referência o esforço dividido pelo B.V, será de 1,5, onde as tarefas com o ROI menor que este valor será descartado. [pic 5] Descartando as três tarefas que ficaram abaixo da linha de corte, não terá necessidade de fatiar nenhuma tarefa, pois com a divisão dos sprints a equipe conseguirá entegar as tarefas sem necessidade de fatiar. A priorização definida pelo PO, seguiu a mesma ordem do ROI, mas dependendo da tarefa, o PO pode priorizar conforme a necessidade do projeto, neste caso seguiu a mesma ordem prioritária.
Número de sprints, considerando um valor estimado da velocidade da equipe. [pic 6] Velocidade da equipe O valor de esforço para cada sprint definido para o projeto ficou de no máximo 5 de esforço (velocidade da equipe), descartando as tarefas que ficaram abaixo do ROI estipulado, ficou um total de 21 de esforço, dividindo considerando que não poderá ultrapassar o valor de 5, teremos aproximadamente 4,2 sprints para o projeto, arredondados para 5 sprints. Estima-se que cada sprint a equipe levará 3 semanas para finalizar, sendo assim os 5 sprints levarão 15 semanas para serem entregues, considerando que não ocorrerá nenhuma mudança durante este periódo. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
*REFERÊNCIAS BIBLIOGRÁFICAS Caso faça uso de fontes de pequisa, liste-as de acordo com os referenciais da ABNT. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CASTRO, M; BARCAUI, A – E-book Métodos Ágeis. Rio de Janeiro: FGV, 2022. Disponível em: https://ls.cursos.fgv.br/d2l/lor/viewer/viewFile.d2lfile/522151/661875/assets/metodos_ageis. pdf#page=10 Acesso em out. 2022. 7 Dimensões do Produto: uma forma eficiente de escrever User Stories. Disponível em: https://cafecomscrum.com/2016/03/27/as-7-dimensoes-do-produto/ Acesso em out. 2022. Ator – Este software está sendo desenvolvido para ajudar as pessoas a realizarem a reciclagem e coleta seletiva de maneira correta e eficaz. Interface – Para interação o usuário precisará apenas instalar um aplicativo em seu smartphone e realizar o agendamento da retirada. Ação – Com este software os cidadãos poderão agendar junto a empresa a coleta de seus materiais de reciclagem, também terão acesso aos pontos de entrega, caso o usuário tenha interesse em levar seus recicláveis. Informação – O usuário pode agendar e reagendar suas retiradas e alterar dados de seu perfil. Regras do negócio – O agendamento de retirada deve ser realizado com pelo menos um dia de antecedência. Ambiente – Android e IOS Requisitos não funcionais – Por se tratar de um aplicativo novo, poderão surgir alguns requisitos não funcionais que poderão atrapalhar o uso da aplicação em termos de desempenho, usabilidade, segurança e disponibilidade, a falha do não atendimento a um requisito não funcional, poderá tornar todo o sistema ineficaz |
...