Gerenciamento Ágil de Projetos 2a edição

ferramentas.

O PMI reconheceu o ágil como sendo mais uma técnica que pode ser utilizada para o gerenciamento de projetos e, em 2011, lançou uma certificação específica para o assunto, denominada PMI-ACP (ACP = Agile Certified Practitioner).

Diferentemente de outras certificações voltadas para métodos ágeis, que englobam um framework ou metodologia específica, a certificação PMI-ACP aborda vários frameworks, técnicas e metodologias ágeis.

Trata-se de uma certificação que está em franco crescimento, totalizando aproximadamente 19 mil pessoas certificadas no mundo todo, sendo quase duzentas certificadas no Brasil (até março de 2018).

Vitor, qualquer um pode fazer o exame?

Sim, desde que respeitados alguns critérios de elegibilidade.

1.1. Elegibilidade para o Exame

Para ser considerado elegível ao exame você deve possuir e comprovar ter:

Diploma de ensino médio.

2.000 horas de experiência em gerenciamento de projetos nos últimos cinco anos ou certificação PMP (Project Management Professional) do PMI ativa e regularizada.

1.500 horas de experiência em equipes de projetos que utilizaram metodologias ágeis nos últimos três anos.

21 horas de treinamento em metodologias ágeis.

Atenção! As horas de gerenciamento de projetos e as horas de utilização de métodos ágeis não podem ser intercaladas. Exemplo: atuei de janeiro a abril de 2014 no Projeto X e em abril de 2014 também atuei no Projeto B. No projeto X atuei no planejamento do projeto, totalizando 560 horas. No projeto B atuei como coach da equipe em métodos ágeis, totalizando 80 horas. Ou considero as 560 horas trabalhadas em gerenciamento de projetos e 0 (zero) hora em utilização de métodos ágeis ou considero 480 horas trabalhadas em gerenciamento de projetos e 80 horas em utilização de métodos ágeis.

Atenção! As horas de treinamento aceitas são aquelas referentes a cursos presenciais, cursos via videoconferência ou cursos on-line. Horas de autoestudo não devem ser computadas como horas de treinamento.

1.2. Como se Inscrever para o Exame

Ok Vitor, atendo aos critérios de elegibilidade. E agora?

Agora você deverá seguir o roteiro adiante:

1. Ler o handbook da certificação disponível no site http://www.pmi.org/~/media/PDF/Certifications/PMI-ACP_Handbook.ashx .

2. Criar login e senha no site do PMI ( www.pmi.org ) e ir até a opção Apply for PMI-ACP Credential .

3. Você terá um prazo de 90 dias para o preenchimento do formulário de inscrição.

4. Após submissão do formulário, o PMI revisará a inscrição em até dez dias.

5. Após a liberação do PMI, pagar o valor da inscrição através de cartão de crédito internacional.

6. Após o pagamento, a candidatura pode ser selecionada pelo processo de auditoria e poderão ser solicitados documentos que comprovem as informações preenchidas na inscrição.

7. Se a candidatura não for selecionada pelo processo de auditoria, o PMI enviará a Elegibility Letter , e o exame deverá ser agendado em um Centro Prometric ( www.prometric.com ) em um prazo máximo de um ano.

1.3. Conteúdo do Exame

O exame é presencial e contém 120 questões, das quais 20 não são consideradas para a pontuação final. Para o candidato ser aprovado no exame deverá ter aproximadamente entre 70% a 80% de aproveitamento.

A duração do exame é de três horas, ou seja, 1 minuto e 30 segundos por questão. É um tempo relativamente agressivo.

Desde março de 2018, o exame encontra-se traduzido para o português.

1.4. Bibliografia Referencial para o Exame

Em setembro de 2017, o PMI, em parceria com a Agile Alliance, lançou o Guia Ágil como sua referência de práticas ágeis a serem utilizadas em projetos e serve como insumo de estudos para a realização do exame.

O PMI também recomenda a leitura de 12 livros considerados base para o exame, são eles:

Agile Estimating and Planning, de Mike Cohn.

Agile Project Management: Creating Innovative Products – 2nd Edition, de Jim Highsmith.

Agile Retrospectives: Making Good Teams Great, de Esther Derby e Diana Larsen.

Agile Software Development: The Cooperative Game – 2nd Edition, de Alistair Cockburn.

Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition, de Lyssa Adkins.

Effective Project Management: Traditional, Agile, Extreme, de Robert K. Wysocki.

Exploring Scrum: The Fundamentals, de Dan Rawsthorne e Doug Shimp.

Kanban in Action, de Marcus Hammarberg e Joakim Sunden.

Kanban: Successful Evolutionary Change for Your Technology Business, de David J. Anderson

Lean-Agile Software Development: Achieving Enterprise Agility, de Alan Shalloway, Guy Beaver e James R. Trott.

