João Cerdeira é um líder de equipa e entusiasta do Agile. Apresenta os princípios e práticas do Agile como uma alternativa ao modelo tradicional Waterfall para gerir projetos de software de forma mais flexível e iterativa. Introduz o framework Scrum como uma das abordagens mais populares do Agile, explicando os seus artefactos, papéis e eventos.

1. Introdução ao Agile

2. 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

3. 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.

4. Agenda
Waterfall Agile
Scrum Conclusão

5. 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

6. 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

7. Agenda
Waterfall Agile
Scrum Conclusão

9. 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

10. 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

11. 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

12. Princípios
Agile
Cria Visão Global
-> Todos participam nas decisões
-> Todas as decisões são públicas
-> Mantêm terminologias comuns
entre todos os elementos do projeto
image:http://www.criacionismo.com.br/2012/04/transparencia-nova-mentira.html

13. Princípios
Agile
Processo Orientado ao Cliente
-> 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
image:http://www.criacionismo.com.br/2012/04/transparencia-nova-mentira.html

14. Princípios
Agile
Colaboração Diária
-> Clientes e Equipa devem comunicar diariamente
-> A comunicação deve ser, preferencialmente, cara a cara
-> Os temas devem centrar-se:
Troca de informação
Estratégia comum

15. Princípios
Agile
Manter o Fluxo
-> 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)

16. Princípios
Agile
Pensar em Grande,
Mas começar pequeno
-> Entregar “coisas” pequenas, o mais
cedo possível
-> Recolher feedback, o mais cedo
possível
-> Realizar entregas com valor de
forma regular

17. Princípios
Agile
Outros
-> 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

18. Iterativo
Incremental
Incremental
Iterativo

19. Agenda
Waterfall Agile
Scrum Conclusão

20. XP
Técnicas Software importantes
-> TDD
-> Continuous Integration
-> Pair Programming
-> Acceptance Tests
-> Refactoring

21. Princípios do
Scrum
Comunicação
Simplicidade
Respeito
Feedback
Coragem

22. Scrum
http://www.slideshare.net/rdelyon/scrum-poster

23. 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

24. Artefactos
User Story #2
Cunhado 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/

25. Artefactos
Backlog de produto
-> Lista de User Stories
-> Ordenada Por “Business Value”
-> Stories mais detalhadas no início da lista
-> Priorizada pelo “Product Owner”
http://www.slideshare.net/rwirdemann/user-stories-for-your-product-backlog

26. Artefactos
Sprint Backlog
-> Conjunto de User Stories a entregar numa “Sprint”
-> Pertence à equipa de desenvolvimento
-> Depois do “Sprint” começar, não pode mudar

27. 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

28. 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

29. 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/

30. Papéis
Scrum Team
-> Equipas pequenas mais de 3
e 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

31. 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

32. 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 um
facilitador
http://uni4.com.br/blog/tag/sprint-planning-meeting/

33. Reuniões
Sprint Planning #2
A equipa deve estimar as User Stories antes da reunião
de “Sprint Planning”, numa reunião marcada para o
efeito

34. 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

35. Reuniões
Retrospetiva
-> Reunião que deve ser feita
no final de cada Sprint
-> Objetivo é identificar:
O que correu bem
O que correu menos bem
As acções que devem ser tomadas para melhorar

36. 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/

37. Estimativa
Planning Poker
http://www.crisp.se/planningpoker/

38. Estimativa
Planning Poker
http://www.crisp.se/planningpoker/

39. Estimativa
Planning Poker
http://www.crisp.se/planningpoker/

40. 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/

41. Planeamento

42. Planeamento

43. Planeamento
BurnDown Charts
-> Indicador de progresso da “Sprint”
-> Permite à equipa ver a evolução
e, caso seja necessário, tomar
medidas
-> Deve estar visível para todos
Vertical: Story Points
Horizontal: Dias

44. Planeamento
Velocity
-> Número de Story Points que a
equipa 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 Points
Por Sprint (2 semanas) são efectuados 50 SP
Ou seja, projeto demora 2 * 10 Semanas
http://agilemakingprogress.blogspot.pt/2011/04/velocity-and-release-planning.html

45. Planeamento
-> Caso seja necessário, podemos dividir o projeto em
releases
-> Dessa forma podemos ter vários níveis, como:
Projecto
Fase #1
Release #1
Sprint #1
Sprint #2
Release #2
Sprint #N1
Sprint #N2
Fase #2
….............

46. Scrum
http://www.slideshare.net/rdelyon/scrum-poster

47. Agenda
Waterfall Agile
Scrum Conclusão

48. Scrum na Gestão
“Scrum Is A Major Management Discovery”
by Steve Denning
http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/
“Executive Scrum” by Alexandre Magno
http://www.slideshare.net/gueste1b6a5b/an-executive-scrum-team
Management 3.0

49. Scrum para
Projetos grandes
Scrum of Scrums
http://www.mountaingoatsoftware.com/scrum/team

50. 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 …..

51. 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

52. 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

53. 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)

54. Sucesso
O Grupo Gartner previu que 80% dos projetos de
desenvolvimento de software em 2012 terão metodologias
ágeis
http://www.gartner.com/DisplayDocument?id=1244514
PMI abriu um área para Agile:
PMI Agile Certified Practitioner (PMI-ACP)
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
CMMI também quer ser Agile:
http://www.sei.cmu.edu/cmmi/compatibility/agile.cfm

55. Sucesso
O Grupo Gartner previu que 80% dos projetos de
desenvolvimento de software em 2012 terão metodologias
ágeis
http://www.gartner.com/DisplayDocument?id=1244514
PMI abriu um área para Agile:
PMI Agile Certified Practitioner (PMI-ACP)
http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx
CMMI também quer ser Agile:
http://www.sei.cmu.edu/cmmi/compatibility/agile.cfm
Porque é que todos quem estar ligados ao Agile ?

56. Q&A
?