Já a algum tempo venho estudando um pouco sobre teoria de sistemas e sobre suas influências no modelo ágil para desenvolvimento de software. Especialmente no que diz respeito aos trabalhos do Jim Highsmith e do seu método adaptativo. Recentemente, durante esse estudo, me deparei com o trabalho de Donella Meadows sobre os 12 pontos de alavancagem sistêmica e vi muita convergência com os princípios e práticas relacionados a abordagem ágil para projetos de software. Pesquisei um pouco e achei aqui um pequeno texto sobre esse assunto adaptado a área de software, mas achei bastante superficial. Resolvi então juntar alguns textos que tinha escrito sobre análise sistêmica em projetos de software e produzir um artigo. Espero que seja proveitoso para todos.  Projetos Ágeis e os 12 Pontos de Alavancagem Sistêmica.pdf (573,53 kb)

 
 
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