No início desse mês foi divulgada a pesquisa anual realizada pela VersionOne em conjunto com a APNL (Agile Project Leadership Network) sobre a situação atual do Desenvolvimento Ágil no mundo. Foram mais de 1700 entrevistados em 71 países. Pelo menos 30% dos entrevistados atuam em empresas com mais de 250 funcionários. A pesquisa não serve para avaliar a penetração dos métodos ágeis no mercado de TI de modo geral, mas dá uma idéia de como as pessoas os têm implementado em suas empresas. Dois números me chamaram a atenção: O Scrum aparece em aproximadamente 70% dos projetos como metodologia utilizada; ou sozinha, ou associada a alguma outra, como XP por exemplo. 82% dos entrevistados afirmaram usar uma ferramenta de issue tracking em seus projetos. Em termos de ferramenta, é o maior percentual, ganhando de ferramentas de testes e de integração contínua. Isso certamente é reflexo da simplificação no uso de ferramentas que os métodos ágeis propiciam. Porquê Scrum? Eu justificaria essa adoção em massa ao Scrum, analisando os seguintes pontos: O Scrum é muito simples de entender e é um ótimo primeiro passo para a entrada no mundo Ágil; Seu público-alvo é formado por quem tem poder de decisão para influenciar seus projetos (gerentes e líderes) É muito bem documentado; Não sugere práticas que gerem resistência inicial; Não interfere diretamente nas práticas de desenvolvimento já utilizadas pela equipe que o adota; E aquilo que eu acho que teve o maior peso: Hoje o Scrum já movimenta um mercado de consultorias, treinamentos, certificações, eventos e papers. E tal mercado vem sendo muito bem administrado pela Scrum Alliance. Apesar das críticas iniciais ao modelo de certificação utilizado pela Scrum Alliance, minha impressão é que é esse modelo que vem trazendo cada vez mais pessoas e empresas para buscarem conhecimento e treinamento sobre o assunto. Hoje as empresas não costumam apostar seu futuro em algo que não seja apoiado por algum tipo de empresa ou instituição atuante. Talvez seja uma boa lição para outras metodologias e para a própria Agile Alliance. Apesar de haver a necessidade legítima de se manter a natureza "open-source" do movimento, é importante que alguma instituição sem fins lucrativos possa servir de referência comercial para o mercado em geral. O DSDM tem um modelo semelhante, mas o seu Consortium bem estruturado não foi capaz de vencer uma maior complexidade conceitual da metodologia e sua atuação mais contundente em alguns países europeus.    É um tema polêmico, eu sei. Mas se deu certo para o Scrum, porque não daria para as outras metodologias?

