Alisson Vale

Hoje vive-se o dilema de encontrar o limite adequado entre o craft e o lean. Quanto do processo de software deve ser "criação" e quanto deve ser "produção". O quanto ele deve ter de "artesanal" ou de "industrial". Hoje há dois extremos em agile. E é difícil saber onde se posicionar entre eles.

Talvez seja isso que torne o paradigma tão forte conceitualmente. Software precisa de qualidade e excelência (craft), mas também precisa de gestão, números e tendências (lean)... quanto é necessário de cada um para compor um bom projeto de software? Como nivelá-los de acordo com a situação e com o cenário em que se atua?

Por outro lado, há um outro fenômeno interessante. Muitos querem usar Agile, e não é fácil em muitos cenários. Enquanto uma parte das pessoas tenta proteger o novo paradigma de conceitos atrelados ao velho, outros tentam adaptá-lo a esses conceitos para que possam entrar no circuito ou expandir sua influência na indústria como um todo. Algumas vezes para dar respostas a nichos de mercado que não querem assumir o risco ou não tem certeza sobre os efeitos gerados por uma mudança tão brusca. É por isso que quando, por exemplo, a palavra CMM se junta à palavra Ágil em algum momento, a internet recebe uma enxurrada de e-mails, posts, etc com opiniões contra e a favor. O interessante que tanto quem é contra quanto quem é a favor clama por defender ou se beneficiar dos mesmos princípios. Mais uma vez, o que é certo? o que é errado? Talvez não se ter certeza sobre o que é certo e o que é errado seja a nossa principal qualidade como comunidade.

O que se vê nesse momento é que o fato de Agile ter sido criado em cima de valores e princípios, e o fato de ele ser representado principalmente por comunidades virtuais, o torna mais poderoso do que se pensa. Hoje não há ninguém que controle Agile. Nenhum dos autores do manifesto, ou mesmo um pequeno grupo deles, pode, isoladamente, controlá-lo. É um movimento de vida própria. E ele vem conseguindo oferecer as peças que precisamos para o quebra-cabeças que é desenvolver software. E o que o mantém assim é o equilíbrio gerado pela existência de diferentes abordagens e soluções para um número ilimitado de realidades e cenários de negócio que temos por aí.

O Movimento Ágil é hoje um Sistema Adaptativo Complexo, como descrito pelo Highsmith. Ele começa a atuar sob regras que o fazem assumir "Comportamentos Complexos", onde "Complex Behaviour = Simple Rules + Rich Relationships". Em outras palavras, a comunidade hoje funciona assumindo os mesmos comportamentos esperados em projetos Ágeis de software: emergência, adaptabilidade e colaboração, tudo isso sob a proteção de quatro regras simples.

Em resumo, o que faz Agile hoje ser tão poderoso são as polêmicas, as discordâncias. Elas mantém o paradigma atrelado ao bom senso. Nenhum dos lados deixa o modelo estável. Há dois extremos, e é a experiência e o estudo de cada um de nós que nos ajudará a localizar o ponto ideal entre eles. Nesse momento, a única certeza que se tem é que nenhum dos dois extremos é o melhor lugar para se posicionar.

Um dos aspectos mais interessantes dos métodos ágeis é sua estruturação conceitual.
Oficialmente são quatro declarações de valor que nos inspiram, um pequeno conjunto de princípios que nos guiam e uma grande quantidade de métodos que nos ajudam a estabelecer "como" as coisas devem ser feitas. Cada método estabelece seu próprio conjunto de pressupostos e práticas. E é comum equipes de projeto adotarem práticas de diferentes métodos enquanto os adaptam às suas realidades.

Depois de quase cinco anos trabalhando com desenvolvimento ágil, nosso dia-a-dia de trabalho nos levou além das fronteiras estabelecidas pelos diversos métodos. Algumas práticas se consolidaram e hoje estão imersas no nosso cotidiano de tal maneira que sem elas, tudo pára. Outras foram vencidas pelo nosso processo de adaptação e acabaram em desuso.

