Vaga para atuar com EAI/SOA/JEE – Rio de Janeiro

Pessoal, estou precisando de pessoas para trabalhar no meu time para a seguinte oportunidade:

Empresa:
Ideais Tecnologia – Classificada como uma das 30 Melhores Empresas para Trabalhar no Rio de Janeiro (Great Place to Work)

Descrição:

Atuar no desenvolvimento e aprimoramento de arquiteturas de software, com aplicações heterogêneas e que requerem alta disponibilidade, escalabilidade e que envolvem componentes distribuídos

Atribuições: 

- Analisar problemas em ambiente de produção em cima de uma arquitetura orientada a serviços
- Desenvolvimento de aplicações em Java (JEE) utilizando melhores práticas e frameworks e considerando questões como escalabilidade, concorrência, disponibilidade, componentes distribuídos, controle transacional
- Ser capaz de bolar soluções em cima de problemas existentes
- Modelagem e criação de processos utilizando BPEL
- Condução de POC’s e iniciativas em cima de novos assuntos, tecnologias e conceitos
- Implantação e acompanhamento de soluções junto ao cliente
- Análise de requisitos (funcionais, de negócio e não funcionais)
- Desenvolvimento de ferramentas de integração utilizando padrões arquiteturais (EAI)
- Modelagem de dados e modelos canônicos
- Criação de fluxos de integração utilizando Enterprise Service Bus

Benefícios para conhecimento:

- Trabalho com grande envolvimento junto ao cliente, inclusive na tomada de decisões e planejamento de soluções
- Acesso e participação a base de conhecimento gerada pelo time de integração
- LABS
- Grupos de estudos
- DOJO e Hackathon
- Oportunidade para trabalhar em iniciativas de pré-venda, caso tenha interesse
- Participação em eventos no Brasil e exterior
- Incentivo para certificações e treinamentos
- Vivência em equipes ágeis

Ambiente de trabalho:

- Snacks liberados
- Bebidas liberadas (refrigerante, suco, mate, etc)
- Video-game (Playstation 3 + xBox)
- Shiatsu
- Bermuda liberada (sexta-feira e feriados :)

Local de Trabalho:

Centro – Rio de Janeiro

Contato:

Enviar currículo para:

Taymara Mello (taymara.mello@ideais.com.br)
Assunto: Oportunidade EAI/SOA

Carreira & Profissão

Fale sobre soluções, não sobre ferramentas

Tenho trabalhado nos últimos anos com alguns conceitos como SOA e BPM e desde então sempre tive a preocupação de estudar, pesquisar e me informar sobre esses assuntos. Entender os conceitos, o que está por trás, quando usar, acompanhar casos reais, a evolução, enfim, entender verdadeiramente os fundamentos de BPM e SOA.

Infelizmente, vejo que no mercado, pelo menos o nacional, as coisas não funcionam dessa maneira, onde a maioria dos profissionais estão preocupados muito mais com ferramentas do que com soluções, o que é muito preocupante, pois esse é o fator principal, no meu modo de ver, que faz a adoção de BPM e SOA quase sempre serem associadas ao insucesso dos projetos.

Recentemente, tive mais uma prova disso, onde participando de um treinamento em cima de uma ferramenta de BPM (BPMS) observei que os participantes estavam muito mais preocupados em entender a ferramenta, o que tem de novo, como fazer tal coisa, do que pensar no porque elas precisam daquela ferramenta e de todos aqueles recursos maravilhosos. Ouvi algumas coisas realmente impressionantes como “Fulano trabalha com SOA, desde que SOA chegou no Brasil”. Ahn?! Como assim?! SOA é um produto? É um software de caixinha para ter chegado no Brasil? Isso é realmente preocupante.

Os grande players vendedores dessas soluções, como Oracle, IBM, SAP, TIBCO, etc.. tem uma parcela de culpa nisso, pois vendem (e como é fácil vender!) as suas ferramentas como as novas maravilhas do mundo moderno, mas não explicam o principal: para usar SOA e BPM as organizações precisam mudar a sua maneira de pensar, a maneira de enxergar os seus negócios, pois sem isso, pode ser com a ferramenta que for, qualquer projeto estará fadado ao fracasso. E afirmo isso sem exagero algum. Já temos muitos casos no Brasil que comprovam isso, afinal, qual case de SOA ou BPM é realmente um exemplo por aqui? Dos que já tive a oportunidade de ver no Gartner, acho que não vi nenhum no Brasil.

Mas é óbvio que nós, profissionais do meio, somos os maiores culpados. Como profissionais, temos o dever de estudar e entender tudo que está por trás de SOA e BPM, precisamos ter claro na nossa cabeça, que ferramentas são apenas um dos meios para para viabilizar estratégias de SOA e BPM, mas não devem ser o fim. É perfeitamente possível, por exemplo, ter um projeto BPM de sucesso sem que necessariamente haja um BPMS envolvido.

Não quero dizer com tudo isso, que as ferramentas são desnecessárias, óbvio que não, muitas delas são úteis, bem úteis por sinal. Um BPMS é um grande aliado para modelagem de processos, simulação a partir de métricas e indicadores e monitoramento. Assim como um Service Bus, é necessário para um catálogo de serviços bem definido, para ajudar na questão de governança e para implementar padrões de integração (EAI patterns). Mas ferramentas são, mais uma vez, um meio de se conseguir implementar um bom projeto de BPM e SOA e não o fim, esse é o grande ponto chave.

Hoje, muito dos profissionais que trabalham com BPM por exemplo, não tem a menor noção do que é um ciclo de vida de um projeto BPM, o que é AS IS e TO BE, o que são KPI’s e o pior: não estão nem um pouco alinhados com o negócio das organizações. Por sua vez, as organizações gastam milhões e milhões nessas ferramentas caríssimas e não tem uma pessoa (ou um escritório) responsável pelos processos, além não terem pessoas que entendem do próprio negócio da empresa trabalhando nesses projetos. SOA e BPM tem tudo haver com negócio, não com software!

E no final, aquela velha pergunta sobre o ROI, fica sem resposta. O que de processos foi construído que realmente agrega valor ao negócio? O que foi melhorado na rotina dos funcionários da empresa? O que foi otimizado no dia-a-dia daquele usuário? Qual era o resultado esperado e qual foi o obtido? Nenhuma dessas perguntas tem resposta!

BPMS oferecem recursos interessantíssimos como papéis, onde os analistas de negócio deveriam implementar e desenhar seus processos e os desenvolvedores apenas implementar o que deve ser automatizado em cima até de uma arquitetura orientada a serviços (SOA). Mas o que vemos, na maioria dos casos por aí, são organizações usando um BPMS como um meio de se construir software e não como uma maneira de fazer o famoso (e sonhado) alinhamento entre negócio e TI, não como uma maneira de gerar valor ao negócio.

Da mesma maneira, empresas que usam SOA, sabem muito pouco sobre design de serviços, quase nada sobre governança e não utilizam um dos principais conceitos de SOA que é a composição de serviços para gerar resultados mais rápidos de acordo com a demanda e a rapidez do seu negócio.