The Software Project Manager’s Bridge to Agility, de Michele Sliger e Stacia Broderick.

User Stories Applied: For Agile Software Development, de Mike Cohn.

Atenção! O PMI revisa constantemente as informações sobre o conteúdo do exame, então se houver qualquer tipo de divergência entre as informações deste livro (basea­do nas informações sobre o exame até março de 2018) e as informações do PMI, considerar as informações do PMI como corretas.

1.5. Preparando-se para o Exame

Gostaria de dar algumas dicas para o seu plano de estudo:

Faça um bom curso preparatório, utilizando este livro como material de apoio e complemento.

Intercale cada matéria do seu curso revisando a matéria correspondente neste livro e fazendo os respectivos simulados.

Estude de duas a três horas por dia, todos os dias.

Leia de dois a três livros considerados bibliografia referencial para o exame.

Faça os dois simulados de revisão cronometrando o tempo e sempre procurando fazer um tempo menor que 1 minuto e 30 segundos por questão, pois será seu tempo para revisar as questões.

Ao término do seu curso e da leitura deste livro, faça o simulado final de 120 questões encarando como uma grande final de campeonato. Cronometre seu tempo e busque acertar no mínimo 100 questões.

Se você acertar 100 ou mais questões, gaste mais uma semana fazendo uma revisão final. Se acertar menos, estude mais um pouco para preencher suas lacunas de conhecimento.

Preferencialmente, tente marcar o exame em uma segunda-feira, pois seu cérebro estará livre das preocupações do dia a dia e do cansaço acumulado da semana.

Se você agendou seu exame para uma segunda-feira, estude até o sábado anterior. NÃO estude no domingo e tenha um domingo tranquilo com boa alimentação, bastante repouso e uma noite bem dormida! Adie o churrasco e a cervejada para o domingo seguinte como comemoração da sua certificação!

1.6. O Dia do Exame

Chegou o tão aguardado dia! Deixe-me dar algumas dicas para você:

Trace uma estratégia de intervalo. Exemplo: a cada 40 questões faça uma pausa para tomar uma água, ir ao banheiro e relaxar um pouco.

Ficou na dúvida? Questão complicada? Assinale alguma alternativa e marque a questão para revisar posteriormente. Lembre-se de que você tem 1 minuto e 30 segundos por questão, então não perca tempo!

Bom, agora que falei tudo o que você precisava saber sobre o exame, comece a jornada para que este livro o ajude a se tornar mais um certificado PMI-ACP!

Aos estudos!

Neste capítulo falarei sobre os valores e princípios que sustentam as metodologias ágeis. Também mencionarei as principais metodologias e frameworks ágeis existentes e o que você precisa saber sobre elas para encarar o exame.

2.1. Manifesto Ágil

No ano de 2001, 17 gurus do desenvolvimento de software reuniram-se na cidade de Snowbird para discutirem diversos assuntos e um deles foi: projetos de software sempre fracassam ou atrasam ou são problemáticos sempre pelos mesmos motivos. O que fazer?

Como fruto dessa discussão os 17 membros (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas) assinaram o manifesto contendo quatro valores e 12 princípios.

Os valores do Manifesto Ágil são:

Indivíduos e interações sobre processos e ferramentas

Hoje em dia, no mundo dos projetos, muitas pessoas adotam uma postura defensiva, resguardando-se sempre através de processos e ferramentas. Quem nunca passou por algum momento de tensão ou crise no projeto onde foram usados os termos: mas já tinha te informado por e-mail ou estava escrito na documentação passada? Minha resposta para esse tipo de questionamento é: quando falamos pessoalmente sobre isso? Quando nos comunicamos de forma a deixar as expectativas claras?, ou melhor: quando interagimos enquanto indivíduos que se comunicam de forma verbal quase 90% do tempo?.

Descrevo a seguir três situações curiosas onde a prioridade de processos e ferramentas sobre a comunicação verbal entre os envolvidos levaram projetos a situações de desgastes desnecessários:

Uma vez voltando de férias, havia acabado de ligar meu equipamento quando fui abordado por um colega a respeito de um problema que dependia de minha atuação. Minha resposta foi: nossa, não estou sabendo de nada ainda. E a réplica: mas te mandei um e-mail. De forma muito educada respondi que havia acabado de voltar de férias e mostrei que havia 529 e-mails pendentes na minha caixa postal; logo, não saberia em cinco minutos o que era crítico e o que não era.

Certo dia precisei ausentar-me e de repente recebo uma série de ligações no meu celular de alguns gerentes preocupados com uma situação crítica que estava acontecendo e que ninguém estava conseguindo me localizar. O argumento: foram enviadas diversas mensagens e você não respondeu. A réplica: enviadas para onde? A tréplica: para seu WhatsApp. Ou seja, fui acionado por um dispositivo que depende da precária internet 3G do país, sendo que uma simples ligação poderia ter resolvido o problema.

