Entrevista Mike Cohn: Agile scaling and scope

Lendo o Blog do Alexandre Magno vi este vídeo do Mike Cohn, muito bom altamente recomendavel.

O ScrumMaster e seu papel

O Guilherme Chapiewski escreveu um post esta semana bem polêmico e a discussão esta correndo solta no Blog. O ponto é, até onde vai o papel do ScrumMaster quando este pode ajudar o time resolvendo, quando possível, impedimentos técnicos ou discutindo uma dada solução técnica.

Nas últimas semanas, venho conversando muito com o Guilherme e com a Patricia Fontes (nossa Product Owner nos projetos de vídeos da Globo.com) sobre estas questões de relacionamento entre Time, ScrumMaster e PO, até onde vai o papel de cada um. Nas nossas conversas geralmente temos pontos de vistas diferentes e as vezes opostos, mas o resultado destas conversas tem sido muito enriquecedor, pelo menos para mim. No final de cada conversa sinto que estamos mais unidos e concientes de onde queremos chegar e sempre que discutimos tentamos manter como nossa referência o que é a melhor solução/decisão/atitude para os produtos que estamos construindo.

O Phillip Calçado também fez um post onde coloca o seu ponto de vista sobre ter um SM que também é um líder técnico. Neste post dele gosto muito da frase:

Quem assume que isso é uma verdade absoluta está buscando respostas fáceis ao invés de tentar resolver o problema. Isso não é diferente em nada do cidadão que usa todos os templates, artefatos e papéis do RUP no seu projeto, ou daquele que acredita que um selo como CMMI ou MPS.BR traz qualidade.

E replicando meu comentário no blog do Phillip, para mim não existem verdades absolutas, e sim evolução e aprendizado contínuo, aprendizado quer dizer que erramos e acertamos em ciclos infinitos, e se estivermos no caminho certo, mais acertamos do que erramos, e estes erros que cometemos não deveriam se repetir.

Agile na SD West 2008

Como alguns de vcs sabem estou nos Estados Unidos nesta semana, tivemos algumas reuniões em San Francisco com a ADOBE, onde vimos algumas das novidades que vão acontecer durante 2008 e inicio de 2009 nas plataformas da empresa.

Em seguida, vim para Santa Clara para participar da SD West 2008, um evento com diversos tracks legais e super sintonizados com o momento de transição que estamos passando na Globo.com, particularmente estou assistindo a maioria das apresentações do track chamado People, Process and Methods, onde são discutidas práticas ágeis de gerenciamento do desenvolvimento do Software, como o SCRUM, Crystal Clear e XP entre outros assuntos. Hoje assisti várias palestras e aproveitei para tirar algumas dúvidas com uns dos maiores nomes do mundo Agile, como Mike Cohn, Alistair Cockburn, Paul Hodgetts entre outros.

Na primeira palestra que participei foi a “Agile Transitions“, que na verdade foi um round de discussão de como realizar a mudança para uma metodologia ágil, independente de qual vc estaria interessado. Foi muito bom ver que grande parte das perguntas feitas eu consegui responder corretamente, o que mostra que estamos avançando no quesito de conhecimento sobre práticas ágeis. Uma das perguntas que fiz foi a respeito de qualidade versus número de features, justamente perguntando se na situação onde o time vê a necessidade de melhorar a qualidade do software criando uma estória de refactoring , por exemplo, é correto dropar uma feature e escolher a qualidade?

A resposta foi em linha com o que pensava, todos foram categóricos com o fato de que com qualidade não se discute e que isso é uma decisão do Time juntamente com o PO, mas que o PO precisa entender o que esta em jogo e o que se ganha ao realizarmos um refactoring ou automatizar um teste que na maior parte das vezes é muito sutil, porque só se percebe o Technical Dept quando ele já esta muito alto e coloca o projeto todo em risco, é função do Time mostrar este valor para o PO.