Em janeiro desse ano, nosso processo adaptativo cruzou o caminho de uma nova abordagem hoje especialmente defendida e divulgada por David Anderson e Corey Ladas. Essa abordagem usa um kanban como elemento central para fazer fluir todo o trabalho necessário para tirar uma demanda da lista de desejos do cliente, transformando-o em software funcional. O foco do modelo é a entrega de software just-in-time. Isso significa essencialmente entregar o software certo na hora certa e fazer isso repetidamente com o objetivo de diminuir ao máximo o tempo entre a demanda e a entrega, por meio da detecção e eliminação das perdas que ocorrem nesse intervalo. Na prática, essa abordagem abre todas as portas para uma boa implementação Lean e pode ser uma boa opção em determinados tipos de projetos.

O kanban é o instrumento utilizado para amortecer as demandas e permitir o estabelecimento do "fluxo" e do "pull system" tão necessários em ambientes que querem se beneficiar do modelo de produção enxuta (Lean). Até aqui não há nada novo. Projetos ágeis de modo geral já se beneficiam do uso de kanbans já a bastante tempo. No entanto, esse modelo extrapola o tradicional quadro de 3 colunas (Pendente, Em andamento e concluído) para um sistema que sinaliza e restringe o trabalho de tal maneira que qualquer "hands-off" é amortecido pelo kanban e "puxado" (ao invés de alocado). O objetivo é estabelecer o fluxo unitário, um fluxo de valor que começa na demanda e finaliza com a entrega efetiva para o cliente.  Assim, o desenvolvedor puxa do backlog de demandas, quem inspeciona puxa do backlog de inspeção, quem faz deploy puxa do quadro de itens resolvidos e por aí vai. O trabalho é primeiro sinalizado e só depois é puxado por quem irá executá-lo, e este só puxa depois que sinaliza o trabalho que acabou de fazer de forma que a próxima etapa do processo possa puxá-lo novamente até que ela chegue ao cliente. Ou seja, quem termina sempre sinaliza o item n e então puxa o n+1.

Nesse modelo, não há iterações. Há um fluxo contínuo de entregas e a previsibilidade dessas entregas se dá com base no SLA (Service Level Agreement) conquistado pela equipe. Para chegar nesse ponto, a equipe precisa medir e controlar seu Lead Time e esse será o principal parâmetro de controle da sua produção. Como não há iterações, o backlog pode ser alterado o tempo todo, cartões podem ser removidos, inseridos ou reordenados a qualquer momento.

Já o esquema de priorização se adapta bem a um cenário onde há competição pelo recurso, ou seja, um determinado número de clientes compete pelos mesmos recursos do projeto. Nesse cenário, a tarefa de priorizar não pode ser dos clientes, mas de um elemento intermediador capaz de utilizar diferentes critérios para o estabelecimento da ordem pela qual as entregas devem sair. A priorização será o resultado de uma análise que leva em conta uma série de aspectos circunstanciais que envolvem questões técnicas, comerciais e de negócio, mas o aspecto mais relevante é o chamado Cost of Delay, ou o custo decorrente de se fazer ou não uma entrega hoje, amanhã ou na próxima segunda-feira.
 
No que diz respeito a estimativas, a orientação é não estimar. As demandas são categorizadas para composição do SLA, não estimadas. E essa categorização é feita com base no feeling e na experiência da equipe. As expectativas dos clientes devem ser adaptadas à capacidade de produção da equipe.

Hoje tenho visto a utilização dos termos Kanban Development ou Sustaining Enginnering para identificar esse modelo. Mas independentemente do modo como ele é chamado, aqui na empresa ele tem sido uma grande fonte de inspiração para avançarmos na organização do nosso modelo de trabalho.

No meu entendimento, essa abordagem não deve substituir os métodos ágeis mais utilizados atualmente, mas é uma boa alternativa para projetos que não conseguem atender a alguns de seus pressupostos. Ele se adaptará bem a projetos que:

1) Já mantém o(s) seu(s) produtos em uso em ambiente de produção;
2) Demandam re-organização constante do backlog;
3) Há forte competição pelo recurso (o tempo investido nas features atende a diferentes interessados)
4) É viável a utilização de SLA (Service Level Agreement) como instrumento de negociação, planejamento e prestação de contas junto aos clientes;

A seguir eu descrevo um pouco da nossa implementação dessa abordagem.

O elemento centralizador desse modelo é o quadro kanban de acompanhamento do trabalho. Ele identifica a parte mais relevante do backlog e também o chamado Work in Process. Nosso quadro Kanban foi evoluindo na parede até chegar ao modelo apresentado na Figura 1.

