Please enable JavaScript.
Coggle requires JavaScript to display documents.
02 - Engenharia de Software (Extreme Programming (XP) (processo para…
02 - Engenharia de Software
Conceitos Gerais
desenvolvimento de SW
métodos
processo
ferramentas
Foco na qualidade
princípios
abstração (considerando apenas os aspectos mais relevantes)
decomposição (divide o problema em partes)
formalidade (processos definidos - desenvolver, testar etc)
flexibilização (permite alteração)
generalização (reaproveitar solução)
disciplinas
Projeto de Software (desenha-se a solução do problema)
Construção de Software (implementação ou
codificação em si)
Análise de Software (desenha-se o problema)
Testes de Software (realizam-se verificações para garantir sua
consistência e funcionamento)
Requisitos de Software (entender e levantar os requisitos)
Implantação de Software (coloca-se
o software em produção na organização)
Requisitos de Negócio (entender como o negócio funciona)
Manutenção de Software (busca manter o software funcionando)
A engenharia de SW está inserida no contexto das Engenharias de Sistemas, de Processo e de Produto
principais atividades
desenvolvimento
validação
evolução
especificação
é uma disciplina de engenharia que se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a manutenção desse sistema, após sua entrada em produção – passando por aspectos humanos, hardware também, etc
Metodologias Ágeis
manifesto ágil
valorizar mais software em funcionamento do que documentação abrangente
valorizar mais colaboração com o cliente do que negociação de
contratos
valorizar mais indivíduos e suas interações do que processos e
ferramentas
valorizar mais a resposta a mudanças do que seguir um
planejamento específico
princípios
Entregar frequentemente software funcionando
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto
Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente
Construa projetos em torno de indivíduos motivados
busca se adaptar às necessidades dos clientes e entregar valor
continuamente
conversa face a face
Software funcionando é a medida primária de progresso
desenvolvimento sustentável (ritmo constante, sem horas extras)
Contínua atenção à excelência técnica e bom design aumenta a agilidade
Simplicidade
equipes auto-organizáveis
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo
A abordagem ágil comum é fixar tempo e preço, deixando o escopo variar (os requisitos são variáveis) de forma controlada
Domain Driven Design (DDD)
Abordagem de desenvolvimento de software para lidar com comportamentos complexos na construção de um software.
Ele tem três premissas:
focar o projeto no domínio principal e no domínio lógico;
basear projetos complexos em um modelo do domínio; e
iniciar uma colaboração com os especialistas técnicos e de domínio para refinar o modelo conceitual
Modelo é um sistema de abstrações que descrevem aspectos específicos de um domínio
Domínio é uma área de conhecimento, i.e., é o assunto do problema
O objetivo central de um software é melhorar a utilização ou aplicação dos processos de negócio de um domínio específico
Técnicas para Planejamento de Escopo em Projetos Ágeis
priorização binária
ordenar o escopo inteiro de projetos e suas atividades da prioridade mais alta à prioridade mais baixa
Priorização baseada em Valor de Negócio
Priorização MoSCoW
acrônimo para Must Have, Should Have, Could Have e Won’t Have
Priorização Kano
dividem-se os requisitos em Must-be, Onedimensional, Attractive, Indifferent e Reverse
Ciclo de Vida de Software
fases
Desenvolvimento ou Construção
Operação ou Utilização
Definição ou Concepção
Retirada ou Aposentadoria
Processos de Desenvolvimento de Software
modelos específicos
métodos formais
baseado em componentes
iterativo
incremental
RUP
metodologias ágeis
RAD
evolucionário
prototipagem
Exploratória / Evolucionária
Throw-away / descartável
espiral
sequencial ou linear
cascata ou clássico
Extreme Programming (XP)
metodologia ágil de desenvolvimento de software para equipes pequenas, coesas e multidisciplinares cujos projetos possuem requisitos vagos e em constante mudança
todos os requisitos são expressos como
cenários
(também chamados
histórias do usuário
)
Os
programadores trabalham em pares
e desenvolvem
testes para cada tarefa antes da escrita do código
processo para desenvolver um incremento
Planejar versão
Desenvolver, integrar e testar SW
Dividir histórias em tarefas
Liberar o SW
Selecionar cenário para a versão atual
Avaliar o sistema
PRÁTICAS
Projeto Simples (atenda aos requisitos atuais e nada mais)
Desenvolvimento Test-First
Pequenos Releases (O conjunto mínimo útil de funcionalidade que agrega valor ao negócio é desenvolvido primeiro)
Refactoring
Planejamento Incremental (as histórias a serem incluídas em um release são determinadas pelo tempo disponível e sua prioridade relativa)
Programação em Pares
Propriedade Coletiva (Qualquer um pode mudar
qualquer coisa)
Integração Contínua
Ritmo Sustentável (Trabalhar por longos períodos se torna
contraproducente)
Metáforas (caso consiga encontrar uma que realmente faça sentido dentro do contexto e possa facilitar a comunicação)
Cliente On-site (o cliente é um membro da equipe de desenvolvimento e é responsável por trazer os requisitos do sistema)
Reuniões em Pé
Time Coeso (equipe multidisciplinar)
Jogo do Planejamento (Os clientes priorizam e os desenvolvedores avaliam e estimam)
atividades principais
projeto
codificação
planejamento
teste
valores fundamentais
feedback
coragem (para refatorar o código, quando necessário)
simplicidade (desenvolver funções que não são necessárias hoje pode ser prejudicial)
respeito (garante um alto nível de motivação e incentiva a lealdade dentro da equipe)
comunicação (comunicar os requisitos do sistema para os desenvolvedores)
princípios básicos
Presumir Simplicidade (problema resolvido da maneira mais simples possível)
Mudanças Incrementais (solução deve ser aperfeiçoada a cada iteração)
Abraçar Mudanças: mudanças devem ser bem-vindas
Trabalho de Qualidade: a qualidade jamais deve ser comprometida
Feedback Rápido(retorno tempestivo do cliente a cada mudança)
as novas versões de software podem ser compiladas várias vezes por dia e os incrementos são entregues para os clientes aproximadamente a cada duas semanas.
A nova compilação do software será aceita somente se todos os testes foram executados com sucesso
Scrum
Scrum é um framework leve, simples de entender e extremamente difícil de dominar, para desenvolver e manter produtos complexos e adaptativos
pilares (é o famoso T I A)
Inspeção
A ideia aqui é identificar rapidamente qualquer desvio sobre a meta que deve ser atingida
Adaptação
Como mudanças sempre ocorrem, recomenda-se a adaptação em vez de evitá-las
Transparência
O objetivo é encarar as dificuldades de forma honesta e chegar a um consenso sobre como estes podem ser ultrapassados
papéis -
Time Scrum
(auto-organizável e multifuncional)
Scrum Master
Responsável pela gestão de pessoas e gestão do processo
Ele deve garantir que o Scrum seja entendido e aplicado.
Development Team
Responsável pela micro-gestão e pela criação do produto
não contem sub-times dedicados a domínios específicos de
conhecimento, tais como teste ou análise de negócios
a equipe deve ter entre 3 e 9 integrantes
Product Owner
responsável pela macro-gestão e pela gestão do produto
O Time de Desenvolvimento só responde ao Product Owner. Além disso, só ele pode cancelar uma sprint
artefatos
Sprint Backlog
O Sprint Backlog é o conjunto de itens selecionados para serem implementados durante a sprint mais o plano para transformá-los em um incremento.
Definition of Ready (DoR), que significa que o
requisito tem informações suficientes para começar a ser desenvolvido imediatamente
Product Increment
Ao final de cada sprint, a equipe de desenvolvimento entrega um incremento do produto, resultado do que foi produzido durante a sprint
Definition of Done (DoD) é um acordo formal que define
claramente quais são os passos mínimos para a conclusão de um item ou funcionalidade potencialmente entregável
Product Backlog
Product Backlog é uma lista ordenada (por valor, risco, prioridade, entre outros) criada pelo Time Scrum de requisitos ou funcionalidades que o produto deve conter
o formato mais utilizado para os itens são Estórias de
Usuário (User Stories)
somente o Product Owner pode inserir, remover ou reordenar esses itens
O Product Backlog apresenta itens de negócio (ou funcionais), itens não-funcionais, itens arquiteturais e itens de infraestrutura
Gráfico Burndown
torna visível a evolução diária do trabalho da equipe de desenvolvimento, na medida em que mostra a comparação entre o trabalho estimado inicialmente com a quantidade restante estimada de trabalho
eventos
Daily Meeting
A Reunião Diária (Máximo de 15 minutos) é
um evento que busca criar um plano para as próximas 24 horas e inspecionar o trabalho desde a última Reunião Diária
Sprint Review
inspecionar o que a equipe de desenvolvimento produziu e colher opiniões e impressões dos presentes para, caso seja necessário, adaptar o plano para a sprint seguinte. O foco é aprimorar o produto
Sprint Planning
planeja o trabalho a ser realizado na Sprint. a Equipe de Desenvolvimento
decide como irá transformar os itens selecionados (do product backlog), pelo PO, em um incremento durante a Sprint e desenvolve o Sprint Backlog
Sprint Retrospective
é uma chance para o Scrum Team inspecionar a si próprio e criar um plano de melhorias para a próxima sprint
Reunião de Visão
Product Owner deve expor os detalhes do produto a ser construído
Release Planning Meeting
muitas vezes é desejável esperar algumas sprints até juntas todas as funcionalidades e entregar uma release (conjunto de funcionalidades).
Essa cerimônia serve para planejar como será essa release
fluxo
sprint
ao fim de cada sprint, deve-se entregar um incremento potencialmente funcional do produto ao cliente
duração de 2 a 4 semanas
As sprints são compostas por uma Reunião de Planejamento da Sprint, por Reuniões Diárias, pelo Trabalho de Desenvolvimento, por uma Revisão da Sprint e pela Retrospectiva da Sprint
ciclo de vida
Pré-Planejamento (Pre-game Phase) Define o sistema sendo desenvolvido. Cria-se o Product Backlog
Desenvolvimento (Game Phase) O sistema é desenvolvido em sprints
Pós-Planejamento (Post-game Phase) integração, testes finais e documentação