Projeto de exemplo com Cucumber, Selenium e Rails http://github.com/cmilfont/bddonrails
Para executar o exemplo deve se lembrar de ter o java instalado [de preferência o da SUN] por dependência do Selenium. Execute os comandos abaixo para baixar e rodar a aplicação:
Posted in Behaviour Driven Development, Rails, Ruby, Test Driven, XP, xpce ~ 1 Comment
A grade foi finalizada com a confirmação da segunda palestra para o evento com um profissional experiente falando e demonstrando na prática como desenvolver com Rspec e Cucumber seguindo uma moderna abordagem chamada Behaviour Driven Development.
Palestra: BDD prático com Cucumber, Selenium e RSpec
Resumo: Palestra na forma de “hands on” com a construção de uma aplicação utilizando conceitos de BDD. Outside in development visto na prática através da construção e automação de user stories com Cucumber + Selenium e descrição de comportamento com RSpec e Remarkable
Palestrante: Jefferson Jean Martins Girão
Desenvolvedor no Grupo Tubform (http://www.grupotubform.com.br) atualmente trabalhando na migração de um ERP industrial de MS FoxPro para Ruby on Rails e Javascript com EXTjs. Tem 4 anos de experiência em desenvolvimento de software já tendo passado por áreas como automação comercial, terceiro setor e gestão pública municipal.
Informações sobre o evento:
Posted in Behaviour Driven Development, Engenharia de Software, Melhores práticas, Metodologia, Métodos Ágeis, Rails, Ruby, XP, teste, xpce ~ No Comments
Processos de desenvolvimento de software são quase todos iguais em termos de práticas e todos podem assumir práticas novas de outros processos, até cascata pode aplicar qualquer prática de XP e Scrum em seu modelo naturalmente.
O que diferencia esses processos não são as práticas, são os valores. O problema é que entender, compreender e adotar valores é algo subjetivo que varia de pessoa para pessoa por mais que se tenha princípios bem definidos que conectem as práticas a esses valores.
Diante disso, nenhum processo garante que seu projeto será um sucesso por estar o seguindo, mesmo que seja “By The Book”.
Há uma preocupação com o chamado Scrumbut, mas eu já vejo e vi projetos Scrum que não são Scrumbut e mesmo assim o software produzido, por mais ágil que seja, não tem qualidade e no primeiro refactoring você já entra no prejuízo similar a um software desenvolvido em Cascata.
Fato é que esses valores e princípios não garantem software com código coeso, desacoplado, limpo, claro e facilmente lido, ou seja, com qualidade interna.
Hoje minha preocupação em todos os projetos é a qualidade interna do software, não importa que metodologia seja adotada. Qualidade interna garante que o software tem boa saúde e é fácil de ser medida.
Saúde do software é o quão rápido e efetivo ele se recupera de mudanças e o quão limpo ele está de defeitos. Para se recuperar de mudanças o software precisa ser limpo e claro, ser facilmente entendível e lido.
Livre de defeitos é ter uma cobertura de testes que explorem e machuquem o código até descobrir falhas que passam despercebidas.
A grande maioria dos processos se preocupa mais com a qualidade externa do que a interna. Não importa se você faz reuniões em pé, tenha o cliente presente ou faça Scrumban ou até mesmo que você esteja entregando software rápido, nada disso vai garantir qualidade e que não vá ter prejuízo no futuro.
Vender qualidade externa tem um apelo comercial fácil porque você não precisa comprovar a qualidade do software e sim do processo, o discurso é sempre mais elegante do que falar em código, principalmente para alta gerência e burocratas, tanto é que todos os modelos de qualidade reconhecidos avaliam o processo e não o produto.
CMMi, ISO ou seja lá que for, não garantem que o produto será de qualidade e sim que o processo seja e se pararmos para pensar um momento, o processo realmente é de qualidade, temos um conjunto de métodos eficazes para produzir… processo e não produto.
Um exemplo de qualidade interna de um software são os testes automáticos em suas diversas nuances como unitários, aceitação, integração e funcional, mas não apenas isso, métricas de coesão, cobertura, LOC, complexidade e tantas outras.
No Maré de Agilidade eu fiz questão de enfatizar:
“Não importa que processo você siga, se é ágil ou não, se você não faz testes de Software vocês está errado em todos.”
Não existe um software sem bateria de testes automáticos com qualidade, isso é lenda. Em mais de 10 anos de profissão o que tenho notado é que a grande maioria, senão todos, são fortemente acoplados e de baixa coesão como consequência da falta de testes. Aplicar testes nesses softwares é uma tarefa quase impossível e proibitiva em relação a custos, sai mais barato fazer um software novo.
Outra coisa que falei no Maré de Agilidade foi:
“Não seja ágil, seja o melhor possível, porque ao procurar ser o melhor você invariavelmente vai se deparar com práticas que o tornam melhor e aí você se tornará ágil”.
Assim como o lema da Rossi: “Armas não matam pessoas, pessoas matam pessoas” podemos induzir que: Processos não desenvolvem software, pessoas desenvolvem software!
Ao trabalhar com pessoas, precisamos entender que modelos de negócios como software são de terceira onda [Alvin Toffler aqui] e não da segunda onda [industrialismo]. Qualquer analogia com modelos de segunda onda provocará insuficiência no trabalho dessas pessoas [por isso Lean faz tanto sucesso hoje] e elas precisam estarem motivadas para produzir qualidade interna, coisa que o trabalho sobre qualidade externa não produz.
Esse tema sobre pessoas e processos [como homem/hora] será escrito em outro artigo.
Resumo desse artigo é: Pessoas são responsáveis por produzirem qualidade interna ao produto e não processo, invista nelas.
Posted in Behaviour Driven Development, Engenharia de Software, Melhores práticas, Metodologia, Métodos Ágeis, Scrum, Test Driven, XP, teste ~ 6 Comments
Copyright © 2010 Milfont Consulting | Design by CMilfont | Xhtml Happy | CSS Happy | Entries (RSS) and Comments (RSS)
OPML Completo.
Texto Completo