One of my current initiatives is to write about studies and experiences that I am having lately with knowledge work systems. It started as a blog post, then become several posts and now is a mini-book that I want to evolve as my motivation about the subject grows with time. So here is the link for a draft of the first few pages: Click here to download I'm really proud to announce this in AgileBrazil which is happening in my birth city (Brasilia) at this moment.  I will be glad to receive any feedbacks or suggestion of topics to cover by e-mail. My e-mail address --> contact at alissonvale dot com.

 
 
Recentemente foi publicada a 3ª Edição da Revista Visão Ágil que contou com um artigo meu intitulado "Aperfeiçoamento de Projetos Ágeis - Uma Visão Sistêmica". O artigo foi dividido em duas partes. Nessa primeira parte, eu falo um pouco sobre os aspectos teóricos que circundam o processo de aperfeiçoamento contínuo que se estabelece em um projeto ágil. Na segunda parte, falarei sobre formas e modelos de aperfeiçoamento para uso na prática. Alguns trechos do artigo que acho serem importantes para discussões sobre o tema:     - Sobre o ciclo Especulação, Colaboração e Aprendizado do Jim HighSmith no contexto do auto-aperfeiçoamento.  "No contexto do aperfeiçoamento contínuo, a percepção adequada desse entendimento gira em torno de  saber que para ter um processo que seja melhor hoje do que ontem, é necessário (1) especular sobre algo que precisa ser melhorado  (2) colaborar para que tal melhoria seja alcançada e (3) aprender e incorporar a melhoria conquistada." - No fundo... "...o processo de melhoria contínua gira em torno de, dentre outras coisas, buscar melhores maneiras de (1) aumentar  a quantidade do tempo em que a equipe está envolvida com atividades que geram valor para o cliente por meio de software funcional; e (2) de aumentar a qualidade do tempo em que a equipe está envolvida com atividades que visem garantir as condições de segurança, estabilidade funcional, compreensibilidade e manutenibilidade do software que está sendo desenvolvido."      - O PDCA e seu padrão sistêmico "Em projetos ágeis, é o padrão sistêmico de adaptação e aperfeiçoamento que faz a equipe controlar o processo, evitando que o processo controle a equipe.  Entender o ciclo PDCA e identificar seu funcionamento dentro do projeto é fundamental, pois ele estabelece esse padrão sistêmico cujo resultado é a incorporação de pequenos elementos de controle sobre a complexidade do projeto. É o padrão que garantirá a sustentabilidade do projeto a longo prazo." - O entendimento da Toyota "A Toyota (...) enxerga o rendimento de um sistema (no nosso caso de um projeto) segundo uma rede complexa de influência dos chamados “elementos de avaliação primários” (...) Em seu modelo de melhoria contínua (o kaizen), toda e qualquer ação de resolução de problemas é executada por meio do entendimento de suas influências nos elementos de avaliação primários."  - A relação entre qualidade e aperfeiçoamento contínuo "A qualidade é como um fluido que deve ser colocado para lubrificar cada engrenagem do processo. Uma engrenagem sem o fluido será um potencial ponto gerador de defeitos."   Ao fim do artigo, eu tento descrever um cenário real onde o entendimento sistêmico poderia criar um diferencial na hora de se colocar em prática questões de aperfeiçoamento. Mas aí é melhor ler o artigo para saber exatamente do que esse exemplo trata.  A idéia da segunda parte desse artigo é entrar nos modelos utilizados para auto-aperfeiçoamento atualmente. Descrever práticas de retrospectiva e as práticas utilizadas pela Toyota para fazer essa roda de melhoria contínua girar a favor do projeto.   Espero que seja útil para aqueles que querem implantar um poderoso ciclo de melhoria contínua em seus projetos. 

Posted by: alisson.vale
Posted on: 1/28/2008 at 7:03 PM
Tags: , , ,
Categories: Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
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)

 
 
Como ando recebendo alguns pedidos para envio do material que utilizei na palestra que ministrei no evento JavaBrasil, optei por publicar a apresentação aqui. O título da palestra foi "O Paradigma Ágil". A apresentação foi baseada em uma compilação do livro de mesmo nome que estou escrevendo e na qual discuto temas teóricos que embasam os conceitos utilizados em projetos ágeis. A idéia do livro é descrever a mudança pela qual as atividades de desenvolvimento de software vêm passando desde o lançamento do Manifesto Ágil sob a ótica da teoria de "Mudanças de Paradigmas" e "Revoluções Científicas" proposta por Thomas Kuhn em 1965. A teoria de Kuhn descreve o processo de evolução do conhecimento humano não como fator resultante do acúmulo linear de descobertas ao longo do tempo, mas, como é dito no livro "por meio do surgimento de um novo volume de idéias, percepções, circunstâncias intelectuais, possibilidades e estratégias disponíveis para especialistas de uma determinada ciência ou disciplina em um dado momento". Em outras palavras, o conhecimento humano evolui quando uma nova perspectiva pela qual determinado assunto pode ser explicado é teorizada, aplicada e provada empiricamente. Para explicar como se dá esse mudança no contexto do modelo ágil para desenvolvimento de software, é preciso entender de onde vem cada um dos conceitos sobre a qual o movimento está embasado, como eles se relacionam e o qual o efeito esperado em se juntá-los na direção de formar um novo modelo produtivo mais eficiente. E é nesse ponto que precisamos ser capazes de tecer toda a teia de conceitos que definem a natureza do movimento. Estamos falando de, entre outras coisas, Qualidade Total, Controle Estatístico de Processos, o Modelo Lean, Sistemas adaptativos complexos, Pensamento Sistêmico e princípios de liderança e gerenciamento modernos que juntos estabelecem a essência do paradigma ágil: a criação de sistemas adaptativos controlados pelas próprias pessoas que o compõe. Apresentacao_O_Paradigma_Agil.pdf (485,62 kb)

