Palestra de 45min realizada no VII Seminário de Gerenciamento de Projetos do PMI-RS (Porto Alegre, RS - 23/09/2010), no V Seminário de Gerenciamento de Projetos do PMI-MG (Belo Horizonte - 09/11/2010) e IIBA Rio de Janeiro Chapter (27/10/2010). Descrição: Segundo o PMBOK, o gerenciamento do escopo inclui os processos necessários para assegurar que um projeto contemple todo o trabalho necessário, e apenas o necessário, para concluí-lo com sucesso. No entanto, o que ainda não foi percebido por muitos profissionais que atuam em projetos de desenvolvimento de software é que a forma como descobrimos e realizamos o escopo (a logística do conhecimento) pode representar um grande diferencial de custo, qualidade e prazo em projetos de inovação tecnológica. Valor e desperdício, fluxo contínuo de valor, sistema puxado, heijunka, kanban e just-in-time, são conceitos do Pensamento Enxuto (Lean Thinking) que podem afetar diretamente a forma como estamos acostumados a gerenciar o escopo de nossos projetos. Esta palestra irá demonstrar como o balanceamento efetivo das atividades de descoberta e realização do escopo do projeto, segundo os princípios do Pensamento Enxuto, irá garantir a conquista do sucesso mediante o desenvolvimento de uma equipe de alto desempenho e a entrega constante de valor agregado para as partes interessad

1. O Pensamento Enxuto no Gerenciamento
do Escopo dos Projetos de Software
Luiz Claudio Parzianello
http://twitter.com/lcparzianello

2. Quem sou eu?
Mestre em Engenharia de Sistemas pela USP
Engenheiro Eletricista (Eletrônica) pela PUCRS
+ 25 anos de experiência em informática
+ 12 anos atuando em Engenharia de Software
+ 8 anos de experiência com Metodologias Ágeis
Lean, Crystal, Scrum e Extreme Programming
Palestrante em eventos nacionais e internacionais
Assessoria e treinamento na formação de equipes de alto desempenho
Agile Business Analysis, Agile Adoption, Lean Based Process Improvement
Membro da Agile Alliance e da Scrum Alliance (CSM)
Membro do International Institute of Business Analysis (IIBA)
Membro do Core Team da Agile Extension do BABOK
Presidente do IIBA Porto Alegre Chapter
Atua na coordenação de Grupos de Usuários na SUCESU-RS:
“Análise de Negócios” (GUAN) e “Metodologias Ágeis” (GUMA)

3. Afinal, do que trata o
Gerenciamento do
Escopo do Projeto?

4. Gerenciamento do Escopo do Projeto
“Inclui os processos necessários para assegurar que o
projeto inclui todo o trabalho necessário, e apenas o
necessário, para terminar o projeto com sucesso.”
PMBOK, 4ª.Ed., 2004
Se o desenvolvimento de software
depende diretamente da criatividade do
ser humano, como seremos capazes de
prever antecipadamente todo o
trabalho necessário, e apenas o
necessá
necessário, para terminar o projeto
necessá
com sucesso?

5. Gerenciamento do Escopo do Projeto
Para você, o que é sucesso num projeto de software?
Cliente satisfeito com o investimento?
Fornecedor satisfeito com o lucro?
Usuários satisfeitos e elogiando o produto?
Equipe satisfeita e orgulhosa com os resultados?
Equipe ainda mais competente?
Todos prontos para um novo projeto?

6. Gerenciamento do Escopo do Projeto
“Esse gerenciamento está relacionado,
principalmente,
principalmente com a definição e controle do que
definiç
está e do que não está incluso no projeto.”
PMBOK, 4ª.Ed., 2004
Se é principalmente, é porque não é exclusivo?
Qual o critério para definir o que está incluso?
Que tipo de controle faremos sobre o escopo?
Como esses dois elementos podem afetar os
resultados de nossos projetos?

7. O que é
“Pensamento Enxuto”?

8. 100 anos de
evolução em
projeto e,
principalmente,
PROCESSO!
PROCESSO

10. E tudo isso se aplica em
“Projetos de Software”?

11. Lean no Desenvolvimento de Software?
Tudo começou por volta do ano 2000 ...

12. Mas quais os princípios básicos do
“Pensamento Enxuto”?

13. Princípios básicos do pensamento enxuto
VALOR FLUXO DE VALOR
CONTÍ
FLUXO CONTÍNUO SISTEMA PUXADO PERFEIÇÃO
PERFEIÇ

14. O Pensamento Enxuto é Focado na
Entrega de Valor e Redução dos Desperdícios
Valor é visto através dos olhos
daqueles que pagam pelo uso
e que se beneficiam com os
sistemas que desenvolvemos.
Desperdício é qualquer coisa que
deprecie os recursos no tempo,
esforço, espaço ou dinheiro sem
acrescentar valor ao cliente.