Na segunda palestra Prioritizing Requirements, com Mike Cohn, foram apresentadas técnicas de priorização do Product Backlog, em resumo é possível dividir estas técnicas em dois grupos: Financeiras e as Não-Financeiras. Na parte de técnicas financeiras nenhuma grande novidade, ele falou bem superficialmente sobre NPV, FV, IRR, etc. Mas na parte de técnicas não-financeiras achei interessante o Método de Kano e tb o reforço no método do Beneficio Relativo. Para saber mais sobre este assunto leia o livro do Mike “Agile estimating and planning“.

A terceira palestra foi sobre o Crystal Clear, ministrada pelo Alistair Cockburn (Lê-se Co-burn), onde ele apresentou um overview sobre a metodologia Crystal, que em resumo tem os seguintes propriedades:

• Frequent Delivery
• Reflective Improvement
• Close Communications

Estes principios todos são muito comuns a diversas metodologias ágeis, mas este último tópico (Close Communications) foi muito interessante, onde ele discutiu e mostrou alguns papers como este aqui da Universidade de Michigan chamado Distance Matters, onde é provado que quanto mais proximos estão os membros de um time melhor é o rendimento e a qualidade e por consequencia o retorno sobre o investimento.

A última apresentaçao que fui, ministrada por um consultor da Net Objectives, não teve grandes novidades, mas foi muito interessante para ajudar a verificar como podemos estruturar o conteúdo sobre SCRUM para os nossos treinamentos internos para os Team Members.

Cone da Incerteza e SCRUM

Nos últimos meses eu tinha como foco implementar SCRUM na minha equipe, tudo começou com o Phillip Calçado me explicando o conceito de SCRUM, seguido de um curso com o Bloris Gloger que ele e alguns da equipe fizeram, e depois entramos em um caminho sem volta e nos focamos em implementar o SCRUM da melhor forma possível no nosso time. Acho que posso dizer que estamos muito bem neste momento, claro que ainda faltam detalhes mas o time esta andando e esta entregando software de qualidade a cada ciclo de desenvolvimento.

A próxima meta é escalar o SCRUM para toda a empresa, enquanto estava lendo sobre o assunto acabei me desviando e cai em alguns artigos muito interessantes que discutiam um tema que afeta todo e qualquer projeto de desenvolvimento de software: como estimar com precisão o tempo total para se entregar um software em produção?

Acabei caindo na teoria do Cone da Incerteza, que explica o fenômeno onde nós da indístria de software quando iniciamos um novo projeto não fazemos a menor idéia de quando vamos terminá-lo. Quanto mais o tempo passa e mais perto do fim melhor e mais preciso são as nossas estimativas, ou seja, isso culmina na conclusão de que você só tem 100% de certeza de que terminará o projeto apenas um dia antes de efetivamente terminá-lo.

Esta figura é facilmente associada ao desenvolvimento de um software, ou seja, se começa um projeto sem ter a menor idéia do tamanho dele ai vai se detalhando, escreve-se montanhas de papel com requisitos, desenha-se milhões de telas no Photoshop para fechar o design do projeto, ai finalmente depois de alguns meses é que se começa a escrever software efetivamente. Nestes casos existe uma luta constante para afunilar o cone o mais rápido possível. O grande erro das empresas é fazer um “commitment” com um projeto quando ele esta nas suas etapas iniciais, ao fazer isso elas estão aceitando uma margem de erro de 2x ou 4x nas estimativas, e é neste momento que o projeto começa a ruir.

O que é interessante em metodologias ágeis, como o SCRUM por exemplo, é que podemos observar este fenômeno invertido, explicando melhor, se vc perguntar a um desenvolvedor que já esta envolvido em um projeto o que ele consegue entregar nas próximas duas semanas a estimativa com certeza será bem precisa, mas se perguntarmos o que ele consegue entregar daqui a 6 meses, não fará a menor idéia e vai chutar uma estimativa qualquer pois não há como ter certeza do que irá acontecer. A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão mudar, os requisitos, o design, as funcionalidades e o grande trunfo dos métodos ágeis é de entregar software funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanças.

Então em um ambiente ágil temos sempre mais certeza sobre as estórias que estão priorizadas para o próximo sprint ou estamos trabalhando neste momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme o Product Backlog vai sendo entregue, mas sempre com uma visão muito clara do curto prazo e menos clara para o que esta no fim do Product Backlog. Lembrando que as estórias que estão sendo desenvolvidas no Sprint são as de maior ROI para o projeto.

Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza SCRUM teria este formato:

