Gestão de Projeto e
Análise de Negócios
As disciplinas renegadas do
desenvolvimento ágil
Giuliano Sposito
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...
Giuliano Sposito
Agile Coach
gsposito@ciandt.com
google.com/+GiulianoSposito
twitter.com/gsposito
br.linkedin.com/in/giuli...
Durante a 1a década
do séc XXI…
O modelo vigente para o
desenvolvimento de
software era integralmente
baseado no conceito
clássico de engenharia de
softwa...
Gerentes
de ProjetoWeb
Designers
Arquitetos
Analistas
de Negócio
Líderes de
Projeto
ProjetistasDBA
Testers Líderes
Técnico...
Processo corporativo era
completo e compatível
com CMMI-5, o que
implica em um processo
definido e uma área que
define, co...
CI&T começa a década com 100 e termina com 1000 pessoas, durante o
crescimento se reorganiza para suportar a escalada das ...
A fábrica de software...
Henry Ford
… era a resposta das grandes outsourcings
de desenvolvimento para suportar o
crescimen...
O modelo pressupõe a separação entre o “saber” e o “fazer”, característica da produção de
massa taylorista. No desenvolvim...
A especificação completa do sistema (requisitos, UX, arquitetura e design) era então
passada para equipes de desenvolvimen...
Clássicos problemas de
isolamento entre equipes
de desenvolvimento e
cliente, além da hipótese
do “congelamento do
negócio...
O modelo leva à “otimização dos recursos de
consultoria” com a sua alocação somente no início do
projeto (concepção e elab...
Com todos os requisitos
especificados, o projeto de
desenvolvimento vira
“implementar os requisitos
escritos à qualquer cu...
O desenvolvimento ágil entrou
na empresa através de clientes
que solicitaram não rodar o
modelo de fábrica e ter contato
d...
O Scrum mostrou-se extramamente eficiente
no que diz respeito ao “fazer o melhor
software”, além de diminuir sensivelmente...
O desenvolvimento Ágil vira “Main
Stream” e o único modelo de oferta.
As estruturas clássicas de processo
(RUP e CMMI) são...
Houve um empowerment do “centro de
desenvolvimento”, o time de desenvolvimento e líderes
de equipe (agora como Scrum Maste...
Gerentes de
Projeto
Analistas de
Negócio
Como não eram “Scrum Compliant”, houve diminuição significativa na atuação do Ger...
NokiaTest
55%
100%
80%
75%
Sem a estrutura formal de controle de processo, os times tinham liberdade para adaptar o
desenv...
Em especial, os projetos grandes (definidos como: mais de 20
pessoas no desenvolvimento e com um ou mais anos de
execução)...
O tamanho do Product Backlog é grande
demais para o PO (ou para os vários POs)
terem controle e saberem exatamente
qual é ...
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 a...
Neste sentido a figura do Analista de Negócio se torna um
papel chave para projetos muito grandes.
Mas ele não pode apenas...
É fundamental que o Analista de Negócios
conduza o PO na geração do Product
Backlog que melhor atende as necessidades
dele...
Outro aspecto que afeta os projetos grandes,
mais significativamente que os projetos
menores, é o seu impacto na empresa q...
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,...
Comunicação, Gestão de Expectativa, Gestão de
Custos, Riscos, Mobilização e Prazos, são
competências de “Gerenciamento de ...
É 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...
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 desenvol...
O Gerente de Projeto e o Analista de
Negócio, então, são fundamentais para
suportar o Product Owner e ajudá-lo a
desempenh...
Gerentes de Projeto e Analistas de Negócio?
Não é um RUP disfarçado?
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
gerencia...
Referências
RUP e Scrum
The New Methodology (From Nothing, to Monumental, to Agile) - Martin Fowler
http://www.martinfowle...
Referências
PO Team
The Product Owner Team - Mike Cottmeyer
http://www.leadingagile.com/2009/03/the-product-owner-team/
Me...
THANKS
FOR
BEING
HERE!
>> www.ciandt.com/carreiras <<
Há vagas !!
Giuliano Sposito
Agile Coach
gsposito@ciandt.com
google....
Próximos SlideShares
Carregando em…5
×

[AgileBr] GP & AN - As Disciplinas Renegadas do Ágil - Legendado

493 visualizações

Publicada em

Não há Analista de Requisitos e nem Gerente de Projetos no mundo ágil? Esses papéis não existem e eles são de fato as “galinhas” da anedota “Pigs and Chickens”? Será que é possível conduzir um projeto de desenvolvimento de software com sucesso sem essas disciplinas? Nesta conversa pretendo passar pelas “duras” lições que aprendemos durante a nossa transição de um processo baseado em RUP/CMMI-5 para uma execução Ágil/Lean e como encaramos hoje essas responsabilidades dentro dos projetos ao mesmo tempo em que preservamos a agilidade dos times.

Publicada em: Software
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
493
No SlideShare
0
A partir de incorporações
0
Número de incorporações
34
Ações
Compartilhamentos
0
Downloads
17
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Mais pessoas = Mais públicos distintos

    O que dá mais trabalho, pois uma mesma mensagem pode precisar ser codificada de maneiras diferentes para os públicos.
  • [AgileBr] GP & AN - As Disciplinas Renegadas do Ágil - Legendado

    1. 1. Gestão de Projeto e Análise de Negócios As disciplinas renegadas do desenvolvimento ágil Giuliano Sposito
    2. 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. 3. Giuliano Sposito Agile Coach gsposito@ciandt.com google.com/+GiulianoSposito twitter.com/gsposito br.linkedin.com/in/giulianosposito/ Collaborate. Innovate. Transform.
    4. 4. Durante a 1a década do séc XXI…
    5. 5. O modelo vigente para o desenvolvimento de software era integralmente baseado no conceito clássico de engenharia de software.
    6. 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. 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. 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. 9. A fábrica de software... Henry Ford … era a resposta das grandes outsourcings de desenvolvimento para suportar o crescimento na época.
    10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32. Gerentes de Projeto e Analistas de Negócio? Não é um RUP disfarçado?
    33. 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. 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. 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. 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/

    ×