Agile e PMBoK. Unindo dois mundos para otimizar um projeto Um caso real de aplicação de ferramentas e conceitos de Agile e PMBoK em um projeto

Transcrição

1 : : : : Agile e PMBoK Atualmente temos visto algumas discussões com a tentativa de provar que metodologia (ou base de conhecimento) X é melhor que a Y etc. Em alguns momentos chegamos a duvidar do sucesso de algumas práticas e ferramentas, quando na verdade deveríamos entender como tirar proveito da melhor forma possível das ferramentas e ideias de cada mindset. Neste artigo será apresentado um relato de projeto em que foram aplicadas ferramentas e ideias de Agile e do PMBoK, mostrando como é possível unir dois mundos teoricamente heterogêneos para obter melhores resultados. Unindo dois mundos para otimizar um projeto Um caso real de aplicação de ferramentas e conceitos de Agile e PMBoK em um projeto Marcelo Zeferino (marceloczeferino@gmail.com): formado em Análise de Sistemas, atua com TI desde 1999 e já participou de projetos de software para grandes organizações como Fundação BioRio/Johns Hopkins School of Medicine, Oi, Sul América e Fundação Roberto Marinho. Já atuou pela IBM Brasil e atualmente é líder técnico na Lumis Tecnologia, consultor e instrutor Java em cursos de extensão oferecidos pela UERJ. Mantém o blog com ideias sobre desenvolvimento de software. m projeto com situação difícil, mas onde o sentimento geral implantado é de que tudo está bem. Esta percepção pode ser bastante prejudicial e causar certo tipo de miopia na equipe sobre os problemas que estão acontecendo e que ainda estão por vir. Tal comportamento agrava também outra questão: a síndrome do estudante. Os desenvolvedores sendo apanhados por este clima de que está tudo bem não alcançam o nível de estresse necessário (aquele considerado bom para a produtividade) e começam a postergar atividades, podendo causar grande atraso no final das contas. 26

