É com uma grande satisfação que venho anunciar, que o meu artigo em conjunto com Eduardo Guerra e Alisson Palmeira sobre Arquitetura Orientada a Serviços (SOA) para o Suporte a Interoperabilidade de Aplicação de Comando e Controle (C2), baseado em um projeto SOA que trabalho a 2 anos, foi aceito no XII Simpósio de Aplicações Operacionais em Áreas de Defesa (SIGE), realizado anualmente pelo Instituto Tecnológico de Aeronáutica – ITA.
O SIGE é um evento internacional cujo objetivo é criar um ambiente adequado à troca de experiências entre setores da sociedade civil e militar, interessados em pesquisa e desenvolvimento no âmbito da Política de Defesa Nacional.
Mais informações: http://www.sige.ita.br/
Dando continuidade a série sobre Behavior-Driven Development, vou abordar agora sobre como começar a praticá-lo, com o apoio do JBehave.
O JBehave é um framework open-source estável e intuitivo para pensar em comportamentos de softwares através de User Stories e Cenários de Teste de Aceitação.
Para entendê-lo, nada melhor como um exemplo simples, claro e objetivo.
Supondo que nossa aplicação seja para transações bancárias. Vamos imaginar um dos seguintes comportamentos esperados pela nossa aplicação, na forma de uma User Story (estória).
User Story: Realizar Saque
Eu como um correntista do banco
Quero ser capaz de realizar um saque, caso eu tenha saldo disponível
Para que eu consiga para minhas contas.
Agora, vamos imaginar dois cenários para validarem esse comportamento esperado.
Cenário de Aceitação 1: Realizar Saque com Saldo Suficiente
Dado que eu sou um correntista do banco
Quando eu solicitar o saque no valor de 100.0 reais e tiver na minha conta um saldo de 500.0 reais
Então o saldo da conta devera ficar com 400.0 reais
Cenário de Aceitação 2: Realizar Saque com Saldo Insuficiente
Dado que eu sou um correntista do banco
Quando eu solicitar o saque no valor de 300.0 reais e tiver na minha conta um saldo de 200.0 reais
Então o saldo da conta devera ficar com 200.0 reais
Agora, para converter esta estória e cenários em algo executável, para iniciarmos o nosso desenvolvimento guiado por comportamento. Vamos seguir os seguintes passos.
Passo 1: Crie um arquivo texto, denominado “realizar_saque”, conforme exemplo abaixo:
Nota: Repare os termos em negrito: Story, Scenario, Given, When e Then. Eles são termos reservados do JBehave, que podem ser traduzidos (mas isso fica para outro post), e que em português significam respectivamente: Estória, Cenário, Dado Que, Quando e Então. Percebeu alguma semelhança com a descrição dos comportamentos iniciais? Pois é, continua praticamente a mesma coisa.
Passo 2: Crie agora uma classe como o mesmo nome dado ao arquivo do Passo 1, sem as “_”, RealizarSaque.java. Conforme exemplo abaixo:
Nota: Repare que essa classe herda de org.jbehave.scenario.Scenario. Ou seja, ela será responsável por executar o cenários de testes comportamentais descritos no arquivo do Passo 1.
Passo 3: Execute a classe RealizarSaque.java como uma JUnitTest, e veremos no console o seguinte resultado:
Nota: Essas mensagens de pendentes, informam que não foi encontrado nenhum dos passos para execução dos cenários informados no arquivo “realizar_saque”. Vamos implementá-los então.
Passo 4: Antes, vamos criar uma classe ContaCorrente.java, conforme exemplo abaixo:
Passo 5: Agora vamos criar os passos que devem ser executados, com base nos cenários de aceitação descritos acima. Veja o exemplo abaixo:
Nota: Os tokens nas strings que possuem o caracter $, atuam como elos entre o valores do arquivo “realizar_saque” e as variáveis de entrada dos métodos.
Nota: No código acima eu utilizei a biblioteca open-source para Java denominada FEST, que tem como missão simplificar nossos testes de software.
Passo 6: Altere novamente a classe RealizarSaque.java, deixando-a conforme exemplo abaixo:
Passo 7: Agora, vamos executar a classe RealizarSaque.java, e teremos no console o seguinte resultado:
Nota: Caso alguns dos passos falhem, teremos o seguinte resultado do console abaixo. No caso, o passo When falhou e por isso, o passo Then nem executou.
Como podemos perceber, com os testes automatizados guiados por comportamentos, fica muito mais fácil entender o que o nosso software deve fazer antes da implementarmos, e depois entender o que ele está fazendo, ou melhor, se comportando após as implementações.
Além disso, por sua boa legibilidade nos resultados, facilita e muito a comunicação com todos os envolvidos do projeto. Até porque, o início do processo (criação do arquivo com os cenários de aceitação) pode ser feito pelos usuários chaves, depois implementados pelos programadores, e novamente vistos pelos usuários chaves. Em suma, envolvimento de todos acontece de ponta-a-ponta na cadeia de desenvolvimento.
Em breve, mais recursos sensacionais do JBehave. Aguardem.
Abs.
No post “Você continua usando TDD para testes? Você está com sérios problemas”, comentei que o problema ou confusão na adoção da prática Test-Driven Development (TDD) para testar é justamente a palavra “Test”. Já que TDD é uma técnica para aprimorar o Design e não para realização de testes.
Mesmo assim, ainda vejo várias empresas ou equipes tentando utilizar TDD para testar seus softwares. E em todos estes casos constatei um grande problema nesta adoção: A dificuldade em fazer as classes ou componentes de testes, escritas pelos desenvolvedores em ferramentas como JUnit ou similares, compreensíveis para todos envolvidos do projeto.
Ou seja, o problema não é a prática TDD em si, mas sim o público alvo que ela se propoe trabalhar, ou seja, desenvolvedores. Com isto, uma prática de testes somente pode ser considera assim, se os gestores, analistas, equipes de qualidade e principalmente os clientes, são capazes de compreendê-la. E é aqui que Behavior-Driven Development vem agregar.
O Behavior-Driven Development (BDD), ou desenvolvimento guiado pelo comportamento, nasceu para tentar desacoplar a TDD do mundo dos testes, trazendo para ele a responsabilidade de testar o software.
Nesta série sobre BDD eu não vou discorrer sobre sua origem e motivações iniciais para sua criação. Quem estiver interessado sobre esses aspectos histórico, eu sugiro ler a própria descrição do autor Dan North.
O grande poder do BDD é justamente na amplicação do público alvo, permitindo que todos os envolvidos no projeto possam utilizar a mesma fonte (comportamentos esperados do sistema), para a partir dela realizar os seus trabalhos. Veja figura abaixo.
Para alcançar isso, o BDD encherga que tudo em um dado software é um comportamento, que entrega valor ao negócio. Ou seja, tanto as pessoas de negócios quanto as de TI devem referir ao software em questão de uma mesma forma: comportamentos promovidos por uma linguagem ubíqua ou onipresente, e que estes comportamentos sejam verificadores do valor para o negócio.
Os comportamentos são necessidades que seu software deve fazer para gerar algum valor ao negócio e satisfazer seus usuários chaves. Já os valores de negócio serão essênciais para direcionar a prioridade dos comportamentos a serem contemplados em seu plano de entrega.
Se você é adepto de práticas ágeis e utiliza User Stories, vai ficar mais fácil entender o que são os comportamentos. Mas antes, vamos relembrar a lei de formação das User Stories, baseada nos 3 C’s:
- Card (Cartão) – A descrição escrita da estória;
- Conversation (Conversação) – Uma estória é um convite para uma conversa. Este C, representa o diálogo entre os membros de um time sobre uma estória, notas e documentações complementares;
- Confirmation (Confirmação) – São os critérios do teste de aceitação que dirão se a estória está completa ou não.
Logo, os comportamentos são os critérios dos testes de aceitação de cada User Story. Veja esse decomposição na figura abaixo.
Eu vejo o BDD como uma excelente prática para suportar os métodos de desenvolvimento ágeis de ponta-a-ponta. Com ele, é possível suportar desde a análise ágil, com nossos usuários chaves ou analistas de negócios escrevendo os cenários, até a automação dos testes de aceitação. Ou seja, vejo o BDD como um estrutura fractal para apoiar desde a análise até a codificação eficiênte e pragmática.
No próximo post desta série, irei detalhar ainda mais os conceitos aqui descritos e como implantá-los com apoio de alguns frameworks open-source.
Até lá. E bons projetos.
Neste exato momento, sei que muitos estão trabalhando com SOA e outros irão começar algum projeto SOA. Então, antes de eu começar a publicar os posts direcionados a SOA, descrevendo as minhas experiências e recomendações, deixo aqui a minha contribuição na língua portuguesa do Manifesto SOA, no qual eu assino embaixo e sempre tive como premissa nos projeto que atuei.
Em breve, voltaremos a falar sobre esses princípios na minhas experiências em projeto SOA. Desfrutem do Manifesto.
Manifesto SOA
A Orientação a Serviços é um paradigma que molda o que você faz.
A Arquitetura Orientada a Serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação a serviços.
Temos aplicado a orientação a serviços para ajudar as organizações a entregarem valor aos negócios de forma consistente, de maneira sustentada, com maior agilidade e custo-benefício, alinhado com as necessidades de negócio.
Através do nosso trabalho, temos priorizado:
O Valor de Negócio mais que a estratégia técnica.
As Metas Estratégicas mais que os benefícios específicos dos projetos.
A Interoperabilidade Intríseca mais que a integração personalizada.
Os Serviços Compartilhados mais que as implementações de propósito específico.
A Flexibilidade mais que a otimização.
O Refinamento Evolutivo mais que a busca da perfeição inicial.
Isto significa que enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.
Princípios
Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção SOA pode variar. Devemos manter os seus esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe levará à SOA, nem aplicarão para você, o paradigma de orientação à serviços.
SOA pode ser alcançado através de uma variedade de tecnologias e padrões.
Estabelecer um conjunto uniforme de polítcas e padrões corporativos baseado em padrões da indústria, padrões de facto, e padrões da comunidade.
Buscar a uniformidade no exterior a medida que permita diversidade no interior.
Identificar os serviços através da colaboração de pessoas de negócios e de tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro da organização.
Verificar se os serviços satisfazem as metas e os requisitos de negócio.
Evoluir os serviços da organização em resposta ao seu real uso.
Separar os diferentes aspectos do sistema para mudar em velocidades diferentes.
Reduzir as dependências implícitas e publicar as dependências externas para aumentar a robustez e reduzir o impacto das mudanças.
Em qualquer nível de abstração, organizar cada serviço em torno de unidades functionais coesas e gerenciáveis.
Minha motivação para escrever post, partiu da percepção que até hoje muitos caíram e outros continuam caíndo na armadilha da palavra “Test” ao adotar a prática Test-Driven Development (TDD). Por que armadilha? Pois a palavra “Test”, em engenharia de software, sempre nos faz pensar no primeiro momento, em atividades para garantir a qualidade (Quality Assurance) do software que estamos produzindo ou mantendo.
Para quem entendeu bem o conceito da TDD, perceberá que o mesmo não tem nada a ver com a disciplina de testes. O próprio Kent Beck, criador da TDD, uma vez falou: “TDD encoraja designs de código simples e inspira confiança”.
Na verdade, os testes unitários criados em TDD tem uma parcela de garantia de qualidade funcional, mas não é seu principal objetivo. O principal objetivo da TDD é ajudar no design dos seus códigos, promovendo a refatoração.
Nota: Vale destacar que por refatoração entende-se: “Mudar a implementação interna de um artefato de software, sem mudar seu comportamento desejado”.
Além disso, se você é um estudioso da prática TDD, já deve ter lido no site do Scott W. Ambler (caso contrário clique aqui) a seguinte frase: “What is the primary goal of TDD? Onde view is the goal of TDD is specification and not validation (Martin, Newkirk, and Kess 2003). In other words, it’s one way to think through your design before your write your functional code.”.
Percebeu? Mais uma vez: A TDD é sobre Design e não sobre Testes.
Se você ainda não está completamente convencido, dê uma olhada no próprio processo do TDD:
- Escreva um pequeno teste de um código que ainda não exista;
- Rode esse teste e, naturalmente, você perceberá que irá falhar;
- Agora escreva apenas o suficiente para fazer o teste passar;
- Quando o teste funcionar, observe o resultado do design e refatore para otimizar seu código, possível.
Repare que fiz questão de destacar em negrito/itálico o que devemos focar no final do processo TDD. É impressão minha ou não foi comentado nada sobre: “Verifique com seu especialista de domínio, analista de negócio, product owner, analista de teste ou QA, se o comportamento obtido está conforme desejado.”? É, não tem nada disso.
Com isto fica claro perceber, o porque que quando adotamos somente TDD as seguintes situações emergem durante o projeto:
- Quem desenvolve os componentes de testes unitários são os próprios desenvolvedores e não a equipe de quality assurance;
- Experimente entregar um componente de teste unitário para o analista de negócio, especialista de domínio ou product owener e espere ele dizer: “Mas que p%$#& é essa? Não consigo entender nada.”;
- Os bugs funcionais do projeto não diminuem. Pois é comum seus testes unitários estarem todos funcionando, mas sua ferramenta de gestão de bugs está lotada de pendências funcionais;
- Normalmente, seu cliente não aceita os componentes de testes unitários com entregável da disciplina de testes.
Uma vez, em 2002, um professor meu de Engenharia de Software da UFPA falou: “Softwares sem constantes refatorações, virarão hardwares com passar do tempo”. E isto ficou na minha cabeça até hoje, como premissa em qualquer projeto que participei.
Em suma, vejo a prática TDD como uma das que compõe o alicerce para atendimento do princípio: “Contínua atenção à excelência técnica e bom design, aumenta a agilidade”, presente no Manifesto Ágil. Ou seja, use-a para promover melhorias nos seus códigos e para identificar padrões arquiteturais emergentes na sua arquitetura. Não a adote em substituição às outras práticas de garantia de qualidade, pois isto será tão negativo quanto não ter nenhum controle de qualidade em seu projeto.
Bons designs… 
A Análise Kano, apesar de não ser uma técnica nova (publicada na década de 80), vem novamente ganhando força com o direcionamento dos métodos de gestão e engenharia de software para maximizar a entrega de valor para os clientes, ou seja, entregar aquilo que realmente os clientes precisam sem perder tempo em requisitos fantasiosos, que no final das contas nunca ou dificilmente serão usados.
Este post está organizado da seguinte forma: Uma breve introdução sobre a Análise Kano; A Técnica e seus passos; E, a conclusão com alguns benefícios que obtive ao aplicá-lo em algum projeto.
Breve Introdução
Nota: Antes de começarmos gostaria de resumir os termos funcionalidades, estórias de usuário, temas e épicos, na palavra requisitos. Ok? Então, quando eu usar requisito no texto abaixo, qualquer uma delas está valendo.
A Análise Kano oferece um mecanismo de priorização de requisitos através do nível de satisfação dos usuários chaves. Ou seja, esta técnica visa nos ajudar a identificar e priorizar aquilo que devemos entregar para o nosso cliente, de forma que melhor o satisfaz e que traga um retorno do investimento.
Vale destacar que essa técnica é recomendada quando você possui uma quantidade elevada de usuários chaves. Normalmente, eu aplico quando tenho mais do que 8 usuários chaves. Você entederá o porque disso, no passo 2 da explicação dessa técnica.
Quem estiver interessado em aprofundar mais sobre o assunto, segue uma referência: http://www.kanomodel.com/
Para entendermos como identificar esse nível de satisfação, a Análise Kano classifica os requisitos em basicamente quatro categorias:
Nota: Para facilitar o entendimento, vou assumir que o nosso produto é um carro.
- Devem ser feitos (Must be): São aqueles requisitos que foram explicitamente solicitados pelo usuário e caso não sejam contemplados, não teremos chances de convencê-lo a usar o nosso produto.
- Atrativos (Attractive): São aqueles requisitos que o usuário não falou verbalmente ou não imaginou até vê-las, gerando nele um sentimento de surpresa positiva. São estas as funcionalidades que torna o seu produto diferenciado em relação aos concorrentes.
- Quanto mais melhor (More is better): São aqueles requisitos que quanto mais existirem, melhor para satisfazer o usuário. Exemplo:
- Indiferente (Indefferent): São aqueles requisitos que tanto faz estar presente no produto ou não.
- Não devem ter (Reverse): São aqueles requisitos que não agradam a grande maioria, gerando mais insatisfação do que a satisfação, em virtude de afetarem a produtividade, gerarem mais burocracia e etc.
A Técnica
De posse e entendimento da classificação dos requisitos propostos por Kano, vamos aprofundar na técnica de priorização utilizando essa classificação, adotando os seguintes passos:
- Passo1: Classificação de Satisfação do Requisito
Para cada requisito identificado, devemos realizar duas perguntas para cada usuário chave do projeto. Lembrem-se: É muito importante perguntar para cada usuário chave. São elas:
- Pergunta Funcional: Como você se sentirá, se o requisito estiver presente no produto?
- Pergunta Disfuncional: Como você se sentirá, se o requisito não estiver presente no produto?
Iremos perceber com a aplicação desta prática, que as respostas para ambas as perguntas, sobre um mesmo requisito, podem tanto ser extramente claras quanto conflitantes. Até porque, estamos em um estágio subjetivo.
Para evitar perdas de temp, e dar um caráter mais objetivo à prática, podemos fazer um referência cruzada com base no quadro abaixo para classificar cada requisito. Neste quadro, estão algumas palavras que o usuário chave pode incluir na sua resposta que irá nos ajudar na classificação.
Legendas: A – Atrativos; D – Devem ser feitos; N – Não devem ser feitos; Q – Quanto mais melhor; I – Indiferente; ? – Questionável (o requisito ainda não está claro).
Obs: Enquanto o requisito estiver convergindo para “? – Questionável”, você deve realizar um trabalho de maior entendimento do mesmo ou até mesmo quebrá-lo em requisitos menores.
Para facilitar, vamos para um exemplo de utilização do quadro acima:
Requisito: “Termômetro de temperatura em uma lata de cerveja.”
-> Pergunta Funcional: Como você se sentirá ao ver um termômetro de temperatura na latinha de cerveja? Digamos que o usuário chave responda: Me agradaria.
-> Pergunta Disfuncional: Como você se sentirá em não ver um termômetro de temperatura na latinha de cerveja? Digamos que o usuário chave responda: Eu posso conviver sem isso.
Pelo cruzamente de ambas as respostas em nosso quadro, este requisito é classificado como Atrativo (A).
- Passo2: Priorização dos Requisito Classificados
Entendido o primeiro passo, devemos repeti-lo para cada requisito e para cada usuário chave, de forma que possamos realizar uma coleta quantitativa do nível e satisfação de cada requisito. Com isto, poderemos priorizar quais funcionalidades deveremos focar para satisfazer e gerar valor para os usuários.
Segue abaixo, um exemplo da coleta quantitativa após a realização do primeiro passo com todos os requisitos e usuários chaves (totalizando 20 usuários).
Neste simples exemplo, podemos perceber que os dois últimos requisitos devem ser priorizados para confecção. Enquanto que o primeiro, se possível ser feito, gerará uma enorme satisfação e diferenciação do nosso produto, porém caso não venha ser contemplado, não afetará a satisfação (ou aceite) dos nossos usuários.
Conclusão
A Análise Kano nos oferece uma boa forma para priorizar nossos requisitos, independente se estamos utilizando algum método ágil ou não. No caso do método ágil Scrum, termos um Product Backlog com uma priorização direcionada por valor de negócio e satisfação dos stakeholders é essêncial para o sucesso do projeto, e Análise Kano pode ser muito útil.
Minhas experiências na utilização da Análise Kano, pude obter os seguintes benefícios:
- Democratização da opinião de cada usuário chave, onde cada um foi capaz de expressar seu nível de satisfação para cada requisito de forma objetiva;
- Rápida identificação de quais requisitos são obrigatórios e essênciais, onde a equipe pode concentrar neles durante as primeiras iterações (sprints);
- Promoveu uma interação saudável com cada usuário chave;
- Foi possível perceber que certos requisitos não seriam necessário logo no início do projeto.
Em suma, a Análise Kano é uma ótima opção para a priorização dos requisitos do seu projeto. Usá-lo lhe trará bons benefícios.
Entretanto, a Análise Kano não é “bala de prata”. Com isto, nos próximos posts irei abordar algumas outras técnicas de priorização que podem ser combinadas para gerar ainda mais benefícios nos seus projetos, principalmente quando existem poucos usuários chaves.
Até lá, e bons planejamentos.