Figura 1: Modelo kanban utilizado na parede.

O kanban era composto por cartões semelhantes ao apresentado na Figura 2. Mandamos confeccionar esses cartões de forma a apresentarem informações relevantes que não só nos dessem um mapa visual do trabalho que precisava ou que estava sendo executado, mas também que permitisse o registro de dados que tínhamos a intenção de monitorar (como o tempo que o cartão passava em cada estágio do nosso fluxo de trabalho).


Figura 2: Modelo de cartão utilizado no kanban

Criamos três categorias de cartões utilizando como critério o benefício que aquele tipo de trabalho gerava para a equipe:

• Cartões Verdes (Investimento): Agregam valor ao produto (novas features)
• Cartões Vermelhos (Custo): Implementação necessária para manter o produto ou o cliente em pleno funcionamento operacional (defeitos, extração de dados, análises de cenários complexos, infra-estrutura, etc). Normalmente cartões vermelhos representam o que eu costumo chamar de aqueles-originados-devido-a-débito-técnico-aparente ou coisas-que-nos-distraem-de-agregar-valor-ao-produto, por isso essa cor gritante.
• Cartões Amarelos (Improvement): Agregam valor ao modelo de execução ou ao ambiente de trabalho (Auto-improvement);

Cada cartão recebe uma sinalização que indica a sua expectativa de tamanho, o que é conhecido como T-Shirt Sizing. No nosso caso cada cor representa um dos 3 tamanhos possíveis (Small, Medium ou Large) ou simplesmente P,M e G.

Nosso objetivo é então medir quanto tempo cada tipo de cartão leva para percorrer todo o fluxo de trabalho, saindo do backlog até o status de entrega. Essa métrica é bastante conhecida no modelo Lean como "Lead Time" e é um dos principais elementos para monitoramento da eficiência do sistema de trabalho, além de ser útil para a obtenção de estimativas de datas para entrega junto aos clientes.

Na nossa implementação, o backlog do kanban é dividido em duas áreas na parte esquerda inferior do quadro. A primeira contém os 7 cartões de mais alta prioridade e contém aquelas entregas que atingiram o estágio que chamamos de LRM (Last Responsible Moment). Ou seja, cartões nesse estado requerem a atenção imediata da equipe, não por uma questão de urgência, mas porque ao compor o momento atual com o Lead Time da equipe, percebe-se que estamos no momento certo para implementá-los. A segunda área contém os cartões que "provavelmente" serão trabalhados nos próximos trinta dias. Os outros cartões do backlog ficam guardados para não poluir o quadro.

Quando um desenvolvedor fica disponível ele simplesmente "puxa" o cartão que está no topo da área LRM (cartão circulado em vermelho no topo dessa área) para a área associada ao seu nome. A implementação envolve análise, documentação, codificação e testes e está associada a prática de "Done Definition". Ao finalizar essa fase de implementação, o cartão é colocado na área de inspeção para que um outro membro da equipe possa "puxar" o cartão para realização da inspeção.

Após essa inspeção, o cartão deixa o kanban da equipe de desenvolvimento e segue para um novo kanban, dessa vez da equipe de atendimento ao cliente. Essa equipe puxa novamente o cartão para fazer o processo de deploy da demanda, explicando, notificando, instalando, tirando dúvidas ou executando qualquer operação que precise ser realizada no ambiente do cliente. Veja Figura 3:

Figura 3: Kanban na área de atendimento

Alguns pontos que achamos interessantes nessa abordagem:

