Escolar Documentos
Profissional Documentos
Cultura Documentos
Livro-Texto - Unidade III
Livro-Texto - Unidade III
Unidade III
5 OS MODELOS E MÉTODOS ÁGEIS
Os métodos ágeis, desde seu surgimento, na década de 1990, têm sido apontados como uma
alternativa aos modelos clássicos ou tradicionais para o desenvolvimento de software. Dessa forma,
discutem-se, há muito tempo, as diferenças e as semelhanças entre essas duas abordagens, e algumas
características têm sido apresentadas para definir suas aplicações aos processos de software.
As abordagens tradicionais são consideradas pelos seguidores dos métodos ágeis como soluções
complexas, pesadas ou fortemente calcadas no planejamento. Com certeza, a prática mostra que elas
nem sempre conseguem atender aos projetos em que há muitas mudanças ao longo do desenvolvimento
e quando não existe muita clareza nos objetivos e soluções que deverão ser implementados.
Como atender ao ambiente extremamente dinâmico que as organizações estão vivendo e responder
rapidamente às demandas e expectativas do mercado e dos clientes? É para responder a essas indagações
que surgiram os métodos ou modelos ágeis, com suas propostas inovadoras na forma de se construir
software.
Os métodos ágeis originaram-se a partir da década, de 1990 e a principal razão apontada era o
fato de que o modelo em cascata ou modelo clássico era visto como extremamente burocrático, lento
e contraditório em relação à forma usual de os engenheiros de software realizarem seus trabalhos
com eficiência. Têm muito em comum com as técnicas de desenvolvimento rápido de aplicação, RAD,
da década de 1980, sugeridas por James Martin, Steve McConnell, entre outros autores. Mas o que
propunha o desenvolvimento RAD?
• geralmente, a falta de um pré-planejamento extensivo permite que o software seja escrito muito
mais rapidamente;
86
ENGENHARIA DE SOFTWARE I
• as técnicas estruturadas e a prototipagem são usadas para a definição dos requisitos dos usuários
e para o design do sistema final.
Recentemente, a empresa americana Ambysoft fez uma pesquisa com a intenção de verificar como
o mercado vê de que forma os times ágeis agregam valor ao cliente, e os resultados são apresentados
na figura a seguir.
O objetivo da pesquisa era explorar como as equipes ágeis adotaram os critérios ágeis, e as respostas
da figura anterior, especificamente, questionavam como os times estão agregando valor ao cliente ou
interessado.
Os resultados mostram, pelos percentuais, que os times consideram que o fator mais importante
na entrega de valor ao cliente é produzindo software (88%). Todavia, outros fatores também
foram bem-avaliados, como o debate regular com o cliente, a identificação dos objetivos dos
clientes etc.
É interessante notar que poucos consideram que o início do projeto e mudanças de pessoal são
fatores relevantes na entrega de valor ao cliente.
87
Unidade III
Observação
Outras quatro questões foram colocadas na pesquisa:
1) A equipe está validando o seu próprio trabalho?
2) A equipe trabalha em estreita colaboração com os seus stakeholders?
3) A equipe se organiza?
4) O time melhorou seu processo?
Essas questões foram embasadas nos princípios dos métodos ágeis.
A história dos métodos ágeis se inicia formalmente em fevereiro de 2001, quando membros
proeminentes da comunidade de software se reuniram em Snowbird (The Lodgeat Snowbirdski Resort,
em Utah) e adotaram o nome métodos ágeis.
De acordo com Pressman (2006, p. 52), “nasceu o Manifesto Ágil, documento que reúne os princípios
e as práticas desse paradigma de desenvolvimento”.
Uma das observações mais importantes, ainda, na atualidade, é a que diz que os métodos ágeis
são caracterizados como o oposto de metodologias guiadas pelo planejamento, ou denominadas
disciplinadas ou preditivas.
Esses quatro valores, até os dias de hoje, provocam muitas discussões calorosas, e muitos especialistas
consideram praticamente impossível a aplicação prática de todos esses valores na sua essência.
Entretanto, a maioria dos métodos ágeis tenta minimizar o risco do desenvolvimento de software ou
batalhar para eliminar a “crise do software” da seguinte maneira:
• usando ciclos curtos de tempo, chamados de iteração, sprints etc. que vão de poucos até, no
máximo, 30 dias;
• cada iteração ou sprint, ou ciclo, é como um projeto de software em miniatura e inclui todas as
tarefas necessárias para implantar o mini-incremento da nova funcionalidade:
88
ENGENHARIA DE SOFTWARE I
• métodos ágeis enfatizam a comunicação em tempo real, preferencialmente, face a face, no lugar
de documentos escritos;
• a partir dos valores do Manifesto Ágil, também foram definidos os chamados Princípios dos
Métodos Ágeis, que são:
— softwares funcionando são entregues frequentemente (em dias, semanas, em vez de meses);
— bons projetos surgem por meio de indivíduos motivados, em uma relação de confiança;
— simplicidade de projetos;
— em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, então, refina e
ajusta seu comportamento.
— essa forma de trabalho parecer semelhante à maneira pela qual as pessoas (times) utilizam os
métodos ágeis.
Outro fator importante a se analisar é a aplicabilidade dos métodos ágeis que, em geral, pode ser
examinada de múltiplas perspectivas:
• da perspectiva do produto: os métodos ágeis são mais adequados quando os requisitos são
instáveis (mudam rapidamente);
89
Unidade III
O quadro a seguir mostra uma comparação do ambiente ideal para os processos de software, tanto
os ágeis quanto os clássicos ou tradicionais.
Com relação ao gerenciamento de projetos, os métodos ágeis diferem largamente dos métodos
tradicionais no que diz respeito à forma pela qual são gerenciados, mas alguns métodos ágeis são
complementados com guias para direcionar o gerenciamento do projeto, embora nem todos sejam
aplicáveis. Contudo, diversos autores consagrados da engenharia de software fazem críticas ao método
de desenvolvimento ágil:
• esse método é, algumas vezes, criticado como codificação cowboy (termo que indica uma forma
não organizada de trabalho);
• o início da programação extrema (XP) soava como controverso e dogmático, como a programação
por pares e o projeto contínuo; alguns princípios dessa programação não foram fáceis de entender
e aplicar à cultura vigente;
Muitas dessas críticas, contudo, têm sido vistas pelos defensores dos métodos ágeis como um mal-
entendido a respeito do desenvolvimento ágil.
Observação
90
ENGENHARIA DE SOFTWARE I
Serão apresentados a seguir os principais métodos ágeis ainda vigentes e que merecem um estudo
mais detalhado. Para efeito de comparação entre uma metodologia pesada (processos tradicionais ou
clássicos) e uma metodologia leve (métodos ágeis) tem-se que uma metodologia pesada tem muitas
regras, práticas e muitos documentos associados, enquanto uma metodologia leve apresenta:
O método ágil XP é uma disciplina leve do desenvolvimento de software, que é fortemente baseada
nos seguintes princípios:
• simplicidade;
• comunicação;
• feedback;
• coragem.
A disciplina ou método ágil XP é desenhada para uso em times pequenos e para quem necessita
desenvolver softwares de forma rápida, num ambiente de mudanças constantes de requisitos.
De acordo com Beck (2001), (considerado o “pai” ou criador do método), o sucesso metodológico da
XP vem do esforço pela satisfação do cliente. O método ágil XP, quando desenvolvido por Beck, tinha
como objetivos:
• a satisfação do cliente;
91
Unidade III
Segundo o método ágil XP, existe uma limitação na definição do grupo, sendo possível um grupo de
no máximo dez pessoas, incluindo gerentes e clientes.
Lembrete
• P 2 (Prática 2): o projeto ocorre sempre em pequenas versões. Estas são produzidas em ciclos curtos
de desenvolvimento. De preferência, cada pedaço de software resultante deve ser executável e
colocado em produção junto ao cliente.
• P 3 (Prática 3): metáfora. Todos utilizam nomes comuns e uma linguagem comum nos seus
códigos. A padronização na escrita dos códigos é fundamental para o sucesso do método.
• P 4 (Prática 4): design simples. Não existe mais o “construir para o futuro”. O software resolve
o problema de agora, sem perda de tempo estudando as futuras manutenções ou as novas
funcionalidades. É uma proposta que quebra o paradigma tradicional, em que uma arquitetura
deve ser trabalhada antes de se iniciar a codificação propriamente dita.
• P 5 (Prática 5): testes. A validação do software ocorre durante todo o tempo do desenvolvimento,
e não no final da construção. Os códigos vão sendo construídos e testados de forma conjunta.
• P 7 (Prática 7): programação em pares. O código é desenvolvido por dois programadores trabalhando
juntos. Essa prática faz que o código não tenha um único “dono” e resolve o problema da ausência
de um dos desenvolvedores.
• P 8 (Prática 8): propriedade coletiva. Todo o código pertence a todos da equipe. Não existe “dono”
do código, como nos métodos tradicionais.
• P 9 (Prática 9): integração contínua. A equipe integra o software muitas vezes ao dia, na busca da
solução dos problemas de integração, tão comuns nos métodos tradicionais de desenvolvimento.
• P 10 (Prática 10): quarenta horas de trabalho semanais. De acordo com o XP, programadores
cansados cometem mais erros e prejudicam o andamento do projeto.
92
ENGENHARIA DE SOFTWARE I
• P 11 (Prática 11): cliente fazendo parte da equipe. Um projeto XP é conduzido por um cliente, e
decisões são definidas por ele o tempo todo.
• P 12 (Prática 12): codificação-padrão. Os códigos são escritos da mesma forma por todos os
envolvidos no projeto.
A seguir, a figura apresenta uma visão do método ágil sob o ponto de vista do ciclo de desenvolvimento.
Histórias de Cenários de
usuário testes
Metáforas Plano de
do sistema liberação
Próxima Última
iteração versão
Estimativas
incertas
Estimativas
Riscos confidenciais
Apesar do sucesso do método XP, principalmente, nos meios acadêmicos e nas pequenas fábricas de
software, existem críticas ao método.
O autor Matt Stephens, em seu livro Extreme Programming Refactored (STEPHENS; ROSENBERG,
2003), faz uma revisão no método e apresenta as seguintes críticas:
• requer a adoção de mudança cultural: este é um fator importante a ser considerado quando se
pretende adotar o método XP;
• poder levar a maiores dificuldades nas negociações contratuais: como se sabe, os clientes se
protegem por meio de contratos formais que não são aceitos no método XP nem fazem parte da
sua estrutura, o que acaba contrastando com a realidade vivida pelas organizações.
Saiba mais
O método Scrum, inicialmente, foi concebido como um estilo de gerenciamento de projetos ágeis
em empresas de fabricação de automóveis e produtos de consumo (NONAKA; TAKEUCHI, 1986).
Na atualidade, existe uma discussão sobre o método Scrum que sempre vem à tona. Ele é um
framework ágil para projetos de software ou uma metodologia de gerenciamento de projetos? Para
responder de forma mais acadêmica, recorrendo aos principais dicionários (Aurélio, 1988; Houaiss,
2012; e Michaelis, 2009), encontramos o conceito de metodologia:
• implica algo que define procedimentos, regras documentadas (ou o estudo destas), para a
regulamentação de uma determinada disciplina;
94
ENGENHARIA DE SOFTWARE I
Com base nessas definições, pode-se afirmar que o método Scrum não se encaixa em nenhuma
das definições anteriores. Isso porque o método não ensina a fazer pesquisa, não ensina ciência,
nem responde a perguntas da engenharia de software que possam surgir no decorrer do ciclo de
vida de um software. Essas definições descartam Scrum como metodologia de imediato, tendo
em vista que se desenvolveu independentemente dos processos de software e pode ser aplicado,
também, a outras realidades de projetos. Daí ser tratado, neste texto, como um método ágil de
gestão de projetos.
Saiba mais
Uma característica importante do método é forçar as pessoas a seguirem passos predefinidos, com
pouca flexibilidade para mudança. A abordagem é o oposto do modelo em cascata, iniciando-se na
análise, assim que alguns requisitos estiverem disponíveis.
O projeto começa com uma visão composta por requisitos e funcionalidades que concretizam uma
lista de tarefas, denominada product backlog. As prioridades dos itens desse documento determinam
o quanto de valor cada um gera para o negócio. Depois de priorizados os itens, antes de cada iteração
(sprint), a equipe se reúne para dizer quantos itens é possível entregar em um sprint, que, segundo
Schwaber (2002), deve durar cerca de trinta dias, como boa prática.
95
Unidade III
Reunião diária
do time
2-4
semanas
Potentially
Sprint shippable
Product backlog product
backlog increment
Ao final da iteração ou do sprint, conforme ilustra a figura anterior, o que foi desenvolvido é
apresentado ao cliente em uma reunião, e, antes do início da próxima iteração, é feita uma reunião de
retrospectiva, em que é possível extrair lições aprendidas, para a melhoria do processo Scrum daquele
projeto.
O Scrum define diversos papéis a serem desempenhados durante o projeto, que são:
• product owner:
— pode ser definido como o dono do projeto, ou o responsável por este; é quem define e prioriza
as funcionalidades do produto;
• Scrum master:
• Scrum team:
• Sprint planning:
— uma reunião efetuada antes do início de um sprint, para o time alinhar com o product owner
o que será feito dentro do próximo sprint.
96
ENGENHARIA DE SOFTWARE I
O Scrum define um conjunto de fases que devem ser seguidas durante a execução do projeto, que
são:
• planning: de acordo com as práticas adotadas por Schwaber (2002), o planejamento do sprint
deve defini-lo para ocorrer em trinta dias;
• daily Scrum: são reuniões diárias em que cada membro do time coloca em um quadro o que fez
no dia anterior e o que fará no dia seguinte; direcionamentos no projeto devem ocorrer durante
essas reuniões para reduzir as possibilidades de o sprint não dar certo ou não ser cumprido no
prazo acordado;
• retrospective ou sprint review: é uma reunião de lições aprendidas que ocorre após a entrega
de um sprint e tem como objetivo analisar se o que foi feito está de acordo e o que pode ser
melhorado.
A figura a seguir mostra um exemplo do quadro daily scrum utilizado para ilustrar a situação dos
trabalhos durante um sprint no método Scrum.
Sprint 1
Item da Para fazer Em andamento Para verificar Concluído
backlog
Impedido
Requisito
2 Atividade
Atividade 1
2
José
Para estimar o número de funcionalidades que serão produzidas por sprint, Schwaber (2002) propõe
um método chamado pokergame, em que cada membro do time dá uma nota que equivale a um peso.
Os pesos são denominados de acordo com uma progressão aritmética, ou seja, 1, 2, 3, 5, 8, 13 e 21.
97
Unidade III
O peso que se repetir mais vezes pelos membros do time é que valerá para a funcionalidade. Ao total
de funcionalidades, os pesos são somados, e essa é a estimativa de entrega em um sprint.
Observação
O monitoramento do progresso do projeto é realizado por meio de dois gráficos principais: o product
burn down chart e o sprint burn down chart.
Os gráficos mostram, ao longo do tempo, a quantidade de trabalho que ainda resta para ser feito,
constituindo um excelente mecanismo para visualizar a correlação entre a quantidade de trabalho que
falta realizar (em qualquer ponto) e o progresso do time do projeto em reduzir esse trabalho (BARBOSA;
LIBARDI, 2010).
A próxima figura mostra um exemplo do gráfico burn-down chart, onde se veem o progresso ideal
e o progresso realizado ao longo de seis dias.
140
120
100
Horas
80 Ideal
60 Realizada
40
20
0
1 2 3 4 5 6
Dia
98
ENGENHARIA DE SOFTWARE I
Saiba mais
O Iconix é um processo de análise e desenvolvimento de software dirigido por casos de uso e aplica
apenas cinco diagramas da UML, dos quais dois são adendos; utiliza prototipação desde o início da
definição do software e é mais simples que o processo unificado Rational Unified Process (RUP), porém
sem a simplicidade do método ágil XP.
A figura a seguir mostra uma visão das fases do processo envolvido no Iconix.
99
Unidade III
Análise de Requisitos
Prototipação requisitos de software
Revisão dos
requisitos
Projeto
Durante as fases, os desenvolvedores aplicam os diagramas da UML propostos pelo método Iconix,
como mostra a figura.
100
ENGENHARIA DE SOFTWARE I
Modelos dinâmicos
Protótipo Modelo de
Diagrama de
caso de uso
sequência
Diagrama de robustez
Modelos estáticos
Toda a proposta se inicia com a prototipagem, que é a forma de descobrir, detalhar e garantir
os requisitos do software a ser produzido. Com o protótipo e os requisitos definidos, parte-se para a
construção do diagrama de caso de uso, que conterá as funcionalidades a serem implementadas no
produto de software.
Paralelamente, vai-se construindo o modelo de domínio do projeto, isto é, o modelo dos dados que
serão armazenados no produto de software. Na fase de construção, utilizam-se o modelo de robustez, o
diagrama de sequência e o diagrama de classes, para a construção efetiva dos códigos do software. Ao
final, têm-se os códigos, que são validados, ajustados e colocados à disposição do cliente em produção
ou implantação.
O método Iconix preconiza que os casos de uso sejam o mais simples possível, sem ambiguidades,
podendo fazer referência aos objetos do protótipo.
Lembrete
Os passos para se aplicar o processo e os diagramas da UML propostos pelo Iconix são:
101
Unidade III
— diagrama de robustez: faz a derivação dos cenários dos casos de uso em uma visão de solução
técnica dentro das camadas de interface, lógica da aplicação e camada de banco de dados;
— diagrama de sequência: mostra a lógica das transações por meio da comunicação entre os
objetos do sistema e a passagem de comunicação entre eles (mensagens);
— diagrama de domínio: é a visão das entidades de dados no nível de negócio, com seus dados
básicos e seus relacionamentos de alto nível.
• programar a interface de modo que ela implemente o que o caso de uso determina;
Percebe-se que, mesmo não abrindo mão de alguns diagramas, o método ágil Iconix é razoavelmente
simples e muito robusto. O processo permite que os erros de análise e as dúvidas dos clientes ou usuários
sejam minimizadas conforme as iterações do processo ocorrem.
Saiba mais
O método ágil FDD já existia antes do Manifesto Ágil, que ocorreu em 2001. Foi concebido
originalmente por Jeff de Luca, em Singapura, entre os anos de 1997 e 1999, com base no método
Coad (criado por Peter Coad, nas décadas de 1980 e 1990) e nos processos interativos e Lean,
já utilizados por ele; busca o desenvolvimento por funcionalidade, ou seja, por um requisito
funcional do sistema; é prático para o trabalho com projetos iniciais ou projetos com codificações
existentes. Apesar de haver algumas diferenças entre os métodos FDD e XP, é possível utilizar as
melhores práticas de cada um.
102
ENGENHARIA DE SOFTWARE I
O FDD atua bem em conjunto com o método Scrum, pois como este atua no foco do gerenciamento
do projeto, e o FDD, no processo de desenvolvimento, eles se complementam.
Assim como acontece no método XP, o FDD faz uso intenso de teste de software. Dessa forma, é
possível utilizar, também, na codificação, o método TDD (é indicada a utilização deste para manter a
qualidade do software). Daí temos a combinação do FDD, como processo, do Scrum, como gestão do
processo, e do TDD, como ênfase na codificação dirigido por testes.
O pessoal que desenvolveu o método FDD acredita, assim como a teoria de sistemas afirma, que a
soma das partes é maior do que o todo. Dessa forma, apesar de criar um modelo abrangente baseado no
todo que será desenvolvido (ver o sistema completo primeiro), essa fase se inicia com o detalhamento
do domínio do negócio, com divisão das áreas que serão modeladas.
O modelo só estará pronto quando todos da equipe estiverem de acordo. O planejamento é feito
com base na lista de funcionalidades ou requisitos do software. Trabalhando com FDD, em conjunto com
o Scrum, a lista de funcionalidades seria utilizada no backlog de produtos, como histórias de usuários a
serem desenvolvidas.
Aplicando-se o Scrum e separando-se o que será feito no sprint, essas funcionalidades serão
colocadas no seu backlog.
O que está no backlog são funcionalidades que serão desenvolvidas durante o sprint (que pode ser
de duas a quatro semanas, conforme sugere o método Scrum). Essas tarefas são então planejadas com
maior rigor, e, nesse ponto, tem-se o planejamento incremental, ou seja, planeja-se apenas o que vai ser
desenvolvido. Nessa etapa, os envolvidos no processo são apenas os componentes da equipe, ou seja,
desenvolvedores, analistas, testadores etc. que vão atuar no processo. Eles devem selecionar os itens
com base no tempo que possuem e nas qualificações atuais da equipe.
103
Unidade III
Após o planejamento, é feito o detalhamento. Nessa fase, é de extrema importância que o desenho
esteja de acordo com o que o cliente deseja, sendo mantido contato constante com esse cliente, como
em todas as metodologias ágeis. Essa documentação é a base para o desenvolvimento: não se deve
perder tempo com documentação que não será utilizada, mas é necessário registrar.
Um ponto que diverge do método XP é que, no FDD, o desenvolvedor é incentivado como o único
responsável pelo módulo que desenvolve; já no XP, o código é comunitário.
Saiba mais
A figura a seguir mostra a visão gráfica do conceito de integração contínua aplicado no método
FDD.
Design ou
projeto
Inspeção do design
Codificação
(sugere-se o TDD)
Integração
Inspeção de
código
Build completo
(entregável)
104
ENGENHARIA DE SOFTWARE I
Utilizar a integração contínua permite que a equipe esteja em contato constante com o cliente,
tornando o processo ágil e com entregas também constantes.
Como cada fase apresentada na figura anterior é específica e curta, e como as fases se completam,
são necessárias informações para manter o controle, bem como para analisar a quantidade de recursos
que estão sendo desenvolvidos de modo semelhante ao burn down e ao burn up do Scrum.
• projeto: 40%;
• desenvolvimento: 45%;
• integração: 1%.
Saiba mais
O método FDD aplica as chamadas melhores práticas, que indicam boas práticas ao desenvolver
com o FDD:
• gerenciamento de configuração;
• é iterativo e incremental;
• pode ser aplicado também a sistemas grandes e complexos;
• é considerado um arcabouço para evitar o caos;
• o cliente sempre está presente durante o processo;
• desenvolvimento de aplicações em conjunto com a técnica de reunião Joint Application
Development (JAD).
A próxima figura mostra os ciclos do processo ASD, que é constituído de três fases:
Colaborar Especular
Aprender
• especular (speculate): fase em que se fixam prazos e objetivos, e se define um plano baseado em
componentes;
• colaborar (collaborate): fase em que se constrói de forma concorrente os vários componentes;
• aprender (learn): fase em que são efetuadas repetitivas revisões de qualidade e foco na
demonstração das funcionalidades desenvolvidas (learning loop); conta com a presença do cliente
e de especialistas do domínio.
106
ENGENHARIA DE SOFTWARE I
• orientado a missões (misson-driven): atividades são justificadas por uma missão que pode mudar
ao longo do projeto;
• orientado a riscos (risk driver): itens de alto risco são desenvolvidos primeiro.
Com relação a cargos e responsabilidades, o ADS não os descreve em detalhes, mas define:
• desenvolvedores (developers).
Viabilidade
Modelo
funcional Implementação
(iteração)
Design e
construção
(iteração)
O método ágil DSDM define um conjunto de cargos e responsabilidades que devem ser obedecidos
pelos times participantes do processo de desenvolvimento e de suas fases:
O método ágil Crystal/Clear faz parte de um conjunto de metodologias criadas pelo autor Cockburn
(2004), editor da série Agile Software Development, com diversos livros publicados pela Addison-Wesley.
Saiba mais
• o método Crystal/Clear foi direcionado para projetos pequenos com equipes de até seis
desenvolvedores;
• toda especificação e todo projeto são feitos informalmente, utilizando quadros publicamente
visíveis;
• os requisitos são elaborados utilizando casos de uso (UML), um conceito similar às histórias de
usuários XP;
• as entregas das novas versões de software são feitas em incrementos regulares de um mês;
• podem existir alguns subprodutos do processo que são responsabilidade de membros específicos
do projeto.
Grande parte do método é pouco definida e, segundo Cockburn (2004), isso é proposital. A ideia do
Crystal/Clear é permitir que cada organização implemente as atividades que lhe pareçam adequadas,
fornecendo um mínimo de suporte útil, do ponto de vista de comunicação e documentos.
O método ágil TDD de desenvolvimento de software, que se baseia em um ciclo curto de repetições,
caracteriza-se por:
• primeiro, o desenvolvedor escreve um caso de teste automatizado que define uma melhoria
desejada ou uma nova funcionalidade;
• depois é produzido um código que possa ser validado pelo teste, para, posteriormente, ser
refatorado para um código sob padrões aceitáveis.
Por meio do TDD, programadores podem aplicar o conceito para melhorar e depurar código legado
desenvolvido a partir de técnicas antigas. O TDD requer dos desenvolvedores a criação de testes de
unidade automatizados antes de escrever o código da aplicação.
• Adicionar um teste:
— esse teste precisa, inevitavelmente, falhar, porque é escrito antes de a funcionalidade ser
implementada (se não falhar, a funcionalidade ou melhoria “proposta” será óbvia);
110
ENGENHARIA DE SOFTWARE I
— o desenvolvedor pode fazer isso por meio de requisitos, casos de uso ou user stories que
abranjam as funcionalidades e exceções condicionais;
— ele torna o desenvolvedor focado nos requisitos “antes” do código, o que é uma sutil, mas
importante diferença;
— esse passo valida se todos os testes estão funcionando corretamente e se o novo teste não traz
nenhum equívoco, sem requerer nenhum código novo;
— pode-se considerar que esse passo testa o próprio teste: ele regula a possibilidade de o novo
teste passar;
— o novo teste deve, então, falhar, pela razão esperada: a funcionalidade não foi desenvolvida;
— isso aumenta a confiança de que se está testando a coisa certa, e de que o teste somente irá
passar nos casos intencionados.
• Escrever código:
— o novo código escrito até esse ponto poderá não ser perfeito e, por exemplo, passar
no teste de uma forma não elegante; isso é aceitável, porque posteriormente ele será
melhorado;
— o importante é que o código escrito deve ser construído somente para passar no teste;
nenhuma funcionalidade (muito menos não testada) deve ser permitida em qualquer
ponto;
— se todos os testes passarem, o programador poderá ficar confiante de que o código possui
todos os requisitos testados;
111
Unidade III
• Refatorar código:
— nesse ponto, o código pode ser limpo tanto quanto for necessário;
— ao executar novamente os testes, o desenvolvedor pode confiar que a refatoração não será um
processo danoso a nenhuma funcionalidade existente;
— nesse caso, entretanto, significa remover qualquer duplicação entre código de teste e código
de produção.
• Repetir tudo:
— iniciando com outro teste, o ciclo é então repetido, empurrando a funcionalidade para frente;
— o tamanho dos passos deve ser pequeno – de uma a dez edições de texto entre cada execução
de testes;
— se o novo código não satisfizer rapidamente um novo teste ou outros testes falharem
inesperadamente, o programador deverá desfazer ou reverter as alterações, em vez do uso de
excessiva depuração;
Observação
A modelagem ágil ou MA tem sido proposta por diversos autores consagrados como um caminho
alternativo para as pessoas que querem mais do que os métodos ágeis oferecem, todavia não podem
abrir mão de um pouco de documentação, padrões e contratações formais.
112
ENGENHARIA DE SOFTWARE I
A figura a seguir apresenta uma visão sobre os extremos que as metodologias, os métodos e os
modelos apresentam na atualidade.
A modelagem ágil (MA), de acordo com Ambler (2004), é uma metodologia baseada na prática e
na documentação eficazes de sistemas baseados em software. É um conjunto de práticas guiadas por
princípios e valores para profissionais de software aplicarem em seu dia a dia. A MA não é um processo
prescritivo.
• definir e mostrar como colocar em prática um conjunto de valores, princípios e práticas relativas
a uma modelagem eficaz e leve; esse objetivo segue os princípios dos métodos ágeis;
• lidar com a questão de como aplicar técnicas de modelagem de projetos de software adotando
uma perspectiva ágil; esse objetivo visa a garantir um pouco da interação escrita nas formas de
comunicação;
• discutir como se pode melhorar as atividades de modelagem adotando uma perspectiva “quase ágil”
para equipes de projetos prescritivos; mudança de paradigma no desenvolvimento convencional e
clássico.
A MA adota os valores XP de Kent Beck, que são: comunicação, simplicidade, feedback e coragem.
Mas adiciona um quinto valor, a humildade.
113
Unidade III
Humildade para admitir que você pode não saber tudo e que outros têm valor a acrescentar aos
esforços no projeto. Ainda de acordo com os autores da modelagem ágil:
— é compreensível;
— é suficientemente preciso;
— é suficientemente consistente;
— é suficientemente detalhado;
Resumo
115
Unidade III
Exercícios
Questão 1. O Manifesto Ágil é um documento criado em 2001, em Utah, EUA, por diversos
especialistas em processos de desenvolvimento, que reúne os princípios e os valores adotados para os
métodos ágeis. A partir dessa constatação, têm-se os seguintes valores:
I) Afirmativa correta.
Justificativa: essa afirmativa não faz parte do Manifesto Ágil, e um time motivado faz parte dos
princípios dos métodos ágeis.
116
ENGENHARIA DE SOFTWARE I
V) Afirmativa correta.
II – O método ágil Scrum também pode ser entendido como uma metodologia completa de
desenvolvimento de software.
III – O método Scrum pode ser entendido como um processo particular das metodologias clássicas.
IV – O método XP começa com uma arquitetura de risco e, a partir dos riscos, desenvolve soluções
por meio de pequenas iterações.
V – O método Iconix é semelhante aos métodos XP e Scrum, pois trabalha praticamente com os
times se comunicando face a face e com quase nenhuma documentação.
117