SOA, assim como BPM, virou apenas uma maneira mais corporativa de se construir aplicações e fazer software. Só que virou também uma maneira muito mais cara de se fazer isso.

BPM, Carreira & Profissão, SOA

Usando funções da Oracle com HSQLDB

Essa é uma dica simples e rápida para quem usa o banco de dados HSQLDB

No meu caso específico, uso o HSQLDB para execução de testes funcionais e como a maioria desses projetos usam BD Oracle para desenvolvimento/produção, algumas queries acabam por conter funções específicas do Oracle, como: to_char, to_date, etc.

Antes de dar a dica, é preciso dizer que esse recurso só funciona para as versões > 2.x do HSQLDB, portanto caso tentem usá-lo na versão 1.8 por exemplo, não será possível. Inclusive tive esse problema no meu projeto, pois como estou usando Grails 1.3.7, o framework por si só já vem com a dependência do HSQLDB 1.8 incluída por padrão e a solução encontrada para contornar isso foi usar o arquivo BuildConfig.groovy, primeiro removendo a dependência da versão 1.8 e depois incluindo a dependência da versão 2.x. Segue:

  1. grails.project.dependency.resolution = {   
  2.     inherits("global") {
  3. 		excludes([group: 'hsqldb', name: 'hsqldb', version:'1.8.0.10'])
  4. 	}
  5.  
  6.     log "warn"
  7.  
  8.     repositories {
  9. 		// Repositorios para os plugins do grails
  10. 		grailsHome()
  11. 		grailsRepo "http://plugins.grails.org"
  12. 		grailsRepo "http://svn.codehaus.org/grails/trunk/grails-plugins"
  13.  
  14. 		// Repositorio necessario pois o maven baixa as dependencias e o grails as encontra no repositorio local
  15. 		mavenLocal()
  16.  
  17. 		// Repositorios da Ideais
  18. 		mavenRepo "http://intranet/archiva/repository/internal/"
  19. 		mavenRepo "http://intranet/archiva/repository/ideais/"
  20. 		mavenRepo "http://intranet/archiva/repository/ideais-snapshots/"
  21. 		mavenRepo "http://intranet/archiva/repository/thirdparty/"
  22.  
  23. 		// Repositorio necessario para que o grails baixe suas proprias dependencias
  24. 		mavenCentral()
  25.     }
  26.  
  27.     dependencies {
  28. 		runtime(
  29. 			[group:'com.oracle', name:'ojdbc14', version:'10.2.0.3.0'],
  30. 		)
  31. 		compile(
  32. 			//Lib para criptografia/descriptografia/mascaramento de numeros de cartao de credito
  33. 			[group:'com.b2w.billing', name:'jsitef', version:'1.0'],
  34.  
  35. 			//Lib para resolver a dependencia do JAXB em ambiente de producao
  36. 			[group:'xalan', name:'serializer', version:'2.7.1'],
  37.  
  38. 			//Libs para o spring-ws plugin
  39. 			[group:'org.springframework.ws',name:'spring-ws',version:'1.5.8', transitive: false],
  40. 			[group:'javax.activation',name:'activation',version:'1.1.1', transitive: false],
  41. 			[group:'com.russmiles.groovy.webservices',name:'client',version:'1.0-SNAPSHOT', transitive: false],
  42. 			[group:'org.springframework.security', name:'spring-security-core', version:'2.0.4', transitive: false],
  43. 			[group:'javax.xml.soap', name:'saaj-api', version:'1.3', transitive: false],
  44. 			[group:'javax.xml.soap', name:'saaj-impl', version:'1.3.2', transitive: false],
  45. 			[group:'org.bouncycastle', name:'bcprov-jdk14', version:'1.43', transitive: false],
  46. 			[group:'stax', name:'stax-api', version:'1.0.2', transitive: false],
  47. 			[group:'wsdl4j', name:'wsdl4j', version:'1.6.2', transitive: false],
  48. 			[group:'org.apache.ws.security', name:'wss4j', version:'1.5.8', transitive: false],
  49. 			[group:'org.apache.ws.commons.schema', name:'XmlSchema', version:'1.4.5', transitive: false], 
  50. 			[group:'xml-security', name:'xmlsec', version:'1.4.3', transitive: false],
  51.  
  52. 			//Libs para o export plugin
  53. 			[group:'com.lowagie',name:'itext',version:'2.1.4', transitive: false],
  54. 			[group:'com.lowagie',name:'iTextAsian',version:'2.1.5', transitive: false],
  55. 			[group:'com.lowagie',name:'itext-rtf',version:'2.1.5', transitive: false],
  56. 			[group:'net.sourceforge.jexcelapi',name:'jxl',version:'ideais-commerce', transitive: false],
  57. 			[group:'org.openoffice.odf',name:'odfdom',version:'ideais-commerce', transitive: false],
  58. 			[group:'net.sf.opencsv',name:'opencsv',version:'1.8', transitive: false],
  59. 			[group:'xerces',name:'xercesImpl',version:'ideais-commerce', transitive: false],
  60.  
  61. 			//Libs para o WSClient
  62. 			[group:'org.codehaus.groovy.modules',name:'groovyws',version:'0.5.1', transitive: false],
  63. 			[group: 'org.apache.cxf', name: 'cxf-bundle', version: '2.2.4', transitive: false],
  64. 			[group: 'com.sun.xml.fastinfoset', name: 'FastInfoset', version: '1.2.7', transitive: false],
  65. 			[group: 'org.apache.geronimo.specs', name: 'geronimo-activation_1.1_spec', version: '1.0.2', transitive: false],
  66. 			[group: 'org.apache.geronimo.specs', name: 'geronimo-annotation_1.0_spec', version: '1.1.1', transitive: false],
  67. 			[group: 'org.apache.geronimo.specs', name: 'geronimo-javamail_1.4_spec', version: '1.6', transitive: false],
  68. 			[group: 'org.apache.geronimo.specs', name: 'geronimo-jaxws_2.1_spec', version: '1.0', transitive: false],
  69. 			[group: 'org.apache.geronimo.specs', name: 'geronimo-stax-api_1.0_spec', version: '1.0.1', transitive: false],
  70. 			[group: 'org.apache.geronimo.specs', name: 'geronimo-ws-metadata_2.0_spec', version: '1.1.2', transitive: false],
  71. 			[group: 'javax.xml', name: 'jaxb-api', version: '2.1', transitive: false],
  72. 			[group: 'com.sun.xml.bind', name: 'jaxb-impl', version: '2.1.12', transitive: false],
  73. 			[group: 'com.sun.xml.bind', name: 'jaxb-xjc', version: '2.1.12', transitive: false],
  74. 			[group: 'jaxen', name: 'jaxen', version: '1.1', transitive: false],
  75. 			[group: 'jdom', name: 'jdom', version: '1.1', transitive: false],
  76. 			[group: 'org.apache.neethi', name: 'neethi', version: '2.0.4', transitive: false],
  77. 			[group: 'woodstox', name: 'wstx-asl', version: '3.2.7', transitive: false],
  78. 			[group: 'xml-resolver', name: 'xml-resolver', version: '1.2', transitive: false],
  79.  
  80. 		) 
  81. 		test(
  82.  
  83.  
  84. 			//Libs para integracao do GEB com SPOCK e do GEB com Webdriver
  85. 			[group:"org.codehaus.geb", name:"geb-spock", version:"0.6.0"],
  86. 			[group:'org.seleniumhq.selenium', name:'selenium-firefox-driver', version:'2.0.0'],
  87. 			[group:'org.seleniumhq.selenium', name:'selenium-chrome-driver', version:'2.0.0'],
  88. 			[group:'org.seleniumhq.selenium', name:'selenium-ie-driver', version:'2.0.0'],
  89. 			[group:'org.hsqldb', name:'hsqldb', version:'2.2.4'],
  90. 		)
  91.     }
  92. }

