Tag Archives: Manifesto Ágil

A oportunidade pode ser única: vá de Paralelismo (fast tracking)!

17 Nov

Sempre que estou prestes a concluir algum projeto gosto de analisar as principais ações adotadas em seu planejamento e execução para avaliar os resultados efetivamente entregues. Desta vez, construirei essa análise com vocês, aqui neste novo post!

Na publicação passada, quando abordei sobre a Eficácia e Eficiência no Gerenciamento de Projetos (clique para ver), procurei enfatizar a necessidade de concentrar esforços em fazer com que o projeto atendesse não só aos requisitos “burocráticos”, mas, principalmente, àqueles que permeassem a qualidade, expectativas e aprendizado.

Ainda influenciado pelos meus vagos pensamentos deste último post, eu comecei a conjecturar sobre um novo projeto que entra em sua Fase de Encerramento. A proposta do projeto está em desenvolver uma Ferramenta de Gestão de Atendimento ao Cliente. Este projeto não chega a possuir alta complexidade de implementação de suas funcionalidades. Entretanto, tivemos (Equipe do Projeto) que fazer uso de algumas técnicas de GP bem interessantes como, por exemplo, o Paralelismo de algumas atividades da Fase de Execução.

Se a análise deste projeto partisse do proposto de [eficácia + eficiência = efetividade] seria ideal envolver as pessoas que demandaram e ajudaram a construir o projeto.  Não que isto não seja importante, ao contrário: é muito importante!!! No entanto, vou restringir, ao menos por enquanto, à análise do uso da técnica do Paralelismo neste projeto.

Pra começar, recorri ao Guia PMBOK v4 para buscar a definição do que seria a técnica do Paralelismo:

“Uma técnica específica para compressão do cronograma de um projeto que altera a lógica de rede sobrepondo algumas fases que normalmente seriam realizadas em sequência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo.”

Essa definição não poderia ser melhor!

A história do nosso projeto é bastante simples: as fases de iniciação e planejamento do projeto não foram sobrepostas, ou seja, seguiram bem a metodologia proposta pela empresa. Mas, as Iterações foram reorganizadas de forma a serem paralelizadas. Ao invés de se concluir uma Iteração para então iniciar a próxima, optamos por implementar várias Iterações no mesmo período, mas que seriam complementares entre si.

E por que disso?! PRAZO! PRAZO!! PRAZO!!!

A compressão do cronograma é uma técnica de “redução da duração do cronograma do projeto sem reduzir o seu escopo“.

Lembro que reduzir escopo para alcançar a restrição de prazo nem sempre é uma boa opção: o cliente não vê com bons olhos ter suas necessidades do projeto minimizadas. Ele se sente impotente e, com isso, acaba se afastando do projeto. Em casos assim, é comum utilizar algumas técnicas de Compressão do Cronograma, como a técnica do Paralelismo!

Para que você possa entender melhor o contexto do projeto, nós utilizamos a metodologia da empresa (ativo organizacional) de Gerenciamento de Projetos e Engenharia de Software, a qual estava embasada no Manifesto Ágil. O conceito de ciclos era algo bem forte na metodologia. E para iniciar um próximo ciclo, necessariamente, o anterior deveria estar homologado pelo cliente.

A imagem 1 a seguir demonstra como o projeto foi inicialmente planejado, sem considerar a sobreposição de tarefas:

Imagem 1: execução do projeto de forma linear.

Facilmente, pelo Gráfico de Gantt, podemos constatar as Iterações encadeadas. O Software seria construído de forma incremental. Outra observação que faço está relacionada ao caminho crítico destacado em amarelo, veja como ele foi alterado na imagem abaixo.

Já a imagem 2 demonstra o uso do Paralelismo no projeto para os ciclos de 1 a 5:

Imagem 2: execução do projeto utilizando Paralelismo.

Com essas duas imagens pode-se comparar o quanto o cronograma é modificado e, principalmente, como o caminho crítico é afetado quando utilizamos alguma técnica de compressão do cronograma.

A primeira coisa que me vem à cabeça, quando utilizo a técnica de Compressão do Cronograma, está relacionada à precariedade em seu uso quando temos uma iteração (ciclo) sendo utilizado como insumo para a implementação do próximo ciclo:

1 – A integração do sistema ficou altamente empobrecida. O que gerou dificuldade de compreensão do fluxo de funcionamento do sistema como um todo;

2 – Geração de retrabalho decorrente da integração dos ciclos;

3 – Sensível incremento nos custos do projeto. A linearidade do projeto se perdeu. Novos recursos humanos tiveram que ser adicionados ao projeto para permitir a execução de atividades em paralelo.

4 – As estimativas de duração das atividades foram impactadas, pela falta do insumo para planejamento do próximo ciclo;

5 – Sobrecarga de trabalho para alguns perfis da equipe;

A sobrecarga de alguns perfis como Analista de Testes e o Designer de Interface, se justifica, já que, tiveram que se dividir entre uma e outra iteração. De certa forma, isto os pressionou e comprometeu seus desempenhos. Não havia disponibilidade de contratação ou alocação de outros recursos com este perfil para o projeto.

O versionamento de documentos, a gestão de atividades e priorização ficou dificultada. Muitas vezes, havia necessidade de parar o projeto para sanar dúvidas que deveriam ser respondidas na Homologação de Cada Ciclo desenvolvido anteriormente – lembro que um ciclo serve de insumo para outro.

Naturalmente, o Paralelismo implica em riscos de integração. Quando se utiliza o desenvolvimento simultâneo de ciclos, a integração deve ser muito bem planejada e o custo disso deve ser previamente aprovado. Nem sempre é fácil prever a variação dos custos do projeto quando se utiliza a Compressão do Cronograma!

E o cliente, como fica nesta situação?

É neste ponto que devemos verificar o Custo x Benefício do uso desta técnica de Compressão do Cronograma. O que será escrito aqui não pode ser tratado como regra para todos os projetos, até porque os projetos não são iguais, ok?

O custo do projeto, apesar de ter evoluído, não era algo determinante para continuar ou não o projeto. Basicamente, o esforço de custo estava em alocação de recursos humanos para o projeto. E este custo já estava pago. Se a equipe não fosse alocada para este projeto estaria em outro mais prioritário. Sobre contratos hora homem no serviço público brasileiro, eu publiquei o post que trata deste tema – IN 1 – Procedimentos para o desenvolvimento, disponibilização e uso do Software Público Brasileiro.

No entanto, o cliente enxergou no projeto uma oportunidade de alavancar seu setor de atendimento ao cliente, que até então era precário. Ou seja: o projeto fazia parte de uma estratégia organizacional maior!

Nestes casos, a Gerência do Projeto deve entrar em ação!

Quando se usa o Paralelismo, o cliente tem que está bem mais envolvido do que o normal. É também essencial que o Cliente esteja ciente dos riscos envolvidos nesta operação. Ele deve ser parceiro do projeto!

Para gerenciar as expectativas do cliente, o Gerente de Projetos deve dar autonomia a equipe técnica para resolver questões de implementação e, principalmente, necessita mantê-lo informado da relação de evolução do Escopo x Tempo x Custo. A análise de valor agregado é fundamental para que o cliente veja o quanto a decisão de antecipar o prazo custou ao projeto!

Lembro que a oportunidade para realizar o projeto era única, já que, havia recursos disponíveis, patrocínio e vontade política!

No entanto, mesmo com os entraves apresentados acima, seria o Paralelismo o fim dos tempos no Gerenciamento de Projetos?!

Não! De forma alguma!

Tente enxergá-lo como uma oportunidade. Explico:

Propiciar aos clientes da empresa um atendimento mais qualificado  é algo que deve ser visto como investimento e não custo. O prazo deveria ser atendido, já que a vontade política para realizar o projeto passava por essa restrição. Em qualquer projeto, não se pode perder o patrocínio, ainda mais quando voltado para órgão público.

Neste caso, a Técnica de Compressão do Cronograma baseada no Paralelismo é muito importante.

Aí convenhamos: mesmo com todas as dificuldades no Gerenciamento do Projeto e nos eventuais fracassos obtidos em relação a isso, sob a ótica do cliente o projeto atendeu as expectativas técnicas e negociais, já que cumpriu com seu escopo e com os objetivos políticos determinados para ele.

Veja o porquê do dilema de Eficácia e Eficiência continuou a ventilar os meus pensamentos…

É isso! Continue visitando o blog!

Até a próxima!

