Neste artigo conheceremos maneiras para se adequar ao desenvolvimento ágil. Com Behavior Driver Development – BDD os processos de trabalho podem ser modificados de uma forma mais eficiente. Áreas e profissionais, de tecnologia ou não, também devem adaptar-se para que tudo realmente funcione.
Em que situação o tema útil
O tema discutido neste artigo é útil para todos aqueles que tenham interesse na implantação de metodologias ágeis em suas organizações.
Testes ágeis com BDD
Behavior Driven Development ou BDD é um novo framework com foco em desenvolvimento guiado a comportamento. Surgiu em 2003, criado por Dan North. Este modelo reúne as melhores práticas ágeis do Test Driven Development – TDD e Domain Driven Design – DDD.
Neste artigo veremos maneiras para se adequar ao desenvolvimento ágil. Mostraremos aqui dicas úteis de como se manter a qualidade nos projetos diante de tanta agilidade. Com a substituição de diversos insumos que recebemos nos modelos tradicionais de desenvolvimento de software, algumas atividades e entregáveis ainda são os mesmos. E o resultado final exigido ainda é o mesmo, a entrega de um produto com qualidade e que atenda ao negócio.
Apesar da resistência existente em alguns setores e empresas, modelos ágeis de desenvolvimento de software são cada vez mais utilizados. E quando falamos sobre novas metodologias e frameworks, as atenções se voltam fortemente ao desenvolvimento do produto em si. E as mudanças são grandes e não é somente o setor de desenvolvimento de software o único ponto que é atingido com as mudanças. Outras áreas e consequentemente as pessoas têm suas rotinas de trabalho alteradas.
Nos modelos ágeis de desenvolvimento de software há exigência quanto a um grau de envolvimento maior e uma boa comunicação entre todos, que é fundamental para o andamento do projeto.
Com o avanço destes modelos em processos de desenvolvimento de software, o envolvimento mais próximo de algumas pessoas que ate então se mantiveram distantes, a área de negócios - que passamos a chamar aqui de Product Owner - se fez mais do que necessário para que o produto final entregue realmente atenda e tenha valor para todos.
Porém, há diversas dificuldades neste ponto. Este se mostra muitas vezes distante, tanto pela falta de disponibilidade quanto por falta de entendimento e conhecimento técnico durante as diversas reuniões para entendimento e levantamento de requisitos. Muitas vezes, o Product Owner não consegue transmitir com clareza todos os pontos relevantes para o desenvolvimento do produto por, na grande maioria dos casos, se tratar de pessoa não técnica. Alem dos funcionais, vários aspectos não funcionais muitas vezes são sequer citados em reuniões para levantamento dos requisitos.
Isso ocorre por inúmeras deficiências, que vão desde um analista de sistemas que não consegue extrair as informações de maneira adequada para posteriormente transmiti-las ao desenvolvimento, bem como o próprio entendimento incorreto por parte do desenvolvimento e demais envolvidos.
E o Analista de Testes e Qualidade? Como adaptar-se e se tornar tão ágil quanto o time com o qual está envolvido? Como manter a qualidade diante de tanta “agilidade”? As cobranças são as mesmas e até mesmo maiores, dada a resistência em algumas empresas quanto a essa nova forma de trabalho.
Neste cenário, será discutido o detalhamento quanto às mudanças nas rotinas e nos insumos recebidos para a execução das nossas tarefas, em termos de qualidade de software, dentro do novo framework BDD.
...