- O foco é completamente desviado para o controle e a otimização da eficiência do sistema de trabalho por meio do monitoramento do seu rendimento (Throughput);
- Métricas simples (como Lead Time) mantém a equipe focada no objetivo global (rendimento do sistema);
- Controle do WIP (Work In Process). O Kanban limita o trabalho em execução, impedindo a sobrecarga do sistema e forçando-o a trabalhar com sua capacidade real; Um novo cartão só entra em WIP se um outro sair primeiro;
- A demanda deve se ajustar à capacidade de produção do sistema (e não o contrário). Se a demanda não pode se adaptar ao fluxo, deve haver investimento no sistema para que ele aumente o seu rendimento.
- Exposição imediata dos problemas: Os problemas são revelados e resolvidos no momento em que eles surgem. Isso acontece porque o modelo depende do fluxo. Se um problema interrompe o fluxo, o trabalho de todos é afetado, o que faz com que ele seja resolvido mais rapidamente;
- O esforço para estimar é progressivamente reduzido até um nível mínimo;
- Estimula o uso de práticas ágeis de engenharia e acompanhamento (controle visual, daily meetings, pair programming, tdd, refactor, CI, etc) na medida em que a qualidade não pode mais depender de inspeções que só iriam acontecer muito tempo depois do desenvolvimento;
- Todo o trabalho da equipe é convertido e mapeado em itens entregáveis que tem valor real ou para o nosso produto (cartões verdes) ou para nossos clientes (cartões vermelhos);
- Todo o trabalho da equipe está fisicamente visível, nada fica oculto;
- Todos os entregáveis passam um-a-um pelos mesmos estágios permitindo a implementação do fluxo unitário adotado no modelo Lean;
- Algumas ferramentas Lean são mais facilmente aplicáveis. Veja Figura 4.

 Para saber mais sobre Kanban Development:

Lista de discussão no Yahoo Groups
Agile Management - David Anderson
Corey Ladas

Pressupostos são hipóteses que precisamos admitir antecipamente para que possamos aceitar ou compreender as teorias que delas decorrem. Eles são o ponto de partida para justificar as abordagens adotadas. Para optar entre uma ou outra linha de pensamento é necessário antes de mais nada estabelecer concordância com eles.

Quando comparamos o modelo Ágil com o Waterfall eu acredito em quatro pressupostos básicos sobre a qual precisamos nos posicionar antes de partir para uma ou outra abordagem.

São eles:

Afinal, software deve ser produzido de modo fabril ou criado colaborativamente? Para ter qualidade ele deverá seguir rigidamente especificações pré-acordadas ou ser capaz de satisfazer os anseios e necessidades de usuários e clientes? Como devemos organizar as pessoas? Por meio de um grupo de trabalho com tarefas pré-definidas em um processo controlado? ou criando times de projeto com liberdade para definir e otimizar o seu próprio modelo de trabalho?

Talvez a pior escolha, nesse caso, seja não fazer uma escolha. O modelo teórico que vai embasar as suas práticas de trabalho será decorrente dessa escolha. Há uma conexão direta entre esses pressupostos, os princípios que lhe endereçam, e aquilo que precisamos praticar no dia-a-dia para implantá-los. Quando não há rigidez na escolha do conjunto adequado de pressupostos, o modelo teórico adotado se enfraquece, as práticas anulam-se umas às outras e os riscos de insucesso aumentam.

Recentemente chegou às bancas a edição de número 09 da revista MundoDotNet. Essa edição conta com um artigo onde descrevo uma técnica interessante para administração de cenários de testes implementada com sucesso pelo meu colega Paulo Cesar Fernandes aqui na empresa. 

A técnica consiste em interceptar a execução de métodos de forma a armazenar objetos construídos durante a execução da aplicação em um banco de dados orientado a objetos. Assim, esses objetos podem ser carregados na memória no momento em que são necessários para o SetUp de testes unitários.

Na verdade, o artigo foi um pouco além de descrever a técnica. Grande parte do texto é dedicada a explicar as raízes e as várias formas em que técnicas de teste podem ser utilizadas para aumentar a qualidade do software no contexto de um projeto ágil.

Alguns tópicos e trechos do artigo

Uma nova visão para as atividades de teste de software:  A relação das atividades de teste com qualidade. Algumas das idéias de Deming que podem ser utilizadas em desenvolvimento de software. A relação de Deming com o estilo de administração japonês que levou ao Movimento Ágil e as técnicas que este movimento trouxe de forma a permitir a redução de inpeções no software.

Testes como oportunidades para aumentar a qualidade: Em projetos ágeis, testar significa criar oportunidades para que o produto absorva elementos de qualidade de forma permanente. "Um teste automatizado injeta qualidade dentro do software".

Quando testes automatizados podem aumentar a qualidade do processo:  Testes de aceitação automatizados criam as condições para melhoria do processo de desenvolvimento na medida em que estabelecem um instrumento de colaboração e de comunicação entre clientes e desenvolvedores. "o propósito de um teste de aceitação é aumentar a qualidade do processo de comunicação necessário para as atividades de análise e levantamento de requisitos, por meio de especificações executáveis".

Quando testes automatizados podem aumentar a qualidade do produto: Aqui a defesa é que o uso de TDD aumenta a qualidade interna do produto na medida em que cria as condições para a evolução sustentável do software. "o propósito do teste unitário é influenciar o design da aplicação, permitindo que ele evolua sem sofrer os danos causados pelo seu processo de degradação".

O artigo também oferece um rápido exemplo de como uma ferramenta como o Fitnesse pode criar especificações executáveis fáceis de ler e de produzir. Conforme imagem a seguir:

A abordagem Ágil oferece uma nova perspectiva para endereçar qualidade de software.
Acho que esse artigo dará ao leitor uma boa idéia do que isso quer dizer.

Embora Quality has nothing to do with testing seja um ótimo post que vale a pena dar uma olhada, acho que o título ficaria melhor formulado como Quality has nothing to do with finding defects. Testes são instrumentos de feedback que obtemos do software quando comparamos seus resultados com nossas expectativas. Assim, quando o resultado de um teste é associado com a completude de uma expectativa, ele é sim um importante instrumento de qualidade.

O mérito do post está em desmistificar as atividades de teste como sendo as únicas necessárias para garantir a qualidade do software. Na verdade, o que ocorre é que as atividades de teste perdem dramaticamente o poder de agregar valor em termos de qualidade quando são utilizadas como instrumento de inspeção-para-a-localização-de-defeitos. Se uma feature sai do ambiente de desenvolvimento sem funcionamento adequado, será certamente mais apropriado parar e descobrir porquê isso ocorreu do que registrar os problemas em um bug tracking e depois continuar o trabalho de inspeção incansável até que nenhum problema seja mais encontrado.

Uma melhor opção é utilizar as atividades de testes como instrumentos para prevenção-de-defeitos. Ao criar, por exemplo, um teste automatizado, não há inspeção. Há a formalização de critérios de aceitação que passarão a conviver eternamente de forma agregada ao produto à partir daquele momento. Assim, somos capazes de introduzir qualidade no produto no mesmo passo em quê o desenvolvemos.

A qualidade dos incrementos de software liberados em um projeto Ágil depende muito do efeito conjunto resultante da aplicação de diferentes tipos de técnicas e práticas, cujo intuito central é evitar que defeitos sejam introduzidos no produto. A ação conjunta desses elementos tem o poder de eliminar (muitas vezes por completo) a necessidade de inspeções-para-a-localização-de-defeitos.

Testes orientados para inspecionar aquilo que, já no seu início, é produzido sem levar em conta os vários aspectos de qualidade relevantes para desenvolvimento de software, são nocivos na medida em que criam uma cultura em que quem desenvolve não precisa garantir a qualidade daquilo que faz, pois há uma implícita delegação para que isso seja verificado por uma outra pessoa.   

No entanto, inspeções não serão sempre ruins. Há as inspeções boas também. Elas ocorrem quando o foco é gerar feedback. Ao inspecionar uma nova funcionalidade, por exemplo,  o foco de quem inspeciona não precisa ser verificação e conferência. O objetivo da boa inspeção é dar feedback, é oferecer um novo ponto de vista de modo a encontrar pontos que poderiam estar melhor resolvidos. O mesmo ocorre quando inspecionamos código, seja passando o código para um colega inspecionar, ou seja fazendo inspeção contínua com pair programming. Em ambos os casos, a procura-por-problemas é elemento secundário, enquanto que feedback é o elemento central.

Em resumo, a inspeção ruim procura por defeitos, enquanto que a boa gera feedback.

Essa semana saiu mais uma edição da Revista MundoDotNet. Desta vez, pude dar minha contribuição com um artigo em que a idéia é relacionar "métricas de código" com "design de software".  Acho que ainda exploramos muito pouco dos benefícios que as métricas de código podem oferecer para o aumento nos níveis de qualidade do design de um software. Apesar de haver muitas ferramentas, raramente se vê alguém que efetivamente obtém alguma vantagem em utilizar as informações que elas geram.