P.S.: este blog concorre ao TOP BLOG 2011. Não se esqueça de apoiar!

Anúncios

A TI é o foco? Cuidado ao responder.

2 Set

Não restam dúvidas que a área de tecnologia da informação (TI) é dinâmica e de vanguarda. E por isso, gostaria de compartilhar uma inquietude: se estamos envolvidos em uma área que olha sempre pra frente, que precisa a todo instante de recursos financeiros e ao mesmo tempo não gosta de ser identificada com uma área que consume muito pra pouco, então porque as estruturas de TI são semelhantes (para não dizer idênticas) a de outros setores, como contabilidade, RH, financeiro, etc.?

Antes de olharmos para metodologias e frameworks de governança, como ITIL e CoBiT, é necessário dizer qual será o posicionamento da TI frente às outras unidades de negócio da organização.

Basicamente: ela será descentralizada ou centralizada?

Isto é algo que realmente importa. Definir como a TI está situada dentro da empresa é fundamental. Acredito que muito se gasta com a TI por ela não ter o posicionamento correto. Ou seja, o modelo de outras unidades não serve para a TI!

Geralmente, os profissionais de TI e, especialmente, os Gerentes de Projetos, relacionam-se com pessoas de diversas áreas de conhecimento, principalmente por que precisamos entender o que e como fazem, para então propormos a melhor solução.

Isso traz a nossa área uma característica muito, mas muito especial: ela tem os profissionais que entendem como as unidades de negócio da empresa trabalham e como elas podem se integrar. A TI não é  fim nela mesmo. Engana-se o profissional que acha que isso é diferente.

Como consequência disso…Nós conhecemos os processos, melhor de que qualquer um! Isto é um fato!

Bom, mas o que isso tem haver com que coloco sobre a TI ser o foco?

Dizer que a TI é suporte parece ser simples, não é? E você com certeza já escutou isso em várias palestras, seminários, programas de auditório, entre outros meios…

Então, se somos meio, porque centralizamos a nossa gestão?

Onde quero chegar com essa conversa: os clientes conhecem do seu negócio e nós conhecemos os caminhos para que eles produzam de maneira mais eficaz e eficiente. Sendo assim, porque cada unidade de negócio não ter sua equipe de TI dedicada?!

Evidente que esta teoria não é minha. Muitos autores já propõe um modelo descentralizado de TI. Antes realmente achava essa ideia absurda, mas atualmente vejo que ela pode ser a saída.

Muitos Gerentes de Projetos tem o sonho de trabalhar em uma estrutura totalmente projetizada, acham que este é o caminho do sucesso. Mas sabemos as desvantagens que este tipo de estrutura pode trazer.

Estas mesmas desvantagens, como: perda de conhecimento, alto custo com equipes, dificuldade em se ter padrões e integrar soluções, desmotivação da equipe, etc. também acontecerão se a TI for descentralizada.

No entanto, pense comigo: se focamos nas unidades que tem prioridade de orçamento e projetos, consequentemente, a empresa, no sentido global, alcançará os resultados de maneira mais rápida e com maior qualidade. Com a TI não deve haver intermediários. A TI é meio, certo?! Não se pode ter uma estrutura totalmente funcional para a organização da TI.

Por mais que isso possa parecer subversivo, a ideia tem que ser discutida. Dê para cada unidade de negócio a sua equipe de TI. As reclamações que somos inoperantes vão diminuir sensivelmente. Indo além: os responsáveis pelas áreas que atualmente só demandam, passam a ser responsáveis pelo sucesso ou fracasso da equipe e do projeto. Para mim isso é fundamental!

E nós como ficamos?

Os gerentes de projetos, com o apoio de um PMO, será o elo entre a operação e a gestão de TI.

Por falar em gestão de TI, ela deve estar preocupada com:

  • Metodologias;
  • Padrões e padronização;
  • Integração;
  • Estabelecimento de políticas;
  • Acompanhamento de portfólio;
  • Suporte;
  • Busca por novas tecnologias, pesquisa…; e
  • Desenvolvimento humano.

Indo um pouco além, penso que nem sobre o investimento a Gestão de TI deverá ser responsável. A organização, neste caso, contará com um BELO de um PLANEJAMENTO ESTRATÉGICO que alinhe as unidades e direcione os recursos. Por isso, a organização será responsável pelo investimento e não um ou outro gestor.

