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&T

Giuliano Sposito

Giuliano Sposito Agile Coachgsposito@ciandt.com

google.com/+GiulianoSposito

twitter.com/gsposito

br.linkedin.com/in/giulianosposito/

Collaborate. Innovate. Transform.

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

software.

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.

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.

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.

A fábrica de software...

Henry Ford

… era a resposta das grandes outsourcings

de desenvolvimento para suportar o

crescimento na época.

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

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.

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”.

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.

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.

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.

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”.

O desenvolvimento Ágil vira “Main

Stream” e o único modelo de oferta.

As estruturas clássicas de processo

(RUP e CMMI) são abandonadas.

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”.

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.

No

kia

Te

st

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.

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.

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.

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”.

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”.

É 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”.

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.

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.

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.

É 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.

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.

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.

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

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.

Referências

RUP e Scrum

The New Methodology (From Nothing, to Monumental, to Agile) - Martin Fowlerhttp://www.martinfowler.com/articles/newMethodology.html

Scrum and XP from the Trenches - Henrik Kniberghttp://www.amazon.com/dp/1430322640/ref=cm_sw_r_tw_dp_td.wub1R42QJB

Nokia Test

Nokia Test Online

Scrum Inchttp://www.scruminc.com/nokia-test-online/

Nokia Test: Where did it come from?

Scrum Inchttp://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 Sutherlandhttp://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 Pichlerhttp://www.romanpichler.com/blog/the-definition-of-ready/

Referências

PO Team

The Product Owner Team - Mike Cottmeyerhttp://www.leadingagile.com/2009/03/the-product-owner-team/

Metrics

An Appropriate Use of Metrics - Patrick Kuahttp://martinfowler.com/articles/useOfMetrics.html

Measure productivity in Agile Before It’s Too Late - Fernando Ostanelli & Felipe BritoParte 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 Costahttps://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 Rooshttp://www.amazon.com/Machine-That-Changed-World-Revolutionizing/dp/0743299795/

The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer

Jeffrey Likerhttp://www.amazon.com/Toyota-Way-Management-Principles-Manufacturer/dp/0071392319/

THANKS

FOR

BEING

HERE!

>> www.ciandt.com/carreiras <<

Há vagas !!

Giuliano Sposito Agile Coachgsposito@ciandt.com

google.com/+GiulianoSposito

twitter.com/gsposito

br.linkedin.com/in/giulianosposito/