Já para usar sintaxes do Oracle com o HSQLDB, basta incluir a seguinte instrução no início do script SQL:

SET DATABASE SQL SYNTAX ORA TRUE;

Para deixar isso automático, foi criado no arquivo BootStrap.groovy a seguite rotina:

  1. def init = { servletContext ->
  2. 		def envs = [Environment.DEVELOPMENT, Environment.TEST ]
  3. 		if (Environment.current in envs) {
  4. 			if(Environment.current == Environment.TEST) {
  5. 				executeHSQLDBWithOracleQuerySyntax()
  6. 			}
  7. 		}
  8.  
  9. 	}
  10.  
  11. def executeHSQLDBWithOracleQuerySyntax() {
  12. 		def sqlString = "SET DATABASE SQL SYNTAX ORA TRUE;"
  13.  
  14. 		def sql = Sql.newInstance(
  15. 			ConfigurationHolder.config.dataSource.url, 
  16. 			ConfigurationHolder.config.dataSource.username, 
  17. 			ConfigurationHolder.config.dataSource.password, 
  18. 			ConfigurationHolder.config.dataSource.driverClassName
  19. 		)
  20. 		sql.execute(sqlString)
  21. 	}

Simples assim, agora a todo start-up da aplicação, quando o escopo for de teste, o HSQLDB já estará pronto para aceitar funções inerentes ao banco de dados Oracle.

Tecnologia, Software & Desenvolvimento

Groovy + Grails

Desenvolver para WEB com Java nunca foi algo prazeroso, eu particularmente que sou oriundo de linguagens dinâmicas e de frameworks RoR like, nunca gostei de desenvolver com Java para WEB. Já tive a oportunidade de participar de projetos que utilizam frameworks como: Apache Beehive, Struts e Mentawaii. Assim como também tive a oportunidade de testar outros como: Wicket, Tapestry, Spring-MVC, etc. Desses, o que mais se aproximou de algo razoável foi o Spring-MVC, que parece nunca ser levado a sério pela própria SpringSource, que lançou a versão 3, mas nunca de forma realmente oficial, uma prova disso é que documentações a seu respeito são um tanto difíceis de serem achadas.

Quanto a Servlets (um mal necessário) e JSF (e suas N implementações), prefiro nem citar a minha opinião.

Paralelo a isso, aconteceu toda uma revolução na maneira de pensar em desenvolvimento para WEB com o lançamento do Ruby on Rails – framework WEB da linguagem Ruby – que foi um verdadeiro marco e que acabou impactando quase todas as outras linguagens, inclusive o próprio Java. A idéia do RoR é simples: facilitar, simplificar e tornar prazeroso o desenvolvimento para web. Seguir essa idéia sempre me pareceu uma boa opção.

Java como plataforma

Com todo esse advento dos novos frameworks WEB baseados no RoR e do crescimento de algumas linguagens como o próprio Ruby, Python e até linguagens de programação funcional, o Java, que já tem um estigma de ser uma linguagem complexa e que demora a evoluir, acabou perdendo força na comunidade como linguagem, mas em compensação passou a ser mais notada como plataforma, principalmente por causa do poder da JVM e das possibilidades que a mesma trás, com isso alguns projetos interessantes como Jython e JRuby surgiram e esses projetos nada mais são do que outras linguagens rodando em cima da JVM, ou seja, é possível desenvolver código Python e no final o mesmo virar byte-code e ser executado pela JVM.

E é nesse ponto que eu quero chegar, o assunto do próximo tópico.

Groovy

Groovy é uma nova linguagem, que roda em cima da JVM e que foi pensada de uma forma para ser dinâmica, simples e enxuta e ainda com a vantagem de poder se usar as API’s do Java.

Fora isso, foram criadas API’s específicas do próprio Groovy que facilitam muito o uso de alguns recursos/api’s do Java, como: coleções, mapas, strings, arquivos, etc.

A grande diferença do Groovy para o Java, é que o Groovy é uma linguagem de tipagem dinâmica, o que inicialmente pode ser um perigo para programadores habituados com Java, mas depois desse “trauma” inicial, a linguagem se mostra extremamente poderosa através de recursos como a possibilidade de se definir DSL’s.

Outra possibilidade interessante, é que é possível construir scripts com a linguagem Groovy, o que é uma verdadeira mão na roda para criação de rotinas de automatização, builds, etc.

Grails

Grails é um framework Groovy para WEB baseado no RoR e que tenta resolver todos os problemas já citados da burocracia de se desenvolver para WEB com Java.

Dentro do “pacotão” do Grails, já vem embutidos recursos como: injeção de dependência, mapeamento objeto relacional, segurança, testes (unitários e funcionais), validações, etc. Além do que, o framework é completamente focado em uma abordagem rich domain, diferentemente de outros frameworks.

Outro recurso muito interessante são os plugins, que são como mini-aplicações que podem ser instaladas dentro do Grails de acordo com a sua necessidade. Atualmente existem muitos plugins disponíveis no repositório do Grails e que atendem as mais variadas necessidades.

O framework é todo baseado em convenções e dispensa o uso de complexos arquivos XML para fins de configurações, o que no final das contas acaba sendo mais um fator para facilitar e agilizar o desenvolvimento, pois dessa maneira a equipe de desenvolvimento acaba ficando focada no que realmente interessa, que são os requisitos de negócio.

Porque escolhi Groovy+Grails

Antes de mais nada, escolhi por todos os motivos apresentados anteriormente, talvez até não tivesse toda essa visibilidade no começo do projeto, mas como o projeto novo não apresentava desafios muito grandes e ao mesmo tempo não era tão crítico, pensei que uma boa maneira em deixar minha equipe motivada seria investir em uma nova tecnologia.

Fora o fato, que como a equipe tinha experiência com Java, na pior das hipóteses, no caso da não adaptação da equipe com o Groovy, poderíamos usar códigos Java dentro do projeto, já que a linguagem permite isso, ou seja, foi um risco, mas um risco controlado e calculado.