Alerto para que isso não deva ser interpretado com um sonho, mas sim com uma premissa! Planejamento é obrigação e não acessório.

Para finalizar, recentemente li um artigo sobre “quais os três cargos de TI que devem sobreviver no futuro” e pensei: a TI descentralizada está cada vez mais próxima, ou melhor, já é uma realidade!

Se você tem uma opinião diferente ou concorda comigo, opine!!!

Abraços e até a próxima!

———————————————————————–

Sobre este assunto visite:

http://www.malima.com.br/article_read.asp?id=634

http://blog.opus-software.com.br/?p=170

http://olhardigital.uol.com.br/negocios/digital_news/noticias/quais_os_3_cargos_de_ti_que_devem_sobreviver_no_futuro

http://www.bain.com/bainweb/PDFs/cms/Public/Voce_tem_organizacao_de_ti_certa_Portuguese.pdf

http://www.tiespecialistas.com.br/2011/01/repensando-ti-na-estrutura-organizacional/

Imagem retirada de:

http://promoview.com.br/artigos-e-cronicas/131368-um-show-no-atendimento-por-paulo-araujo/

Scrum Master vs Gerente de Projetos, PMP: Presente e Passado?

4 Jul

Se você ainda não vivenciou uma situação parecida com que vou descrever, então imagine: de um lado um ScrumMaster certificado (CSM) e do outro um PMP, e algumas pessoas em volta observando a discussão de quem é o melhor perfil para gerenciar projetos!!!

Seria mais uma daquelas discussões intermináveis?!

Pensando nisso, resolvi escrever este post: seria o CSM o presente e o PMP o passado na gerência de projetos?

Lembro que a proposta de ser iterativo e incremental, pregada pelo Scrum, não é nova. Há várias metodologias na Engenharia de Software que pregam a construção baseada em ciclos e releases. Não pretendo com isso minimizar a importância do Scrum, ao contrário. Eu vejo a força desta metodologia na forma de organização do time do projeto e na condução das iterações (sprints) durante o desenvolvimento do projeto, além  da questão da qualidade nos produtos desenvolvidos. Realmente acredito nesta proposta! Mas não é isto que torna o ScrumMaster o grande profissional de gerenciamento de projeto.

De acordo com o Scrum Guide de 2010, a equipe Scrum (Scrum teams) é designada para otimizar a flexibilidade e produtividade do projeto; e para este fim, a equipe é auto-organizada, são cross-functional  (time com diferentes experiências e habilidades voltadas para um objetivo comum) e trabalham por interações.

Faz parte da equipe Scrum: o ScrumMaster; o Proprietário do Produto e a Equipe Scrum.

O ScrumMaster é o responsável por garantir que o processo é compreendido e seguido por TODOS.

Atenção! É também premissa básica, super importante, fundamental etc. etc. etc., que o PMP garanta o processo adotado para o gerenciamento do projeto e que todos os envolvidos tenham ciência deste processo e o execute de maneira coerente, ok?!??!

As figuras do Sponsor (PMBOK) e do Proprietário do Produto (Scrum) dão um encaminhamento distinto para a atuação dos dois perfis, veja:

O Proprietário do Produto é o responsável por maximizar o valor do trabalho que o Time SCRUM realiza.  Já o Sponsor, como apontado no PMBOK, é a pessoa ou grupo que fornece os recursos financeiros, em dinheiro ou em espécie, para o projeto.

Fundamentalmente isso já traz uma consequência para a atuação do ScrumMaster e o Gerente de Projetos que se baseia no PMBOK, concorda?

Observe que o Proprietário do Produto atua em conjunto com a equipe para que o projeto atenda aos requisitos necessários. Já  Sponsor é uma espécie de suporte ao gerente de projeto, para tratar de assuntos relacionados à mudança, além de ser o porta-voz do gerente de projetos para os níveis gerenciais mais altos.  Esta diferença é realmente importante e na prática acaba fazendo toda a diferença.

