Durante a transformação do desenvolvimento de software de modelos tradicionais como RUP para modelos ágeis, os papéis de gestão de projeto e análise de negócios foram renegados. No entanto, projetos grandes enfrentam desafios que ultrapassam a capacidade de apenas times ágeis. O documento defende que esses papéis são importantes em projetos grandes, desde que atuem de forma a apoiar o dono do produto e o time, em vez de controlar o processo.

1. Gestão de Projeto e
Análise de Negócios
As disciplinas renegadas do
desenvolvimento ágil
Giuliano Sposito

2. A evolução dos papeis de GP & AN
durante a transformação do processo de
desenvolvimento de RUP/CMMI-5 para
Lean/Ágil na CI&T
Giuliano Sposito

3. Giuliano Sposito
Agile Coach
gsposito@ciandt.com
google.com/+GiulianoSposito
twitter.com/gsposito
br.linkedin.com/in/giulianosposito/
Collaborate. Innovate. Transform.

4. Durante a 1a década
do séc XXI…

5. O modelo vigente para o
desenvolvimento de
software era integralmente
baseado no conceito
clássico de engenharia de
software.

6. Gerentes
de ProjetoWeb
Designers
Arquitetos
Analistas
de Negócio
Líderes de
Projeto
ProjetistasDBA
Testers Líderes
Técnicos
Developer
Os papeis e disciplinas em
um time de projeto de
desenvolvimento
praticamente copiava os
papeis do RUP - Rational
Unified Process.

7. Processo corporativo era
completo e compatível
com CMMI-5, o que
implica em um processo
definido e uma área que
define, controla e fiscaliza
a execução do mesmo.

8. CI&T começa a década com 100 e termina com 1000 pessoas, durante o
crescimento se reorganiza para suportar a escalada das demandas e para
atender projetos de grande porte.

9. A fábrica de software...
Henry Ford
… era a resposta das grandes outsourcings
de desenvolvimento para suportar o
crescimento na época.

10. O modelo pressupõe a separação entre o “saber” e o “fazer”, característica da produção de
massa taylorista. No desenvolvimento de software isso é traduzido entre dividir as equipes
entre “consultores” e “centros de desenvolvimento”.
O trabalho dos consultores é especificar e projetar o software

11. A especificação completa do sistema (requisitos, UX, arquitetura e design) era então
passada para equipes de desenvolvimento que deveriam construir, testar e empacotar o
software desenvolvido.

12. Clássicos problemas de
isolamento entre equipes
de desenvolvimento e
cliente, além da hipótese
do “congelamento do
negócio” acabam na
geração de um produto que
“não é bem aquele que
precisa”.

13. O modelo leva à “otimização dos recursos de
consultoria” com a sua alocação somente no início do
projeto (concepção e elaboração) e o encurtamento da
fase de construção através da paralelização excessiva
de recursos para ganhar prazo, o que leva os projetos
de desenvolvimento executarem como waterfall.

14. Com todos os requisitos
especificados, o projeto de
desenvolvimento vira
“implementar os requisitos
escritos à qualquer custo”. O
foco da construção sai do
produto e vai para o plano. A
construção sofre com as
requisições de mudanças
constantes e a pressão pelo
prazo.

15. O desenvolvimento ágil entrou
na empresa através de clientes
que solicitaram não rodar o
modelo de fábrica e ter contato
direto com os
desenvolvedores.
Outras experiências foram
feitas com cenários em que os
requisitos eram voláteis e a
prioridade mudava em
questões de semana.

16. O Scrum mostrou-se extramamente eficiente
no que diz respeito ao “fazer o melhor
software”, além de diminuir sensivelmente a
sobrecarga gerencial, ganhando aos poucos
espaço e virando um modelo de “oferta”.

17. O desenvolvimento Ágil vira “Main
Stream” e o único modelo de oferta.
As estruturas clássicas de processo
(RUP e CMMI) são abandonadas.

18. Houve um empowerment do “centro de
desenvolvimento”, o time de desenvolvimento e líderes
de equipe (agora como Scrum Masters) foram
colocados em contato direto com o cliente, assumindo
atividades que antes eram da “consultoria”.