2 Síndrome do estudante Fenômeno no qual pessoas começam a se esforçar para finalizar uma tarefa no último momento possível antes do final do prazo. Isso leva a perda de qualquer buffer reservado para tarefas individuais durante estimativas. Definição retirada de post no Blog Visão Ágil, baseado na definição do Wikipedia para o termo (que por sua vez está baseado no que foi definido por Goldratt ver quadro de referências no final do artigo). Tal comportamento pode ser muito prejudicial no desenvolvimento de software em que a qualquer momento podemos descobrir impedimentos tecnológicos ou conceituais. Quanto mais cedo fizermos estas descobertas, melhor para o processo. Com a síndrome do estudante isso pode ser atrasado para um momento no qual não haverá mais tempo hábil para agir na remoção dos impedimentos, fazendo com que o desenvolvimento tenha atraso significante. Este é um problema típico de uma gestão ruim, no qual o gerente de projetos normalmente pergunta sobre o status e a equipe reporta o andamento em números subjetivos (sem apresentar itens em funcionamento) até que o gestor recebe a notícia ruim de que há problemas no desenvolvimento e os prazos não serão atingidos. Lembro da palestra de Jason Yip, no Agile Brazil 2009, com vários bonequinhos desenhados à mão e neste ponto de discórdia no desenvolvimento um boneco de um gerente de projetos atacando um desenvolvedor. Estava claro que não estávamos indo bem e precisávamos tomar algumas ações para que as coisas voltassem aos trilhos. Basicamente, nos guiamos através de alguns conceitos importantes que serão abordados ao longo deste artigo, a saber: Unindo dois mundos um pouco diferentes, mas que podem ser complementares Aqui entra a parte interessante, misturar diferentes conhecimentos para conseguir alavancar um projeto antes que seja tarde demais. Sempre entendi metodologias e ferramentas como peças em uma caixa de ferramentas que deveriam ser usadas cada uma para a resolução de problemas específicos. Como um marceneiro usa um martelo para pregar um prego ao invés de uma chave de fenda. Em alguns momentos acabamos fazendo algo como martelar parafuso. Talvez o objetivo final seja alcançado, porém usamos muito mais força que o necessário. Por que não juntar o melhor de várias ferramentas para conseguir o objetivo de forma mais efetiva? Nesse caso utilizamos ferramentas de duas caixas de conhecimento ditas por muitos como bastante diferentes: PMBoK e Agile. Muito tem sido falado sobre as diferenças nas duas abordagens. Indo no sentido contrário, apresentaremos neste artigo um exemplo de como as duas podem coexistir de forma bastante benéfica. A seguir será abordado cada item mencionado acima, descrevendo as práticas utilizadas em cada caso. Reestimativa das atividades restantes A equipe que atuava diretamente no projeto ainda não havia obtido plenitude no uso da ferramenta escolhida para o projeto. Esse problema fazia com que estimativas fossem bastante distorcidas e que muitos imprevistos acontecessem ao longo do desenvolvimento. Fizemos uma reestimativa de todas as atividades ainda não concluídas com o apoio de uma pessoa com mais conhecimento técnico e contamos com a experiência dessa pessoa para que considerasse que não seria ele o desenvolvedor e que a equipe não tinha o mesmo nível de conhecimento. Atividades não concluídas (mesmo que consideradas pelos desenvolvedores como 80% concluídas) foram estimadas como não iniciadas para evitar mais distorções. O PMBoK sugere que as estimativas sejam feitas pelo próprio desenvolvedor ou por especialistas. Prefiro estimar com os próprios desenvolvedores e com alguma técnica como Planning Poker, mas no nosso caso as estimativas dos desenvolvedores não estavam sendo úteis. Planning Poker Esta técnica foi abordada no livro de Agile Estimating and Planning de Mike Cohn. Trata-se de uma dinâmica na qual as User Stories são apresentadas e os desenvolvedores escolhem uma carta com valores que podem seguir uma sequência predefinida (como 1, 2, 3, 5, 8, 13, 21, por exemplo). Todos apresentam suas estimativas no mesmo momento (o que favorece a individualidade visto que um desenvolvedor com menos experiência não saberá o valor que um desenvolvedor mais experiente apresentará. Logo não será influenciado). Após, os envolvidos discutem a discrepância das estimativas, mais detalhes da story são apresentados e todos tentam chegar a algum número coerente para todos. 27

3 : : : : Simplesmente estimar com um especialista e imaginar que os outros desenvolvedores com menos experiência consigam chegar a tal produtividade é ingenuidade. Por isso, acatamos a nova estimativa e fizemos com que outras pessoas com mais conhecimento ajudassem os mais novos, pareando em alguns momentos. No fim das contas, o estimado ficou bem parecido com o realizado. Criação de cronograma realista com as novas estimativas Após a nova estimativa, elaboramos um cronograma tentando ser o mais realista possível, considerando a equipe atual. Milagrosamente, se tudo ocorresse exatamente como esperado (quase piada em projetos de software) entregaríamos o projeto no prazo, incluindo tempo para equipe de Testes e Qualidade, correção de bugs e revisão final após correções. Sabíamos que o tempo que conseguimos reservar para o pós-desenvolvimento era muito curto e arriscado, inclusive para a equipe de Testes e Qualidade. Nesse momento, apresentamos a situação para a equipe e conseguimos mostrar que a situação não estava tão tranquila como imaginavam. Nesse ponto conseguimos aumentar o nível de estresse da equipe, ponto que foi fundamental para melhorar o desempenho geral. A apresentação destes dados e do cronograma foi em uma sextafeira e, com certeza, todos foram para o final de semana sabendo que teríamos um belo desafio no início da próxima semana. Compressão de cronograma O PMBoK sugere duas técnicas para compressão de cronograma, visando que atividades sejam fiscalizadas em tempo menor que o estimado. Uma abordagem bastante comum é a paralelização, na qual as tarefas que não precisam ser sequenciais são distribuídas entre pessoas diferentes da equipe e executadas em paralelo, criando um pipe-line de tarefas. Este foi o próximo passo que tomamos para melhorar a situação. Após a paralelização de algumas tarefas o cronograma agora refletia uma boa situação, com as tarefas restantes sendo terminadas em um prazo bem mais seguro (considerando as estimativas e que a equipe se dedicaria totalmente ao projeto), o que seria praticamente uma semana antes do prazo anterior (sem a compressão). Esse adiantamento nos daria "um fôlego" e permitiria que o time de Testes e Qualidade pudesse fazer mais testes e teríamos também mais tempo para possíveis correções. Porém, como o tempo de desenvolvimento era bastante curto, havia a necessidade de um acompanhamento de perto para detectar impedimentos e desvios, agindo rapidamente nesses problemas. PMBoK sobre compressão de cronograma Segundo o PMBoK, a técnica de compressão pode ser definida como: (...) encurta o cronograma do projeto sem mudar o escopo do mesmo, para respeitar as restrições do cronograma, datas impostas ou outros objetivos do cronograma. Duas opções são definidas: Compressão: uma técnica de compressão na qual as compensações entre custo e cronograma são analisadas para determinar como obter a maior quantidade de compressão com o mínimo de incremento e custo. Exemplos de compressão poderiam incluir a aprovação de horas extras, recursos adicionais ou o pagamento para aceleração da entrega das atividades no caminho crítico. (...) Paralelismo: uma técnica de compressão de cronograma na qual fases ou atividades normalmente executadas em sequência são executadas em paralelo. (...) Reuniões diárias Após o passo acima, iniciado o desenvolvimento seguindo a nova estratégia, recorremos ao baú do Agile e utilizamos stand-up me- 28