O ScrumMaster de acordo com o Scrum Guide:

  • Trabalha com os clientes e gestão para identificar e indicar um Proprietário do Produto.
  • Ensina o Proprietário do Produto como fazer o seu trabalho. Espera-se que o Proprietário do Produto saiba como conseguir otimizar valor usando Scrum. Se não, temos o ScrumMaster responsável.
  • Pode ser um membro da equipe, por exemplo, um desenvolvedor que executa tarefas no Sprint (iteração)No entanto, isso muitas vezes leva a conflitos quando o ScrumMaster tem que escolher entre remover impedimentos e realizar tarefas.
  • Nunca deve ser o Proprietário do Produto.

O Gerente de Projetos segundo o Guia PMBOK:

  • Pessoa designada pela organização executora para atingir os objetivos do projeto;
  • Sua autonomia depende do tipo de estrutura organizacional que projeto será desenvolvido;
  • Requer habilidades da área específica e das proficiências ou competências de gerenciamento geral;
  • Ter capacidade de realização;
  • Ter liderança;
  • Capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge os objetivos e equilibra as restrições do mesmo;
  • Dependendo do contexto do projeto, o GP poderá determinar a necessidade de um controle mais eficaz sobre certas entregas;
  • Cabe ao Gerente de Projetos e a sua equipe, determinar o método mais apropriado de execução do projeto.
  • Gerenciar as expectativas das partes interessadas;
  • Desenvolve o plano de gerenciamento de projeto e todos os componentes relacionados;
  • Identifica e monitora os riscos;
  • Fornece relatórios precisos e oportunos das métricas do projeto;
  • É o líder responsável pela comunicação com todas as partes interessadas;

As funções do Proprietário do Produto e do ScrumMaster são bem definidas e claras. Já o PMBOK dá ao gerente de projetos a responsabilidade sobre atividades que poderiam ser compartilhadas com o Sponsor do Projeto.

Resultado disso na prática:

Bom, aí penso que nem todos os projetos cabem, unicamente, em um ou em outro perfil. O contexto mais uma vez vai direcionar qual a melhor forma de orientar e conduzir os trabalhos.  O momento atual do manifesto ágil é muito bom, mas não significa que a filosofia PMI seja ultrapassada, afirmar isso, a meu ver, seria leviano.

Os profissionais PMP passam por um regime mais rigoroso de certificação que os certificados ScrumMaster, isto tem que ser levado em consideração ao avaliarmos os perfis. 

O IT-Management, baseado em uma pesquisa realizada pelo site de empregos de TI, Dice Learning, publicou sobre as certificações percebidas como de grande valor, e a certificação PMP aparece no topo, sendo que a CSM nem na lista aparece. Pense nisso!

O mercado, no entanto, quer alguém que responda com mais agilidade e seja menos burocrático ou estritamente metodológico. Por muitas vezes, já presenciei gestores importantes referindo-se aos PMP’s como “grandes burocratas de alto custo”.  Vejo como demasiadamente dura a afirmação.

Talvez, digam isso por perceberem que os profissionais que conduzem projetos, baseados no manifesto ágil, dão maior foco nos resultados funcionais do projeto. No entanto, vejo que os PMP’s, para projetos de alta criticidade, que requerem maior controle de custos, riscos e recursos, são os mais adequados.

Para que funcione bem, o Scrum requer uma equipe mais experiente, que saiba como se auto-organizar e que tenha em seu “líder” alguém que seja um facilitador para os problemas que surgem no dia-a-dia do projeto e garanta o processo. Por mais belo que isso seja na teoria, nem sempre é fácil de realizar na prática.

Finalizando: nem o PMP é passado e nem o CSM é o presente. Ambos são realidades! Quem é melhor… Aí é uma discussão interminável, do tipo projetista JAVA  vs projetista C#…

Abraços e até a próxima!

Case Projeto Automação BPM: PMBOK e o Manifesto Ágio, mistura possível?

19 Abr

No post deste mês gostaria de escrever sobre algo que pudesse conciliar teoria com prática e, ao mesmo tempo, fosse conciso e prazeroso de ser lido. Foi aí que, pra variar, em conversas “informais” com amigos ligados ao gerenciamento de projetos e outros da engenharia de software, surgiu à ideia de falar sobre os ingredientes que utilizei para gerenciar um projeto de Automação de Processos (BPM) em um órgão público de Brasília. Esses ingredientes foram às práticas do Guia PMBOK v4 e o Manifesto Ágil, mais precisamente as ideias propostas pelo SCRUM.

