Engenharia de Software Ágil

Prévia do material em texto

Desenvolvimento Ágil
Ementa
Introdução à Engenharia de Software;
Desenvolvimento Ágil;
Engenharia de Requisitos;
UML;
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
Product Backlog
Lista priorizada dos requisitos necessários para transformar a visão em produto;
Deve existir apenas um backlog durante toda a vida do projeto e ele deve refletir tudo que precisa ser feito;
A priorização é baseada no valor de negócio, dependências e riscos;
Escrita em linguagem de negócio;
Idealmente expressada de forma que cada item tenha valor para o usuário;
Qualquer um pode contribuir com itens para o backlog;
Product Backlog
O Product Owner é responsável pela priorização e por ter certeza que os requisitos estão bem formatados;
É regularmente atualizado pelo Product Owner para refletir as mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, ideias novas, mudanças em geral;
Composto de vários itens: funcionalidades, requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs, etc.;
Product backlog – Sistema de Hotel
Backlogitem
Estimativa
Permitir cliente realizarreservas
3
Como cliente, eu gostaria de cancelara minha reserva
5
Como cliente, eugostaria de alterar as datas da minha reserva
3
Como funcionário do hotel, eu gostaria de ter acessoao relatórioRevPar(revenue-per-available-room)
8
Melhorar o tratamento de exceção
8
ControleFinanceiro
30
Controle Contábil
50
...
...
Product Backlog
Se a priorização está nas mãos do cliente, as funcionalidades que realmente importam estão no topo do Product Backlog.
Product Backlog
Product Backlog
A priorização deve acontecer antes do início da Sprint Planning Meeting, mas pode ser refinada no seu decorrer;
Boas técnicas de priorização:
Kano;
Theme Screening;
Priorization Poker (Planning Poker);
Método de triagem MoScoW
Must Have: 
Sem este item, não podemos entregar;
Should Have: 
Precisamos negociar;
Could Have: 
Nos dará uma certa vantagem;
Nice to Have: 
Seria bom ter, mas não agora;
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
Item do Product Backlog
É uma pequena descrição que detalha um item do Product Backlog, também chamado de estória ou user stories;
Uma estória ajuda no entendimento e também é utilizada como lembrete para as atividades de planejamento;
Permite fazer a estimativa de velocidade da equipe e a duração da sprint;
Geralmente a estimativa é feita em pontos ou horas/dias;
Podem incluir de testes de aceitação;
Item do Product Backlog
Como escrever uma estória:
Conversações sobre a estória, entre os usuários e desenvolvedores, de modo a detalhar o item e esclarecer todas as dúvidas sobre o que deve ser feito;
Como <tipo de usuário>,
posso <fazer>
para que <razão>.
Exemplo de User Stories de sistema de locadora
Exemplo de User Stories de sistema de livraria
Estórias devem ser INVEST
Independt(Independente): mesmo sendo impossível para alguns sistemas, tenha em mente que uma User Story deve ser independente;
Negotiable(Negociável): Uma User Story não é um contrato. Não é uma especificação detalhada. É apenas uma introdução às funcionalidades para que a equipe possa discutir e colaborar para esclarecer os detalhes próximos ao momento de desenvolver a funcionalidade;
Valuable(Valiosa): Uma User Story deve ser valiosa para o cliente. Deve ser escrita em linguagem de negócio. Deve ser a descrição de uma funcionalidade, não uma tarefa;
Estórias devem ser INVEST
Estimatable(Estimável): User Stories devem ser passíveis de serem estimadas. Devem prover informação suficiente para serem estimadas, sem serem muito detalhadas;
Small(Pequena): Nem pequena demais, nem grande demais. User Stories devem ser do tamanho suficiente para o entendimento do que é a funcionalidade;
Testable(Testável): User Stories devem ser claras o suficiente para serem testáveis;
Atividade
Escrever User Stories para o sistema de radio online;
Papéis
Timeboxes
Artefatos
Product Owner
Release Planning
Product Backlog
Scrum Master
Spring Planning
Product Backlog Item
Team
Sprint
Sprint Backlog
Daily Meeting
Scrum Board
Sprint Review
Burndown Chart
Sprint Retrospective
Sprint Planning Meeting – Parte 1
Usada para determinar o trabalho que pode ser completado dentro da próxima sprint;
O time se compromete com aquilo que sentem que podem realizar;
É determinada a meta da sprint;
Time puxa itens do Product Backlog;
Colabora com o PO para entender melhor cada um dos requisitos;
Determina o que pode ser transformado em funcionalidade potencialmente entregável;
Define as tarefas para as estórias selecionadas;
Inclui estimativas para alcançar a definição de “pronto”;
Sprint Planning Meeting – Parte 2
A segunda parte da reunião existe para o time realizar o que estão se preparando para construir e como eles vão fazer para que seja feito;
Artefatos: Desenho, Sprint Backlog, Desenho;
Qual é o desenho para os itens que o time se comprometeu em fazer? Então o time realiza como eles irão desenvolver a funcionalidade, que se traduz em quem faz o que: Tarefas!
O PO está presente para fazer esclarecimentos e tomar decisões quanto ao design da aplicação;
Nossa etapa o time pode se descomprometer com estórias ou novas estórias podem ser incluídas;
Definição de pronto
O time deve ter uma definição de “pronto”: especificado, implementado, testado, integrado, documentado?
O time deve ser capaz de produzir pedaços de código prontos em todas as sprints;
PO faz inspeção e adaptação para otimizar o ROI;
O trabalho “incompleto” precisa ser identificado;
Undone work é um item do Product Backlog que precisa ser finalizado antes de entrar em produção;
Undone work cresce gradativamente a cada sprint;
Estimando o Product backlog
Estimando “tamanho” da leitura
1 2 3 5 8 13
759 págs
368 págs
50 págs
158 págs