4 etings para manter o grupo integrado e com boa visibilidade das tarefas sendo executadas por cada um. Existem diversas práticas interessantes para a realização de tais reuniões, como técnicas para retirar o foco do Scrum Master/Líder para não virar uma reunião de status, eleger um representante para guiar a reunião e outras. No entanto, nossas reuniões foram bastante simplórias e usaram apenas algumas poucas características importantes: - sem visibilidade de todas as tarefas sendo executadas e problemas. Além disso, sempre me senti mal em reuniões onde o líder da equipe (ou Scrum Master quando utilizando o Scrum) não falava sobre suas tarefas, pois a reunião tende a se tornar uma reunião de status onde todos se reportam ao líder. executar as reuniões na parte da manhã, por volta de 10h. Isso ajuda no planejamento diário de tarefas. Um detalhe interessante durante uma das primeiras reuniões foi um alerta de um membro da equipe sobre estarmos gastando mais de 15 minutos. O motivo foi gastarmos tempo da reunião para falar sobre delegação de tarefas. Tal questão deveria ser organizada através do quadro kanban e não discutidas durante as reuniões. Basicamente, criamos um fluxo bastante simplificado para facilitar o acompanhamento e adesão da equipe. As colunas utilizadas foram: testes) Como as atividades foram divididas em tarefas normalmente estimadas em no máximo 8 horas, o esperado era que fizéssemos algumas movimentações ao menos diariamente. O quadro foi uma ferramenta bastante interessante principalmente para a equipe de testes, que teve mais visibilidade sobre as atividades pendentes sobre o momento em que novas tarefas chegariam em sua fila de trabalho. Uma característica muito positiva deste tipo de abordagem é o aumento de visibilidade sobre o projeto, gerando um ambiente mais próximo de um Information Radiator, fazendo com que até pessoas fora do projeto tentassem se interar sobre o que estava acontecendo, gerando discussões e sugestões interessantes. Diariamente após as reuniões nos reuníamos em frente ao quadro e analisávamos o fluxo das atividades e atualizávamos o nosso Burndown Chart com nossas estimativas para completar o trabalho restante. Em diversos momentos tivemos impedimentos sendo identificados e pedidos de ajuda durante as reuniões. Esse ponto foi essencial para conseguirmos manter a visibilidade do time do andamento do projeto. Utilização de um quadro para o projeto (kanban) Apesar de precisarmos utilizar softwares e ferramentas tradicionais para o acompanhamento do projeto, como cronogramas e software para Issue Tracking, decidimos utilizar um kaban (apenas o quadro, não o processo Kanban) para organizar as tarefas e acompanhar o fluxo. 29