Só para contextualizar, o projeto de Automação BPM já vinha se arrastando na empresa há alguns anos e vários tipos de recursos já haviam sido despendidos. No entanto, os resultados práticos da automação não aconteceram. Ou seja, os processos já tinham sido modelados “as/is” e diagnosticados para uma melhoria “to/be”, mas TUDO estava em grandes mapas plotados ou na ferramenta utilizada para modelagem. A automação em si, não havia acontecido. Para agravar a situação, temos uma característica básica quando trabalhamos com processos, eles são vivos e não estáticos que perduram ao longo dos anos. Ao contrário disso, eles se modificam!

Já se pode imaginar qual era a missão? Fazer acontecer à automação de pelo menos uma área negócio da empresa. Então vamos lá: restrição de prazo, custo, recursos e baixíssima credibilidade dos tomadores de decisão quanto ao projeto e a estima da equipe bem abalada. Este era o cenário. E para apimentá-lo, havia um ponto fundamental, este era o primeiro projeto da área de TI que seguiria uma metodologia de gerenciamento de projetos que havia sido elaborada pelo escritório de projetos recém-implantado. Ou seja, o cliente interno não tinha a cultura dos projetos de TI serem desenvolvidos de forma estruturada. Mas este era o cenário e tínhamos que encará-lo!

Os ingredientes propostos pelo SCRUM e o PMBOK v4 se casaram bem à medida que colocamos a força de cada um no seu devido lugar. Para ilustrar, utilizarei o cronograma, a EAP e o Product Backolog para demonstrar como os dois “paradigmas” podem funcionar juntos.

Acreditei naquilo que o PMBOK talvez tenha de melhor: os processos de iniciação, planejamento, gestão de mudanças e monitoramento do projeto. Não é porque deve ser “ágil” que o projeto não deva ser planejado. Lembrando que o conceito de “ágil” no manifesto não se refere à velocidade, rapidez de entrega, mas sim, de agilidade em resposta a mudança. E como não poderia ser diferente, os órgãos públicos exigem, por força de lei, forte controle de custos e prazos, além dos recursos humanos envolvidos. O Guia PMBOK é uma boa sugestão para ser utilizado para estes casos.

clique para ampliar

Primeira coisa: eu precisava saber se os processos mapeados para a automação continuavam válidos. Foi aí que entrou o processo de iniciação e a atividade de análise de documentação pré-projeto, previsto no PMBOK. Daí foi possível compreender o escopo e, consequentemente, foi hora de definir o product backlog do projeto. Sim, este conceito vem do SCRUM e tem objetivo similar ao da EAP. Tanto que fiz um product backlog para a execução e a EAP para a gerência do projeto. Duplo trabalho? Claro que não! A EAP é uma ótima ferramenta de comunicação com os gestores do projeto e o product backlog é excelente para lidar com a equipe técnica e o “product owner” do projeto. Mais do que isso, no caso desta empresa pública, em que o projeto foi desenvolvido, há uma metodologia de gestão de projetos em que  a EAP é um artefato obrigatório, já o product backlog foi algo acrescentado pela circunstância do projeto.

clique para ampliar

A execução do projeto foi toda direcionada para que  o manifesto ágil prega: desenvolvimento iterativo, incremental e equipe pequena (havia 4 pessoas voltadas a execução).  Toda a execução foi divida em sprints com igual período de execução. Minha função na execução do projeto era de um facilitador junto à equipe técnica e perante a gestão da empresa, eu era o gerente de projetos que controlava custo, tempo, recursos, escopo, mudanças e realizava a comunicação. O prazo definido pela equipe, a partir da definição do product backlog e do sprint backlog, se fez totalmente compatível com a restrição de prazo que havia para o projeto. Outra iniciativa que trouxe do SCRUM foi a realização das reuniões diárias com a equipe. A reunião propicia excelentes resultados junto à própria equipe, que não fica ilhada em demandas isoladas. As reuniões criam o senso de equipe, pois todos sabem o que está acontecendo e, mais do que isso, se propõe em fazer um ajudar ao outro.

clique para ampliar

Em fim, qual o grande barato disso: é possível adequar dois paradigmas e obter bons resultados. Os projetos críticos, com altos níveis de riscos, não podem ser planejados exclusivamente com base em requisitos funcionais. Deve-se, por exemplo, levar em consideração as etapas da área de conhecimento de riscos, que por sinal é bem descrita no guia PMBOK.

