Post on 06-Jul-2015
description
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”!