View
1.089
Download
2
Category
Preview:
DESCRIPTION
Citation preview
Introdução ao Agile
Quem sou ?
-> Nome: João Cerdeira-> Team Leader na MULTICERT-> Entusiasta do Agile: Scrum / Kanban / Lean-> Acredito, realmente, no sucesso do OpenSource-> Co-Organizador dos Porto Agile Meetups
http://twitter.com/jacerdeira cerdeira@gmail.com
Disclamer-> Posso entender as vossas questões, mas não tenho resposta para tudo!
-> Não trabalho numa empresa Agile!
-> Mas uso Agile em projetos e com a minha equipa.
Agenda
Waterfall Agile
Scrum Conclusão
Waterfall
Processo definido e previsível
Fases sequenciais
Planeamento Integral no início do projeto
Os Riscos e as Dificuldades são agravadas com o aproximar do término do projeto
Waterfall Problemas
-> Não lida bem com a mudança
-> A especificação é abstrata e pode ser interpretada de diferentes formas
-> Poucos testes durante o desenvolvimento
-> Integração tardia
-> O progresso é medido pela % de tarefas executadas
-> O “Business Engagement” diminui com o tempo
Agenda
Waterfall Agile
Scrum Conclusão
Agile Manifest
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile
-> Aborda os projetos de forma incremental e iterativa
-> Facilita mudanças no projeto
-> Com frequentes entregas, aumenta o “Business Value”
-> Aumenta a clareza do projeto para todos os intervenientes
-> Progresso medido por testes efetuados com sucesso
-> Melhoramento progressivo devido à observação periódica
Agile
-> Processos empíricos e adaptativos
-> Ciclos pequenos e repetitivos
-> Planeamento a curto prazo com constante feedback, inspeção e adaptação
-> Desenvolvimento iterativo diminui a complexidade, nas fases finais do projeto
PrincípiosAgile
-> Todos participam nas decisões
-> Todas as decisões são públicas
-> Mantêm terminologias comunsentre todos os elementos do projeto
Cria Visão Global
image:http://www.criacionismo.com.br/2012/04/transparencia-nova-mentira.html
PrincípiosAgile
-> Trabalhar sempre na perspetiva do cliente
-> Deixar ser o cliente/utilizador a decidir o que é mais importante
-> Prioridade máxima às tarefas que acrescentam valor ao cliente
-> Aceitar com agrado a mudança
Processo Orientado ao Cliente
image:http://www.criacionismo.com.br/2012/04/transparencia-nova-mentira.html
PrincípiosAgile
-> Clientes e Equipa devem comunicar diariamente
-> A comunicação deve ser, preferencialmente, cara a cara
-> Os temas devem centrar-se:Troca de informaçãoEstratégia comum
Colaboração Diária
PrincípiosAgile
-> Projeto dividido em “Timeboxes” para manter as entregas constantes
-> Tarefas centralizadas numa lista, todos os membros do projeto sabem quais são as próximas tarefas
-> Trabalho constante e regular mantém a paz (diminui as horas extras)
Manter o Fluxo
PrincípiosAgile
-> Entregar “coisas” pequenas, o mais cedo possível
-> Recolher feedback, o mais cedo possível
-> Realizar entregas com valor de forma regular
Pensar em Grande,Mas começar pequeno
PrincípiosAgile
-> Reflexões constantes e periódicas (Melhoria contínua)
-> Eliminar os desperdícios (funcionalidades desnecessárias, requisitos não usados, …)
-> Equipas pequenas e multi-disciplinares
-> Requisitos e Arquitectura evoluem ao longo do tempo
-> Desenvolvimento iterativo e incremental
Outros
IterativoIncrementalIncremental
Iterativo
Agenda
Waterfall Agile
Scrum Conclusão
XP
-> TDD
-> Continuous Integration
-> Pair Programming
-> Acceptance Tests
-> Refactoring
Técnicas Software importantes
Princípios doScrum
Comunicação
Simplicidade
Respeito
Feedback
Coragem
Scrum
http://www.slideshare.net/rdelyon/scrum-poster
Artefactos
User Story #1
-> Representam um objetivo a ser alcançado (requisito)
-> Deve ser estimado em Story Points (sequência fibonacci)
-> DoD (Definition of Done)
-> Pode ter vários tamanhos – Epic, Feature and Story
Artefactos
User Story #2Cunhado pelo Mike Cohn
Exemplo:
As a User I want to have access to detailed billing information so that I can manage the month billing value
http://sanjaal.com/java/tag/agile-story-card-example/
Artefactos
http://www.slideshare.net/rwirdemann/user-stories-for-your-product-backlog
Backlog de produto
-> Lista de User Stories
-> Ordenada Por “Business Value”
-> Stories mais detalhadas no início da lista
-> Priorizada pelo “Product Owner”
Artefactos
Sprint Backlog
-> Conjunto de User Stories a entregar numa “Sprint”
-> Pertence à equipa de desenvolvimento
-> Depois do “Sprint” começar, não pode mudar
TimeBoxes
Sprints
-> Periodo Fixo para cada entrega de conjunto de User Stories (1 a 6 semanas)
-> Entrega Potencial do produto no final
-> Inclui todas as fases do projeto:Planeamento, Desenvolvimento, testes, etc
-> A duração deve manter-se constante
Papéis
Product Owner-> Um por projeto !!
-> Toma as decisões do produto/projeto
-> É o responsável pela BackLog de Produto
-> Tem a última palavra no planeamento da release/sprint
-> Tem a obrigação de explicar as User Stories à equipa
http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-activities-product-owner
Papéis
Scrum Master-> Um por equipa
-> Responsável por transmitir os valores do Scrum
-> Garante que o processo é seguido
-> Responsável por resolver os impedimentos
-> É o líder da equipa (facilitador)
http://blogs.collab.net/agile/2011/04/05/a-scrummaster-of-scrummasters/
Papéis
Scrum Team-> Equipas pequenas mais de 3e menos de 9 (ideal 5 a 9)
-> Equipas multidisciplinares (dev, testes, BAs, etc)
-> Poder de decisão, mas também mais responsabilidade
-> Equipas Auto-Organizadas
-> As equipas devem ser estáveis e alocadas a 100% ao projeto
Reuniões
Daily Scrum-> Reunião da equipa em pé
-> Reunião Diária a horas fixas
-> Não deve durar + de 15 min
-> Cada membro da equipa deve dizer:O que fez ontem ?O que tem para fazer hoje ?Que impedimentos tem ?
http://martinfowler.com/articles/itsNotJustStandingUp.html
Reuniões
Sprint Planning #1-> Planeamento do próximo “Sprint”
-> É decidido quais as User Stories que serão entregues
-> Todos os membros têm de se comprometer com as User Stories
-> O PO leva a backlog priorizada
-> O Scrum Master actua como umfacilitador
http://uni4.com.br/blog/tag/sprint-planning-meeting/
Reuniões
Sprint Planning #2A equipa deve estimar as User Stories antes da reunião de “Sprint Planning”, numa reunião marcada para o efeito
Reuniões
Sprint Review
-> Reunião no final de cada Sprint
-> Deve incluir todas as pessoas do projeto
-> É efetuada uma “demo” para demonstrar o progresso executado no Sprint
-> O Product Owner (ou cliente) avalia o sucesso do Sprint
http://www.ogcnetwork.net/node/279
Reuniões
Retrospetiva
-> Reunião que deve ser feita no final de cada Sprint
-> Objetivo é identificar:O que correu bemO que correu menos bemAs acções que devem ser tomadas para melhorar
Reuniões
PIGs and Chickens
Pigs: Product Owner, Scrum Master, Dev Team.Chickens: Users, Stakeholders, Managers.
http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/
Estimativa
Planning Poker
http://www.crisp.se/planningpoker/
Estimativa
Planning Poker
http://www.crisp.se/planningpoker/
Estimativa
Planning Poker
http://www.crisp.se/planningpoker/
Estimativa
Planning Poker
A equipa deve sempre tentar chegar a um consenso
Em caso de dificuldades, o Scrum Master é que tem a última palavra
http://www.crisp.se/planningpoker/
Planeamento
Planeamento
BurnDown Charts-> Indicador de progresso da “Sprint”
-> Permite à equipa ver a evoluçãoe, caso seja necessário, tomarmedidas
-> Deve estar visível para todos
Vertical: Story PointsHorizontal: Dias
Planeamento
Velocity-> Número de Story Points que aequipa consegue entregar numa Sprint
-> Usado para medir as datas em que as User Stories são entregues ou a finalização do projeto
-> Exemplo:Backlog tem 500 Story PointsPor Sprint (2 semanas) são efectuados 50 SPOu seja, projeto demora 2 * 10 Semanas
Planeamento
http://agilemakingprogress.blogspot.pt/2011/04/velocity-and-release-planning.html
Planeamento
-> Caso seja necessário, podemos dividir o projeto em releases
-> Dessa forma podemos ter vários níveis, como:
ProjectoFase #1
Release #1Sprint #1Sprint #2
Release #2Sprint #N1Sprint #N2
Fase #2….............
Scrum
http://www.slideshare.net/rdelyon/scrum-poster
Agenda
Waterfall Agile
Scrum Conclusão
Scrum na Gestão
“Scrum Is A Major Management Discovery” by Steve Denning
“Executive Scrum” by Alexandre Magno
Management 3.0
http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/
http://www.slideshare.net/gueste1b6a5b/an-executive-scrum-team
Scrum para Projetos grandes
Scrum of Scrums
http://www.mountaingoatsoftware.com/scrum/team
Agile não Têm
-> Não tem Análise de Risco
-> Não tem política de Aquisição de Serviços
-> Não obriga a documentação detalhada
-> Não tem processo de alterações
-> Não tem …..
Agile não Têm
-> Não tem Analise de Risco
-> Não tem politica de Aquisição de Serviços
-> Não obriga a documentação detalhada
-> Não tem processo de alterações
-> Não tem …..
Mas em lado nenhum diz que não se pode fazer …. se for necessário deve-se fazer da forma mais adequada
Resumo
-> Processo Simples e Escalável
-> Processo Empírico
-> Técnicas e Artefactos simples
-> Equipas auto-organizadas em colaboração com o Cliente
-> Cria uma forte abertura e clareza
-> Tenta optimizar o trabalho em equipa
Lições Aprendidas
-> O Scrum (agile) é simples na teoria, mas difícil de executar na prática
-> O Scrum é muito exigente: a cada 2 semanas são efectuadas 3 Reuniões com toda a equipa
-> Não é fácil para pessoas que não participaram nunca em estimativas ser-lhes dada essa responsabilidade
-> O Scrum é como a Sogra – Mostra que existem problemas, mas não indica como resolvê-los
-> Os processos são como um buffet, quanto mais se tem disponível mais se come (consome)
Sucesso
O Grupo Gartner previu que 80% dos projetos de desenvolvimento de software em 2012 terão metodologias ágeis
PMI abriu um área para Agile:PMI Agile Certified Practitioner (PMI-ACP)
CMMI também quer ser Agile:
http://www.sei.cmu.edu/cmmi/compatibility/agile.cfm
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
http://www.gartner.com/DisplayDocument?id=1244514
Sucesso
O Grupo Gartner previu que 80% dos projetos de desenvolvimento de software em 2012 terão metodologias ágeis
PMI abriu um área para Agile:PMI Agile Certified Practitioner (PMI-ACP)
CMMI também quer ser Agile:
Porque é que todos quem estar ligados ao Agile ?
http://www.sei.cmu.edu/cmmi/compatibility/agile.cfm
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
http://www.gartner.com/DisplayDocument?id=1244514
Q&A
?
Recommended