AgileFAQ #2: E o cliente?

Seguindo essa ótima idéia do Agile FAQ, acho que essa é realmente a segunda pergunta que mais recebemos em apresentações. Na verdade ela aparece em diversos formatos:

  • E se meu cliente não for técnico?
  • E se meu cliente não quiser participar da equipe?
  • E se meu cliente estiver longe?
  • E por aí vai…

Continue reading

Projeto Ágil, de Nível Nacional e no Governo! O Case Encceja.

É verdade! E não é que os tempos estão mudando mesmo? No último dia 06 de outubro, entrou no ar o Encceja: Exame Nacional para Certificação de Competências de Jovens e Adultos. Ou, da forma mais fácil como nos descreveram, tipo um supletivão do governo.

Nossa história com o projeto começou quando eu e o Bruno fomos chamados pelo Fábio Petrillo, Coordenador Geral de Sistemas de Informação do INEP para ajudarmos o pessoal a trabalhar com Metodologias Ágeis. Não houve esforço nenhum para o Petrillo comprar a idéia, pois ele já acreditava em Agile e já tinha trabalhado com isso antes. Já leu os livros que eu li, os que você já leu e mais um monte que a gente nem ouviu falar ainda. É um cara que sabe das coisas.

O desafio pra gente era com a equipe, pois não seria legal chegar com “pose” de consultor pedindo pra eles fazerem as coisas de uma forma completamente diferente e depois ir embora deixando eles com o pepino na mão. Eles tinham que ver muito rápido benefícios nas práticas adotadas, e ver que estávamos do lado deles, senão a consultoria e o projeto iam afundar. Não sabíamos por qual prática começar, nem como abordar o pessoal.

Restavam 11 semanas de projeto e o prazo não era negociável por força de lei. A equipe começou com Danielzim, Cláudio Alberto e Sandro. Depois entraram Robert (JBoi Seam), Vitor e Kelly.
O desafio inicial era enorme. O projeto já tinha um módulo administrativo funcionando, com algumas fraquezas, e tínhamos que migrar o banco, desenvolver a inscrição web e refazer o módulo administrativo. Ao longo do projeto, a idéia da migração do banco e do redesenvolvimento do módulo administrativo foram abandonados. Ainda bem! A inscrição web já tinha por si suficientes desafios. Tinha que resolver diversos problemas legados de outras inscrições.

Cláudio Alberto pilotando o sistema apresentado pela equipe, para dar feedback ao cliente. Atrás: Bruno, Vitor, Petrillo, Robert e Daniel

Começamos levantando tudo em estórias e planejando iterativamente. A equipe tem muito mérito pois absorveu as práticas de forma surpreendentemente rápida. Também são muito habilidosos e desenvolveram as coisas bem rápido. No começo eu e o Bruno achamos as estimativas otimistas demais, que acabariam se frustrando, mas eles conseguiam cumpri-las muito bem. Havia receios por parte deles em relação à não utilização de casos de uso com toda descrição do sistema. Acredito que há até hoje! :o)

O Kanban começou numa porta de armário. Falta de espaço não pode servir de desculpa pra não começarmos a utilizá-lo. Depois foi pra um quadro chique, com product burndown e tudo mais.

Ao longo do projeto, o Cláudio foi fazendo a interface com o cliente a cada versão gerada e também levantava casos de teste, pois o cliente tinha restrições em estar presente. O feedback gerou diversas alterações que melhoraram bastante o sistema e também permitiram que escopo fosse cortado dessa release. Foi bom pra todos. O pessoal desenvolveu testes automatizados e também se ajudou em pares. Inclusive, pra eles isso foi um ponto forte destacado: a integração da equipe de desenvolvimento.

Par que nada, esta foi uma triple do pessoal, pra resolver problemas na automação de testes.

Uma das últimas stand-up meetings do projeto, falando dos testes e ajustes finais.