Como já disse aqui, ter a perspicácia do que utilizar e quando utilizar pode levar o projeto ao sucesso. As ideias dos paradigmas do Guia PMOBK e do Manifesto Ágil podem ser trabalhadas em conjunto sim!

Até a próxima!

O PMI agora é ágil: certificação PMI Agile!

18 Mar

Ao anunciar que vai promover a Certificação com Práticas Ágeis de Gerenciamento de Projetos, o PMI (instituto de gerenciamento de projetos) causou um verdadeiro rebuliço junto aos profissionais da área, especialmente naqueles que possuem alguma certificação vinculada à instituição. E como em toda ação, essa também possui reflexos positivos e negativos. As dúvidas que pairam no ar fazem esquentar essa discussão. Neste post abordarei algumas dessas dúvidas e esclarecerei o que será esta certificação.

No arquivo disponibilizado pelo PMI há alguns pontos que me chamaram a atenção e gostaria de compartilhá-los:

  • Definição do que é ágil: para se definir práticas ágeis o PMI utilizou a comparação com as práticas de desenvolvimento em cascata (Waterfall) – aquela no qual uma fase é pré-requisito para outra e o cliente tem pouca participação no processo de desenvolvimento.

Ágil foi definido como uma filosofia que utiliza modelos organizacionais baseados em pessoas, colaborações e compartilhamento de valores.

Importante!

O PMI associa o desenvolvimento ágil como sendo baseado em planejamento por ondas sucessivas. Algo que o guia PMBOK destaca, mas não aprofunda.

Dúvida nº 1: Então, seria o Guia PMBOK também utilizável para desenvolvimento ágil?

  • Sim. Como um guia ele indica as práticas de gerenciamento de projetos que podem ser adequadas à realidade do manifesto ágil.

O material também realça a questão do desenvolvimento iterativo, com entregas incrementais, rápido e flexível a responder às mudanças, e aberto a comunicação entre equipes, interessados no projeto e clientes.

Bom, até aí tudo conforme o manifesto ágil prega.

Ah! O PMI até cita as metodologias (se assim podem ser chamadas) como SCRUM, XP e TDD. Novos tempos…

Dúvida nº 2: Metodologias Ágeis concorrem com o guia do PMI para gerenciamento de projetos?

  • Não. No meu ver, uma complementa a outra. Dependerá da realidade do seu projeto. Ele tem requisitos instáveis? É possível definir as fases de desenvolvimento de forma que atenda as demandas prioritárias? A equipe é pequena e está localizada em um mesmo ambiente?
  • Práticas Ágeis são definidas como sendo atividades que aplicam os princípios ágeis.
  • Princípios Ágeis são apresentados como “verdades fundamentais e valores compartilhados que orientam o comportamento nas metodologias ágeis”.
  • O que é um projeto ágil?

É um projeto que é gerenciado usando princípios e práticas ágeis.  (fonte PMI)

  • Suas características:

a)      Entregas ao longo do desenvolvimento, de forma a mensurar o investimento cada vez mais cedo. Entregas interativas do produto.

b)      Alta visibilidade do progresso do projeto.

c)       Envolvimento contínuo do cliente durante todo o desenvolvimento do produto.

d)      Poder ao proprietário para tomar decisões sobre o projeto.

e)      Melhor gerenciamento de requisitos. (Melhor adaptação à mudança)

f)       Redução de resíduos do processo e do produto. (MUITO BOM!!!)

Dúvida nº 3: O Guia PMBOK , quando utilizado em sua essência, não teria tais características?

  • O Guia PMBOK é um cardápio de opções. Você o utiliza conforme o projeto e a cultura da organização. Quando misturam conceitos de engenharia com de gestão a coisa pode se complicar, mas o guia PMBOK pode ter tais características.

O valor da certificação ágil (destaque para o profissional), segundo o PMI, para:

a)      Demonstrar ao “mercado” o nível de profissionalismo nas práticas ágeis na gestão de projeto;

b)      Aumentar sua versatilidade profissional em ferramentas de gerenciamento de projetos e técnicas.

c) Mostrar que se tem a capacidade de liderar equipes básicas de projetos ágeis, garantido por uma certificação que possua maior credibilidade do que as ofertas existentes com base apenas em provas ou treinamento.

