Desenvolvimento Ágil de Software

Inovador com

José A. S. Alegria
PT Comunicações
<jose.alegria@telecom.pt>

Lisboa, 14 de Novembro de 2007

 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
Personal Foundations
 Ao nível tecnológico, a
“agilidade” no desenvolvimento
de software já me acompanha há
mais de 30 anos!
 “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.
1977
1977
The Xerox Star 9010
“Dandelion”

Simula-67  Smalltalk 80
1977
1977 … 2001
2001
Como profissional a experiência
confirmou-me vezes sem conta
que…
A
A
 B
B

Source: Strategic Management and

Organizational Dynamics by Ralph
Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Beedle.
 C
C

A produtividade da maioria dos

“knowledge workers” é
significativamente reduzida por
“problemas (GAP) de
comunicação”…
 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
The New
The New New
New Product
Product
Development Game
Development Game
Hirotaka Takeuchi
Hirotaka Takeuchi and
and Ikujiro
Ikujiro Nonaka
Nonaka
Harvard Business
Harvard Business Review
Review

January 1986
January 1986
A forma como a
Eng.ª Química
lida com
processos
“instáveis”…
 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…
 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
Martin Fowler Brian Marick

“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.
 SCRUM

(www.controlchaos.com)
 SCRUM

(www.controlchaos.com)
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.”
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 ☺
SCRUM: Sumário
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

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”
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”
SCRUM “No changes during Sprints” !!!

A duração dos “sprints” deve ser planeada de forma

a garantir evitar alterações a meio

“TIME BOXED”
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”!
SCRUM “No changes during Sprints”
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

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
SCRUM: Sprint “Burndown Chart”
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 ☺
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
SCRUM
Bibliografia Recomendada
 SCRUM

1º 2º 3º

(www.controlchaos.com)
eXtreme Programming
Balancing Agility and Discipline
Fred Brooks versus Linus Torvalds
Bom “Hacking”!