15. Afinal, qual o valor de um projeto de software?

16. Um Modelo de Valor para o Produto de Software
Ideal A Successful Software
guided by
explores Product usually
Identity
and Mission
guided by
respects
Beliefs and improves supports
Personal Values
developed by
Capabilities
and Strategies ☺
supported by Good or Bad
Actors can be
Behaviors
determine generate Results
Market or
Environment Authored by Luiz C. Parzianello
relative to based on Robert Dilts’ Logical Levels

17. Método Científico
Cientí
“Até que se prove o contrário, a maioria dos requisitos
Até contrá
são hipóteses aguardando comprovação”
hipó comprovação”

18. Isso afeta a coleta e a definição do escopo?
Geralmente, novos recursos são
“empurrados” para o ambiente, mesmo
não agregando valor para seus
usuários, tampouco para o negócio ...
By Chris Matts
“Feature Injection”
Se trabalharmos orientados ao verdadeiro
valor agregado, somente acrescentaremos
recursos num produto de software quando o
valor de negócio for puxado pelo cliente.

19. Como fica o fluxo de valor de nosso escopo?
Implementers Stakeholders
Business
Business
Operating
Operating
Value
Value (incidental)
Environment Vision
Vision
Environment Stakeholders
Integrators
QAs
BAs Feature
Feature
Further
Further Sets
Sets
Code
Code The Pull
Software Key Users
Developers Lifespan BAs
Users
Stories
Stories
UI Code
UI Code QAs
Developers
Users Users
UI Design Scenarios
Scenarios
UI Experts UI Design
Pull Signal
UI Experts Creates
Baseado em “Pulling Power: A New Software Lifespan de Elizabeth Keogh
Pulling Lifespan”

20. Por que um fluxo contínuo em pequenos lotes?
Let’s play
Let’’s play
Let’
Let
a game!
a game!

21. Grandes Lotes x Pequenos Lotes
Setup da Equipe
Analista Projetista Programador Testador Cliente
Objetivo do Jogo
Entregar para o cliente 10 requisitos de software analisados,
projetados, codificados e testados no menor tempo possível.

22. Resultados do Experimento
Operação em Grandes Lotes
Análise
Aná Projeto Programação
Programaç Testes
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
Duração Total = 40 UT 1º. Feedback = 31 UT
Em 77,5% da operação ainda temos 90% das funcionalidades com alto risco.
Operação em Pequenos Lotes (Fluxo Unitário)
Análise
Aná 1 2 3 4 5 6 7 8 9 0
Ganho de Velocidade = 40 / 13 = 3,07
Projeto 1 2 3 4 5 6 7 8 9 0
Lead Time Final = 13 / 40 = 32,5%
Programaç
Programação 1 2 3 4 5 6 7 8 9 0
Testes 1 2 3 4 5 6 7 8 9 0
Tempo para Feedback = 4 / 31 = 12,9%
Duração Total = 13 UT 1º. Feedback = 4 UT
Em 30,8% da operação ainda temos 60% das funcionalidades com risco zero.

23. Questões para nossos Gestores
1. É do interesse de sua organização realizar projetos
de software de forma tão lenta?
2. Se realmente não é do interesse, o que mantém a
cultura da organização apegada ao desperdício?
3. As “partes interessadas” nos projetos de software
tem alguma noção dos riscos que elas correm?
4. Você acredita que esse baixo desempenho e alto
risco podem afetar os resultados do negócio?
5. Qual poderia ser o interesse de um Gerente de
Projetos diante deste cenário?

24. Como ficaria a verificação e o controle?
Concepção Geral
Concepção Geral Aprovação
Aprovação
Business Case
Business Case Project Charter
Project Charter
JIT
Setup de Ambiente
Setup de Ambiente Ciclo de Produção
Ciclo de Produção Ciclo de Produção
Ciclo de Produção
Auto-Organização
Auto-Organização Detalhamento Progressivo
Detalhamento Progressivo Detalhamento Progressivo
Detalhamento Progressivo
Sprint 0 Sprint 1 Sprint 2
Validation
Requirements
Workshop de N+2 Retrospective de N
Sprint N Daily Scrum
Sprint Review de N
DS DS DS DS R DS DS DS DS R
SR SR
P1 RW1 VAL1 RW2 VAL2 P1 RW1 VAL1 RW2 VAL2
P2 P2
Dia 1 Dia 2 Dia 3 Dia 4 Dia 5 Dia 1 Dia 2 Dia 3 Dia 4 D5 Dia 1
Sprint Planning 2 de N
Sprint Planning 1 de N Requirements Sprint N+1
Workshop de N+1