Após o sistema entrar em produção, a equipe já estava gerando versões com naturalidade e confiança pra ir corrigindo detalhes e disponibilizando versões a cada dia – graças às builds semanais. Na última visita que fizemos a eles, dia 8, já havia cerca de 20 mil inscritos (Rodando no JBoss – cha chim!!$$$), e consideramos o projeto um grande case de sucesso com agile.

Claro que ainda há muito o que aprender, aliás, essa é a moral da história: sempre há! Agora o desafio é espalhar a cultura no resto do departamento. Já sabemos que outro projeto vai começar a adotar metodologias ágeis, o Enem. Em breve, de um jeito ou de outro, todos acompanharemos os resultados – acredito que seja com muita alegria, como no case do Encceja.

Abraço a todos, parabéns ao INEP pela coragem e parabéns à equipe pelo ótimo trabalho!!!
Willi

PMBoK e Agile… Pode?

Essa é uma questão me fazem vez ou outra. Me senti na dívida de explicar melhor o assunto, e cá estamos. A questão ocorre como se ao adotar uma metodologia ágil, a pessoa estivesse de alguma forma “subvertendo os preceitos do PMBoK”, e isso poderia estar indo contra o “código de ética dos PMP’s”, como se um padre pregasse sem seguir a Bíblia ou coisa assim. Que pecado!

pecado

A má interpretação mais recorrente é que o PMBoK é um processo, assim como seriam as metodologias ágeis, e que esse processo deve ser seguido fielmente pra seu projeto dar certo, pra você ser um bom gerente de projetos, ter sucesso, etc. O PMBoK não define um processo, é um conjunto de conhecimentos e as ditas melhores práticas.  Da introdução:

“O Conjunto de conhecimentos em gerenciamento de projetos é a soma dos conhecimentos intrínsecos à profissão de gerenciamento de projetos. (…) inclui práticas tradicionais comprovadas amplamente aplicadas, além de práticas inovadoras que estão surgindo na profissão, inclusive materiais publicados e não publicados. (…) está em constante evolução.” (PMBoK pág. 3)

Tenho visto cursos que ensinam gerência de projetos através dos processos descritos no PMBoK, inclusive passando aquela noção errada de que gerenciar é seguir fidedignamente todos aqueles processos, preenchendo toda documentação de cada caixinha, suas entradas e saídas. (O próprio livro diz que os processos podem interagir de diversas formas, como definir uma ordem?)
Ora, gerenciar não é preencher papel! Imagina ter que fazer tudo que o livro traz em cada projeto em todas os tipos de projetos? Seria o segredo para o fracasso na verdade! Já pensou? Por exemplo, já vi projetos simples de sites que deveriam ficar prontos em 15 dias, um mês às vezes… Não daria pra fazer nem metade dos formulários! Imagina os recursos gastos, mesmo reaproveitando os textos! Ou você sempre estouraria o orçamento, ou seria caríssimo, logo pouco competitivo. De qualquer forma terminaria fora do mercado.

Outro exemplo: pra desenvolver um sistema em tempo real, digamos para um avião, você tem que dedicar muita atenção ao gerenciamento de riscos. Realmente cabe documentar bem, várias análises, gente preocupada só com isso pra assegurar que gente não morra. Imagina fazer isso tudo pro simples site exemplificado anteriormente…

O PMBoK traz resposta pra isso, na mesma página, quando se refere a seus objetivos:

“O principal objetivo do Guia PMBoK é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico.” (PMBoK pág 3, destaque do livro).

E isso é reforçado na página 37:

“Isso não significa que o conhecimento, as habilidades e os processos descritos devam ser sempre aplicados uniformemente em todos os projetos. O gerente de projetos, em colaboração com a equipe do projeto, é sempre responsável pela determinação dos processos adequados e do grau adequado de rigor de cada processo, para qualquer projeto específico.” (também em negrito no livro)