Posted by: alisson.vale
Posted on: 11/6/2007 at 2:52 PM
Tags: , , , ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (1) | Post RSSRSS comment feed
 
 
Em desenvolvimento ágil, é muito comum as equipes estabelecerem uma espécie de "comprometimento de sangue" com seus clientes em se entregar tudo que foi planejado no início de uma iteração. Pode haver muita boa vontade nisso, mas certamente é uma prática pouco eficiente. Mas porquê é ruim criar um compromisso para entregar o que foi planejado? Quando um compromisso é estabelecido, não cumpri-lo pode resultar em frustração tanto do cliente quando da equipe e de sua liderança. O que ocorre na prática é que não há garantia de que os requisitos planejados no início de uma iteração realmente poderão ser concluídos até o seu final.  Se a liderança do projeto, ou o cliente, estabelecerem uma relação de cobrança para com a equipe no que diz respeito a entrega ao fim de uma iteração dos requisitos planejados e acordados no seu início, fatores indesejáveis poderão atuar negativamente no processo, entre eles: (1) o aumento de trabalho over-time e do stress no dia-a-dia de trabalho; (2) a equipe começa a super-estimar as features com medo de assumir compromissos irreais (3) a  qualidade pode começar a ser sacrificada; (3) relaxamento na execução das práticas e (4) em um atraso iminente, a equipe começa a evitar o acionamento do cliente para obtenção de feedback (pois isso pode significar mais trabalho para ser entregue no mesmo tempo). O que fazer então? Sem metas rígidas, como gerar ritmo e obter alguma previsibilidade no projeto? O segredo é não tentar impor controle sobre o processo, mas estudá-lo e observá-lo com o intuito de se ganhar a capacidade de aperfeiçoá-lo sistemicamente. O objetivo é conquistar (e não controlar) o ritmo e a previsibilidade desejada. Se as metas de implementações para a iteração continuamente não são alcançadas, pode ser que: As metas estão sendo mal-definidas (consciente ou inconscientemente). Normalmente devido ao desconhecimento da capacidade real de produção da equipe. Às vezes tenta-se impor metas mais arrojadas para tentar puxar o ritmo da equipe, mas o resultado acaba sendo pior; Os requisitos foram insuficientemente explorados durante a reunião de planejamento. Apesar de não ser uma boa prática detalhar em excesso o que será desenvolvido, é importante conhecer o suficiente sobre o que será desenvolvido, de modo a diminuir a margem de erro nas estimativas. Isso pode ocorrer quando as reuniões de planejamento são rápidas de mais ou muito superficiais; Eventos não planejados (veja "variações especiais" mais a frente no texto) ocorreram durante a iteração diminuindo a capacidade de produção da equipe. Em todos os 3 casos, a culpa não é da equipe. Não adiantará, portanto, pressioná-la ou influenciá-la para produzir mais. Todo o projeto é um sistema. Sistemas que produzem abaixo do esperado, o fazem devido a causas sistêmicas, não pela existência de um ou mais "culpados".  Todo o sistema tem um rendimento e esse rendimento, segundo Deming, sofrerá de variações causadas por causas comuns ou por causas especiais. Especialmente quando falamos em projetos de software, há variações inerentes ao sistema e há variações especiais  que tornam seu rendimento imprevisível, mas controlável. O ato de medir esse rendimento continuamente gera o controle estatístico necessário para nos dar a condição de prever resultados com muito mais acuracidade do que os planejamentos adivinhatórios e impositivos que estamos acostumados a  ver. Assim, as expectativas devem ser trabalhadas com base em medições e não com base em compromissos irreais.    Durante o estudo e a observação do sistema da qual faz parte o projeto, será possível detectar variações especiais, removê-las e, assim, otimizar seu rendimento. Quando todas as variações especiais forem removidas, o sistema poderá ser otimizado como um todo e, aí sim, haverá uma melhoria substancial na sua capacidade de avançar com mais velocidade, mantendo o alto nível de qualidade desejado.  Um projeto observado e aperfeiçoado com uma visão sistêmica pode oferecer muito mais controle e previsibilidade do que um projeto gerenciado com metas impostas de cima para baixo. 

Posted by: alisson.vale
Posted on: 10/26/2007 at 1:42 AM
Tags: , , , , ,
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed