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.

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. 

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 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.

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.

Esta semana duas publicações interessantes sobre Integração Contínua me chamaram a atenção a ponto de eu estar sugerindo aqui no meu blog.

A primeira é um screen cast no DnrTV com Scott Hanselman e Jay Flowers sobre o CI Factory. O CI Factory realmente me impressionou. Ele ajuda a preparar e gerenciar "workspaces" que isolam, padronizam e permitem fácil extensão e manutenção de sistemas de integração contínua. Em poucos minutos de contato com a idéia da ferramenta já dá pra perceber o quanto seus projetos vão poder se beneficiar de seus recursos. Acho que o ponto alto do CI Factory é trazer consigo um grande conjunto de boas práticas na construção e no gerenciamento de sistemas de Integração Contínua e Build Servers. Algumas das boas práticas que detectei apenas vendo o vídeo (ainda não parei para me aprofundar no uso da ferramenta, mas certamente o farei assim que puder):

• Todos os arquivos necessários para execução da build estão no mesmo contexto de controle de versão do próprio aplicativo;
• Toda a lógica de build é portável de forma que pode ser rodada não só no servidor, mas também nas workstations dos desenvolvedores;
• As referências a componentes de terceiros são organizadas e gerenciadas em um espaço próprio;
• Adicionar ou Remover passos é simples e rápido;
• Incorporar novos recursos à sua build também é muito fácil e rápido. Já vem com os pacotes para vários controladores de repositório, Versionamento de assemblies, Frameworks para execução de Unit Tests, Code Coverage, Métricas, Análises de Código, Deployment e Pacotes para Instalação.

Um outro post interessante foi do Martin Fowler a respeito dos gargalos que às vezes podem ser gerados com builds quebradas em processos de integração contínua. Quando uma build é quebrada, o resto do time é afetado até que a build seja corrigida. A solução pode ser o uso de “branches privados” onde o desenvolvedor faz uma integração prévia antes de integrar com a mainline. Eu particularmente acho que alguma disciplina pode ajudar bastante em diminuir este problema. Práticas como, por exemplo, não integrar no fim do expediente e na iminência do horário de almoço, não realizar integrações simultâneas, deixar bem visível para o restante da equipe que há alguém integrando e evitar que desenvolvedores que estão integrando sejam interrompidos por qualquer motivo.

Uma das coisas que estou trabalhando neste momento é em uma maneira de registrar o que aconteceu em cada Sprint de projeto. Acho que vale a pena ter um instrumento simples pra fazer isso, e em termos de simplicidade ninguém consegue bater um “wiki”.

Assim, estou trabalhando agora em modelo de registro histórico dos sprints em nosso wiki (mediawiki), conforme mostrado no screenshot a seguir:

É importante para nós saber o que aconteceu em cada Sprint. O Product Owner assumiu então esse compromisso de manter um registro histórico dos principais acontecimentos de uma sprint. Isso envolve registrar:

·          a agenda que foi acordada;

·          a meta definida;

·         O backlog do sprint;

·         Que intervenções não planejadas precisaram ser realizadas;

·         Que bugs foram corrigidos?

·         Atendimentos  realizados ao cliente

·         Quais foram os resultados da retrospectiva.

o   O que funcionou bem?

o   O que pode melhorar?

Minha impressão me diz que esse tipo de registro vai ser simples de fazer e deixará uma sensação concreta do progresso do projeto. Será sempre interessante rever sprints de meses ou anos passados e analisar como o projeto evoluiu até seu estado atual.

O ambiente informativo é uma das características mais marcantes de um projeto ágil. Saber o que está acontecendo em um dado momento do projeto apenas olhando as paredes da sua "War Room" é um dos grandes atrativos oferecidos pelos métodos ágeis.

Além disso, há o fator psicológico. Ter todas as ações relacionadas com o escopo da iteração fora da sua cabeça alivia a pressão e o stress de ter que gerenciar uma enorme lista de coisas a fazer na sua memória de curto prazo. O desenvolvedor faz um planejamento das tarefas necessárias para o desenvolvimento de uma funcionalidade, escreve em post-its e cola no quadro. Cada tarefa deve durar no máximo um dia. Ao começar uma nova tarefa, o desenvolvedor remove seu post-it associado da área "To do" e o coloca na área "In Progress". Ao terminar, o post-it é movido para a área "Done". Como uma funcionalidade é criada por meio da execução de n tarefas (representadas em post-its), quando todos os post-its forem movidos para a área "Done" o seu desenvolvimento termina.

O que o SCRUM traz de interessante em suas práticas é que cada funcionalidade (ou item de backlog) é "atacada" por todo o time de uma só vez. Em outras palavras todos os membros do time de projeto trabalham na mesma funcionalidade até que ela seja completamente finalizada. Só aí passa-se para o próximo item de backlog da iteração. Dessa maneira, os post-its com as tarefas são distribuídos e resolvidos em paralelo e não mais de maneira sequencial. O principal benefício desse método é o trabalho em equipe. Cinco ou seis mentes com um objetivo comum produzem realmente um trabalho melhor. O lado negativo fica por conta da perda de produtividade. Não tenho elementos para comprovar que essa perda ocorra de fato, mas para nós esse fato se tornou evidente.

Pensando no processo transcorrendo dessa maneira projetamos um quadro informativo conforme a figura abaixo:

No mundo real o quadro ficou assim:

Os cartões brancos representam itens do backlog. Os post-its são as tarefas. A foto foi tirada no meio de uma iteração experimental de uma semana, por isso poucos cartões brancos. Mas repare na quantidade de post-its. O que tem de ser feito não está na cabeça de alguém, está no quadro e pode ser feito por qualquer membro da equipe.

Na teoria o quadro parece se encaixar bem no dia-a-dia de uma equipe Scrum. Na prática tivemos dificuldade em fazer algumas áreas funcionarem, principalmente a parte de impedimentos. A expectativa é que isso mude na medida em que o processo se torne mais aderente às nossas rotinas diárias.

Essa semana tive o prazer de participar como palestrante no projeto de boas-vindas aos alunos da Unes do Espírito Santo. Minha palestra foi sobre Extreme Programming e eu dividi em três partes:

- Slides com conteúdo teórico sobre o movimento ágil e XP;
- Uma demo sobre TDD usando C# em uma aplicação web;
- Uma demo de Integração Contínua dessa aplicação usando o CruiseControl.Net com o CVS e NAnt;
- Uma demo de automação de testes de aceitação com o Sellenium.

Espero que tenha sido proveitoso para alunos e professores.

Download da Apresentação (581,56 kb)

 Abaixo seguem alguns screenshots das demos apresentadas:

Uma user story e seus testes de aceitação
Escrevendo um teste de unidade
O teste falha
Escreve-se o código para passar no teste
O teste passa
Início da Integração: Envio de alterações para o repositório
Integração Contínua disparada no BuildServer
Nant Output da build
Execução dos testes unitários na build
Automatizando testes de aceitação com o Sellenium

Semana passada fui a São Paulo participar do curso de certificação Scrum Master oferecido pela alemã SPRINT IT em parceria com a TeamWare do Brasil.  Confesso que estava esperando um curso tradicional focado em conteúdo introdutório sobre práticas ágeis e sobre o processo sugerido pelo SCRUM. Felizmente não foi bem assim: muitos exercícios e dinâmicas cujo objetivo era fazer “com que a ficha caísse” em conceitos importantes não só para o SCRUM mas para toda e qualquer metodologia que segue os valores e princípios ágeis

Em busca da compreensão efetiva do funcionamento do Scrum, consolidei alguns tópicos de informação que tirei dos dois dias de curso no mind-map apresentado a seguir.

Figura 1: Map mind com tópicos de informação sobre o SCRUM. (Clique para ampliar).

Desconsiderando um pouco essa parte da mecânica de funcionamento do Scrum, o que mais me chamou atenção no curso foi o foco na compreensão de alguns aspectos importantes das metodologias ágeis que normalmente são mal-compreendidos não só por aqueles que as condenam, mas muitas vezes também por aqueles que a utilizam, como por exemplo:

·         Como os times podem ser auto-gerenciáveis;

·         Como fazer o time se comprometer com uma meta e não com simples execução de tarefas;

·         Como “Valor Agregado” pode ser medido e como é claro e transparente sua prestação de contas;

·         O papel e a forma de liderança em um ambiente ágil;

·         A importância do Auto-aperfeiçoamento da equipe e do processo;

Deixar o time se auto-gerenciar é uma prática totalmente fora de propósito para qualquer gerente que segue a cartilha tradicional de gerenciamento de projetos.  No entanto, quem participa do curso acaba se convencendo que não há modo melhor de fazer um time realmente se comportar como uma equipe que persegue incansavelmente metas claramente definidas e que não precisa de um gerente atribuindo e cobrando a execução de cada tarefa que vai ser executada. O time inteiro passa a ser gerente de si mesmo. A própria dinâmica do processo se encarrega de criar uma espécie de “pressão do time” que leva cada integrante da equipe a dar o seu máximo para que a meta definida seja alcançada.

Na minha visão, o SCRUM se revelou como um framework de processo que conduz a equipe a trabalhar de forma orientada a metas e proporciona a entrega de produtos (“deliverables”) cujo valor agregado é sentido de imediato pelo cliente. Um projeto SCRUM é incrivelmente fácil de ser acompanhado, medido, alinhado com demandas de negócio e adaptado a variações de requisitos. Os instrumentos são simples e eficazes.

A capacidade de auto-aperfeiçoamento do time foi um assunto que obteve bastante ênfase durante o curso. Vários exercícios nos levaram a perceber o quão essa prática realmente pode trazer benefícios para o processo e fazer a equipe aumentar sua taxa de produtividade durante o projeto. Assim como no XP, o SCRUM também determina a reunião de retrospectiva. A engenharia dessa reunião é bem semelhante à do XP. No entanto, o SCRUM vai bem mais além quando assume que um dos principais papéis do Scrum Master é o de remover problemas e impedimentos que dificultam o trabalho do time de projeto. Certamente outro mito sobre o gerenciamento ágil. Hoje é muito comum o pensamento de que a função de coach em um projeto ágil é o de um líder técnico. Além do Scrum Master ter grande parte de suas atividades voltadas para o auto-aperfeiçoamento da equipe, o SCRUM também sugere uma mecânica interessante para acompanhamento dessas atividades, por meio do “Backlog de Impedimentos”.

Um dos pontos altos do curso foi a apresentação de alguns conceitos e técnicas de liderança. Muito apropriado e contextualizado com a natureza do que estava sendo apresentado. Foi apenas um overview, mas que plantou idéias e dicas interessantes na cabeça de todos.

Uma coisa é certa: Não basta saber o que é o Scrum, é preciso fazer para realmente entender e se apaixonar pela metodologia.

Assim, se você está na dúvida se participa ou não da próxima turma, minha recomendação é que vá. O custo é sem dúvida compensado pelos benefícios, experiências e conhecimentos adquiridos.

Fica então meus parabéns a todos que organizaram ou participaram do curso.

O meu processo de certificação agora continua em direção ao “Certified Scrum Master Practitioner”.

 Até Lá!