Outro fator que contou muito para escolha dessa dobradinha, foi que passamos a adotar uma abordagem mais ágil e interativa com a presença mais próxima do cliente junto ao time de desenvolvimento e isso significava que deveríamos ter algo entregável toda semana, que foi a periodicidade que definimos para as nossas iterações. A adoção do Groovy e Grails agilizaria nosso tempo de desenvolvimento, consequentemente conseguiríamos produzir mais features em menos tempo, que era exatamente o que estavámos buscando.

Qual tem sido a minha experiência

A melhor possível. Quando eu digo a melhor possível, é porque tem sido melhor que o esperado, mas obviamente, como tudo na vida, tem seus prós e contras.

Um dos pontos positivos, foi que a curva de aprendizado foi bem menor do que o esperado, ou seja, a equipe entrou no “ritmo” do framework bem rápido.

Outro ponto positivo, é a abordagem do framework de ser realmente orientado a objetos, favorecendo uso de uma modelagem focada em domínio rico e testes. Para toda entidade, service, ou controller novos criados, automaticamente um teste já é criado, ou seja, isso torna claro para o desenvolvedor, que seguindo os conceitos do TDD, o mais aconselhável é que os testes sejam criados antes da implementação, pois só dessa maneira o design do seu código será influenciado para se tornar mais coeso, menos acoplado e com as camadas bem definidas de acordo com a sua responsabilidade dentro do contexto.

Como o framework é full-stack e baseado em convenções, configurar um projeto e rodar tem o custo quase zero, ou seja, muito pouco tempo é disperdiçado.

Como nem tudo são flores, tivemos um impacto inicial com a curva de aprendizado de uma linguagem dinâmica (para quem não tinha prática com isso), fora os novos conceitos do próprio framework. Mas volto a repetir: o impacto foi menor que o previsto. Para resolver esse tipo de problema, adotamos algumas medidas como: pair programming e um grupo de estudo interno para troca de conhecimento, onde cada um deveria mostrar algum tópico em que já tivesse mais avançado, para o restante.

Outro impacto que tivemos foram de algumas peculiaridades do framework, que apesar de ser muito bom, ainda apresenta alguns pequenos bugs (e até manhas) que demoram a serem notados. Como o framework está em evolução e ainda em versão 1.*, é normal que esteja um pouco imaturo, portanto não o recomendaria ainda para um projeto mais complexo e crítico.

IDE’s ainda são um problema quando se pensa em Groovy + Grails, na verdade, existe uma IDE muito boa, mas que é paga e não é o Eclipse, IDE no qual a maioria dos desenvolvedores Java já está acostumada. Essa IDE é o Intellij da Jet Brains, no qual já testei e realmente é a melhor opção no mercado.

Conclusão

Recomendaria Groovy+Grails se você tem uma visão semelhante a minha sobre desenvolvimento para WEB com Java e também se você tiver a oportunidade de usá-los em algum projeto sem muita criticidade e complexidade (apesar de existirem alguns cases), mas é importante mensurar sempre os riscos da adoção de algo novo, pois no final isso pode ser irreversível.

Java, Tecnologia, Software & Desenvolvimento

Testes: TDD e BDD.

Há algum tempo atrás, havia escrito sobre BDD e a verdade é que minha opinião sobre BDD não mudou, mas acho válido explicar um pouco melhor sobre a relação TDD e BDD, suas diferenças e da viabilidade de usar uma ou outra abordagem, pois tenho visto algumas pessoas fazendo confusão sobre os dois conceitos.

Diferenças

Enquanto TDD é focado em testes unitários, BDD é focado em testes de aceitação, a grande diferença que isso trás é que o BDD é algo muito mais “human-readable” e o ganho disso é que a equipe de desenvolvimento consegue definir os testes juntamente com a equipe de negócios, ou com o PO. Na verdade, acredito que o cenário é ideal é onde junto a um cartão de uma nova funcionalidade/mudança, já venha o seu teste de aceitação, ambos criados pelo PO.

Se for o caso da equipe criar o teste funcional, ou de aceitação (como preferir), a equipe pode alinhar junto com o cliente se aquele teste atende a funcionalidade/alteração pedida. Dessa maneira, temos quase uma garantia de que o que vai ser entregue está dentro do que realmente o cliente espera.

Para guiar design do código, eu particularmente acho que TDD é muito mais eficiente, pois através dos testes unitários e principalmente pelo ciclo do TDD, é muito mais fácil notar alguns conceitos como alta coesão/baixo acoplamento e também a divisão de responsabilidades (separation of concerns).

Uma abordagem anula a outra?

A resposta é não. Eu particularmente gosto muito de trabalhar com as duas abordagens em meus projetos, onde TDD guia o desenvolvimento (design de código, refactoring, etc) e o BDD dá o suporte necessário para testes e prevenção de bugs.

Inclusive, uma abordagem que eu adoto junto a minha equipe e que acho muito eficiente, é para cada bug reportado pelo cliente, de criar um teste funcional para o mesmo, dessa maneira evitamos o clássico problema de bugs recorrentes.

Em ferramentas de integração contínua, inclusive costumamos separar os builds. Temos um build de compilação + testes unitários, outro de testes funcionais e outro de testes integrados. A razão dessa separação, é evitar que os builds fiquem excessivamente lentos e fazer com que a equipe perca o valor principal da integração contínua que é o feedback rápido, mas todo dia temos um nightly build que executa todos os tipos de teste, assim como em dia de entregas oficiais, já que também rodamos o build com todos esses testes.

Ah, usar BDD para testes integrados também acho uma abordagem muito válida. Minha equipe tem trabalhado em um projeto Groovy/Grails e estamos usando o Spock + GEB e os resultados tem sido muito bons.

Tecnologia, Software & Desenvolvimento

Lidando com o fim de um projeto

É inevitável que um projeto chegue ao fim, na verdade, se pensarmos na teoria, todo projeto deve começar com o seu escopo bem definido e isso inclui uma data de entrega. O pessoal que trabalha com ágil pode dizer “mas nós trabalhamos com ciclos interativos e é o cliente quem define as prioridades”, sim, é verdade, mas todo cliente quer uma data de quando o projeto será entregue. Até mesmo, porque o cliente tem seu planejamento e seu orçamento e tudo isso gira em torno do tempo de execução do projeto.

No final do projeto, é normal que a equipe começe a ter ciclos de ociosidade, justamente porque novas features não serão adicionadas, bugs críticos já foram corrigidos e o projeto já está estável o suficiente para ir para produção. Só que essa ociosidade da equipe, pode trazer danos irreverssíveis, como: insatisfação, desinteresse, frear o ritmo da equipe, esquecimento de pontos específicos do projeto, etc.

Imagino que nenhuma equipe queira passar pelos problemas expostos acima, por isso o final do projeto deve ser enxergado como uma oportunidade de melhorar o que já existe, de mudar alguma tecnologia que esteja “desatualizada”, de documentar o que for necessário e de refletir sobre erros e acertos. Uma estratégia que tenho usado e que tem me ajudado muito nesses momentos, é de criar uma espécie backlog de tudo que pode ser melhorado no projeto, mas que não é crítico em determinado momento, depois, conforme for sobrando tempo, vou priorizando esse backlog e executando com a equipe as melhorias pontualmente.

Atualmente estou em um projeto, que devido ao escopo ser muito apertado, eu e minha equipe tivemos que abrir mão de qualidade para podermos entregar o projeto no tempo estimado. Isso, como pode-se imaginar, gerou alguns códigos difíceis de manter. Minha equipe também era um pouco imatura no início do projeto e isso também impactou diretamente na qualidade do código. Para piorar, muitas regras de negócio foram sendo definidas em runtime pelo cliente e é claro que isso também impactou na qualidade do projeto. Como o projeto está de certa forma estabilizado, o momento para pensar em melhorias e algumas mudanças é agora e isso passa a ser a arma do líder de projeto para manter sua equipe motivada, ocupada e no seu ritmo. Sem contar o fato de que as melhorias, tirarão das costas própria equipe o trabalho árduo de manutenção no futuro (o que poderia também desmotivar a equipe).

Vale ressaltar, que nesse momento do projeto, o líder deve ter todo cuidado para que essas melhorias feitas através de técnicas de refatoração não impactem o funcionamento do projeto, afinal a definição mais simplista de refatoração é: melhorar algo que já existe, mas mantendo o seu comportamento original.

Além disso, o líder sempre deve contar com a possibilidade do cliente solicitar alguma mudança ou resolução de algum bug durante esse processo de melhoria, e para não ser pego de surpresa, o que eu indico é que o processo de melhoria seja feito paralelamente a última versão de código do projeto entregue ao cliente. Como fazer isso? Usando o famoso trunk (última versão entregue ao cliente) e branch (versão gerada a partir do trunk e onde será feita o processo de melhoria). Depois, todo cuidado é pouco durante o merge dessas alterações e é nesse momento, onde os testes, que inicialmente foram esquecidos, irão ajudar muito!

O principal objetivo do desenvolvimento orientado a testes (TDD) é direcionar o design do código para que o mesmo fique claro e legível o suficiente para suportar manutenções e ser escalável, mas outro ponto do TDD, é que os testes sejam uma maneira de fornecer segurança aos programadores para realização de melhorias (refatorações), por isso, se você teve que abrir mão de testes no começo do projeto, não deixe de pensar neles no final, mesmo que isso não seja o mais indicado e que o ciclo do TDD não indique isso, mas como já sabemos, na teoria as coisas são de um jeito, na prática elas são de outra.

Seguem algumas dicas de tarefas que podem ser executadas/pensadas na fase de término do projeto:

- Testes unitários
- Testes de interface/aceitação
- Testes integrados
- Programação em par (o uso em processos de refatoração é muito válido e tem um resultado muito positivo)
- Padronização do código
- Documentação do código
- Estudo de novas tecnologias/frameworks/linguagens (para os próximos projetos ou até mesmo projeto atual)
- Melhoria de performance de algum ponto da aplicação que possivelmente possa ser um gargalo no futuro
- Troca de opiniões entre a equipe para melhoria do processo de desenvolvimento
- Reuniões para discussão de erros e acertos do projeto

Para finalizar, gostaria de ressaltar que essas são observações baseadas na minha própria experiência como líder de projeto e que não tem relação direta com nenhuma metodologia, na verdade são pontos relevantes e que certamente muitos tem como referência pontos específicos de diversas metodologias.

Tecnologia, Software & Desenvolvimento

O que eu tenho aprendido sobre liderança

Desde o começo do ano, tenho tido a oportunidade de trabalhar na liderança de projetos de software (por isso o motivo da minha ausência por aqui) e essa experiência tem sido muito enriquecedora para mim no aspecto profissional, pois tenho dado extrema relevância a aspectos, que em outrora, eram menos relevantes do que aspectos técnicos, como: lidar com pessoas, processos, riscos, prazos e expectativas.

Não tenho a menor dúvida de que liderança é algo que possa ser adquirido através de um processo de aprendizagem, o que me faz constatar, que por mais que existam pessoas que tenham alguns aspectos de liderança mais bem desenvolvidos de forma natural, que é possível ainda assim desenvolver ainda mais esses aspectos. Ou seja, sempre podemos ser melhores líderes. Acredito também, que as melhores maneiras de evoluirmos é observando outros líderes e também dando atenção as pessoas com que trabalhamos.

Baseado no assunto liderança, preparei uma lista com quase 40 tópicos que tem sido de suma importância no meu dia-a-dia como líder de projeto. Esses tópicos foram pensados baseados em erros e acertos que tenho cometido como líder de projetos de software, por isso existem tópicos focados no aspecto de software, entretanto a maioria é voltada para líderes de maneira geral.

1 – Defina, focado no seu problema, os artefatos técnicos a serem usados no seu projeto e certifique-se de que a probabilidade dos mesmos mudarem é pouco provável

2 – Tenha um plano de comunicação bem definido com a sua equipe

3 – Desenvolva ou escolha uma metodologia de desenvolvimento e tenha certeza de que as pessoas da sua equipe a entenderam e acharam a mesma útil

4 – Se preocupe com o seu modelo de dados

5 – Se possível, tenha sempre o layout em mãos antes do desenvolvimento

6 – Não exija respeito, conquiste

7 – Tenha bom humor

8 – Passe segurança a sua equipe, tenha certeza que ela confie em você, um líder precisa, acima de tudo, inspirar confiança

9 – Tente não demonstrar desespero, euforia e nem pessimismo

10 – Saiba cobrar, mas sem pressionar

11 – Contextualize as pessoas sobre o que elas estão fazendo

12 – Posicione as pessoas sobre o andamento e o status atual do projeto em que elas estão participando

13 – Identifique, antes de tudo, os pontos fortes e fracos de cada um e use isso a seu favor

14 – Promova treinamentos e palestras para pontos em que mais de uma pessoa possua dúvida

15 – Cobre uma documentação do cliente que agregue ao seu time

16 – Converse com o seu cliente

17 – Caso necessário, crie uma documentação própria e simplificada, baseada na documentação original do seu cliente

18 – Defina e detalhe bem as tarefas de cada membro da sua equipe

19 – Faça com que as pessoas da sua equipe entendam da aplicação, entendam do negócio, pois só assim elas podem sugerir melhorias

20 – Tente não ficar dependente de uma mesma pessoas para um ponto específico

21 – Dê feedback constante

22 – Ouça a sua equipe

23 – Reuna sua equipe semanamlmente para discutir como foi a última semana e planejar como será a próxima

24 – Tenha preferência em trabalhar com equipes enxutas a equipe com muitas pessoas

25 – Dê atenção as pessoas novas e explique sobre o que ela fará, aprensente ela a equipe, mostre a empresa