De maneira geral, eu tento dar ali um caminho para se chegar a sintomas de problemas de design por meio da análise numérica de informações extraídas do código-fonte. Assim como um médico pode usar os números extraídos de exames - como números de plaquetas, ph, taxas de glicose e colesterol e outras centenas de índices possíveis - para diagnosticar doenças e prescrever tratamentos, desenvolvedores de software também podem. Um dos caminhos é saber como algumas medições revelam problemas no design. Obviamente que números não são suficientes para avaliar o design de um software. A avaliação subjetiva e humana sempre será necessária. Mas eles podem sim ser de grande ajuda nessa questão.

Quando falamos em "problemas de design", a primeira coisa que me vem a cabeça são os mau-cheiros de código que nos levam aos padrões de refatoração. Assim, o artigo tenta mostrar como podemos encontrar pontos de refatoração à partir de métricas coletadas no código-fonte. Além disso, há a questão de utilizar tal abordagem de modo sistêmico, criando assim alguns mecanismos de proteção contínua do design e abrindo espaço para a evolução do código de forma contínua.

Sei que muitos leitores desse blog não trabalham e também não conhecem a plataforma .Net. Mas, mesmo para eles, recomendo comprar de vez em quando a MundoDotNet (eu não trabalho com Java, mas estou sempre lendo a MundoJava). A MundoDotNet é uma revista que foca na plataforma, porém com uma boa ênfase em aspectos gerais sobre desenvolvimento (como design, arquitetura e técnicas de desenvolvimento), o que a faz ser atraente para qualquer um que leve desenvolvimento a sério.

No caso do meu artigo em específico, ele poderá ser lido e aproveitado por usuários de qualquer plataforma de desenvolvimento. Se quiser discutir sobre o artigo, é só deixar um comentário aqui ou me enviar um e-mail.

Boa Leitura! 

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. 

Sempre achei que toda essa filosofia ágil a qual estamos nos acostumando tinha algum modelo teórico comum. Mas sempre me pareceu estranho que este modelo fosse definido apenas por meio dos princípios surgidos com o Manifesto Ágil em 2001. A grande dúvida é: Em quê tais princípios se baseiam? São resultado apenas de experiências empíricas sobre melhores práticas ou tem algum fundamento teórico original?

Como já havia comentado no tópico anterior, recentemente tenho estudado bastante o trabalho de Jim Highsmith sobre como à partir de conceitos extraídos da teoria de sistemas complexos adaptativos é possível redefinir todas as nossas estratégias de abordagem em projetos de software. Desde então, minhas suspeitas recaíram sobre essa teoria a ponto de considerá-la a "semente original" do movimento ágil.

A confirmação veio quando li um recente post do Jeff Sutherland na qual ele esclarece exatamente este ponto. Na verdade, a motivação do seu post foi estabelecer a correta relação entre Scrum e Lean. Qual a relação entre as duas filosofias de gestão mais comentadas atualmente?

Em seu artigo, Sutherland não só confirma e detalha as bases teóricas sobre as quais o Scrum foi concebido, como também comprova a relação teórica intencional com os sistemas complexos adaptativos. Clicando aqui você terá acesso a discussões originais dele com outros membros de comunidades de desenvolvimento ainda em 1994, incluindo Robert Martin e Kent Beck (que percebe-se nesse momento já estar trabalhando na elaboração teórica de seu método).

Muito do que se sabe hoje sobre Lean teve também origem nos conceitos teóricos sobre sistemas complexos adaptativos. Ainda em 1986, Nonaka e Takeushi publicaram um dos primeiros trabalhos sobre essa nova forma de lidar com projetos no livro intitulado The New Product Development Game. O termo Lean só veio a aparecer em 1990 com a publicação do livro The Machine that Changed the World (James Womack et al), mas os princípios teóricos se mantiveram.

Em resumo, tudo o que sabemos sobre o modelo ágil de trabalho deriva dos sistemas complexos adaptativos. E estudá-los é uma boa forma de entender como e porquê eles funcionam.

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)

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. 

Talvez as questões de garantia de qualidade estejam dentre os assuntos mais misteriosos para aqueles que ainda estão começando a trilhar os primeiros passos em métodos Ágeis. Muito se fala em testes de aceitação, TDD, testes unitários, mas é só isso? Qualidade em projetos ágeis se assegura somente com testes automatizados?

