O Gerenciamento de Riscos é uma parte central do gerenciamento de projetos tradicional, e está listado como uma das nove áreas de conhecimento pelo PMI (Project Management Institute) em seu PMBoK. Quando se fala de gerenciamento ágil de projetos, muitos são os que indagam como Scrum (ou Agile no geral) trata as questões de risco, e muitos também são os que dizem que Scrum ignora completamente os riscos. Mas não é bem assim.
Primeiramente, um dos principais benefícios do gerenciamento de riscos se torna desnecessário quando um projeto usa a abordagem ágil. As iterações curtas, o foco em software funcionando, a ênfase em testes automáticos e a entrega frequente ao cliente ajudam o time a enfrentar o maior risco que a maioria dos projetos enfrenta: o de não conseguir entregar o produto. Portanto, o que acontece em muitos projetos ágeis é o gerenciamento implícito de riscos. Para eles, o custo do gerenciamento explícito de riscos se sobrepõe aos benefícios.
Mas, apesar de serem muitos os projetos que podem (e devem) tratar os riscos de tal maneira, outros se beneficiam de gerenciá-los explicitamente. Para isso, John Brothers introduziu uma técnica em 2004 chamada de Risk Burndown Chart, ilustrado na figura abaixo:
Figura: Risk Burndown Chart. A linha vermelha é o parâmetro base da redução do risco ao longo das iterações, enquanto que a azul é a atualização da situação real.
Basicamente, o gráfico mostra a exposição do projeto ao risco ao longo das iterações. A Exposição ao Risco é calculada considerando o tamanho do impacto (em dias) do risco e a sua probabilidade de acontecer. Como exemplo, um risco do atraso do projeto em 15 dias, com 20% de chance de ocorrer, dá uma exposição ao risco de 5 pontos.
Olhando para o gráfico acima, vemos que o risco não tem diminuído a uma taxa apropriada (nem perto disso). Quando isso ocorre, o time pode requisitar dedicar algum tempo no próximo Sprint para trabalhar diretamente com mitigação de riscos.
Como podemos ver então, é possível sim levar a sério o gerenciamento de riscos em projetos ágeis a ponto de explicitá-lo. Se for necessário, o Risk Burndown Chart é uma útil ferramenta.
Por fim, é bom não confundir “não levar o gerenciamento explícito a sério” com “não levar o risco a sério”. Vimos neste texto que o risco sempre é tratado em projetos ágeis, seja explicita ou implicitamente.
Este artigo foi adaptado do post original no blog do Mike Cohn, que pode ser encontrado clicando aqui.
CSPO
Há muito tempo venho querendo passar pelo processo de certificação CSPO (Certified Scrum Product Owner), da Scrum Alliance. Na semana passada eu finalmente consegui, participei do treinamento ministrado em Recife-PE por Michel Goldenberg, CST.
O processo é simples: o candidato se submete treinamento de 16 horas e, no final, o CST (Certified Scrum Trainer) julga se ele está apto ou não a receber a certificação. Parece fácil, mas não é bem assim. A turma era pequena (oito pessoas), e durante dois dias os candidatos não permaneceram um segundo sequer parados, seja participando de dinâmicas, fazendo exercícios que colocam o cérebro para funcionar ou ainda sendo questionados pelo instrutor sobre como aplicariam em suas realidades particulares o conhecimento passado naquele minuto.
Já trabalho efetivamente há dois anos com Scrum, e achava que sabia exatamente qual era papel do PO, ele era o cliente presente, que avaliava continuamente o trabalho do time e priorizava as demandas. Depois do curso, vi que era muito mais do que isso: ele é o cliente que participa de forma totalmente engajada no projeto, e é quem tem o pescoço mais comprometido de todos. Isso mesmo, mais do que o Scrum Master e o time de desenvolvimento. Por isso, ele influencia massivamente (mesmo que indiretamente e utilizando-se de técnicas e artifícios) o processo de desenvolvimento.
Se o Scrum Master é responsável pelo sucesso do Scrum no processo, o Product Owner é quem deve garantir o sucesso do projeto. Ele é cliente, patrocinador e maior conhecedor do escopo do produto. É ele o responsável pelo ROI (Return On Investment – Retordo do Investimento), e mais ninguém.
No treinamento, o participante aprende como determinar o tamanho de Releases e Sprints, estimar a Velocity do time, facilitar o trabalho deste último de várias formas, atuar para influenciar positivamente a produtividade sem sobrecarregar o time e, o mais importante: calcular o ROI e priorizar requisitos de acordo com ele, de forma que se possa entregar o máximo de valor de negócio no tempo mais curto possível no projeto. Algo como 80% do valor de negócio total em 20% do tempo, em uma situação ideal. Outro momento importante, é lógico, são as situações práticas, onde, por exemplo, o instrutor faz propositalmente os candidatos errarem e se sentirem perdidos e em seguida mostra como agir rapidamente para adaptar o projeto às mudanças que o mercado, o negócio em si e os stakeholders em geral fazem ser necessárias para continuar entregando business value.
O treinamento também me abriu outra nova visão: o quanto precisamos de capacitação, não só nas empresas que desenvolvem e fornecem software, mas também naquelas que adquirem. Um bom Product Owner, segundo o Michel, aumenta o ROI do projeto em até dez vezes. Isso significa que o cliente deve se capacitar, para extrair até a última gota de retorno sobre seu investimento ao fazer um contrato de desenvolvimento de software com seu fornecedor, o que é extremamente importante em no mercado competitivo em que vivemos.
Voltei de Recife como CSPO, mas mais importante, com outra cabeça, com novos objetivos, com a proposta (para mim mesmo) de disseminar esses conhecimentos por aqui, começando no trabalho. No futuro, quem sabe, em outros lugares. Confesso que, devido ao valor relativamente alto, fiz o investimento com um certo medo de ter feito um mau negócio. Passado o treinamento, estou totalmente satisfeito, e recomendo-o firmemente, principalmente àqueles que gostaram ou se identificaram com o post anterior deste blog.
Livro: User Stories Applied
Há pouco tempo li o livro “User Stories Applied“, do Mike Cohn, recomendado a mim por Fabrício Paiva. O autor dispensa apresentações para a comunidade Agile, e o material é também de ótima qualidade.
Muito explicativo, e com diversos exemplos da vida real, é o livro de cabeceira para Analistas de Negócio e Gerentes de Produto que trabalham com desenvolvimento ágil.
Especificamente no meu caso, por estar me aprofundando nos estudos e aplicação do Scrum já há algum tempo, gostei muito do conteúdo. Há tempos que procuro um texto mais completo sobre o trabalho e o papel do Product Owner, sendo que em grande maioria os conteúdos disponibilizados na internet e em livros se destinam mais a Scrum Masters ou desenvolvedores de equipes Scrum, descrevendo brevemente o papel do PO.
Fica a dica para os atuais e futuros Product Owners e Scrum Masters. Lembrando que, apesar de fazer referência a Scrum e a XP em suas páginas, o livro não é amarrado a nenhum framework ou metodologia ágil especificamente. Curiosidade: Kent Beck, criador do XP, assina o prefácio do livro.
Casa de ferreiro, espeto de pau
Lendo ontem o blog do Henrik Kniberg, me deparei com o post “Toyota’s journey from Waterfall to Lean software development” (A jornada da Toyota do modelo Cascata para o Desenvolvimento de Software Lean). O título me chamou bastante atenção.
A Toyota introduziu os conceitos de Lean ao mundo, aplicando-os fortemente em sua produção de carros até os dias de hoje. Pouco tempo depois, tais conceitos estavam sendo aplicados por todo o mundo no desenvolvimento de software, e são muito bem aceitos pela comunidade ágil (como Herink Kniberg e Mary Poppendieck).
Ultimamente, a montadora vem cada vez mais sentindo a necessidade de se tornar também uma empresa de TI. Os carros, que poucos anos atrás apenas usavam alguns componentes eletrônicos de terceiros, agora são totalmente computadorizados, e terceirizar o software deixou de ser opção para a Toyota. Ela mesmo partiu para o desenvolvimento.
Henrik então participou de uma viagem à Toyota do Japão, para melhor conhecer as origens do Lean. Mas, para a surpresa dele, a bomba: A Toyota não usa Lean para desenvolver software. Ela usa o modelo Cascata! Foi um choque, e dos grandes!
No artigo, o autor descreve como foi sua experiência nessa visita, a apresentação do processo pelos engenheiros da montadora japonesa, mostrando os clássicos problemas por quais estão passando (todos originados do “jeitão cascata de desenvolver”), e a declaração deles de que estão buscando amadurecer o modelo de desenvolvimento de software, do Cascata para Lean.
A frase que mais me impressionou foi “estamos tentando aprender como aplicar Lean no desenvolvimento de software”. Os criadores do modelo, maiores usuários (na fabricação de carros), ainda não o dominam quando o assunto é desenvolver software.
Pelo menos eles reconhecem que seguem um modelo ultrapassado, e almejam mudar para algo melhor. Já é um grande passo. Mas por essa eu não esperava. Nem o próprio Henrik. Como diria o ditado: casa de ferreiro, espeto de pau!
O Design de Software está morto?
Martin Fowler, famoso por, entre outros, ser o autor de livros como “Refactoring: Improving the Design of Existing Code”, “Patterns of Enterprise Application Architecture” e “UML Distilled”, escreveu um artigo intitulado “Is Design Dead?”, que foi muito bem traduzido para o português pela equipe do InfoQ.
No texto, Fowler fala sobre o mito de que metodologias ágeis de software, especialmente o XP, vêm abolindo a prática de projetar o software.
O autor começa descrevendo os dois principais tipos de design, o planejado e o evolucionário, este último adotado por XP. Sabemos que existem problemas com os dois casos: o planejado sofre com as mudanças (principalmente de requisitos), e o evolucionário com o “codifica-e-corrige”. O Extreme Programming determina uma série de práticas que podem resolver tais problemas. Fowler então descreve o jeito particular de XP tratar o design.
Confira o artigo na íntegra, em português ou inglês. Recomendo fortemente.