26 – Estime prazos reais para o seu cliente, e não prazos que ele gostaria de ouvir

27 – Promova ações para estimular a união da sua equipe, como almoços mensais, por exemplo

28 – Enumere todas as principais funcionalidades do seu sistema, se possível criando uma hierarquia entre elas, isso ajudara você, a equipe e o cliente a terem uma visão macro do projeto

29 – Crie políticas para o bom de uso de controles de versão, ferramentas de gerenciamento, integração contínua, etc

30 – Faça uma auto-avaliação periodicamente

31 – Evite que as pessoas tenham que trabalhar finais de semana, feriados e fazerem hora extra constantemente

32 – Tenha cuidado em elogiar alguém publicamente. Jamais critique alguém publicamente

33 – Anote tudo o que você deseja fazer, mesmo que não seja prioridade

34 – Mostre e deixe claro a importância de cada membro da equipe

35 – Não fale mal da sua equipe para outras pessoas

36 – Trabalhe e se esforçe mais do que todo mundo, você é o exemplo

37 – Sua equipe precisa te admirar e se espelhar em você

38 – Saiba dizer não, demarque seu limite

39 – Em caso de fracasso, a culpa é do líder, em caso de sucesso, o mérito é de todos

Alguns desses pontos são de cunho mais técnico, outros de cunho gerencial e outras focam no relacionamento inter-pessoal entre você e os membros da sua equipe e entre os membros da sua equipe com eles mesmo. Não se esqueça, que antes de qualquer coisa, nós trabalhamos com humanos e humanos são passíveis a cometerem erros, humanos tem dias bons e ruins, humanos tem expectativas, humanos necessitam de comunicação.

Um recurso que tem me ajudado a ter esses pontos de maneira mais clara é o mapa mental, pois dessa maneira consigo ter todos esses pontos listados e interligados, proporcionando uma organização lógica aos mesmos.

Para finalizar, sempre se questione com a seguinte pergunta: eu seria liderado por mim mesmo?

Liderança

BDD com JBehave

Conforme prometido no tópico anterior, irei mostrar o conceito de BDD através da utilização do framework JBehave, que é o framework de BDD mais famoso para Java e que foi desenvolvido pelo Dan North, o idealizador deste conceito.

Antes de mais nada, vamos citar alguns conceitos importantes de BDD.

Estórias e Cenários

BDD é baseado em estórias e cenários, e para criarmos ambos, vamos seguir alguns padrões pré-definidos por autores de BDD. Uma vez que BDD é focado em comportamento e sequência, as estórias e cenários devem ter um formato rígido para que as ferramentas consigam entendê-los e interpretá-los.

As estórias, possuem o seguinte formato:

As I [X]
I want [Y]
so that [Z]

E os cenários possuem o seguinte formato:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Ou seja, isso quer dizer que devemos pensar em nossos requisitos de maneira que possam ser escritos baseados nessa convenção.

O JBehave é originalmente escrito para entender estórias em inglês, entretanto como BDD é focado em pessoas (stakeholders) e na descrição de situações reais, faz muito mais sentido semanticamente que as estórias e cenários sejam escritos em português e para resolver isso, usei uma contribuição do Emerson Macedo para que os cenários possam ser escritos e entendidos em português pelo JBehave.

Começando com o JBehave

O primeiro passo para utilização do JBehave, é fazer download do JAR do projeto e incluí-lo no classpath do seu projeto.

O próximo passo é escrever a estória juntamente com o cenário e para tal resolvi criar um exemplo simples para que o entendimento do conceito possa ser casado através do código a ser desenvolvido.

O exemplo escolhido é baseado no requisito: Compra de produtos em promoção com aviso por email. E é isso que nosso cenário BDD deve descrever.

Por questão de organização, resolvi quebrar a estória em 3 cenários diferentes, onde a primeira parte representa a verificação de produtos em promoção, a segunda representa a compra desses produtos e o terceiro é a finalização da compra e o envio de email. Então, a estória e os cenários ficaram assim:

Compra de produtos em promoção com aviso por email
 
Narrativa:
Como um usuário
Eu quero comprar produtos em promoção
E então receber um email de confirmação
 
Cenário: Verificar produtos em promoção
Dado Que uma loja possui 10 produtos
E Que 5 estão em promoção
Quando Eu verifico quais estão em promoção
Então Preencho minha sacola apenas com produtos em promoção
 
Cenário: Comprar produtos em promoção
Dado Que minha sacola de compras está preenchida com 5 produtos em promoção
Quando Eu verifico o somatório de produtos
Então Devo ter somente um total de 500 reais em produtos
 
Cenário: Enviar email
Dado Que minha sacola está preenchida de produtos
Quando Enviar um email de confirmação
Então Devo receber o status do envio "true"

A primeira linha do arquivo texto representa o título da nossa estória, o requisito de fato. A narrativa é um resumo do que essa estória deve cumprir e a seguir vem os três cenários, que no caso são as três etapas da estória.

É importante notar, que as palavras chaves em inglês (Given, When, Then, And) foram substituídas por palavras em português (Dado, Quando, Então, E).

Esse arquivo texto deve ser salvo com a extensão *.cenario e o seu nome está diretamente ligado a classe que irei criar no passo a seguir, que no caso é a classe que representa a estória e a associação com os cenários.

Criando a classe que irá comportar os cenários

Nesse passo irei criar a classe que irá apontar os cenários que compõe a estória e essa classe deve extender a classe Scenario do JBehave. Dessa forma, a classe ficaria assim:

PrecoPromocaoTeste.java

  1. package scenario1;
  2.  
  3. import scenario1.steps.CompraSteps;
  4. import scenario1.steps.EmailSteps;
  5. import scenario1.steps.PromocaoSteps;
  6. import scenario1.util.PtBRScenario;
  7.  
  8. public class PrecoPromocaoTeste extends PtBRScenario {
  9. 	public PrecoPromocaoTeste() {
  10.            addSteps(new PromocaoSteps());
  11.            addSteps(new CompraSteps());
  12.            addSteps(new EmailSteps());
  13. 	}
  14. }

No exemplo acima, estou extendo a classe PtBRScenario só para que a estória e o cenário sejam escritos em português, mas essa classa herda a classe Scenario como descrito anteriormente.

No construtor da classe, inclui os passos que a estória deve seguir para ser satisfeita e como quebrei a estória em três pedaços, precisei incluir três passos sequenciados.

Criando os passos da estória

Como a estória foi quebrada em três partes, se faz por necessário a criação de 3 classes que irão representar os passos da estória e todas essas classes devem herdar a classe Steps do JBehave.

Pela ordem definida na nossa classe de cenário, vamos aos passos:

PromocaoSteps.java

  1. package scenario1.steps;
  2.  
  3. import java.util.List;
  4.  
  5. import junit.framework.Assert;
  6.  
  7. import org.jbehave.scenario.annotations.Given;
  8. import org.jbehave.scenario.annotations.Then;
  9. import org.jbehave.scenario.annotations.When;
  10.  
  11. import scenario1.entity.Loja;
  12. import scenario1.entity.Produto;
  13. import scenario1.util.PtBRSteps;
  14. import scenario1.vo.Sacola;
  15.  
  16. public class PromocaoSteps extends PtBRSteps {	
  17. 	Loja loja 		= new Loja();
  18. 	Sacola sacola 	= new Sacola();
  19. 	List<Produto> listaProdutoPromocao;
  20. 	int quantidadeProdutoPromocao;
  21.  
  22. 	@Given("Que uma loja possui $quant produtos")
  23. 	public void populaLoja(Integer quantidade) {
  24. 		loja.inicializaProdutos(quantidade);
  25. 	}	
  26.  
  27. 	@Given("Que $quant estão em promoção")
  28. 	public void informaProdutosPromocao(Integer quantidade) {
  29. 		loja.colocaProdutosPromocao(quantidade);
  30. 		quantidadeProdutoPromocao = quantidade;
  31. 	}	
  32.  
  33. 	@When("Eu verifico quais estão em promoção")
  34. 	public void verificaProdutosPromocao() {		
  35. 		listaProdutoPromocao = loja.retornaProdutosPromocao();
  36. 	}
  37.  
  38. 	@Then("Preencho minha sacola apenas com produtos em promoção")
  39. 	public void populaSacola() {
  40. 		sacola.populaSacola(listaProdutoPromocao);
  41.  
  42. 		Assert.assertEquals(listaProdutoPromocao.size(), quantidadeProdutoPromocao);
  43. 	}
  44. }

CompraSteps.java

  1. package scenario1.steps;
  2.  
  3. import java.util.ArrayList;
  4. import java.util.List;
  5.  
  6. import junit.framework.Assert;
  7.  
  8. import org.jbehave.scenario.annotations.Given;
  9. import org.jbehave.scenario.annotations.Then;
  10. import org.jbehave.scenario.annotations.When;
  11.  
  12. import scenario1.entity.Produto;
  13. import scenario1.util.PtBRSteps;
  14. import scenario1.vo.Sacola;
  15.  
  16. public class CompraSteps extends PtBRSteps {
  17. 	Sacola sacola 				= new Sacola();
  18. 	double somatorioProdutos 	= 0d;
  19.  
  20. 	@Given("Que minha sacola de compras está preenchida com $quant produtos em promoção")
  21. 	public void verificaSacola(Integer quantidade) {
  22. 		List<Produto> listaProduto = new ArrayList<Produto>();
  23.  
  24. 		for (int i=1; i<=quantidade; i++) {
  25. 			Produto produto 	= new Produto();
  26. 			produto.preco 		= Math.round(Math.random()*100);
  27. 			produto.emPromocao 	= true;
  28.  
  29. 			listaProduto.add(produto);
  30. 		}
  31.  
  32. 		sacola.populaSacola(listaProduto);
  33. 	}
  34.  
  35. 	@When("Eu verifico o somatório de produtos")
  36. 	public void verificaTotalProdutosSacola() {
  37. 		for ( Produto produto : sacola.retornaProdutos() ) {
  38. 			somatorioProdutos = produto.preco + somatorioProdutos;
  39. 		}
  40. 	}
  41.  
  42. 	@Then("Devo ter somente um total de R$ $total reais em produtos")
  43. 	public void validaSacola(double totalProduto) {		
  44. 		if ( somatorioProdutos > totalProduto )
  45. 			Assert.fail("Total de produtos é acima de R$ 500");
  46. 	}
  47. }
  48. </rpe>
  49.  
  50. <strong>EmailSteps.java</strong>
  51. <pre lang="java" line="1">
  52. package scenario1.steps;
  53.  
  54. import static org.jbehave.Ensure.ensureThat;
  55.  
  56. import org.jbehave.scenario.annotations.Given;
  57. import org.jbehave.scenario.annotations.Then;
  58. import org.jbehave.scenario.annotations.When;
  59.  
  60. import scenario1.util.PtBRSteps;
  61. import scenario1.vo.Sacola;
  62.  
  63. import com.guilhermechapiewski.fluentmail.email.EmailMessage;
  64. import com.guilhermechapiewski.fluentmail.transport.EmailTransportConfiguration;
  65.  
  66. public class EmailSteps extends PtBRSteps {
  67. 	Sacola sacola 		= new Sacola();
  68. 	Boolean statusEnvio = false;
  69.  
  70. 	@Given("Que minha sacola está preenchida de produtos")
  71. 	public void verificaSacola() {
  72. 		System.out.println("Lista cheia..");
  73. 	}
  74.  
  75. 	@When("Enviar um email de confirmação")
  76. 	public void enviaEmail() {
  77. 		EmailTransportConfiguration.configure("localhost", false, false, "", "");
  78.  
  79. 		new EmailMessage()
  80. 	    	.from("eusou@marcuscavalcanti.net")
  81. 	    	.to("eusou@marcuscavalcanti.net")
  82. 	    	.withSubject("Testando BDD")
  83. 	    	.withBody("Testando terceiro cenário e o final da estória.")
  84. 	    	.send();
  85.  
  86. 		statusEnvio = true;
  87. 	}
  88.  
  89. 	@Then("Devo receber o status do envio \"$retorno\"")
  90. 	public void recebeStatusEnvio(String retorno) {	
  91. 		ensureThat(statusEnvio.toString().equals(retorno));
  92. 	}
  93. }

Nos exemplos acima, que representam os passos de um cenário, é importante notar que os métodos seguem a ordem definida no arquivo texto, assim como todos são anotados com as palavras chaves correspondentes, no caso Given, When, And, Then. As anotações recebem como parâmetro as frases descritas no arquivo texto, excluindo apenas as palavras chaves no começo da frase, que estão devidamente representadas pelas anotações.

Os parâmetros são identificados com o formato $variavel, e uma vez que usamos esses parâmetros, devemos também colocá-los na assinatura dos métodos. Esses parâmetros são automaticamente capturados pelo JBehave através do uso de expressões regulares.

Executando o exemplo

Para executar o exemplo deve-se executar a classe que extende a classe Scenario do JBehave, nesse caso seria a classe PrecoPromocaoTeste.java, e para acompanhar os resultados, eu utilizo a integração do Eclipse com o JUnit, através de uma view própria da IDE.

No exemplo, usei ainda algumas classes auxiliares criadas especificamente para o exemplo, mas que não irei mostrar aqui os seus códigos para não tornar o tópico extenso demais. De qualquer forma, ao final desse tópico botarei um link para download do projeto no Eclipse que contém todos os códigos.

Observações finais

Um dos problemas que eu notei no JBehave é em relação a parametrização de alguns valores no arquivo texto para o código Java, em alguns casos isso pode se tornar um trabalho sacal e pouco produtivo, mas acredito que com a evolução do framework esse problema será resolvido.