A resposta é não. Essas técnicas são importantes, mas há todo um universo conceitual por trás dos projetos ágeis que poderão lhe ajudar a não só explicar como isso se dá, mas também a aplicar pequenas melhorias que podem causar grande repercussão no seu processo. 

O primeiro ponto a se entender é que qualidade é um meio não um fim. A idéia é não procurar montar um processo cujo objetivo seja gerar um produto de qualidade. O ideal é fazer com que a própria busca pela qualidade oriente a formação do seu processo.

A forma como um projeto ágil lida com qualidade está muito sintonizada com as idéias de Edward Deming e com o modelo de administração e gerenciamento oriental (muito influenciado por ele). O modelo ocidental lida basicamente com o uso de inspeções em massa para assegurar qualidade. O mesmo modelo é utilizado pelos processos tradicionais de desenvolvimento de software. A idéia é mais ou menos a seguinte: Depois que está tudo pronto, vamos testar pra ver se funciona. Talvez por isso a idéia de se criar testes antes de se escrever o software seja considerada tão "excêntrica" por aqueles que ainda não conhecem a abordagem ágil. O modelo mental de se testar só depois que algo é considerado pronto é muito forte. Não foram poucas as vezes que eu ouvi me dizerem: "Mas pra quê eu vou testar agora se ainda não está pronto?"

Assim, para entender como se garante qualidade em projetos ágeis, há 5 pontos que acho serem fundamentais:

1. Não depender de inspeções para garantir qualidade: Se você inspeciona seu software com a expectativa de encontrar defeitos, seu processo ainda não tem qualidade. Então, invista em qualidade durante a produção, não depois. Inspeções são ineficientes porque não previnem o problema, apenas o encontram. Em quê ajuda encontrar um erro em uma inspeção? O erro já está lá! Inspeções são necessárias, certamente não vamos conseguir viver sem elas tão cedo. Mas encontrar erros em uma inspeção no final do processo é desperdício. Considere que há duas maneiras de evitá-las ou reduzir a dependência que você tem delas:

• Inserindo qualidade no produto. Aqui entra a figura dos testes automatizados.
• Antecipando as inspeções de modo que elas aconteçam antes que um defeito seja inserido no produto. Como? Muitas práticas ágeis já ajudam muito, cada uma da sua forma: Integração Contínua, times multi-disciplinares, shared workspaces,  daily meetings, pair programming, TDD, code e design Inspections e outras. Cada prática dessas traz consigo uma diferente forma de inspeção. Você também pode ajudar fazendo testes durante o processo de produção, não depois. Um exemplo é chamar alguém para testar o que foi feito, antes que o software saia da máquina do desenvolvedor. É o melhor momento para se encontrar um problema.  Se deixarmos pra testar tudo no final de uma iteração, as chances de não entregar nada no final são grandes.

2. Valorize a prevenção, não a detecção. Encontrar um defeito não pode ser algo comum. O processo de prevenção deve ser revisado imediatamente. A equipe não deve ir adiante enquanto houverem defeitos. Há várias formas de se trabalhar com prevenção, uma delas é a automação. Por exemplo, automatizar o deploy e a instalação do seu software é investir em prevenção. Um grande número dos problemas encontrados em ambientes fora da fronteira da equipe estão associados às configurações necessárias para se instalar e rodar o software produzido. Os próprios desenvolvedores devem ser capazes de incorporar os recursos que ele precisa para ser instalado. Assim, é o desenvolvedor que tem que indicar que scripts de banco devem ser rodados e que arquivos de configuração devem receber novas entradas. É comum o uso de uma gerência de configuração para isso. Mas é desnecessário quando há automação. Aqui no nosso projeto, o próprio desenvolvedor que produziu a funcionalidade configura tudo que será preciso ser executado quando da instalação do software. A automação elimina a necessidade de intermediação. Isso aumenta a qualidade porque elimina mais um hands-off do processo.