Esses parágrafos esclarecem toda a questão, não? O próprio livro as destaca! A equipe é responsável por determinar quais áreas de conhecimento devem ser aplicadas, quais processos, em que grau, rigor, com quais entradas e saídas e em que nível de formalismo. A equipe que deve escolher as ferramentas mais adequadas para cada situação!


Está sendo atribuída ao PMBoK a mesma responsabilidade que muitas vezes é atribuída ao RUP. Nem no RUP, que é de fato um processo, você deve usar toda documentação, completa, com todas atividades, na ordem determinada, com cada pessoa pra exercer um papel, etc. Alguém, exercendo o papel de engenheiro de processo, deveria customizar o processo, selecionar artefatos e adequar tudo aquilo que se tem à disposição para o projeto em particular.

Isso não era feito, o processo virava um cascatão super burocrático, complicado, cheio de atropelos, cheio de gente e a culpa ia pro RUP (que também tinha melhores práticas e conhecimento agregado de anos de experiência da Rational em desenvolvimento de software).

Talvez o RUP tenha sido apresentado como um remédio para todos os males das organizações, traumatizadas pelos projetos que não tinham documentação nenhuma, ficavam na mão de analistas do mau, que às vezes às chantageavam, sabendo que eram insubstituíveis pois levariam consigo todo conhecimento dos sistemas. Projetos eram jogados inteiros no lixo porque ninguém conseguia entender ou dar manutenção, milhões eram perdidos…

Mas como todo remédio, dependendo da dosagem, pode fazer mal. E partimos dum extremo sem documentação nenhuma pra outro com documentação demais!


“Adotar o RUP” não adiantou. Projetos continuavam falhando. As organizações então devem ter pensado: “Deve ter sido por falha de gerência…” Que venham os PMPs!
E quando virem que só isso também não vai bastar, quais letrinhas serão adotadas?
A culpa vai ser sempre dessa sopa de letrinhas!

Pessoal, claro que isso tudo foi só uma brincadeira…

E as metodologias ágeis? Ser ágil é seguir os valores do manifesto. Só! Só que é o que faz toda a diferença nos projetos. O XP traz práticas alinhadas aos valores, mais focadas na engenharia, o SCRUM traz um framework para gerenciar projetos favorecendo os valores e assim por diante.

Logo, casar as duas coisas é totalmente possível! Não está ferindo nada!


Se ainda não se convenceu, seguem aqui mais algumas fontes de leitura que achei interessantes, (já devem até ter surgido outras desde que fiz essa pesquisa):

  • Aqui, uma relação das áreas de conhecimento de integração, escopo, risco e qualidade, do PMBoK, com práticas ágeis de uma autora, Michele Sliger, que é PMP e CSM. Recomendo!
  • Nesta apresentação, ela traz, além do mapeamento das áreas de conhecimento, Evidências de que as Metodologias ágeis são aceitas pelo PMI como  revistas do PMI com publicações sobre Agile, fala de mais gente do PMI que adotam Agile, etc.
  • Uma interessante apresentação do Alan S. Koch, do PMI de Pittsburg, em que ele analisa cada processo do PMBoK e aponta suas compatibilidades e incompatibilidades, concluindo que nada nas metodologias ágeis é incompatível ao PMBoK, e adicionar alguns processos do PMBoK pode ser recomendável, mas só onde realmente necessário e de preferência que não comprometa a agilidade.

Faltam iniciativas do Brasil, né? O que está faltando pra nos convencermos?

Abraços,

Trabalho como gerente de projetos de desenvolvimento de software na SEA Tecnologia, atualmente utilizando e divulgando metodologias ágeis em Brasília.
Formado em Computação na UnB, Pós-Graduado em Software Livre pela UNISUL e cursando MBA em Projetos pela FGV. Certificado como PMP, ITIL Foundations, Java Programmer, IBM RMUC e IBM RUP Specialist.