Posted by: alisson.vale
Posted on: 9/3/2007 at 12:23 AM
Tags: , , ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed
 
 
Recentemente foi publicada uma palestra introdutória sobre Lean e DSDM no InfoQ. A palestra foi dividida em duas partes e contou com Jean Tabaka e Mary Poppendieck. Algumas reflexões que eu tirei das duas palestras: Sobre DSDM Como primeiro contato com o DSDM, sinceramente achei os 9 princípios formulados por esse método - ainda em meados da década de 90 – extremamente claros e concisos, muito focados  em “business purpose” e no processo cooperativo que os métodos ágeis estabelecem. Arriscaria-me até a dizer que é uma das declarações de princípios mais próxima da essência do que é o desenvolvimento ágil. O princípio 4 me chamou a atenção por que reflete exatamente o que eu venho defendendo atualmente: Fitnesse for business purpose is the essential criterion for acceptance deliverables. Ou seja, o critério essencial para aceitação de uma entrega é a sua aderência ao propósito de negócio que o software endereça. O que significa que software não deve ser encarado como um emaranhado de cadastros desconexos que geram muito mais features do que uma solução de negócio para o seu cliente. Em outras palavras, ao invés de se concentrar na produção de features em massa, um time que segue esse princípio se concentrará em soluções de negócio apoiadas pelo software que está sendo desenvolvido. Isso também tem a ver com o jogo de cooperação e colaboração existente em um ambiente ágil. É como se o time se unisse para resolver efetivamente uma demanda de negócio de seu cliente, mesmo que isso envolva apresentar soluções mais abrangentes do que meramente o software produzido. Outro momento interessante da palestra, foi quando Jean falou sobre uma técnica – até então desconhecida pra mim - para ajudar os usuários na priorização de estórias ou requisitos. Trata-se do uso do mnemônico MoSCoW. M para Must Have (Tem que ter) S para Should Have (Deveria ter) C para Could Have (Poderia ter) W para We Would Like to Have (Gostaríamos que tivesse) Muito útil para ajudar clientes/product owners em reuniões de planejamento. Sobre o Lean Por mais que você já tenho lido ou discutido sobre Lean Software Development, ouvir a Mary Poppendieck falar, mesmo em palestras introdutórias, é sempre um aprendizado. O primeiro ponto que destaco é um slide que converge exatamente para o que a Jean descreveu anteriormente em sua palestra de DSDM e que eu fiz questão de ressaltar neste post. O título do slide é “Software plays a supporting Rule”  e fala sobre a característica inútil do software em si mesmo quando desassociado do seu propósito. Software só tem utilidade quando atende o seu propósito. Entender o seu propósito é a chave para construir bons produtos de software. E qual é o propósito de um software? Ao contrário do que muita gente pensa, seu propósito não é meramente “Permitir que o usuário cadastre um...”, é muito diferente disso. Na verdade, quando pensamos em construir software estamos falando em produzir algo que efetivamente “ajude seu cliente a realizar seu trabalho”. Essa percepção é fundamental para entender as premissas e argumentações que levam a composição das práticas em um ambiente de desenvolvimento ágil. Um outro assunto importante tratado pela Mary, diz respeito ao nosso entendimento sobre a aplicação de controles de qualidade em um processo de desenvolvimento de software. Um bom processo de controle de qualidade se concentra em prevenir defeitos e não encontrá-los. Se você procura por defeitos, significa que eles existem. Se eles existem significa que há um problema no seu sistema de produção. Ou seja, seu sistema de produção permitiu que o defeito fosse inserido no produto. Um outro ponto problemático é quando você aceita a existência de subprodutos sem qualidade no seu processo. No Lean, implementar significa entregar. Codificar, testar, documentar, instalar, comunicar, divulgar, publicar, etc, são atividades que definem uma implementação e que não são executadas de forma seqüencial. Tais atividades não geram subprodutos, e dessa forma, não há espera. Um testador não deve esperar o código gerado por um desenvolvedor. Ele se antecipa para trazer o controle de qualidade para dentro do processo (e não para depois dele). Trata-se de um princípio importantíssimo do Lean chamado Build Quality In, onde a qualidade é inserida dentro do processo e não após ele.  Quando há uma área de teste que está esperando por uma funcionalidade, subentende-se que o processo de teste está separado da área de desenvolvimento e que ele recebe como subproduto uma solução de software “quase” pronta. Esse “quase” é incoerente com um processo enxuto. Não existe o “quase” nesse modelo: ou a solução está pronta (o que significa implementada, documentada, testada e outros “adas” exigidos pelo seu negócio) ou não está.  Um membro do time de desenvolvimento do produto (estamos falando de um time multi-funcional aqui), não pode partir para o desenvolvimento de um novo produto se o produto em que o time está trabalhando no momento ainda não foi entregue. Tanto o Lean quanto o DSDM são abordagens conceituais que levam os princípios ágeis para fora da fronteira do projeto propriamente dito. O Lean gera benefícios no nível organizacional, já o DSDM no nível do negócio . São abordagens que se integram com extrema perfeição aos métodos mais focados na parte técnica do seu projeto (XP) e em sua parte gerencial (Scrum). Fica por nossa conta, então, montar esse quebra-cabeça ágil de forma a chegar a uma solução mais ampla que atenda a todos os níveis de nossas organizações.

Posted by: alisson.vale
Posted on: 7/21/2007 at 6:04 PM
Tags: , , ,
Categories: Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (1) | Post RSSRSS comment feed