Dúvida nº 5: Como o PMI irá transformar um manifesto em algo padronizado e de consenso como o Guia PMBOK?

  • Essa questão é a melhor. Não tenho ideia!

Dúvida nº 6: A certificação PMP é algo que segue um padrão consolidado. O que fará a certificação PMI Ágil ser diferente da SCRUM MASTER, por exemplo?

  • O PMI vai colocar sua credibilidade na certificação. Os requisitos de elegibilidade já falam por si só. A única questão é que a SCRUM MASTER tem como base o SCRUM, que é diferente do XP (extremming programming) . O que será utilizado pelo PMI?

Minhas considerações:

Ter uma nova certificação PMI, voltada para as práticas ágeis é benvinda, e disso não há como negar. O meu questionamento maior está em torno do posicionamento do mercado em relação aos profissionais PMP, CAPM e os “Ágeis”.

Seremos, nós PMP’s, rotulados como burocráticos?

Particularmente, vejo que é um risco que se está correndo.  Não gosto muito da ideia de começar a defender algo, criando justificativas, com base em comparações com práticas que não servem para todas as indústrias. O Guia PMBOK se propõe a ser utilizado para todas as indústrias, inclusive as de serviços.

Seria, então, a certificação ágil somente para o desenvolvimento de novos produtos?

No material disponibilizado pelo PMI, observei que a palavra “serviço” não é citada. A própria comparação entre modelos iterativos e incrementais com o modelo em cascata já sugere o desenvolvimento de produtos.

No entanto, o PMI diz que as duas certificações (ágil e PMP) têm objetivos distintos. De acordo com o instituto, a certificação ágil está voltada para “validar a capacidade de um profissional compreender os princípios e práticas ágeis.” Já a certificação PMP tem seu foco voltado para reconhecer a competência na liderança e gestão de equipes de projetos.

Para mim essa distinção não é esclarecedora e até surpreende!

Enfim, acredito que a discussão seja valida e vai durar por algum tempo, ao menos até que a certificação piloto seja lançada oficialmente.

No mais, vejo como EXCELENTE que o PMI tenha se posicionado a respeito do manifesto ágil. Ao invés de criticá-lo, o PMI verificou na prática (por meio do seu grupo de estudo) que os princípios e práticas ágeis funcionam.  Algo que o mercado já vem constatando.

O PMI não pode perder o bonde da história e ficar na janela criticando e defendendo um único modelo. A nova certificação agrega valor ao seu portfólio de certificações.  Utilizo há algum tempo o SCRUM com PMBOK e o resultado é excelente.  No entanto, neste caso, ser simplista em achar que as práticas ágeis cabem em qualquer situação seria o primeiro passo para o abismo.

Requisitos para Certificação:

Requisitos de Elegibilidade Descrição
Nível de Escolaridade Formal secundário ou superior
Experiência em Gerenciamento de Projetos 2000 horas de trabalho em equipes de projetos (últimos 5 anos).Se você for PMP não precisará demonstrar novamente.
Experiência em Gerenciamento de Projetos Ágeis 1.500 horas de trabalho em equipes de projetos ágeis ou em metodologias ágeis. Estas horas são adicionais às 2000 de experiência em Gerenciamento de Projetos. Ou seja, 1500 + 2000 = 3500 horas

Elas devem ter sido adquiridas nos últimos 2 anos.

Treinamento em Gerenciamento de Projetos Ágeis 21 horas. O treinamento deve ter necessariamente tópicos de metodologias ágeis.
Exame Teste dos fundamentos Ágeis e habilidade para aplicar em projetos
Manutenção da Certificação 30 PDUs / 3 CEUs a cada três anos em gerenciamento de projetos ágeis.Importante: essas horas contam como requisitos para as duas certificações.

 

O PMI disponibilizou alguns marcos para a certificação, que valem ser conferidas:

    • Quando o conteúdo para a certificação estará disponível?

    O esboço de conteúdo estará disponível em Abril de 2011.-

    • Quando vão começar a ser aceitos os pedidos pelo PMI para a nova certificação?

    Maio de 2010.

    • Quando é que o exame de Certificação PMI Agile será oferecido pela primeira vez?

    A primeira oferta será durante o terceiro trimestre de 2011.

    Até a próxima!

    %d bloggers like this: