O documento discute o desenvolvimento ágil de software. Apresenta Scrum como uma metodologia ágil que requer equipes auto-organizadas capazes de entregar software incrementalmente em releases mensais, mantendo os requisitos em uma lista de backlog do produto priorizada pelo dono do produto. As equipes Scrum se auto-organizam em torno de um objetivo de sprint para completar tarefas em um backlog de sprint durante o sprint de um mês.

1. Desenvolvimento Ágil de Software
Inovador com
José A. S. Alegria
PT Comunicações
<jose.alegria@telecom.pt>
Lisboa, 14 de Novembro de 2007

2. Sinopse
Cada vez mais o desenvolvimento de produtos inovadores tem de ser feito de
forma rápida e envolvendo o desenvolvimento concorrente de todas suas
componentes, e, muito em particular, do software que muitas vezes é o seu
factor principal de diferenciação. As metodologias preconizadas pela engenharia
de software clássica mostram-se demasiado inflexíveis para satisfazer os
requisitos de agilidade que a inovação rápida de produtos intensivos em
software exige. Nesta workshop iremos apresentar uma nova via, já utilizada
internamente no nosso grupo na PT, baseada nos princípios por detrás do
movimento pró agilidade de desenvolvimento de software e, em particular,
aqueles defendidos pela metodologia Scrum hoje usada por empresas com
ciclos rápidos de inovação como a Yahoo, a Google, a Nokia, etc

3. Personal Foundations

4. Ao nível tecnológico, a
“agilidade” no desenvolvimento
de software já me acompanha há
mais de 30 anos!

5. “Old” Personal Foundations
1. Fui pioneiro (1977) na utilização de “programação orientada a objectos” na
construção de todas as fases de um compilador. Introduzi a nível
universitário (Eng.ª Informática) o ensino desta tecnologia de construção de
compiladores.
2. Desenvolvi a primeira implementação de uma DDSL (Declarative Domain
Specific Language) em Portugal (linguagem declarativa de especificação e
simulação de múltiplas carreiras militares) utilizada pelo Departamento de
Investigação Operacional do EMGFA para planear a reestruturação das
carreiras militares no pós guerra colonial.
Projecto que mereceu a uma carta de louvor do EMGFA (Chefe do Estado-
Maior-General das Forças Armadas) em 1979
3. Desenvolvi a primeira aplicação “100% Orientada a Objectos” em Portugal
(1979), integralmente desenvolvida em Simula 67.

6. 1977
1977
The Xerox Star 9010
“Dandelion”
Simula-67 Smalltalk 80

8. …
1977 2001
1977 2001

9. Como profissional a experiência
confirmou-me vezes sem conta
que…

10. A
A

11. B
B
Source: Strategic Management and
Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Beedle.

12. C
C
A produtividade da maioria dos
“knowledge workers” é
significativamente reduzida por
“problemas (GAP) de
comunicação”…

13. D
D
Esse “gap” de comunicação é
sempre mais grave em ambientes
em que o “objecto alvo” é de uma
diferente cultura empresarial,
evolui ou muda rapidamente
Exemplo: ambientes com desenvolvimento rápido
e concorrente de produtos inovadores

14. The New New Product
The New New Product
Development Game
Development Game
Hirotaka Takeuchi and Ikujiro Nonaka
Hirotaka Takeuchi and Ikujiro Nonaka
Harvard Business Review
Harvard Business Review
January 1986
January 1986

16. A forma como a
Eng.ª Química
lida com
processos
“instáveis”…

17. Tal como eu, muitos estão convencidos
que o rápido e concorrente
desenvolvimento de produtos inovadores
(mas não “life critical”) exige dos
“Software Developers” métodos, técnicas
e tecnologias mais ágeis…

18. The Manifesto for Agile Software Development
Kent Beck James Grenning
Mike Beedle Jim Highsmith
www.agilealliance.org Arie van Bennekum Andrew Hunt
Alistair Cockburn Ron Jeffries
Ward Cunningham Jon Kern
Brian Marick
Martin Fowler
“We are uncovering better ways of developing software by
doing it and helping others do it. Through this work we have
come to value”:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.

19. SCRUM
(www.controlchaos.com)

20. SCRUM
(www.controlchaos.com)

21. SCRUM: Origem
• “The New New Product Development Game” in
Harvard Business Review, 1986.
– “The… ‘relay race’ approach to product development…may
conflict with the goals of maximum speed and flexibility.
Instead a holistic or ‘rugby’ approach—where a team tries to
go the distance as a unit, passing the ball back and forth—may
better serve today’s competitive requirements.”