5 : : : : Information Radiator De acordo com o site de Alistair Cockburn, este termo foi cunhado por ele por volta de 2000, enquanto observava alguns quadros informativos em um escritório da Thoughtworks. Um Information Radiator é um mecanismo utilizado para que as pessoas que circulam por determinado ambiente consigam perceber de forma simples e rápida o que está acontecendo. Por exemplo, em projetos que utilizam um kanban podese facilmente entender o fluxo das atividades, gargalos e problemas no processo. Além disso, caso existam gráficos (com um burndown chart, por exemplo) podemos também perceber o andamento das atividades do projeto, criando um ambiente bastante informativo. Segue descrição sobre o que é um Information Radiator, do livro Crystal Clear: A Human-Powered Methodology for Small Teams, de Cockburn (traduzido livremente aqui): Um Information Radiator é uma painel colocado em um local onde as pessoas possam vê-lo enquanto trabalham ou caminham. Ele apresenta aos leitores as informações que lhes são importantes sem a necessidade de perguntar sobre essas questões. Isso significa mais comunicação com menos interrupção. ao ScrumMaster ou líder do projeto atuar no entendimento dos problemas que estão causando esta tendência e remover os impedimentos para que as coisas voltem ao normal. Nesse sentido, as reuniões diárias podem ajudar bastante, visto que são um ótimo momento para se identificar impedimentos e possíveis desvios. A partir da análise do gráfico, pode-se tomar algumas atitudes, como acrescentar ou retirar trabalho do backlog, por exemplo. No nosso caso o escopo era fechado e não tínhamos a possibilidade de retirar itens do backlog, um ponto que pode ser negativo caso o burndown apresente um tendência negativa. Logo nos primeiros dias de nossa pequena iteração, percebemos que não estávamos conseguindo entregar como o estimado devido a alguns impedimentos. Durante as reuniões tivemos alguns pedidos de ajuda, a própria equipe se mostrou bastante engajada na resolução dos problemas, ajudando uns aos outros o espírito de equipe havia sido implantado com sucesso! Em pouco tempo com o empenho de todos tivemos nossa curva voltando para próximo do tempo esperado e conseguimos entregar dentro do tempo esperado. Burndown chart O Scrum introduziu algumas ferramentas interessantes para o acompanhamento da evolução dos projetos, entre elas o Burndown Chart. Um Burndown Chart é um gráfico com dois eixos que demonstra a quantidade de tempo que ainda será gasto para finalizar as tarefas restantes do backlog até o final da Sprint. Tal gráfico deve ser atualizado diariamente pela equipe com as estimativas para término das tarefas. Em um eixo temos a quantidade de trabalho que ainda resta ser executado (podendo ser representado em horas, pontos ou outra unidade de medida) e no outro temos os períodos até o final da iteração ou sprint (normalmente em dias). No Scrum este gráfico é idealmente atualizado diariamente durante ou logo após as Daily Meetings e conforme é esperado que a linha que representa a quantidade de trabalho necessário para a conclusão diminua gradativamente. Este gráfico pode rapidamente fornecer um feedback de que o andamento do projeto está com uma tendência a consumir mais tempo que o esperado para conclusão das atividades, mostrando que as coisas não andam bem e haverá um atraso caso nenhuma atitude seja tomada. Cabe Sprint Burndown Chart Segundo a tradução do Scrum Guide, um Sprint Burndow é: (...) um gráfico da quantidade restante de trabalho do Backlog da Sprint. Para criar esse gráfico, determine quanto trabalho resta somando as estimativas do Backlog a cada dia da Sprint. A quantidade de trabalho restante para uma Sprint é a soma do trabalho restante para tudo do Backlog da Sprint. E uma dica, também do Scrum Guide, é: Acompanhe essas somas diariamente e utilize-as para criar um gráfico que mostre o trabalho restante ao longo do tempo. Traçando uma linha através dos pontos no gráfico, o Time pode gerenciar seu progresso em completar o trabalho de uma Sprint. É bastante comum anexar um gráfico como esse no kanban e atualizá-lo diariamente após as reuniões diárias, ajudando a criar um ambiente informativo.