3. Não confie nas especificações como forma de garantir satisfação dos usuários. Se seu projeto ainda está atrelado à necessidade de se desenvolver para atender uma especificação, saiba que elas não são capazes de contar toda a história. Especificações não são bons instrumentos para descrever como um software deve funcionar. A melhor maneira de aumentar a qualidade que o seu cliente percebe no seu produto é envolvendo-o no processo. Ciclos de feedback geram aprendizado, confiança e ajudam o usuário a encontrar a melhor solução. Seguir uma especificação é separar o problema da solução e direcionar o cliente para apenas descrever o problema, enquanto você fica responsável pela solução. O ideal é que o problema e a solução estejam no mesmo contexto, e que eles sejam trabalhados em conjunto. Se, de alguma forma, o cliente contribuir para a solução, ele não só ficará mais satisfeito, como também se tornará seu cúmplice e o ajudará nos momentos difíceis pelos quais você pode chegar a passar.

4. Qualidade não se controla, se incorpora. Em caso de equipes de projeto, não acredito que bugs aparecem por causa de desenvolvedores ruins (talvez problemas de design ou de performance apareçam por causa de desenvolvedores ruins). Bugs aparecem porque a falta de qualidade do processo permitiu. Assim, medidas de punição ou recompensa, ou qualquer outra abordagem top-down para tentar reduzir bugs não funcionam a longo prazo. É injustificável ficar tentando controlar algo tão precioso - como é o caso da qualidade - quando é possível incorporá-la ao seu dia-a-dia.   

5. Treine a aquisição de habilidades, não o uso dos instrumentos. As pessoas são capazes de se tornarem multi-disciplinares. Basta treiná-las para isso. Você vai incorporar qualidade ao seu processo na medida que investe nas pessoas para que elas adquiram novas habilidades. Assim, treine:

• modelagem, não UML;
• padrões de arquitetura, não Webservices;
• design, não novos recursos da IDE;
• programação pragmática, não novos recursos de linguagem;
• a especificar testes, não a usar ferramentas de testes;

Enquanto que os itens a esquerda geram novas habilidades nas pessoas, os itens a direita podem ser resolvidos com 20 minutos de pesquisa no google.

Documentação em projetos ágeis sempre foi um assunto muito polêmico. Há ainda muita gente que a considera um mal necessário. Talvez não seja muito difícil definir uma boa estratégia de documentação se houver um pouco de bom senso e criatividade. Como disse Scott Ambler, um projeto ágil persegue dois objetivos. (a) Objetivo primário: Entregar software funcionando (b) Objetivo secundário: Dar sustentabilidade para o próximo esforço.

Documentação tem haver com o objetivo secundário. O fato de ser secundário não o faz ser menos importante. O fato é que cada documento que uma equipe deve gerar tem um custo, e esse custo tem que ser muito bem dimensionado com relação ao benefício que ele causa.

Um dos principais problemas da documentação é ela não estar atualizada. Uma boa abordagem para incentivar sua atualização é mantê-la o mais integrada possível com os outros artefatos que o desenvolvedor ou a área de qualidade trabalham no seu dia-a-dia. Assim será fácil e prazeroso mantê-la atualizada. Um exemplo disso pode ser observado na figura 1 (É melhor clicar na imagem para vê-la melhor). Ela representa um documento executável.

 
Figura 1: Exemplo de um documento executável

Na verdade, trata-se de um documento para execução de testes web com o Selenium, mas ele tem algo mais dentro dele. Há comandos que não são interpretados pelo Selenium, mas por um outro tipo de parser que pode ser utilizado para transformar o documento em um outro artefato; fazendo-o servir para diferentes propósitos, como por exemplo, uma especificação funcional, um caso de uso ou até um manual de usuário. No exemplo da Figura 1, pode-se notar na coluna parâmetro I, que há comandos que serão executados para a criação automatizada de um manual ou de uma especificação (spec) ou de ambas (manual, spec). Diferentes outputs podem ser gerados dependendo de onde o documento será visualizado: pdfs, documentos words, ou ainda podem ser diretamente publicados em portais ou wikis. Veja, na Figura 2, qual seria o resultado desse documento publicado no mediawiki.

 
Figura 2: Visão do documento executável já
transformado em uma página wiki

Repare também que o documento pode ser diretamente mapeado com o sistema de issue tracking. No caso desse exemplo, por meio de uma integração do Mantis com o MediaWiki. O documento pode comportar também links para outros issues relacionados, bem como outros documentos executáveis. Trata-se de uma forma bem interessante de manter os documentos vivos, fazendo parte efetiva do processo de desenvolvimento.