Algumas pessoas utilizam alternativas variadas para resolver esse problema, como por exemplo criar o valor dos parâmetros diretamente como atributos nas classes que representam os passos. Eu particularmente não gosto dessa abordagem, pois acredito que isso faz com que os arquivos que descrevem os cenários percam seu valor e esses arquivos são essencial para utilização e sentido do BDD.

No exemplo citado, usei ainda algumas bibliotecas como FluentMailApi, Mail e Activation da JavaMail e Hamcrest. Essas bibliotecas servem basicamente para o envio de email e uso mais aperfeiçoado de expressões regulares por parte do JBehave.

Para finalizar, é importante citar que as classes do meu negócio (Sacola, Usuario, Loja, etc) foram construídas baseadas no meu requesito, no meu cenário, que foi a primeira etapa a ser elaborada na construção do exemplo.

Download

Para download do projeto completo no Eclipse, basta clicar aqui.

Java, Tecnologia, Software & Desenvolvimento

Algumas observações sobre BDD

Ultimamente estive pesquisando sobre o assunto BDD (Behaviour-Driven Development) e também praticado com alguns exemplos reais, através disso devo dizer que consegui tirar algumas conclusões bem interessantes sobre o assunto, nas quais gostaria de expor aqui. Vamos a elas:

BDD ajuda você, BDD ajuda seu cliente

Um ponto que pude observar, é que usando BDD a possibilidade de um cliente participar de um projeto é imensa, mesmo que você não use alguma metodologia ágil (falarei sobre isso a seguir). E por que ele pode participar? É simples, pois é ele quem pode escrever os testes. Se ainda assim não for o seu cliente o responsável por escrever os testes, será ele quem irá validá-los, ou seja, você pode escrever os testes e pedir para que ele aprove ou não. Isso é muito importante, pois nesse caso os testes em BDD seriam o contrato entre você o seu cliente, entre o que você está entregando e o que ele está esperando.

BDD favorece o sucesso do uso de metodologias ágeis

Sem dúvida nenhuma um dos pontos fortes do uso de BDD é que suas características se encaixam muito bem em equipes que fazem o uso de metodologia ágil. E são vários pontos que favorecem.

Uma delas é a já citada participação do cliente, pois um dos requisitos para o sucesso do uso de metodologias ágeis é a participação e contribuição efetiva do cliente e no caso do uso de BDD ele pode participar diretamente, uma vez que é ele quem é o responsável (PO) por criar as estórias (ítens do backlog) e criar os testes de aceitação para as mesmas, onde tudo isso é usado no BDD.

Os artefatos que constituem BDD são muito, mais muito semelhantes aos artefatos presentes em ágil.

Em BDD se usa estórias e testes de aceitação, além de BDD favorecer a construção de aplicativos de forma evolutiva (sprints) e tudo isso casa perfeitamente com os requisitos das metodologias ágeis.

Favorece a escrita de testes antes da implementação

Uma boa prática na criação de testes, independente se você usa BDD ou TDD, é que os testes sejam criados antes de tudo. Ok, eu concordo, mas devo dizer que com TDD isso não é muito nítido, pois na maioria dos casos, principalmente no começo, as pessoas tendem a implementar os códigos e depois escreverem os testes para validá-los. Já com BDD, a primeira coisa que você precisa ter em mãos antes de implementar os testes são as estórias e os cenários, não tem como fugir disso, o que torna muito mais nítido que em primeiro lugar vem os testes e depois as implementações.

Torna mais nítido o que sua aplicação deve fazer

Com BDD é muito mais fácil isolar as funcionalidade da sua aplicação, já que o que é testado é exatamente isso, dessa forma fica fácil identificar os componentes que envolvem determinada funcionalidade, torna mais nítido qual é o papel daquela funcionalidade, além do que consegue dar um sentido melhor para a sua aplicação de maneira geral.

Com BDD, você consegue ainda uma visão de workflow da sua aplicação, ou seja, uma visão macro, o que favorece dar manutenção a mesma. Percebo também, que BDD favorece um bom design de código, evitando assim problemas de desenvolvimento como códigos com alto-acoplamento.

Torna os testes mais humanos

A essência do BDD são os cenários e não parte isoladas da aplicação e essa maneira de lidar com testes favorece o entendimento por parte de nós, humanos.

Testes de interface com o Selenium, tornam-se mais compreensíveis num contexto que envolva BDD, como em um teste de login, por exemplo.

Conclusão

Na minha opinião, está mais do que clara a vantagem no uso de BDD, entretanto ele não substitui o uso de TDD, pois a abordagem de ambas são diferentes e complementares.

No próximo tópico, irei mostrar um cenário de testes com o framework JBehave, um framework BDD para Java.

Mais sobre o assunto

The truth about DDD

The difference between TDD and BDD

Tecnologia, Software & Desenvolvimento

Algumas frases sobre SOA e BPM

Tenho andado sem tempo para postar coisas novas (apesar de ter mais de 20 posts engatilhados) e para não ficar tão ausente, resolvi colocar em prática algo que eu já vinha tendo vontade de fazer há algum tempo, que no caso seria publicar frases de autores que costumo ler.

As frases são tiradas de um contexto específico, mas podem tranquilamente ser usadas de maneira isolada para reflexão, aprendizado e até para fixar uma idéia.

Nessa “primeira edição”, vou me ater a frases que envolvam SOA e BPM.

Eis as frases:

“The first of those milestones has come to pass: process is not simply the way business operates itself, but manages itself.”
Phil Gilbert

“It’s been said, “If you can’t measure it, you can’t manage it.” It’s also been said, “Opinions are like a*******, everybody’s got one.” The ability to manage by fact (measurement), rather than opinion, is what sets the rare professional manager from the masses of loudmouth, intimidating, egotists who’ve been given the title Manager. Leaders, on the other hand, earn that title. And one of the most effective ways of earning that title is to learn to mange objectively, not subjectively. Objective management starts with identifying objective performance measurements.”
Jim Reardan

“Service Decomposition splits service, not function.”
Thomas Erl

“IT realizes the burden is not on them anymore. The business has to be the responsible party.”
Peter Woodhull

“Often when we look at business processes and SOA we ignore the information aspect and focus on the technology aspect. What’s important is that you have some vision of sets of services that you need now and then over time to meet your business requirements.”
Mike Rosen

“Unless you use SOA in the context of what you’re trying to do with the business, you can end up with just the new spaghetti to replace the old spaghetti.”
Marc Smith

“…often sees a team of business experts thinking in purely business terms and a team of developers thinking only in terms of what code they’ll need to write. But SOA is not the sort of architecture that one builds by throwing code at it. It is, at its core, very conceptual.”
Sandy Kemsley

“Using SOA as we do – as an architecture and business modeling approach – helps bridge the gap between traditional business process modeling and technology delivery.”
Steve Jones

“SOA is simply the technology architecture that defines how any technology is designed and deployed. BPM, on the other hand, represents how you link business strategy to business implementation… with [SOA-based] technology being a part of that implementation.”
Phil Gilbert

BPM, SOA