Desenvolvimento Ágil de Software com SCRUM

3,933 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,933
On SlideShare
0
From Embeds
0
Number of Embeds
91
Actions
Shares
0
Downloads
217
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Desenvolvimento Ágil de Software com SCRUM

  1. 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. 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. 3. Personal Foundations
  4. 4. Ao nível tecnológico, a “agilidade” no desenvolvimento de software já me acompanha há mais de 30 anos!
  5. 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. 6. 1977 1977 The Xerox Star 9010 “Dandelion” Simula-67 Smalltalk 80
  7. 7. … 1977 2001 1977 2001
  8. 8. Como profissional a experiência confirmou-me vezes sem conta que…
  9. 9. A A
  10. 10. B B Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.
  11. 11. C C A produtividade da maioria dos “knowledge workers” é significativamente reduzida por “problemas (GAP) de comunicação”…
  12. 12. 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
  13. 13. 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
  14. 14. A forma como a Eng.ª Química lida com processos “instáveis”…
  15. 15. 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…
  16. 16. 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.
  17. 17. SCRUM (www.controlchaos.com)
  18. 18. SCRUM (www.controlchaos.com)
  19. 19. 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.”
  20. 20. 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 ☺
  21. 21. SCRUM: Sumário
  22. 22. 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
  23. 23. 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”
  24. 24. 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”
  25. 25. SCRUM “No changes during Sprints” !!! A duração dos “sprints” deve ser planeada de forma a garantir evitar alterações a meio “TIME BOXED”
  26. 26. 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”!
  27. 27. SCRUM “No changes during Sprints”
  28. 28. 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
  29. 29. 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
  30. 30. SCRUM: Sprint “Burndown Chart”
  31. 31. 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 ☺
  32. 32. 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
  33. 33. SCRUM
  34. 34. Bibliografia Recomendada
  35. 35. SCRUM 1º 2º 3º (www.controlchaos.com)
  36. 36. eXtreme Programming
  37. 37. Balancing Agility and Discipline
  38. 38. Fred Brooks versus Linus Torvalds
  39. 39. Bom “Hacking”!

×