Em um dos meus workshops, uma analista de negócios me descreveu o fluxo de comunicação de um projeto que estava sendo conduzido. Ela escrevia um longo documento de escopo, que seguia para um líder técnico, que encaminhava para a equipe de desenvolvimento. Se a equipe tivesse dúvidas, elas eram encaminhadas para o líder técnico, que encaminhava para a analista de negócios. A analista de negócios respondia e todo o fluxo começava de novo. Pequeno detalhe: tudo escrito e tudo via e-mail. Ora, por qual razão a analista de negócio e a equipe não podiam interagir juntos? Por que passar sempre por essa figura do líder técnico? Por que comunicação escrita sempre? Qual é o tempo desperdiçado nesse vaivém de informações?

Deus nos deu um dom maravilhoso, que é o dom da fala, o dom das pessoas se comunicarem umas com as outras olhando nos olhos! Pergunto: por que a cada dia não se usa esse dom nos projetos? Por que se defender atrás de ferramentas e processos?

Como sempre digo, o sucesso de um projeto depende de captar as necessidades e expectativas do cliente final. As necessidades, sendo algo objetivo, podem ser captadas em papéis, documentos e e-mails. Mas e as expectativas? Como captar algo subjetivo e pessoal sem fazer bom uso da comunicação, da interatividade, da prática da empatia, da escuta ativa e da inteligência emocional?

Processos e ferramentas são importantes para formalizar ou documentar decisões, mas a primeira forma de comunicação deve ser sempre feita de forma pessoal e interativa.

Dica para as equipes de projeto: comuniquem-se mais e melhor, defendam-se menos através de processos e ferramentas e garantam um projeto de parceria e sucesso.

Software funcional sobre documentação abrangente

Muitas organizações exigem que qualquer processo de desenvolvimento só possa começar após a área de negócios preencher documentos como: Declaração de Escopo, Requisitos de Negócios, Solicitação de Mudanças, Casos de Uso, fora outras documentações de governança exigidas. Até aí, problema algum! A dificuldade surge quando esses documentos se tornam o principal canal de comunicação entre a área de negócios e a equipe de desenvolvimento.

Já presenciei absurdos de algumas equipes de desenvolvimento exigirem que o documento de especificação tenha no mínimo 50 páginas para passar clareza!

Outra situação delicada ocorre com organizações que implementam escritórios de PMO da forma mais engessada e burocrática possível (lembrando que não são as boas práticas do PMBOK® Guide que engessam os processos, e sim as pessoas que aplicam as boas práticas de forma burocrática). Esses escritórios costumam exigir diversas documentações para atender ao processo de governança.

Mas pergunto: e a qualidade do meu software? Qual é a garantia de que todas essas documentações vão gerar um software de qualidade? Já vi casos de documentações tecnicamente perfeitas, atendendo a todos os processos de governança, e o software ser uma bela porcaria. Pergunto: valeu a pena?

Se a interatividade entre as áreas de negócio e desenvolvimento é um dos fatores-chave para o sucesso de um projeto, o canal de comunicação entre eles deve ser leve.

Aí você pode me dizer: mas, Vitor, isso soa muito anárquico! E se um diretor da minha organização pedir a documentação do meu projeto? Minha resposta é: não, você deve continuar gerando a documentação pesada do seu projeto se necessário, mas essa documentação não deve ser o canal de comunicação com sua equipe, e sim a formalização do processo para ser arquivado dentro da organização.

Lembre-se sempre de que o projeto deve entregar um produto de qualidade e não somente uma documentação de qualidade. Um exemplo prático: você lê um longo artigo em uma revista sobre um determinado restaurante. O artigo está bem escrito, dá muitos detalhes dos tipos de comidas servidas, carta de vinhos e preços. Você se interessa e vai ao restaurante, mas quando chega lá encontra garçons mal-educados e uma comida não tão boa assim. Você voltaria?

Agora faça esse comparativo com um projeto de software, reflita e tire suas conclusões.

Colaboração com o cliente sobre negociação de contratos

Imagine o seguinte cenário: um cliente contrata consultoria externa para o desenvolvimento do projeto de um novo software. Estabelecem um contrato de preço fixo, com uma duração determinada, onde o cliente exerce toda sua capacidade de prever o futuro e identifica todos os requisitos nos mínimos detalhes no início do projeto. Qualquer mudança no decorrer do projeto, mesmo que seja algo que agregue valor ao cliente ou provocado por mudanças no mercado, torna-se um drama! Surgem discussões sobre cobranças adicionais, responsabilidades, escassez de recursos para atuarem nas mudanças, etc., etc., etc. E o principal, que é o VALOR, fica em segundo plano.