6 E o final da história Durante o projeto tivemos alguns imprevistos e problemas, como existem em todos os projetos, principalmente em nossa área. No entanto conseguimos superar os problemas e fazer com que o projeto apresentasse o resultado esperado. Há alguns pontos interessantes que conseguimos "sentir" durante e ao fim do projeto: Não adianta forçar a utilização de metodologia X, Y ou Z em ambientes onde sua aplicação não é válida. Claro que em alguns casos a organização precisa de mudanças para que consiga melhorar seus resultados e neste cenário a adoção de uma metodologia pode ser bastante útil. Scrum pode gerar alguns problemas e desconfortos devido às mudanças necessárias e não ser aplicado por completo. No entanto, vale frisar que é esta mudança que pode melhorar a forma de funcionamento da organização, trazendo à tona problemas antes escondidos. Nessa linha, alguns preferem a adoção do Kanban ao Scrum por provocar menos atritos. Assim, a melhor metodologia para um projeto é a que melhor se encaixa nas características do projeto e da equipe e de nada adianta tentar forçar a utilização de algo que não é compatível com a realidade do projeto. Considerações finais Durante este projeto comprovarmos um ponto que tem ganhado bastante atenção da comunidade nos últimos anos a união de técnicas do pacote de conhecimento Agile e do PMBoK e com o objetivo de melhorar os resultados de projetos. Mesmo em organizações que utilizam a abordagem do PMI, podemos utilizar práticas e conhecimentos adquiridos na aplicação de metodologias ágeis. Por exemplo, as histórias que serão inseridas no backlog de uma sprint podem corresponder às atividades de um pacote de trabalho em um cronograma de um gerente de projetos, elaborado no MSProject (que é quase diabólico para alguns agilistas). No sentido inverso, podemos perfeitamente apresentar o andamento de projetos para um grupo de gerenciamento de projetos utilizando um Burndown Chart, que apesar de não cobrir todas as áreas de interesse pode transmitir o status do projeto de forma rápida e clara. Ou melhor, pode transmitir esse status para todos os presentes no ambiente onde este gráfico está visível. A intenção desse relato é aumentar a pilha (que atualmente considero pequena) de trabalhos mostrando que podemos viver bem e maximizar o sucesso de projetos utilizando diversas metodologias e bases de conhecimento, amadurecendo os processos utilizados na organização e trabalhando abordagens diferenciadas para cada projeto. Apesar de essa frase ser mencionada há alguns anos, acabamos esquecendo disso em algumas discussões e no dia-a-dia. Não há uma solução única e perfeita para todos os problemas. Não podemos esquecer as palavras de Fred Brooks. Precisamos encarar o conhecimento como uma grande caixa de ferramentas e retirar os itens que mais se encaixam e melhor resolvem os problemas. Como dito pelos agilistas do Agile Manifesto e ratificado pela comunidade nos últimos anos, pessoas devem ser mais importantes que processos e ferramentas. O comprometimento da equipe e dos envolvidos no projeto é o principal motivo do sucesso ou fracasso de um projeto ou iniciativa. Este é um ponto pelo qual não gosto da afirmação do PMI de que o gerente de Projetos é o principal papel em um projeto. Mesmo que isso apenas signifique que o gerente é uma espécie de maestro, pode ser mal-entendido e levar a criação de um ambiente centrado nesse papel e não na equipe. Ponto para o Agile, que desde sempre enfatiza que o ambiente seja centrado na equipe com a intenção de alcançar os objetivos definidos para o projeto e ganhos (não só financeiros) para os envolvidos. Figura 2. Agile Manifesto. GUJ Discussões sobre o tema do artigo e assuntos relacionados Discuta este artigo com 100 mil outros desenvolvedores em Referências scrum.org/scrumguides/. - ning Poker, mantida pela Mountain Goat Software, de Mike Cohn. burn. ckburn a respeito de Information Radiator. 31