19. Gerentes de
Projeto
Analistas de
Negócio
Como não eram “Scrum Compliant”, houve diminuição significativa na atuação do Gerente de Projeto
e dos Analistas de Negócios, enquanto o primeiro se concentrou no relacionamento com cliente e
como “ponto de escalada”, o último formalmente até deixou de existir como um papel.

20. NokiaTest
55%
100%
80%
75%
Sem a estrutura formal de controle de processo, os times tinham liberdade para adaptar o
desenvolvimento à qualquer situação. O que era bom, mas ao mesmo tempo trazia risco.
Neste período várias experimentações foram feitas e o resultado dos projetos variavam sem relação
direta com o grau de agilidade da equipe.

21. Em especial, os projetos grandes (definidos como: mais de 20
pessoas no desenvolvimento e com um ou mais anos de
execução) sempre apresentavam resultados ruins do ponto de
vista de Prazo, Custo, Escopo e Expectativas.
Não era raro as situações em que o produto de software em si era
exatamente o que o PO desejava, mas não atendia a expectativa
da área ou da empresa onde seria usado.
Havia situações que o produto, ao longo do desenvolvimento,
acabava não atendendo mais os objetivos de custo e prazo.
Do ponto de vista de Gestão de Projetos e do Cliente isso é visto
como “Projeto de Fracasso”.
Em especial alguns fatores críticos, que estão “fora do contexto
de execução e desenvolvimento ágil”, afetam os projetos
grandes.

22. O tamanho do Product Backlog é grande
demais para o PO (ou para os vários POs)
terem controle e saberem exatamente
qual é o produto a ser construído.
O tamanho é uma dificuldade para
priorização, em especial quando há mais
de um PO representando áreas diferentes
da empresa (comum em projetos
grandes). Há uma dificuldade em saber se
o Backlog forma um produto “integro” e
se todos os itens são de valor.
Para que o desenvolvimento ágil produza
valor é essencial que o PO tenha domínio
sobre o negócio e sobre o product
backlog.

23. Faz-se necessário a presença de um papel para auxiliar o(s) PO(s) na definição do produto, priorização
e organização das atividades de gestão do Product Backlog, bem como alinhamento entre os objetivos
do produto quando este envolve várias áreas distintas (Engenharia de Valor).
Atribuições que são de “Análise de Negócio”, no sentido “amplo”.

24. Neste sentido a figura do Analista de Negócio se torna um
papel chave para projetos muito grandes.
Mas ele não pode apenas se comportar como um “tirador
de pedido” ou mero “escriba de requisitos”.

25. É fundamental que o Analista de Negócios
conduza o PO na geração do Product
Backlog que melhor atende as necessidades
dele, da área e da empresa onde trabalha.
E durante todo o desenvolvimento, pois o
negócio evolui ao longo do projeto.
Pois esse é o real GAP que precisa ser
sanado e não o de “formalização de
requisitos”.

26. Outro aspecto que afeta os projetos grandes,
mais significativamente que os projetos
menores, é o seu impacto na empresa que o
encomenda.
Um projeto de grande porte afeta muitas
áreas e as vezes de maneira muito profunda.
Dependendo, esse impacto pode ser um
obstáculo à realização do projeto.
Há um esforço grande de mobilização,
alinhamento, comunicação e gestão de
espectativas que ultrapassa as atribuições
da equipe de desenvolvimento e muitas
vezes sobrecarrega o PO.

27. Além disso, estando em outro patamar
orçamentário (milhões em vez de milhares) a
pressão corporativa e atenção aos riscos,
controle de prazo e custos é muito mais
intensa e muito mais ampla.
Mecanismos de previsão de custos e
acompanhamento de gastos são
necessários.
Também ultrapassando as atribuições e
capacidade do PO e fora da alçada do time
de desenvolvimento.

28. Comunicação, Gestão de Expectativa, Gestão de
Custos, Riscos, Mobilização e Prazos, são
competências de “Gerenciamento de Projeto”.
Faz-se necessário um papel para auxiliar o PO na
condução desses aspectos no seu projeto de
desenvolvimento.
O Gerente de Projeto é membro da equipe que
traz essa competência aos POs que não a
possuem e auxiliando-os nas tomadas de
decisões.

