José A. S. AlegriaPT Comunicações

<jose.alegria@telecom.pt>

Desenvolvimento Ágil de Software Inovador com

Lisboa, 14 de Novembro de 2007

SinopseSinopseCada 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 FoundationsPersonal Foundations

Ao nAo níível tecnolvel tecnolóógico, a gico, a ““agilidadeagilidade”” no desenvolvimento no desenvolvimento de software jde software jáá me acompanha hme acompanha háá

mais de 30 anos!mais de 30 anos!

1.1. Fui pioneiro (1977) na utilizaFui pioneiro (1977) na utilizaçção de ão de ““programaprogramaçção orientada a objectosão orientada a objectos”” na na

construconstruçção de todas as fases de um compilador. Introduzi a não de todas as fases de um compilador. Introduzi a níível vel

universituniversitáário (Eng.rio (Eng.ªª InformInformáática) o ensino desta tecnologia de construtica) o ensino desta tecnologia de construçção de ão de

compiladores.compiladores.

2.2. Desenvolvi a primeira implementaDesenvolvi a primeira implementaçção de uma ão de uma DDSLDDSL ((DDeclarativeeclarative DDomainomain

SSpecificpecific LLanguageanguage) em Portugal ) em Portugal (linguagem declarativa de especificação e simulação de múltiplas carreiras militares) utilizada pelo Departamento de utilizada pelo Departamento de

InvestigaInvestigaçção Operacional do EMGFA para planear a reestruturaão Operacional do EMGFA para planear a reestruturaçção das ão das

carreiras militares no pcarreiras militares no póós guerra colonial.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.3. Desenvolvi a primeira aplicaDesenvolvi a primeira aplicaçção ão ““100% Orientada a Objectos100% Orientada a Objectos”” em Portugal em Portugal

(1979), integralmente desenvolvida em Simula 67.(1979), integralmente desenvolvida em Simula 67.

“Old” Personal Foundations

Simula-67 ���� Smalltalk 80

The Xerox Star 9010“Dandelion”

19771977

19771977 20012001…

Como profissional a experiência Como profissional a experiência confirmouconfirmou--me vezes sem conta me vezes sem conta

queque……

AA

BB

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

A produtividade da maioria dos A produtividade da maioria dos ““knowledge workersknowledge workers”” éé

significativamente reduzida por significativamente reduzida por ““problemas (GAP) de problemas (GAP) de

comunicacomunicaççãoão”…”…

CC

Esse Esse ““gapgap”” de comunicade comunicaçção ão éésempre mais grave em ambientes sempre mais grave em ambientes em que o em que o ““objecto alvoobjecto alvo”” éé de uma de uma

diferente cultura empresarial, diferente cultura empresarial, evolui ou muda rapidamenteevolui ou muda rapidamente

ExemploExemplo: ambientes com desenvolvimento r: ambientes com desenvolvimento ráápidopidoe concorrente de produtos inovadorese concorrente de produtos inovadores

DD

The New New ProductDevelopment Game

Hirotaka Takeuchi and Ikujiro Nonaka

Harvard Business Review

January 1986

The New New ProductDevelopment Game

Hirotaka Takeuchi and Ikujiro Nonaka

Harvard Business Review

January 1986

A forma como a A forma como a Eng.Eng.ªª QuQuíímica mica lida com lida com processos processos ““instinstááveisveis”…”…

Tal como eu, muitos estão convencidos Tal como eu, muitos estão convencidos que o rque o ráápido e concorrente pido e concorrente

desenvolvimento de produtos inovadores desenvolvimento de produtos inovadores (mas não “life critical”) exige dosexige dos

““Software DevelopersSoftware Developers”” mméétodos, ttodos, téécnicas cnicas e tecnologias mais e tecnologias mais áágeisgeis……

The Manifesto for Agile Software Development

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

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

www.agilealliance.org

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…mayconflict 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—maybetter 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 formaa 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 RecomendadaBibliografia Recomendada

SCRUM

(www.controlchaos.com)

1º 2º 3º

eXtreme Programming

Balancing Agility and Discipline

Fred Brooks versus Linus Torvalds

Bom “Hacking”!