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.

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.

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.

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!

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.

Algo familiar? Ou será que o chefe do Dilbert é o único que acha que o ponto determinante no sucesso do desenvolvimento é a metodologia ou framework utilizado?

Infelizmente não. No mundo real ainda há muitas pessoas com tal mentalidade e, pior, muitas também com poder de decisão. No final, quando tudo vai por água abaixo, a culpa é da pobre metodologia…

Scrum mal aplicado

Não é culpa do Scrum. Desenvolvimento ágil não trata apenas de boas práticas de engenharia. É também sobre o reconhecimento da importância das pessoas no processo de desenvolvimento, formando equipes multidisciplinares, com comunicação em larga escala, constantemente refletindo e melhorando, entregando valor, e mudando planos para melhor aproveitar as oportunidades.
E Scrum inclui todos esses pontos. Diz, por exemplo, para colocar a equipe em um ambiente de trabalho compartilhado. Diz que no final de cada Sprint um produto de valor deve estar pronto para ser entregue, e diz também que a equipe deve se auto-organizar, descobrir impedimentos e removê-los.
Scrum também tem algumas poucas coisas mecânicas a respeito de Sprints mensais e Scrum diário. Coisas triviais comparadas com todo o resto. Mas, infelizmente, é essa a única parte que muitas pessoas adotam. Ciclos rápidos, mas nada daquelas boas práticas que fazem o ciclo rápido ser sustentável.

Você está fazendo errado

Neste momento, há muitas equipes falhando com o desenvolvimento ágil. Esses times estão trabalhando em ciclos pequenos. A crescente freqüência de planejamento deu-lhes um maior controle sobre seu trabalho e eles estão descobrindo e consertando alguns problemas. Eles se sentem bem, e eles realmente parecem mais bem sucedidos do que eram antes.

Mas eles não estão trabalhando em ambientes de trabalho compartilhados, nem enfatizando a necessidade de comunicação de larga escala. Eles não mantêm os clientes por perto do local de trabalho. Eles nem mesmo terminam todas as suas Estórias até o final de cada Sprint, e certamente não utilizam boas práticas de engenharia.

Esses times se dizem ágeis, mas eles estão apenas praticando um tipo de “planejamento freqüente”. Ciclos curtos e capacidade de re-planejar são apenas os benefícios que o desenvolvimento ágil lhe dá. É a recompensa, não o método. Essas equipes pseudo-ágeis estão comendo a sobremesa toda noite e pulando o prato principal, os vegetais. Deixando de lado todo o resto (o ‘resto’ realmente ágil), elas estão bem encaminhadas para “dentes cheios de cáries”, “obesidade” e, conseqüentemente, estão fadados a falhar. No começo se sentem bem, mas isso não dura por muito tempo.

Resumindo, pare e pense: você está querendo pular o arroz-com-feijão, os brócolis e a salada, para ir direto a sobremesa? Se sim, você está, como muitos, deturpando os valores defendidos no manifesto ágil, e está no caminho errado.

Metodologias ágeis são tão boas quanto as pessoas que as usam!

O mito da documentação

Um dos grandes mitos do desenvolvimento ágil é que equipes ágeis não documentam seu trabalho. Realmente, equipes ágeis preferem conversas cara-a-cara do que comunicação através de documentos, e preferem escrever documentação para manutenção, no final do projeto, do que no começo (significando menos retrabalho e garantido conteúdo atualizado).

Junto com as acusações de más práticas de documentação, há um outro mito: “Documentação é uma coisa boa”.

Pessoas pensam “estou tendo problemas para entender isto!” e, depois de quebrar a cabeça, amaldiçoam o desenvolvedor pela sua falta de visão de documentação.

Muitos programadores escrevem linhas e mais linhas de comentários, antes de realmente começar a implementar. Mas isso não significa que a implementação que vem a seguir é de qualidade! O bom, desta forma, não vem automaticamente (e necessariamente) da prévia documentação. Isto é um mito!

Então o que é realmente bom? O que é que estamos procurando quando vamos atrás da documentação? A resposta é: Respostas.

Se você mudar sua forma de pensar, procurando as respostas, e não apenas documentação em si, você irá mudar inteiramente sua perspectiva. Documentação então é um meio para um fim, e não um fim em si própria.

A realidade é: queremos respostas, elas sim nos ajudam. E o quanto mais rápido as temos, melhor é.

O melhor caso é quando, as vezes o próprio código fonte, bem escrito e com partes bem nomeadas, não precisa nem de comentários, é intuitivamente óbvio. XP prega isso, e realmente não é uma coisa fácil de atingir, mas é o que se deve tentar.

O segundo melhor caso é quando é possível perguntar a alguém e obter logo a resposta. É o caso de equipes ágeis, onde se recomenda ter equipes com seus membros distribuídos através de várias funções. Os ganhos de produtividade por causa da comunicação são incríveis.

Ainda, continua sendo bom ser possível ir ao Google e procurar pela respostas. Algumas vezes vou ao Google e digito minha mensagem de erro. Descubro que 500 pessoas tiveram o mesmo erro, e proveram soluções. Fantástico.

Por último da lista de como/onde obter resposta, está a atividade de ler documentação atrás da mesma. è claro que algumas vezes a documentação é divinamente organizada, maravilhosamente escrita, e prazerosa de ler. Sim. Mas muitas vezes não. E quanto mais documentação você tiver que ler para obter sua resposta, pior. Ter muita documentação não é bom. A única coisa boa sobre ter toneladas de documentação é o jeito como isso soa.

Então, da próxima vez que você ouvir alguém reclamando sobre a falta de comentários ou de documentação, pare-o por um momento. Do quê realmente ele está reclamando? O código não está claro? A biblioteca tem uma organização pobre? Talvez corrigir isso primeiro fosse a melhor solução. Ou, talvez, nada está errado, e esta pessoa está sucumbindo ao mito da documentação.