BDD – Behavior Driven Development

BDD está ficando mais conhecido ultimamente e muitas pessoas estão adotando a prática no dia a dia de desenvolvimento. Mesmo assim BDD é tão antigo quanto o próprio TDD (Test Driven Development).
BDD nada mais é do que trazer ao código, e principalmente ao código que testa os casos de uso da aplicação, um pouco mais da lógica de negócio e do problema que está sendo resolvido no nível do usuário.

Melhorando a comunicação

Quando escrevemos algum teste unitário, normalmente damos um nome ao teste para que possamos entender os resultados quando gerarmos um relatório após a execução dos mesmos. Também damos nomes que façam sentido, para facilitar a comunicação da equipe de desenvolvimento, pois se outra pessoa da equipe precisar dar manutenção no teste, torna mais fácil a compreensão do que o teste está encarregado de testar sem que seja necessário ler muitas linhas de código.


Nos tempos atuais falamos bastante de aumentar a integração da equipe com o cliente ou a área que entende do negócio da aplicação. Também falamos em uma maior colaboração de ambas as partes no desenvolvimento de software. Para quebrar essa barreira que existe entre desenvolvimento e análise, algumas equipes empregam uma programação mais voltada a resolver os casos de uso propostos, ao invés de resolver problemas de baixo nível e compor uma aplicação final.


BDD prega que o problema que será resolvido deve estar bem claro para a parte quem entende do negócio (chamarei de cliente, mesmo que algumas vezes não seja necessariamente um cliente), e quem desenvolve a aplicação em si. Para isso são escritos casos de testes baseados nos casos de uso do sistema, e tais casos de teste usam uma linguagem comum para ambas as partes.


Como normalmente o cliente não é técnico, fica muito difícil se comunicar com ele via testes unitários em código, e fica mais difícil ainda que o cliente colabore com a melhoria e a escrita de tais testes. Porém, os testes unitários e automatizados são a melhor ferramenta do desenvolvedor para testar a aplicação e garantir que a equipe mantenha o código funcionando.


Para suportar ambas as necessidades, e implantar o BDD de fato, uma das soluções é associar o problema de cada caso de uso, a um teste unitário que irá se certificar que aquele caso de uso está sendo corretamente executado.


Por exemplo, em java podemos dar nomes a nossas classes de teste de acordo com o caso de uso que aquele teste se refere. E podemos também nomear os métodos como a execução específica daquele caso de uso:

Dessa forma quando o cliente ver o resultado dos testes e perceber que este teste falhou, ao invés de ler algo como “O serviço de usuário voltou null.”, ele conseguirá ler “No teste de cadastro de usuário, ao testar que um usuário novo está sendo cadastrado, o teste falhou pois o usuário não possui um nome válido, logo não foi cadastrado.”


Parece pouca coisa, mas para o cliente é um informação muito importante nas discussões sobre prioridade de correção de bugs e melhorias do sistema. Isso porque fica claro para o cliente quando o desenvolvedor descreve o teste exato que falhou e o cliente sabe exatamente a qual caso de teste se refere e qual o problema que está sendo resolvido. Não é informação pertinente ao cliente como que tecnicamente se corrige o problema e como que o sistema está implementado para que o erro ocorre-se, esse é o papel do desenvolvedor.

Simples e Efetivo, mas não é a Silver Bullet

Existem muitos frameworks para facilitar a empregação do BDD. Vimos aqui que mais do que um framework, BDD é uma cultura e pode ser empregado sem o uso de qualquer ferramenta, pois o importante é manter a comunicação entre os níveis técnicos diferente na mesma equipe.


Muitos correm atrás da implantação do BDD nos projetos com a esperança de que os problemas na resolução de bugs e na comunicação da equipe serão resolvidos. Isso não é verdade e seu projeto irá dar tão certo quanto ele daria antes da adoção de BDD. BDD é um mudança de comportamento na equipe onde todos devem estar empenhados na causa de melhorar a comunicação, e tentar entender os problemas de verdade que o sistema se propõe a resolver.


A mudança de comportamento tem que partir do lado do cliente também, pois é necessário a compreensão de que os erros que estão claros para ele agora, não surgiram do nada. Na verdade eles sempre estiveram presentes no sistema, só que protegidos pela barreira que impedia a comunicação entre de desenvolvimento e análise.


Espero ter sido claro, qualquer opinião sobre o assunto será bem vinda.


Por @Gust4v0_H4xx0r

…Houve um tempo em que eu achava que métodos ágeis eram um excelente álibi para programador preguiçoso. E, ainda hoje, as vezes fico pensando sobre o significado do nome “ÁGIL”. Será que esse nome contempla, de fato o seu propósito, ou é um nome meramente “marketeiro”? Veja só:  No dicionário, o significado de “ágil” é ser rápido e flexível, por sua vez, no dicionário, o antônimo de ágil é lento e vagaroso.  Ora, ninguém quer ser taxado como lento e vagaroso!  Sendo assim, se eu não quero ser taxado de lento e vagaroso, então por eliminação eu sou ágil.

Esse clichê formado sobre a palavra ÁGIL distorceu um pouco as coisas. Muitas empresas e desenvolvedores que não conseguiam implantar processos de desenvolvimentos de software maduros, e que por muitas vezes cairam no mito da Fantástica Fábrica de Software,  começaram a se intitular como ágil. Nesse contexto continuo achando que métodos ágeis são um excelente álibi para programador preguiçoso.

A questão é que desenvolver software é uma tarefa que dependente de  tecnologia, processos, e, sobretudo, do conhecimento das pessoas.  Como já diria Fred Brooks em seu famoso artigo No Silver Bullet, não existe bala de prata, não existe ferramenta, metodologia ou qualquer outra mágica que resolva milagrosamente todos os problemas.

Segundo [Filho, 2008]:  “em uma organização imatura os mesmos problemas se repetem de projeto em projeto, o trabalho é excessivo e estressante e frequentemente há a necessidade de corridas desesperadas contra os prazos, a qualidade de vida no trabalho é ruim, o ambiente é desgastante e os profissionais são desmotivados. Os erros relativos ao processos de desenvolvimento de software são comuns em organizações  que utilizam processos imaturos, ocorrendo também naquelas que possuem processos rígidos, complexos e burocráticos e naquelas em que os processos apesar de existirem são seguidos parcialmente, ou em última instância, não são seguidos.”

Não obstante, o mercado tem exigido produtos de software ainda mais sofisticados e em prazos de desenvolvimento mais curtos. A referida exigência, tem instigado a pesquisa na área engenharia de software, objetivando encontrar meios para garantir que o software seja produzido atendendo às expectativas do cliente e aos atributos de qualidade definidos pela organização fornecedora de software e esperados pelo mercado.

Antes  de enfatizar a importância da agilidade do processo, é preciso entender o que ela realmente significa. Em suma, é a capacidade que uma organização possui para responder rapidamente às forças , fraquezas, oportunidades e ameaças do mercado. Há inúmeras situações práticas, onde agilidade do processo é altamente desejado, incluindo: apresentando um novo produto, entrar em um novo mercado,  responder à entrada de concorrentes, responder a alterações de requisitos em produtos em construção, etc.

Outro aspecto, é que o processo de desenvolvimento de software é complexo e precisa favorecer a criatividade e a inovação, e ter um nível adequado de flexibilidade para beneficiar a engenharia de processos na melhoria contínua. O grande desafio na proposta de um processo é conseguir um conjunto de regras que guiem o desenvolvimento sem comprometer a criatividade e a motivação dos desenvolvedores e sem travar a organização para a constante evolução da tecnologia e as adequações necessárias.

Uma abordagem adotada para romper a barreira da imaturidade é a definição de um processo de desenvolvimento de software padrão. O referido processo descreve as atividades que devem ser realizadas no desenvolvimento de software em todos os projetos da organização. A idéia é que isso favoreça que a organização atinja a conformidade com os padrões de qualidade esperados. Na literatura existem várias definições para processos de desenvolvimento de software:

• “Uma sequência de passos executadas para um determinado propósito; por exemplo, o processo de desenvolvimento de software.” [IEEE, 1994]
• “Um processo ´e um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos práticas e transformações usado para atingir uma meta.” [Filho, 2008]
• “O processo de software ´e um conjunto de atividades que leva à produção de um produto de software.” [Sommerville, 2007]

De forma bem resumida, o processo de desenvolvimento de software formal descreve por meio da sua documentação: o que é feito , quando é feito, por quem é feito, como é feito, além dos insumos que usa e os produtos de saída. Em outras palavras, o processo enfatiza a padronização para possuir um parâmetro de medida e de controle e para poder circunscrever o erro em busca de qualidade. Contudo, embora seja necessário definir um processo de desenvolvimento de software, só isso não é suficiente para a construção satisfatória de um software. Existem vários fatores envolvidos que influenciam diretamente a construção do software, por exemplo: a capacitação das pessoas envolvidas, as tecnologias e ferramentas utilizadas, a cultura organizacional, entre outros.

Um processo de desenvolvimento de software não é definido do zero. Na literatura existem vários modelos que descrevem orientações para a definição e implantação de processos, dentre eles a ISO 12207/15504, CMMI e MPS-BR. Nesta linha, o processo de desenvolvimento de software deve estabelecer :

• atividades a serem realizadas durante o processo, sua estrutura e organização (decomposição e precedência), incluindo a definição de um modelo de ciclo de vida quando pertinente;
• artefatos requeridos e produzidos por cada uma das atividades do processo;
• procedimentos (métodos, técnicas, roteiros e padrões) a serem adotados na realização das atividades;
• recursos necessários (humanos, hardware e software) para a realização das atividades.

Em busca de eliminar a imaturidade, as organizações investem em definir e implantar um processo baseando-se em modelos de maturidade como CMMI e MPS-BR. Entretanto, esses modelos são densos, repletos de subprocessos que devem ser implementados em cada área de processo de cada nível de maturidade (no caso de CMMI) .

Um nível de maturidade é um patamar evolutivo bem definido que que “determina” a capacidade que uma organização possui em desenvolvimento de software. Cada nível visa alcançar um processo de desenvolvimento de software cada vez mais maduro.  Os níveis são uma forma de priorizar as ações de melhoria, de tal forma que se aumente a maturidade do processo de forma continua. Assim, os níveis de maturidade são cumulativos, ou seja, um nível de maturidade mais alto inclui os atributos dos níveis mais baixos. Uma vez que os modelos são projetados para descrever níveis discretos de melhoria de processo, níveis de capacidade provêem uma ordem recomendada para abordar a melhoria de  processo dentro de cada área de processo.

É  esperado que a cada nível alcançado pela organização, mais madura ela se torna em desenvolvimento de software. Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos.  Para que isso seja alcançado, um bom processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Essa equipe trabalha constantemente na garantia e no controle de qualidade do processo e do produto, respectivamente.

Quando uma organização atinge o nível 5 no CMMI ou A do MPS-BR, ela entra em um espiral de melhoria continua.  A equipe de projeto e  a equipe de qualidade reportam para a equipe de definição de processo gargalos e deficiências do processo atual, e complementam com sugestões para melhoria de processo. A equipe de definição de processo por sua vez avalia todas as sugestão, e, se pertinentes, implantam a melhoria no processo. Isso se torna um ciclo de inspeção e adaptação do processo.  Quanto mais madura a equipe, menos atividades de inspeção técnica e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto. Veja o post sobre Conformidade com o Produto vs. Conformidade com o Processo.

No gráfico acima tentei ilustrar o que percebo sobre a agilidade de processos. Quando se fala em agilidade em processo, já estamos condicionados a pensar em métodos ágeis de desenvolvimento de software como Scrum, eXtreme Programming , princípios Lean etc. No entanto, agilidade, na essência,  se aplica em um ambiente de desenvolvimento formal também.  No início, quando a organização não possui nenhum processo definido o ambiente não é estável, e, frequentemente, ela depende da competência e heroísmo das pessoas para atingir seus objetivos. Neste ambiente, a rigidez de processo é baixa, informal e caótico, mas apesar disso as organizações muitas vezes produzem produtos e serviços que funcionam. Entretanto, elas freqüentemente estão expostas a vários problemas de projeto como: exceder o orçamento e o cronograma planejado, baixa qualidade, não cumprir compromissos, abandonar processos em momentos de crises e não ser capazes de repetir sucessos do passado.

Para não ficar tão expostas aos problemas de projeto citados, as organizações partem para implantação de processos, e, a medida que esses processos são implantados e os níveis de maturidade de processo são obtidos, mais “rígido”, mais “burocrático”  o processo se torna.  No entanto, entendo que a tão criticada rigidez e burocracia de processos formais é uma fase transitória, de aprendizado, de padronização e, sobretudo de amadurecimento.  Nos níveis mais altos de maturidade o objetivo é a simplificação, a “des-burocratização” de processo. Lendo isto alguém poderia estar perguntando: “Ora! Então porque a organização não vai direto para esse estado?”  Bom, imagino que isso se torna necessário na caminhada da Imaturidade à Agilidade.

Chaus Report 2009 – Standish Group

Pesquisas como as realizadas pelo Standish Group apresentadas no Chaus Report 2009 demonstram que grande parte dos projetos de software falham ou são desafiados, seja porque não cumprem o orçamento, ou não cumprem o cronograma, ou as funcionalidades não atendem às necessidades dos usuários ou porque todos estes fatores estão presentes em conjunto. Para o Standish Group um projeto de software é considerado um Sucesso quando todas a funcionalidades do escopo inicial são entregues no orçamento e cronograma planejado. O projeto é Desafiado quando ele sofre com atrasos, não cumpre o orçamento inicial e/ou é entregue com menos recursos e funções do que o definido no escopo inicial. E finalmente, o projeto é considerado Falho quando ele é cancelado antes da conclusão ou o produto da sua entrega nunca é utilizado.

Há algumas décadas a indústria de software vem buscando técnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. A referida constatação não é recente. Já em em 1968 houve um evento denominado conferência de NATO, que, entre outras coisas, tentou entender e discutir o porquê que a maioria dos projetos de software falham ou são desafiados. De lá para cá, a indústria de software vem evoluindo e a partir dos anos 90 surgiram várias propostas como o desenvolvimento de processos formais como RUP, pautados sobre modelos de maturidade como CMMI e a evolução de autores consagrados como Coad & Yourdon, Pressman, Sommerville, Rumbaugh, Booch, Jacobson, etc.

Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas”: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software de maneiras bem peculiares, apesar dos objetivos finais serem os mesmos. Na escola tradicional o conceito de processo de desenvolvimento de software se assemelha ao usado em processos de produção industrial: um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações usadas para atingir uma meta, centrado em documentação e controle operacional. Já os adeptos das metodologias ágeis não estão presos a processos rígidos; o que interessa é aquilo que de fato agrega valor ao usuário, não que a escola tradicional não pense assim, como entregas rápidas ou como já diria um dos princípios ágeis: “Nossa maior prioridade é satisfazer o cliente através da entrega rápida e contínua de software de valor.”

Não obstante, a indústria de software é bastante dinâmica, novas idéias, tendências e tecnologias surgem a todo instante e em todas as partes do mundo. Acompanhar essa dinâmica é fator crítico de sucesso para profissionais e empresas que pretendem adquirir um diferencial no mercado. Um ponto fundamental para acompanhar o dinamismo do mercado está na habilidade de lidar de forma mais eficiente com as mudanças de requisitos, aumentar a motivação da equipe e melhorar comunicação com o cliente do projeto, e, para isso, será necessário estar pronto para introduzir uma nova cultura de liderança que irá alterar os papeis e trará uma nova forma de trabalhar transferindo parte da responsabilidade do gerente do projeto para a equipe.

A adaptação às mudanças decorrentes de fatores externos são uns dos conceitos centrais dos métodos ágeis. Onde os métodos mais formalizados e centrados em planejamento e documentação são preditivos na tentativa de prever as necessidades futuras, em contrapartida, os métodos ágeis são adaptativos e rapidamente se adaptam às novas exigências, aderindo ao lema “abrace as mudanças!”. A única medida de sucesso é a de produto funcionando.

Outro princípio importante é a simplicidade e pensamento enxuto. De acordo com o conceito de pensamento ágil, projetos de grande escala, por exemplo, não são desejáveis. Pelo contrário, é preferível minimizar a quantidade de trabalho daquilo que não precisa ser feito. Isto inclui, por exemplo, não gastar tempo escrevendo documentação desnecessária.

Cada vez mais a abordagem ágil de desenvolvimento de software vem se popularizando entre grandes empresas de sucesso como: google, yahoo, amazom.com, globo.com entre outras. No entanto, nem sempre as empresas que tentam adotar a filosofia ágil têm obtido o mesmo sucesso. Várias discussões tem se formado para entender o motivo do referido insucesso, e as conclusões estão convergindo para fatores como: falta de treinamento dos colaboradores; equipes hierarquizadas, e, sobretudo, resistência de mudança cultural.

Desenvolver software é uma tarefa que exige técnicas de engenharia e arte. Se uma empresa ou profissional não absorver a filosofia ágil dificilmente se manterá competitiva no cenário atual do mercado de software por mais que se implemente uma metodologia.

Nesse sentido, cabe a nós profissionais críticos, formadores de opinião, termos a a clara consciência de adotar processos tradicionais ou processo ágeis, ou no melhor dos casos, como integrar os dois para tirar o maior proveito.

Os envolvidos com Rails já sabem que no domingo passado terminou o Rails Rumble. Uma competição onde equipes de até 4 pessoas criam aplicações
dentro de um período de de 48h.

As aplicações são julgadas nos critérios de Inovação, Aparência, Utilidade e Acabamento. E neste ano 300 equipes estão competindo nestes pontos e concorrendo a vários prêmios legais.

Neste ano eu tive o imenso prazer de participar da competição e vou contar um pouquinho como foi essa experiência.

Preparação

Montamos nossa equipe bem antes do evento, formada por: eu, João Vitor, Jeffry Degrande, Bruno Alves.

Logo que todos toparam encarar essa maratona a tarefa foi decidir o que ser feito.

Como todo a equipe está em Belo Horizonte decidimos que a melhor forma de colocar as coisas na mesa seria através de reuniões presenciais. A primeira delas foi para a decisão do tema.

Antes da reunião cada pessoa levantou uma série de idéias e no dia fomos descartando o que era complexo de mais ou que não tinha interesse. Ficamos com 3 idéias principais mas no final o que escolhemos foi a idéia do Superfolio

A idéia

Basicamente a ferramenta é uma forma de resolver a criação de site profissionais. Como assim? Toda pessoa precisa de um curriculum, no entanto eles são trabalhosos de serem feitos, ficam desatualizados e para várias profissões não significam muito (ex.: para um desenvolvedor Ruby seu github pode fazer mais diferença que seu CV).

Por outro lado todo profissional precisa de um site na internet com informações bem parecidas com a de um CV, no entanto um site abre um mar de possibilidades. Possibilidades como facilidade de atualizações, anexar imagens e principalmente links para redes que possam interessar seus contratantes e clientes (ex.: um desenvolvedor Ruby pode linkar seu Github e seu Blog). Outro ponto que conta muito em qualquer contratação são sua recomendações, este também é um ponto que um site pode resolver e um CV não.

A idéia é bem simples, permitir que qualquer profissional interessado em criar seu site possa acessar um painel administrativo e definir sua biografia, experiências, fotos de projetos, links externos e aceitar recomendações.

Como a ferramenta é para criação de um site de verdade também é necessário que exista a possibilidade da customização completa do layout, ter um domínio próprio e poder monitorar os acessos (via Google Analytics).

Ficou curioso? Acesse o meu superfolio e veja tudo que pode ser feito: http://daniellopes.me/

Planejando a execução

Com a idéia levantada começamos a fazer encontros semanais na Dito Internet.

Diferente de um projeto de software convencional, desta vez nós sabíamos todas as features e não tínhamos a opção de ir criando o sistema e recebendo feeback. Por essa razão a opção de várias reuniões longas foi tomada ao invés do modelo Agile de reuniões.

Eu fiquei responsável pela interface, então antes mesmo do evento eu fiz todos os mockups necessários para termos a visão completa da aplicação. Com os mockups detalhamos algumas dezenas de tickets no Pivotal Tracker.

Dividindo tarefas

Alguns pontos precisavam ser estudados antes do evento já que no dia não poderíamos aprender nada, apenas executar.

Como dito anteriormente, eu fui o designer então além de todos os mockups também fiz uma grande pesquisa de referência para o layout, pois não haveria tempo para “inspiração”. Com base nos mockups também foi possível identificar quais pontos do HTML seriam complexos então achei solução para estes pontos e também bibliotecas de JS que deveriam ser usadas (jQuery, facebox, jquery-tools e etc).

Bruno ficou responsável por configuração dos servers então ele montou uma receita do que precisaria ser seguido no dia do evento. Também contratou uma VPS para os testes e estudou o Base-App, que automatiza o deploy.

Jeffry ficou com a parte de customização do layout e temas, ele optou pelo Liquid e se especializou neste ponto. Também cuidou de estudar a melhor alternativa para integração contínua (escolhido foi o CI Joe).

No site também temos uma busca complexa na home que pesquisa por qualquer termo no site dos usuários. Para isso João Vitor ficou a cargo das pesquisas e por final usamos o Solr.

Logística

Antes do evento também fizemos a organização do que precisaríamos no dia e quais tipos de refeições deveriam ser feitas para evitar o cansaço.

Para o local do evento o Bruno cedeu o escritório da Dito que conta com uma infra-estrutura muito boa e cercado de restaurantes.

Foi decidido que as principais refeições seriam feitas nesses restaurantes e ali faríamos as reuniões de retrospectiva dos mini-sprints.

Tudo foi muito bem planejado e a único complicador foi a falta de um chuveiro na Dito

Execução

Uma coisa já era fato. O prazo é curto mas todos os membros da equipe são profissionais e nós não sacrificaríamos as boas práticas por causa do tempo.

Ficou definido que usaríamos métodos ágeis, pair pogramming quando necessário, deploy contínuo, integração contínua e principalmente Test Driven Development.

Jeffry montou um server de integração contínua com CI Joe que ficava ligado ao televisão de 42 polegadas da Dito. Todos os pushs para o github do projeto e builds ficavam visíveis e com um som diferente tocando para cada fato. Assim sabíamos ao certo quando os testes paravam de funcionar.

Para deploy usamos o famoso Capistrano. Mas antes do evento fizemos um tunning do meu template de app Rails, o Base-APP. Com ele o Capistrano já fica muito bem configurado além de várias outras coisas que melhoramos nele mas que são comuns para qualquer app (o projeto é open-source e MIT). Também foi usado o Hoptoad para monitoração de exceptions em produção.

Pair programming foi essêncial para achar os erros mas não para planejamento pois tudo já havia sido planejado antes. Também usamos pair programming para evitar o sono.

Para TDD decidimos pelo Rspec com Steak. Uma boa cobertura é essencial, principalmente em um ambiente tão apertado como o Rumble e testes de aceitação fizeram toda a diferença.

Tendência ao amadorismo

Nós, seres humanos, gostamos de colocar a culpa do nosso amadorismo em vários fatos mas nunca em nós mesmo. No Rumble a maior desculpa para a “tosqueira” é o tempo.

Já fui questionado várias vezes se deve ser feito TDD quando o tempo é apertado e vou compartilhar um pouco dessa experiência no caso mais extremo: Rails Rumble.

Não seguimos TDD a risca no projeto mas seguimos desenvolvimento com testes o tempo todo.

Na madrugrada de domingo, já extremamente cansados, estávamos fazendo vários push’s para o Github simultaneamente e em um certo momento alguns testes começaram a quebrar.

Não corrigimos isso na hora e ficamos com 9 testes quebrando. E nesse momento eu estava no HTML e o Bruno e Jeffry implementando novas features não relacionadas aos tests quebrados. Até que o Jeffry largou tudo para consertar os tests. Mas o Jeffry era o único da equipe com conhecimento do Liquid então o Bruno resolveu assumir o “pepino”.

Alguns dos testes foram corrigidos com meu HTML mas o mais complicado era um teste que estava falhando por algum motivo estranho que não era simples de achar. No fim, Bruno descobriu uma falha grave no nosso algoritmo de redirecionamentos que permite a usuário ter seu próprio domínio (daniellopes.me ao invés de de superfolio.net/daniel).

O resumo é que se não tivéssemos testes não teríamos conseguido achar esse bug e se a equipe tivesse deixado o caos tomar conta o sistema teria ido para o ar com este bug grave. Atualmente o sistema está rodando bem e sem notificar nenhuma exception.

Lições aprendidas

O Rumble serviu para colocar a prova todos os nossos conhecimentos de Ruby e desenvolvimento de software. Eu, pessoalmente, pude tirar várias lições (e acho que meu amigos de equipe vão concordar).

Amadorismo

Primeiro, o tópico anterior: Falta de tempo não é desculpa para amadorismo.

Equipe

Outro fator marcante foi a importância da equipe. Mais do que em qualquer projeto, no Rumble, pessoas são mais que processos e manter a comunicação, a amizade e pensamentos na mesma linha em 48h, sem descanso, é um mega desafio.

No nosso caso a equipe se deu muito bem, como eu nunca tinha visto antes. Apesar de nunca termos trabalhado todos juntos houve uma coesão muito grande.

Todos os membros trabalharam como loucos e suaram a camisa pelo projeto. Foi a melhor definição de uma equipe auto-gerenciável que já vi (kudos para o Jeffry, Bruno, João e eu mesmo ).

Descanso

Outra lição é que sempre é preciso haver descanso, não importa o quão apertado é o deadline você não pode entrar no modo “Hero” (como dito no Rework). O estado onde resolver o problema se torna questão de honra, não importando mais nada.

Se você fica muito tempo olhando um problema você nunca vai resolve-lo se não descansar um pouco ou pedir ajuda. Toda vez que a coisa agarrava compartilhávamos o problema com a pessoa mais próxima e um olhar externo resolvia rapidamente.

Design

Outro ponto que ajudou muito foi ter uma equipe de Railer’s experts junto com um designer com conhecimento de Git, HTML, JS e testes. Ou seja, alguém focado no frontend mas com visão geral das tarefas. (depois farei outro post sobre o verdadeiro papel do Design em Software)

Em vários momentos quando eu passava do photoshop para o html nossos testes de aceitação quebravam no protótipo já existente. Conseguir resolver essas coisas sem precisar chamar outro desenvolvedor ajudou muito.

Também foi importante o designer conseguir “baixar” e trabalhar corretamente com o código usando o Git, então o fluxo e forma de compartilhamento era igual entre toda a equipe e eficiente.

A parte do design também guiou as funcionalidades, fazendo que conseguíssemos identificar problemas graves antes de implementarmos.

Refactoring

Ficou bem claro que o mais importante é colocar funcionando e que depois haverá tempo para ajustes. Pensando dessa forma é muito importante manter um bom suite de testes para que você possa voltar e refatorar depois e manter a confiança do funcionamento.

O sistema possui vários pontos que podem ser melhor arquitetados mas o que importa é que ele está online e com nosso suite de testes podemos fazer essa refatoração nos pontos que importam.

Conclusão final

Apesar do cansaço (e da falta de banho eu saí do evento extremamente motivado e satisfeito com o resultado. A equipe foi extraordinária e a competição uma experiência que não tem preço.

Não importa o resultado (bem… importa um pouco a verdade é que conseguimos entregar em 2 dias um CMS relativamente complexo e mantendo a qualidade do trabalho.

Agora é conseguir os usuários que vão fazer uso do sistema de fato. Passando o efeito que chamo de “Onda Sapo” (usuários curiosos que só entram no sistema para sapear e não para usar mesmo acredito que o sistema poderá evoluir para algo bem funcional. O exemplo é o meu próprio site em daniellopes.me .

Também decidimos manter a equipe e fazer encontros frequentes para melhorar o Superfolio como um time.

Com certeza ano que vem participarei novamente e caso passemos para final vamos precisar da ajuda de vocês

Twitter!

Boas práticas e testes no nosso dia-a-dia de desenvolvimento

Testes unitários já foram vistos com maus olhos pela comunidade de desenvolvimento de software quando surgiram, e hoje em dia é uma das práticas obrigatórias no desenvolvimento da maioria dos sistemas. Mas afinal o que fez todo mundo mudar a maneira de pensar e trabalhar? O que motiva um desenvolvedor a “perder tempo” escrevendo testes unitários?

As respostas hoje em dia são bem claras na cabeça de muitos desenvolvedores, por isso vamos passar por temas que vão além dos testes unitários e abordar como nos beneficiamos a longo prazo com uma política de testes e boas práticas bem definida.

Testando sempre, corrigindo sempre

Já que todos concordam (a grande maioria pelo menos) que testes nos beneficiam, porque não testar em todo o processo de desenvolvimento? Uma dúvida que surge assim que a equipe resolve testar suas classes: devemos estimar também o tempo que levaremos para escrever os testes? A resposta é simples, sim e não. Sim porque com certeza o tempo para executar a tarefa será diferente quando resolvemos escrever testes para nossas classes, e não porque não devemos separar a estimativa, como se escrever testes fossem uma tarefa diferente. Inclusive deveríamos considerar que uma tarefa só é concluída se existem testes unitários que garantem o funcionamento da mesma, e que tais testes estejam passando.

Podemos pensar que se para cada funcionalidade que implementamos garantimos o funcionamento da mesma, estamos seguros para implementar uma nova funcionalidade sem interferir no progresso do sistema até então. A única maneira de garantirmos que toda funcionalidade nova estará de acordo com as já existentes é testando ao longo de todo o projeto. O mesmo vale para testes de uso, feitos por uma equipe de testes, pois se pensarmos que os testes unitários nos protegem de nossos próprios erros, ainda assim não estamos protegidos de erros de sistemas externos que serão usados par integração com o nosso projeto.

O fator mais crítico em se testar sempre, é que quando nos deparamos com um determinado erro, nossa cabeça ainda está no contexto da tarefa ao qual o teste falhou, e portanto está mais claro em nossas mentes como corrigi-la, acelerando a correção de erros e o desenvolvimento de novas tarefas mais futuramente.

Relatórios de Cobertura

Os relatórios de cobertura de testes a primeira vista parecem um ferramenta de controle sobre como estamos desenvolvendo. Muito pelo contrário, porque os relatórios de cobertura apenas expoem as linhas e blocos do código que são executados durante os testes, escondendo muitos outros fatores relevantes no desenvolvimento, além do que é bem fácil “roubar” no teste para obter uma cobertura alta.

O relatório de cobertura serve como ferramenta de alerta para a equipe como um todo, para que a qualquer momento, qualquer membro da equipe possa consultar o relatório e se certificar que dado a cobertura de testes, ele pode continuar o desenvolvimento de suas tarefas ou então, notificar toda a equipe que existem partes do código não testadas e que devem receber mais atenção para garantir uma evolução contínua do sistema.

FindBugs e PMD

O FindBugs é uma ferramenta que nos auxilia no desenvolvimento prevendo possíveis pontos problemáticos do sistema. O FindBugs funciona com o Java mas existem versões para diversas plataformas.

No mesmo espírito do relatório de cobertura, os possíveis bugs apontados pelo FindBugs servem como alerta para a equipe para pontos do sistema que talvez mereçam mais atenção, e da mesma forma é possível “roubar” e sempre deixar o FindBugs “contente”, por isso é essencial a consciência da equipe para manter o FindBugs dentro da linha.

O relatório gerado pelo PMD é mais um guia de boas práticas que deveriam ser seguidas durante a implementação do código. O PMD é bem menos intrusivo que o FindBugs no sentido de que a análise feita por ele é mais voltada a estilo de programação, e pode ser configurada e ajustada de acordo com o projeto e a equipe. O ideal seria que conseguíssemos estabelecer uma configuração do PMD e do FindBugs para a DClick, garantindo que se mudarmos algum desenvolvedor de equipe, o desenvolvedor iria estar familiarizado com as práticas e padrões do novo projeto, afinal seriam os mesmos padrões exigidos no projeto em que o desenvolvedor estava.

Site do FindBugs

Site do PMD

Checkstyle

Um dos principais objetivos de se empregar boas práticas de programação, é garantir uma linguagem comum entre equipes de desenvolvimento. Para facilitar tal compreensão, seria interessante que o código implementado independente da equipe, seguisse uma mesma identação e organização. Dessa forma um desenvolvedor novo no projeto consegueria “se encontrar” no código de maneira mais rápida, porque a estrutura adotada seria a mesma em todos os projetos.

Para facilitar e garantir que o padrão está sendo seguido, existe por exemplo, o plugin de ‘checkstyle’ do eclipse. O plugin nada mais faz do que colocar warnings no código, nos trechos em que o padrão de identação e organização definido não está sendo seguido. O plugin consegue ir um pouco mais longe do que meramente validar formatação de código, e consegue “cobrar” o emprego de algumas boas práticas mais básicas, como por exemplo encapsulamento e gerenciamento de variáveis.

Site Oficial do Checkstyle

Documentação

Se escrever código de maneira padronizada, organizada e compreensível é essencial para comunicação, o mesmo se aplica para a documentação das classes.

Por isso que existem ferramentas como o javadoc, que é uma das ferramentas mais difundidas na comunidade. Isso porque garante a geração de uma documentação livre de código de maneira automática e simples. O que deveríamos ter em nossas classes, é uma documentação na qual não seja necessário ler o código para entender o funcionamento da classe. A única maneira de garantir um nível de documentação desses, é sempre manter a documentação atualizada e constantemente mudá-la conforme desenvolvemos o sistema.

No Java existe o Javadoc que é tão difundido que já vem integrado com o Eclipse IDE, e existem versões disponíveis para todas as grandes plataformas, inclusive Flex.

De modo geral

Apesar de citar algumas tecnologias usadas no Java, o objetivo principal do post é mostrar que o emprego de tais ferramentas nos ajuda no dia-a-dia de desenvolvimento em geral, não importando a tecnologia utilizada. A idéia é atingir um nível de qualidade geral, independente de plataforma. Se atingirmos um nível aceitável e conseguirmos seguir um padrão, conseguiremos migrar entre projetos tendo que apenas entender a regra de negócio do projeto, já estando familiarizado com as práticas de desenvolvimento.

Esses dias lendo o livro do Fowler (PoEAA), ele comenta um pouco sobre desempenho e como muitos dos termos de desempenho são usados de forma inconsistente. Para melhorar a comunicação de equipes de desenvolvimento de software resolvi publicar alguns termos e seus respectivos significados.

1. Tempo de Resposta
   

   É a quantidade de tempo que o sistema leva para processar uma solicitação externa. Pode ser uma ação na interface com o usuário, como o pressionamento de um botão, ou uma chamada de API do servidor.

2. Agilidade de Resposta
   

   A agilidade de resposta diz respeito ao quão rapidamente o sistema reconhece uma solicitação (em oposição ao tempo que leva para processá-la). Isso é importante em muitos sistemas porque os usuários podem ficar frustrados se um sistema demorar para responder a uma solicitação, ainda que seu tempo de resposta seja bom. Se o seu sistema esperar durante toda uma solicitação, então sua agilidade de resposta e o seu tempo de resposta são os mesmos. Entretanto se você indicar que recebeu a solicitação antes de completá-la, então sua agilidade de resposta é melhor.

3. Latência
   

   É o tempo mínimo requerido para obter qualquer forma de resposta, mesmo se não houver nenhum trabalho a fazer. Se eu pedir a um programa para não fazer nada, então devo receber uma resposta quase instantânea se o programa rodar na minha máquina local. Entretanto, se o programa rodar em um computador remoto, pode demorar alguns segundos devido ao tempo gasto para que a solicitação e a resposta cheguem a seu destino através da conexão. Como desenvolvedor de aplicações, geralmente, nada posso fazer para melhorar a latência. A latência é o motivo pelo qual devemos minimizar chamadas remotas.

4. Throughput
   

   É a quantidade de coisas que você pode fazer em uma dada quantidade de tempo. Se você estiver contabilizando o tempo gasto na cópia de um arquivo, o throughput poderia ser medido em bytes por segundo. Para aplicações corporativas, ume medida típica é o número de transações por segundo (tps), mas o problema é que isso depende da complexidade da sua transação.

   Nesta terminologia, desempenho pode significar tanto throughput quanto tempo de resposta – o que for mais importante para você. Às vezes, pode ser difícil falar sobre desempenho quando uma técnica melhora o throughput, mas piora o tempo de resposta. Assim é melhor usar o termo mais preciso. Da perspectiva de um usuário a agilidade de resposta em detrimento do tempo de resposta ou do throughput aumentará o desempenho.

5. Carga
   

   A carga é uma medida da pressão a que o sistema está submetido, que poderia ser medida pelo número de usuários a ele conectados em um determinado instante de tempo. A carga é geralmente um contexto para alguma outra medida, como um tempo de resposta. Assim, você pode dizer que o tempo de resposta para alguma solicitação é de 0,5 segundo com 10 usuários e de 2 segundos com 20 usuários.

6. Sensibilidade de carga
   

   É uma medida de como o tempo de resposta varia com a carga. Digamos que o sistema A tenha um tempo de resposta de 0,5 segundo para um número de usuários entre 10 e 20, e o sistema B tenha um tempo de resposta de 0,2 segundo para 10 usuários que aumenta para 2 segundos com 20 usuários. Neste caso o sistema A tem uma sensibilidade de carga menor do que o sistema B.

7. Eficiência
   

   A eficiência é o desempenho dividido pelos recursos. Um sistema que obtenha 30 tps com duas CPUs é mais eficiente que uma que obtenha 40 tps com quatro CPUs idênticas.

8. Capacidade
   

   A capacidade de um sistema é uma indicação do máximo throughput efetivo ou máxima carga efetiva. Este poderia ser um máximo absoluto ou um ponto a partir do qual o desempenho caia abaixo de um limite aceitável.

9. Escalabilidade

A escalabilidade é ume medida de como o acréscimo de recursos (normalmente hardware) afeta o desempenho. Um sistema escalável é aquele que lhe permite adicionar hardware e obter uma melhora de desempenho proporcional, como dobrar o número de servidores disponíveis para dobrar o throughput. A escalabilidade vertical, ou escalar para cima, significa adicionar mais poder a um único servidor (por exemplo, acrescentar memória). A escalabilidade horizontal, ou escalar para fora, significa adicionar mais servidores.

O problema aqui é que as decisões de projeto não afetam todos esses fatores de desempenho de forma igual. Digamos que temos dois sistemas de software rodando em um servidor: a capacidade do Peixe-Espada é de 20 tps, enquanto a do Camelo é de 40 tps. Qual dos dois tem melhor desempenho? Qual é mais escalável? Não podemos responder a questão de escalabilidade com estes dados, e a única coisa que podemos dizer é que o Camelo é mais eficiente em um único servidor. Se adicionarmos outro servidor, percebemos que o Peixe-Espada agora trata 35 tps, e o camelo 50 tps. A capacidade do Camelo ainda é melhor, mas parece que o Peixe-Espada pode ter melhor escalabilidade. Se continuarmos adicionando servidores, descobriremos que o Peixe-Espada obtém 15 tps por servidor adicional e que o Camelo obtém 10. Com esses dados, podemos dizer que o Peixe-Espada tem uma melhor escalabilidade horizontal, ainda que o Camelo seja mais eficiente com menos de cinco servidores.

Os projetistas muitas vezes fazem coisas complicadas que aumentam a capacidade de uma plataforma específica de hardware quando, em verdade, poderia ser mais barato comprar mais hardwares. Se o Camelo tem um custo maior do que o Peixe-Espada, e esse custo maior é equivalente a um par de servidores, então o Peixe-Espada acaba sendo mais barato, mesmo se você precisar de apenas 40 tps. Está na moda reclamar por ter que depender de hardware melhor para fazer o nosso software rodar apropriadamente. No entanto, adquirir hardware mais novo é com freqüência mais barato do que fazer o software rodar em sistemas menos poderosos. De forma semelhante, adicionar mais servidores é freqüentemente mais barato do que adicionar mais programadores – desde que o sistema seja escalável.

Twitter!

Se você já gostava do blog da DClick porque acredita que pode encontrar aqui conteúdo de qualidade sobre RIA e Desenvolvimento de Software em geral, imagine agora, toda semana, ter um resumo dos posts em forma de Podcast que lhe ajudará escolher melhor os posts que mais lhe interessam?

Esta é a idéia do Agon News. Toda sexta as pessoas que fizeram pontos do Round farão um bate papo sobre seus posts, goods ou screencasts.

O primeiro fizemos em forma de Screencast mas acabamos percebendo que o que temos mesmo é um Podcast. Então, confira abaixo o primeiro episódio do Agon News.

Ah, quero ver se você descobre qual é a música que toca no início e no final.

O nome “Pensamento Lean” nasceu nos anos 90 com o lançamento do best seller The Machine That Changed the World : The Story of Lean Production.  Os princípios de demanda puxada, just-in-time, qualidade total, melhoria contínua e flexibilidade aplicados na indústria japonesa, mais precisamente na Toyota e conhecidos como Toyota Way inspiraram também a indústria de software e fez surgir a abordagem do Lean Software Development

O Lean Software Development provê uma série de princípios sobre a aplicação de um conjunto de técnicas oriundas da indústria e aplicadas em desenvolvimento de software. Esses princípios foram amplamente adotados na manufatura japonesa onde vieram a ser conhecidos como “Lean Production“.

Nesse contexto, Mary e Tom Poppendieck identificaram sete princípios fundamentais denominados “Lean Principles” e mostraram como eles podem ser aplicados em abordagens de desenvolvimento de software ágil.  Ao longo dos princípios, eles introduziram também e vinte e dois “thinking tools” para traduzir cada princípio em práticas ágeis, em particular eles apresentaram um toolkit para gerentes, lideres técnicos e gerentes de tecnologia que esperam adicionar valor ao invés de criarem barreiras para suas equipes de projetos, como os a seguir:

• Melhoria contínua em direção à excelência: desenvolvimento de software é como um exercício de descoberta.
• Gerenciando incertezas: “decidir o mais tardio possível” para adicionar mudanças dentro do sistema.
• Reduzindo o fluxo de valor: desenvolvimento rápido, feedback, e melhorias contínua.
• Dê autonomia ao time e ao indivíduo sem coordenação e comando-controle.
• Software com qualidade: promovendo coerência, usabilidade, alta coesão, manutenabilidade e adaptabilidade.

Princípio 1: Elimine o Desperdício

Elimine qualquer coisa que não agrega valor ao produto e que não são percebidos pelo cliente. No pensamento Lean, o conceito de desperdício é um grande obstáculo. Se um programador implementa mais funcionalidades do que o necessário de imediato, isso é um desperdício.  Se a equipe produz documentação de análise apenas para estar em concordância com o processo, isso é um desperdício. Se o time entrega funcionalidades incompletas, isso é um desperdício. O ideal é perceber o que os clientes precisam para então fazer ou desenvolver e entregar exatamente o que eles querem, o mais rápido possível. Qualquer outra coisa que fica que não satisfaça as necessidades do cliente é um desperdício.

Princípio 2: Amplifique o Aprendizado

Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de redução de variações, e por essa razão, aprender a abordagem de desenvolvimento resultam em práticas que são bastante diferentes do que aprender abordagens de práticas de produção.

Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas a partir da experiência de chefes de cozinha. Desenvolver uma receita é um processo de descoberta, onde o chefe utilizando de toda sua experiência e dos ingredientes a sua disposição faz iterações, experimentações, até encontrar a melhor combinação de ingrediente para o melhor sabor. Não se espera que os chefes obtenham uma receita perfeita na primeira tentativa; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é concebido de forma melhor com um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pelo conhecimento amplificado, em um espiral de criação do conhecimento.

Princípio 3: Decida o Mais Tarde Possível

Práticas de desenvolvimento que assegurem a tomada de decisão tardia são mais eficazes em domínios que envolvem incertezas. Decidir o mais tarde possível significa manter suas opções aberta o maior tempo possível. O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. A principal estratégia de atrasar as decisões em um desenvolvimento de um sistema complexo é construí-lo com a capacidade de suportar mudanças.

Princípio 4: Entregue o Mais Rápido Possível

Sem entregas rápidas é impossível haver decisões tardias durante o desenvolvimento. Sem entregas rápidas não haverá feedbacks confiáveis no curto prazo.  No desenvolvimento o ciclo de descoberta é fundamental para a aprendizagem: estórias, implementação, feedback e melhorias. Quanto menor esse ciclo, mais pode ser aprendido.

Uma vez que os clientes decidam o que querem, seu objetivo deve ser para criar esse valor tão rapidamente quanto possível. Entregas rápidas garante que o cliente vai ter o que ele precisa hoje, e não o que ele precisa amanhã.

Em uma organização madura em desenvolvimento de software, tudo isso acontece em um fluxo rápido em resposta a uma necessidade dos clientes.

Princípio 5: Dê autonomia à Equipe

“Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.” Esse já é um dos doze princípios por atrás do manifesto ágil. A equipe de trabalho deve ter autonomia para adequar seus próprios processos de engenharia, fazer os seus próprios compromissos e reunir as informações necessárias para alcançar seus objetivos e cumprir as suas metas. Equipes autônomas são multidisciplinares, possuem indivíduos multidisciplinares, trabalham bem com a interdisciplinaridade  e promovem a autor organização. Nesse tipo de equipe mais um princípio ágil é adicionado: “em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.”

Nesse ambiente, a equipe de desenvolvimento está em melhor posição para saber responder a problemas difíceis e a pedidos urgentes. A melhor maneira de ter certeza de estar fazendo as coisas corretas é trabalhar diretamente com o cliente para entender suas necessidades, colaborar com os colegas para descobrir como satisfazer essas necessidades, e, frequentemente apresentar os resultados aos interessados para ter certeza de que estamos no caminho certo.

Princípio 6: Construa com Integridade

Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus cliente, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coeso. Ela é fator crítico de sucesso para a integridade percebida.

Um produto é considerado ter integridade percebida quando o cliente experimenta o produto e diz: Isso! Era exatamente isso que eu queria! Esse exemplo acontece com frequencia em aplicações do google. Eu particularmente senti isso quando experimentei o novo recurso de caixa prioritária do gmail.

Um produto de software deve estar sempre adicionando integridade. Isso prolonga o seu ciclo de vida operacional. Software com integridade possuem boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender.

Princípio 7: Visualize o Todo

Integridade em sistemas complexo exigem um conhecimento holístico e profundo em diversas áreas. Um dos problemas mais intratáveis com o desenvolvimento do produto é que especialistas em qualquer área (por exemplo, banco de dados ou design) têm uma tendência natural em maximizar o desempenho da parte do produto que representa a sua própria especialidade, ao invés de focar no desempenho do sistema como um todo. Muitas vezes, a integridade do produto como um todo pode ser prejudicado se as pessoas atenderem aos seus próprios interesses especializados em primeiro lugar.

Foque na conformidade com o produto e não na conformidade com processo.

Em desenvolvimento de software não existe mágica, não existe bala de prata, não existe nenhuma conformidade processual que garanta um produto conforme.  Existe, no entanto, um ambiente de descoberta, aprendizado e melhoria constante. Um ambiente formado por pessoas, que praticam socialização, externalização, combinação e internalização em um espiral contínuo de criação de conhecimento, em nível individual, do grupo, e organizacional.  Desenvolvimento de Software pode ser encarado como um jogo cooperativo infinito onde, além de sua atividades de engenharia, também deve ser encarado como uma atividade de ciências humanas, acima das questões técnicas e puramente lógicas. Existem pessoas envolvidas no processo; as que criam e as que usam o software.  A interação entre elas é um dos principais fatores críticos de sucesso para alcançar a conformidade com o produto.

Um dos princípios do manifesto ágil já afirma que “Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.” e um dos valores do manifesto completa que “Indivíduos e interação entre eles mais que processos e ferramentas“. Em desenvolvimento de software, o foco deve ser mais no produto e menos no processo. Os esforços devem ser desprendidos para alcançar a conformidade com o produto e nem tanto com a conformidade de processo. O processo é o meio para alcançar o produto. Elimine qualquer coisa que não agrega valor ao produto e que não são percebidos pelo cliente. Elimine o desperdício, simplifique e aceite mais um princípio ágil: “simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.” Segundo o pensamento Lean, existem alguns desperdícios clássicos em desenvolvimento de software, a seguir:

• Trabalho parcialmente feito  (o “inventário” de um processo de desenvolvimento)
• Processos extra (fáceis de encontrar no desenvolvimento centrado em documentação)
• Funcionalidades extras (desenvolvem-se apenas o que os clientes querem agora)
• Troca de tarefas (todos devem fazer uma coisa de cada vez)
• Espera (para instruções, para mais informações, típico em ambiente comando-controle)
• Handoffs (toneladas de conhecimento tácito se perde)
• Defeitos (pelo menos defeitos que não são rapidamente capturados por um teste)

Manter a conformidade com processo de desenvolvimento formais, tradicionais, prescritivos e centrado em documentação implica em um problema que está muito além de afirmações de serem burocráticos, waterfall, rígido, etc.  O principal problema é o auto custo de se manter esse tipo de processo. Processo formal é caro, manter a conformidade com o processo é caro, manter conformidade de documentação é caro, manter uma equipe de Quality Assurance é caro e fazer alterações de requisitos no meio do projeto é mais caro ainda.  Processo de desenvolvimento de software baseado em modelos de maturidade como CMMI e MPS-BR só podem ser considerados maduros se houver uma equipe de Quality Assurance atuante, autônoma e não condicionada. Sem Quality Assurance nesse tipo de abordagem grande parte dos esforços no desenvolvimento do produto em conformidade com o processo é puro desperdício. O que se espera desse tipo de processo, como em qualquer processo, é um ciclo de melhoria contínua a fim eliminar paulatinamente qualquer fonte de desperdício, e por mais incrível que pareça, as referidas fontes de desperdício acabam sendo em atividades redundantes e sobretudo em atividades da equipe de Quality Assurance. Quando uma equipe formal chega nesse nível significa que ela está madura. Quanto mais madura a equipe, menos atividades de inspeção e verificação são necessárias para garantir a conformidade com o processo e mais esforços podem ser realocado para garantir a conformidade do produto.

Em métodos ágeis, a conformidade com o produto é uma premissa, talvez seja por isso que são chamados de ágeis, e podem ser  observados no próprio manifesto ágil e em seus doze princípios.  As referidas premissas também podem ser observadas nos princípios do pensamento Lean, nos valores e práticas do eXtreme Programming, no jogo cooperativo do Crystal e nas cerimônias do Scrum.

Independente da abordagem, o que importa é “satisfazer o cliente, através da entrega adiantada e contínua de software de valor“. No entanto, no caminho para alcançar esse objetivo, as empresas que desenvolvem software tem que lidar com clientes lidam diariamente com o caos, e freqüentes mudanças operacionais. Esse ambiente em constante mutação gera novas oportunidades e novas demandas dos clientes. O processo tem que ser flexível, melhorado continuamente  para atender as essas “oportunidades”, focando sempre na satisfação do cliente e embarcando conhecimento em conformidade com o  produto.

Ontem, 1º de Setembro de 2010, foi realizado o 1º #HoraExtra Ágil de Curitiba.

Primeiramente quero agradecer a todos que foram ao #HoraExtra, e dizer para você que não foi, “PERDEU”!

No #HoraExtra foram discutidos vários temas onde o foco central ficou sempre em “PESSOAS” e como melhor gerenciar o maior ativo das empresas.

Como essa foi a primeira edição, lógico que algumas coisas foram esquecidas, como por exemplo câmera fotográfica, e bloco de anotações para os papos relevantes, epic fail, mas vou tentar lembrar de alguns.

Começamos conversando sobre o conceito ágil em Desenvolvimento de Software, Scrums e afins, o papo evoluiu para o Kanban, e comparamos com o Kanban de fábrica, a origem do Kanban em software.

X

Passado um tempo o papo foi para o lado das métricas de velocidade de times ágeis, com a seguinte pergunta: Você, gerente ágil recém chegado para facilitar um time que você desconhece, quais métricas você pediria para conhecer de modo geral a capacidade do time?

Depois aproveitamos a experiência internacional de vários participantes para discutir a diferença cultural entre os profissionais brasileiros e europeus.

E o encontro encerrou com o debate sobre a Geração Y e a liberdade de internet para os funcionários, os gerentes comando-controle, como treinar os colaborados para utilizar com consciência os recursos fornecidos pela empresa ao invés da punição pura e simples.