25. Como ficaria a verificação e o controle?
TEMPO
Uma Visão da Priorização no Tempo
Release 1 Release 2 Release 3
Objetivo de Objetivo de Objetivo de
Negócio #1 Negócio #2 Negócio #3
Sprint Backlog 10
Sprint Backlog 11
Sprint Backlog 12
Sprint Backlog 13
Sprint Backlog 14
Sprint Backlog 15
Sprint Backlog 16
Sprint Backlog 17
Sprint Backlog 18
Sprint Backlog 6
Sprint Backlog 7
Sprint Backlog 8
Sprint Backlog 1
Sprint Backlog 2
Sprint Backlog 3
Sprint Backlog 4
Sprint Backlog 5
Sprint Backlog 9
Básico Desempenho Encantamento Básico Desempenho Encantamento
Desempenho Encantamento
Must Have (65%) Should Have (25%) Could Have (10%)
TAMANHO
37pts
35pts 35pts
32pts 32pts 32pts 32pts 32pts
25pts
35pts 35pts 35pts 35pts 35pts 35pts
32pts 32pts
10pts ESCOPO TOTAL = 544 story points

26. Como ficaria a verificação e o controle?
Source: Danube (ScrumWorks)

27. Como ficaria a verificação e o controle?
Estoque inicial Desenvolvedores com uma
Desenvolvedores com uma
Estoque inicial ligeira baixa capacidade
detalhado em alto nível.
detalhado em alto nível. ligeira baixa capacidade
Stelios Pantazopoulos, Project Vital Signs (http://www.projectvitalsigns.com/)
Analistas fazendo estoques QA ee Cliente validando
Analistas fazendo estoques QA Cliente validando
de requisitos detalhados continuamento oo produto
de requisitos detalhados continuamento produto

28. Como ficaria a verificação e o controle?
Henrik Kniberg
QCon,
QCon, San Francisco
Nov 18, 2009

29. Como ficaria a verificação e o controle?
From Continuous Integration
From Continuous Integration
To Continuous Delivery
To Continuous Delivery
““AlwaysShippable””
Always Shippable”
Shippable
David J. Anderson
http://www.agilemanagement.net/Articles/Weblog/Archives/June2009.html

30. “Não somente o escopo da solução,
mas a forma como ele é entregue
a seus usuários pode afetar os
resultados do negócio.”
X

31. Como ficaria a EAP neste cenário?
Project Scope Time
Process Scope
Process Scope
Process Scope
Process Scope
Process Scope
Process Scope
Process Scope
Process Scope
Business Goal #1 Business Goal #2
Business
Scope
Target #1 Target #2 Target #3 Target #4
Feature #1 Feature #2 Feature #3 Feature #4
RELEASE
Product Scope
User Story #1 User Story #2 User Story #3 User Story #4
ITERATION
Acceptance Rules & Tasks &
ITEGRATION
Criteria Constraints Effort

32. O Escopo do Projeto num Placar de Estratégia
ff
Contexto Cená
Cenário Atual ko R1 R2 Cená
Cenário Desejado
Ki c
Resultados Persona Persona Persona Persona Resultados
Negócio
( -) Goals Goals Goals Goals (+)
Negó Declaraç
Declaração Visão do
Problema Business Business Business Business Negó
Negócio
Efeitos
Causas Reqs Reqs Reqs Reqs (ROI)
V R C
Tema 1
Feat.
Feat. 1 Feat.
Feat. 2 Feat.
Feat. 3 Feat.
Feat. 4 Sistema
Sistema Legado 2
Tema 2 Sistema Legado 2
Produto(s)
Legado 1 Story Story Story Story Story Story Story Story Visão do
Produto
Tema 3 Infra-
Infra- Story Story Story Story Story Story Infra-
Infra-
estrutura Estrutura
Tema 4 Story Story Story
Tema 5 Partes
Equipe Prazo Qualidade
Projeto
Interessadas Pessoas Infraestrutura Pessoas Infraestrutura
Atividades / Datas Atividades / Datas
Métodos Ferramentas Custo Riscos
Tempo

33. Dude’
The Dude’s Law
Why
Value =
By David
How
Hussman

34. Redução do Lead Time
Reduç
Dude’
The Dude’s Law
Why
Value =
By David
How
Hussman

35. “First be sure you are building
the right thing. Then make sure
right.”
you are building the thing right.”
The Poppendiecks (based on Peter Druker)
“What defines a winner is
not how fast we deliver,
but how fast we learn
from what we deliver”
Jason Gorman

36. Muito obrigado!
Luiz Claudio Parzianello
http://twitter.com/lcparzianello
parzianello@gmail.com