Se a consultoria trabalha como parceira do cliente e entrega valor, com certeza o cliente a contratará para outros projetos. Caso contrário, é só lembrar-se da história do restaurante que mencionei anteriormente.

Você pode me perguntar: mas, Vitor, as consultorias estão preparadas para trabalhar desse jeito? Alguém já trabalha assim?. Respondo que poucas já trabalham e que, no geral, a maioria ainda não está preparada, pois se trata de uma quebra de paradigmas dos tradicionais contratos engessados com preço fixo. Mas é importante desafiar o status quo e provar que esse é um caminho para ajudar a resolver problemas clássicos de projetos regidos por contratos com consultorias externas.

E, como sempre digo, para provar que algo funciona ou não é preciso experimentar e testar!

Dica: consultorias: colaborem mais com seus clientes e tornem seus contratos mais flexíveis! Clientes: trabalhem com suas consultorias com o conceito de equipe unida e esqueçam o nós e o eles.

Resposta às mudanças sobre seguir um plano

Todo e qualquer projeto deve começar com alguma documentação como ponto de partida, seja uma declaração de escopo, seja um requisito de negócios. Mas começa com um grande problema quando é exigido do analista de negócios, cliente ou usuário que ele especifique todos os requisitos no maior nível de detalhes possível.

Ora, se boa parte dos projetos lida com incertezas, condições tecnológicas, condições de mercado e riscos, como prever que o documento inicial não será passível de mudança? Como prever que todos os cenários foram contemplados nesse documento inicial? Como prever se o requisito que era imprescindível no início do projeto continuará sendo imprescindível? Como prever se uma mudança que agregue valor ao produto não surgirá no meio do caminho?

Tive a oportunidade de ouvir a história de uma analista de negócios que precisou gerar um documento pesado com inúmeras páginas e excesso de detalhamento, pois era o padrão exigido pela área de desenvolvimento do projeto. No decorrer do desenvolvimento, uma condição de mercado mudou e era necessária uma adequação no projeto.

Travou-se o seguinte diálogo:

— Não temos recursos para atuar nisso. Essa mudança terá que ficar de fora.

— Mas se ficar de fora não tenho como lançar o produto. O mercado sofreu mudanças e precisamos adequar o produto para que ele seja lançado com competitividade perante a concorrência.

— Paciência. Temos que fazer o que está escrito.

Na situação real descrita identifica-se que:

Os processos e as ferramentas prevaleceram sobre os indivíduos e suas interações.

Ter a documentação detalhada prevaleceu sobre o produto final.

Seguir um contrato à risca prevaleceu sobre a colaboração com o cliente.

Seguir um plano inicial prevaleceu sobre a mudança necessária.

Outra situação que ocorre muito é quando as mudanças necessárias se tornam a temida fase 2 do projeto. Uso o termo temida, pois muitas vezes o produto gerado na fase 1 do projeto ou não tem o valor esperado pelo cliente ou é ruim mesmo, e a chamada fase 2 torna-se tão ou até mais importante que o projeto original.

No mundo dos projetos criou-se indevidamente uma aversão à palavra mudança. Entendo que a mudança deva ser controlada, senão o projeto se torna o caos. Mas mudanças necessárias para gerar valor ao produto final e ao cliente devem ser analisadas e, na medida do possível, encaixadas no desenvolvimento do projeto. Por esse motivo é interessante utilizar um ciclo de vida iterativo e adaptativo em projetos regidos por incertezas e riscos.

Então, gerentes de projetos, desenvolvedores e gestores no geral, lembrem-se sempre de duas coisas:

O incerto não pode ser previsto com antecedência e precisão.

A mudança que gera valor ao produto final e ao cliente deve ser sempre vista com bons olhos e não com restrições.

Atenção! Para o exame é fundamental que você saiba à risca os quatro valores do manifesto ágil. Cuidado com o jogo de palavras: as palavras equipe, time ou pessoas são diferentes da palavra indivíduos. As palavras iteração ou iteratividade são diferentes da palavra interação. Software funcionando é diferente de software funcional. Entenda também que a principal diretriz de um projeto ágil é estar alinhado com os valores e princípios do Manifesto Ágil.

Falando agora sobre os 12 princípios do Manifesto Ágil:

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Uma vez que as entregas são contínuas, isso permite que o cliente tenha visibilidade e transparência sobre o que está sendo feito, além de se estabelecer uma relação de maior confiança.

2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. Projetos com riscos e incertezas sempre estão sujeitos a mudanças ou inclusão de requisitos, mesmo no final do projeto. Exemplo: seu projeto consiste em lançar um sistema de cotação de seguros on-line . Está quase tudo pronto quando uma organização