22. SCRUM: Principais Características
É um das principais metodologias pró agilidade
Requer / necessita de equipas com “capacidade” de se auto
organizarem
Os seus “outputs” evoluem de forma incremental numa série de
releases “mensais”
Os requisitos são mantidos como elementos de uma lista que
constitui o “product backlog”
Não impõe nenhuma prática especial ao nível de engenharia de
software mas o recurso competente a tecnologias ágeis
ajuda ☺

23. SCRUM: Sumário

24. SCRUM “Master”
Representa a “gestão” no projecto
Tipicamente é um gestor sénior de projecto ou o chefe
de equipa
É responsável por garantir conformidade das práticas
e valores do “Scrum”
A sua principal tarefa é REMOVER OBSTÁCULOS

25. SCRUM “Team”
Tipicamente 5-10 pessoas
Cross-functional
– QA, Programadores, Designers de Interfaces, etc.
Membros devem, em princípio, ser full-time !
As equipes devem ter capacidade para se auto-
organizarem
Alterações à estrutura da equipe só pode
acontecer entre “sprints”

26. SCRUM “Sprints”
Os projectos Scrum avançam por séries discretas de
“sprints”
Semelhante às iterações do XP
Normalmente a duração de um “sprint” deve ser de um
mês (+/- uma semana ou duas)
• Contudo, uma duração constante induz um melhor ritmo!
O “produto” é concebido, desenhado, programado e
testado durante o “sprint”

27. SCRUM “No changes during Sprints” !!!
A duração dos “sprints” deve ser planeada de forma
a garantir evitar alterações a meio
“TIME BOXED”

28. SCRUM “Product Backlog”
“A lista” com todas as “features” desejadas /
requeridas
Normalmente é uma combinação de…
• story-based work (“let user search and replace”)
• task-based work (“improve exception handling”)
“A lista” é prioritizada pelo “Product Owner”
Tipicamente o Gestor de Produto, Marketing, um responsável
pelo negócio, etc. Normalmente não é um “informático”!

29. SCRUM “No changes during Sprints”

30. SCRUM: do “Sprint Goal” ao “Sprint Backlog”
A equipa “Scrum” pega no “Sprint Goal” e decide
que tarefas são necessárias para o concretizar
A equipa auto-organiza-se à volta da forma como
pretendem atingir o “Sprint Goal”
Não é o Project Manager que paternalistamente atribui
tarefas aos seus subordinados…
Os “chefes hierárquicos” não impõem decisões à
equipa
O “Sprint Backlog” é criado

31. SCRUM: Gestão do “Sprint Backlog” durante o “Sprint”
Alterações ao “Sprint Backlog”
– A equipa adiciona novas tarefas / acções sempre que delas
precisem (e só nesse caso) para atingirem o “Sprint Goal”
– A equipa pode e deve eliminar tarefas / acções
desnecessárias
– Mas…: Só a equipa pode alterar o “Sprint Backlog”
Estimativas / projecções são actualizadas sempre que
houver informação nova

32. SCRUM: Sprint “Burndown Chart”

33. SCRUM: Daily Scrum Meetings
Parâmetros
– Diário
– 15-minutos
– Em pé !
– Não são para resolver problemas (“problem solving”)
3 simples perguntas a cada elemento:
1. O que é fizeste ontem?
2. O que vais fazer hoje?
3. Que obstáculos tens ao teu progresso?
“Chickens” and “Pigs” are invited
Evitar sempre outro tipo de convidados…
Só os “Pigs” é que podem intervir. “Chickens” só
observam ☺

34. SCRUM: Sprint Review Meeting
A equipa apresenta o que realizou no “Sprint”
Tipicamente apresenta demonstrando a execução
das novas “features” implementadas ou, por exemplo,
algo que demonstre a arquitectura técnica
Informal
Com tempo mínimo de preparação (max. 2 ou 3 horas)
Participantes
“Clientes” do produto
Gestão
Product Owner
Outros engenheiros / técnicos

35. SCRUM

36. Bibliografia Recomendada

37. SCRUM
1º 2º 3º
(www.controlchaos.com)

38. eXtreme Programming

39. Balancing Agility and Discipline

40. Fred Brooks versus Linus Torvalds

41. Bom “Hacking”!