Recursos especiais neste artigo:
Conteúdo sobre Agilidade.
Este artigo aborda o desenvolvimento de software guiado por critérios de aceitação. Sabemos que as estórias dos usuários são necessidades do cliente e o que o mesmo espera do sistema para atender as suas expectativas. Para que possamos finalizar uma estória temos requisitos mínimos a cumprir e podemos ter nosso desenvolvimento baseado nesses requisitos, que no fundo são seus critérios de aceitação.
Em que situação o tema é útil
Descrever bem uma estória do usuário colocando os critérios de aceitação para finalizar a mesma e em cima disso construir seus testes automatizados pode ser uma boa prática para a qualidade do seu software e a integração contínua do seu projeto. O conteúdo apresentado no artigo foca no valor do que está sendo gerado no seu projeto e procura atingir ao objetivo final que é se ter um software de qualidade e atingindo aos objetivos do usuário final.
A engenharia de software vem passando por mudanças nos últimos anos. No início dos anos 70, tivemos o primeiro modelo de desenvolvimento de sistemas que foi o modelo clássico, mais conhecido como cascata, que é inspirado nos modelos das atividades da engenharia convencional e conhecido por uma abordagem “top-down” em que as atividades do processo de desenvolvimento tem como entrada o fim do processo anterior. Foi o principal modelo utilizado para construção de sistemas grandes por anos e passou a ser criticado por ser linear, rígido e monolítico (sem participação de usuários e clientes, somente ter o software implementado e entregue). Esse método de desenvolvimento acabava sendo falho pelo simples fato de que requisitos sofrem mudanças com o tempo. Muitas vezes aquilo que foi levantado inicialmente já não condiz com a realidade do negócio ao final de todo o processo de desenvolvimento, fazendo com que os sistemas implementados já viessem desatualizados.
Para sanar as necessidades não supridas pelo modelo cascata, nasceu a metodologia RUP (Rational Unified Process), que é um produto/processo iterativo, incremental e customizável de Engenharia de Software pertencente à IBM desde 2003. O RUP está fundamentado em três princípios básicos: orientação a casos de uso, arquitetura e iteração. Os casos de uso envolvem várias características por todo processo de concepção de um sistema, como, regras de negócio, requisitos não-funcionais dentre outros. Casos de uso são documentos e podem ter diferentes aplicações ao longo do processo de desenvolvimento e manutenção de software, podendo ser úteis em diferentes contextos.
O RUP ajudou a engenharia de software, porém começou a se deparar com um problema. As pessoas passavam meses fazendo páginas e mais páginas de documentação e entregam para desenvolvedores que precisavam ler tudo, interpretar os textos e traduzir tudo para código. Ocorriam problemas de interpretação e geralmente nem tudo era lido antes de começar o desenvolvimento. Depois vinha a frase conhecida do cliente “mas não era isso que eu queria”. Como é difícil manter a documentação pois os requisitos mudam, muitas vezes, o cliente descobre o que realmente queria só depois de começar a usar o software, gerando assim retrabalhos. Esses documentos, normalmente chamados de contrato, serão o alicerce de discussões entre clientes e prestadores e, muitas vezes se encontram tão desatualizadas que os casos de uso passam a ser referências para acordos por e-mail ou qualquer outra forma de comunicação entre analistas de requisitos e clientes.
O RUP é um framework e nada impede do RUP ser customizado para ser uma metodologia ágil. É fundamental para qualquer profissional envolvido em um desenvolvimento de sistema a presença de documentação, porém para o usuário final o mais importante é um software funcionando e atendendo as suas necessidades do que o detalhamento de todos os escopos em um documento. Melhor ainda se a documentação for executável para garantir que esteja refletida no código. Por esse motivo surgiu o Manifesto Ágil dando origem às metodologias ágeis e consequentemente ao Scrum.
O manifesto ágil foi criado por 17 pessoas que trabalhavam em um projeto nos EUA, entre eles Martin Fowler e Kent Beck, tem como principais valores:
· Indivíduos e interações mais que processos e ferramentas;
· Software em funcionamento mais que documentação abrangente;
· Colaboração com o cliente mais que negociação de contratos;
·
Responder a mudanças mais que seguir um plano." [...] continue lendo...
Artigos relacionados