Garantindo datas de entrega em projetos SCRUM

Uma situação muito comum no dia a dia de diversas equipes de desenvolvimento de software e como não deveria deixar de ser também acontece aqui na Globo.com, é quando as equipes de marketing ou produto precisam de uma data garantida para o lançamento de um certo projeto, no entanto, estas mesmas equipes se sentem inseguras quando o ScrumMaster esclarece que o time é que vai estimar o que cabe em cada Sprint  e que cada time possui uma velocidade relativa contada em pontos de complexidade. Nessa hora elas entram em um estado de transe e voltam a pedir o que sempre pediram e a trabalhar da maneira como sempre trabalharam, Ken Schwaber chama este reflexo de “Muscle Memory.

Explicando melhor, quando as pessoas estão sobre pressão em um momento em que estão tentando alguma coisa nova (como por exemplo tocar um projeto usando SCRUM), na primeira dúvida que surge elas tendem a querer voltar a fazer as coisas como sempre fizeram, para muitas pessoas é realmente difícil aceitar que o Time é que define a velocidade de entregas, e neste momento elas requisitam alguma coisa que lhes dê uma segurança de que aquele software será entregue com certeza na data definida, é nessas horas que ouvimos o famigerado pedido “Poxa, não dá pra vcs fazerem um Project bonitinho com as datas e tal”, como se um project fosse o certificado de garantia de que o Time vai entregar alguma coisa em alguma data. Eu cada vez mais acredito que cronogramas não funcionam e não tem como garantir nada.

Em uma situação dessas, em que um produto precisa de um determinado set de funcionalidades e onde está se pedindo uma data formal de entrega, uma solução possível seria adicionar uma margem de segurança (ou buffer) nas estimativas para garantir que as estórias do projeto estarão prontas com certeza e, em seguida, verificar quantos Sprints são necessários para realizar esta entrega.

Este buffer é feito usando as estórias e suas estimativas de complexidade, durante o planejamento de um Sprint o Time evolui sua avaliação a respeito da complexidade de implementação das estórias com base no maior esclarecimento que vai acontecendo nas reuniões do Sprint.

Sendo assim podemos presumir que em um primeiro momento, quanto estamos lendo uma estória pela primeira vez, teremos um grau de precisão na avaliação da complexidade relativamente baixo, por exemplo 50%. Conforme as dúvidas e a arquitetura do sistema a ser utilizada são esclarecidos esta precisão aumenta até que no Sprint Planning 1  deve-se ter, idealmente, uma precisão sobre a estimativa de complexidade em torno de 90%. São estes dois dados que vamos utilizar a estimativa com precisão 50% e a estimativa com precisão 90% para calcular o buffer.

Vamos imaginar o seguinte Sprint Backlog com 4 estórias, e que estas foram estimadas pelo time nas reuniões de levantamento de estimativas(50% de precisão) e posteriormente no Sprint Planning 1(90% de precisão).

Com estes dados em mãos agora podemos calcular o tamanho do projeto adicionando o buffer:

 Complexidade do Projeto = Est. 50% + [(Delta)/2]

onde Delta/2 é o buffer.

Usando os números da tabela acima temos que a complexidade do projeto = 28 +(40/2) = 48 e o tamanho do buffer é de 20 pontos de complexidade, ou seja, quanto maior é a diferença entre a primeira estimativa e a estimativa mais precisa (90%), maior será o buffer.

OK, agora que calculamos o buffer podemos calcular quantos Sprints serão necessários para termos certeza de que o produto será entregue contendo estas 4 estórias. Supondo que a velocidade do time seja de 10 pontos de complexidade por Sprint, então vamos precisar de pelo menos 5 Sprints (48/10) para entregar estas 4 estórias com uma boa margem de segurança.

Como os Sprints possuem duração fixa, na Globo.com por exemplo giram em torno de 15 dias, então podemos garantir que em pelo menos 75 dias (15 dias x 5 Sprints) o produto estará entregue com todas as funcionalidades.