29. É importante que a sua atuação não seja a de “executor” de um plano, impondo o triângulo de ferro, ou
do indivíduo responsável por todas as decisões. Pois a dinâmica ágil de escopo variavel precisa ser
preservada.

30. A sua atuação deve ser a de buscar e preservar o ambiente operacional abrindo o caminho
para que o PO e o time de desenvolvimento possuam condições para construir e implantar,
com produtividade e qualidade, através do desenvolvimento ágil, o produto certo atendendo
as espectativas de custo, prazo e risco esperadas.

31. O Gerente de Projeto e o Analista de
Negócio, então, são fundamentais para
suportar o Product Owner e ajudá-lo a
desempenhar da melhor maneira possível
as suas responsabilidades, garantindo
assim que o desenvolvimento do produto
ocorra de maneira ágil e gerando
efetivamente o valor esperado.

32. Gerentes de Projeto e Analistas de Negócio?
Não é um RUP disfarçado?

33. the lean thinking
Taiichi Ohno
Não são as disciplinas que são “culpadas”, as
competências de análise de negócio e
gerenciamento de projeto são importantes! E
são obrigatórias em projetos de grande porte!
É sim a maneira de utilizá-las que faz a
diferença! Neste sentido foco no cliente e
produto e o Pensamento Lean, em todas “as
etapas” do desenvolvimento, garantem o uso
eficiente delas, agregando valor, combatendo o
desperdício e evitando o retorno aos padrões de
desenvolvimento waterfall.

34. Referências
RUP e Scrum
The New Methodology (From Nothing, to Monumental, to Agile) - Martin Fowler
http://www.martinfowler.com/articles/newMethodology.html
Scrum and XP from the Trenches - Henrik Kniberg
http://www.amazon.com/dp/1430322640/ref=cm_sw_r_tw_dp_td.wub1R42QJB
Nokia Test
Nokia Test Online
Scrum Inc
http://www.scruminc.com/nokia-test-online/
Nokia Test: Where did it come from?
Scrum Inc
http://www.scruminc.com/nokia-test-where-did-it-come-from/
Ready-Ready Concept
Scrum and CMMI – Going from Good to Great - Are you ready-ready to be done-done?
Carsten Ruseng Jakobsen & Jeff Sutherland
http://www.researchgate.net/publication/241200176_Scrum_and_CMMI__Going_from_Good_to_Great_Are_you_ready-ready_to_be_done-
done
The Definition of Ready in Scrum - Roman Pichler
http://www.romanpichler.com/blog/the-definition-of-ready/

35. Referências
PO Team
The Product Owner Team - Mike Cottmeyer
http://www.leadingagile.com/2009/03/the-product-owner-team/
Metrics
An Appropriate Use of Metrics - Patrick Kua
http://martinfowler.com/articles/useOfMetrics.html
Measure productivity in Agile Before It’s Too Late - Fernando Ostanelli & Felipe Brito
Parte I: http://www.linkedin.com/today/post/article/20140531170442-242908-measure-productivity-in-agile-before-it-s-too-late
Parte II: https://www.linkedin.com/today/post/article/20140501011627-242908-measure-productivity-in-agile-before-it-s-too-late
Value
Business Value Engineering Framework - Tissiana Costa
https://www.linkedin.com/today/post/article/20140819183644-881635-business-value-engineering-framework
Lean Production
The Machine That Changed the World: The Story of Lean Production
James P. Womack, Daniel T. Jones & Daniel Roos
http://www.amazon.com/Machine-That-Changed-World-Revolutionizing/dp/0743299795/
The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer
Jeffrey Liker
http://www.amazon.com/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319/

36. THANKS
FOR
BEING
HERE!
>> www.ciandt.com/carreiras <<
Há vagas !!
Giuliano Sposito
Agile Coach
gsposito@ciandt.com
google.com/+GiulianoSposito
twitter.com/gsposito
br.linkedin.com/in/giulianosposito/