[UNIP] Metodologia Ágil - 2019

Prévia do material em texto

Metodologia Ágil 
A busca pela padronização de processos e por práticas de excelência na gestão de projetos é constante em 
empresas que desejam a melhoria contínua de suas operações. Nesse tipo de ambiente, a metodologia ágil 
(também conhecida como agile) surge como uma alternativa vantajosa devido aos seus potenciais, 
principalmente para organizações que atuam em setores ligados à tecnologia. 
Por englobar orientações e métodos que contribuem para que equipes desenvolvam soluções mais eficientes e 
dinâmicas, a metodologia ágil otimiza fluxos de trabalho e melhora a produtividade de projetos. 
Em outras palavras, essa metodologia é capaz de elevar significativamente as perspectivas de sucesso do seu 
negócio. Para se ter uma ideia, de acordo com a PWC, projetos ágeis chegam a ser 28% mais bem-sucedidos do 
que os convencionais. 
O que é o manifesto ágil? 
Para entender o que compõe o escopo das chamadas metodologias ágeis, é preciso, antes, saber o que é o 
manifesto ágil. No começo de 2001, um grupo de 17 desenvolvedores reconhecidos se juntou em Utah, nos EUA, 
para discutirem maneiras de desenvolvimento mais leves com base em suas experiências. 
Eles assinaram um documento chamado “Manifesto para o Desenvolvimento Ágil de Software”, que estabeleceu 
12 princípios da metodologia ágil, além de 4 fundamentos-chave: 
 “indivíduos e interações acima de processos e ferramentas”; 
 “software funcionando acima de documentação abrangente”; 
 “colaboração com o consumidor/cliente acima de negociação de contratos”; 
 “responder a transformações/mudanças mais do que seguir um plano”. 
O conceito é que, mesmo existindo valor nos elementos localizados no final das frases, valoriza-se mais os que 
estão em negrito. 
O que é metodologia ágil? 
Desde o manifesto, muitas obras foram desenvolvidas abordando as chamadas metodologias consideradas ágeis, 
que aprimoram a atuação dos times de colaboradores. Seus princípios, antes empregados mais em tecnologia, 
passaram a ser aplicados em outros campos, como na área de projetos e em marketing. 
A metodologia ágil é uma alternativa ao modelo tradicional de gestão de projeto. O objetivo é auxiliar as 
empresas a lidarem com imprevisibilidades dentro de projetos, por intermédio de ciclos que estimulam maior 
interação entre consumidores e colaboradores. 
Existem entregas parciais dinâmicas e constantes, isto é, o cliente não necessita aguardar muito tempo para 
acessar resultados. A metodologia ágil ainda estimula a adaptação contínua e a atuação em equipe. Foco no 
consumidor, produção de maior valor agregado e auto-organização integram os seus pilares. 
Suas práticas têm por propósito a entrega rápida e de alta qualidade do produto final do projeto, permitindo 
ainda que seja entregue em partes à medida que se desenvolve. Basicamente, as abordagens das metodologias 
ágeis sintonizam a criação e a condução de projetos aos objetivos do negócio e às necessidades dos 
consumidores. 
Qual é a sua importância para as empresas? 
Como visto, essa metodologia une sua filosofia a um conjunto de princípios de desenvolvimento para melhorar 
as entregas e os itens produzidos. Dessa forma, as metodologias ágeis têm por finalidade maximizar o trabalho 
das equipes de projetos e os resultados gerados aos clientes, tendo por base seus 12 princípios: 
 
 
1. Ter como prioridade a satisfação do cliente por meio de entregas de valor contínuas e rápidas; 
2. Ser receptivo a alterações nos requisitos em qualquer fase do processo. Aliás, ambientes mutáveis são 
empregados em toda etapa do projeto para entregar ao cliente vantagem competitiva; 
3. Realizar entregas frequentes (do produto ou serviço), no menor período de tempo possível; 
4. Manter a colaboração das partes envolvidas em todo o projeto, diariamente; 
5. Fornecer o ambiente, as ferramentas e o suporte necessários aos indivíduos do projeto, além de 
acreditar neles para realizarem as atividades; 
6. Estimular a comunicação pessoal, que transmite as informações necessárias ao time de colaboradores, 
sendo o meio mais eficiente. Nesse ponto, atenção especial para reuniões presenciais, consideradas mais 
eficazes para o sucesso do projeto; 
7. Um produto final de trabalho corresponde à medida final do êxito. No caso da tecnologia, a medida 
primária de progresso consiste no software em funcionamento; 
8. Os profissionais envolvidos no processo precisam manter um ritmo constante, de modo indefinido, pois 
fluxos ágeis estimulam um desenvolvimento sustentável. De outra forma, temos que o desenvolvimento 
sustentável é feito por intermédio de processos ágeis, por meio dos quais as partes interessadas conseguem 
manter um ritmo contínuo; 
9. Manter atenção frequente à excelência de design e técnica eleva ou aprimora a agilidade; 
10. Eliminar o máximo de esforços que não geram valor ao produto, pois a simplicidade é fundamental; 
11. Equipes auto-organizáveis propiciam os melhores designs e arquiteturas, além de atender aos 
requisitos do projeto; 
12. Por meio de intervalos regulares, o time de colaboradores do projeto reflete sobre como melhorar a sua 
eficiência e eficácia para otimizar o seu comportamento. 
Esses princípios geram benefícios às empresas, como aumento na satisfação do público e comunicação ativa 
entre os participantes do projeto e os clientes. Isso pode reduzir custos. Além do mais, há grande enfoque em 
prazos, de modo que é possível sincronizar o cronograma de execução de orçamento do projeto com as etapas 
e entregas aos clientes. 
Quais são as principais tendências ou métodos de uso relacionados à 
metodologia ágil? 
Existem métodos que se utilizam de processos ágeis para fortalecerem as suas abordagens, tornando os 
procedimentos em que são aplicados mais eficientes. Veja alguns exemplos adiante. 
Kanban 
Kanban, termo de origem japonesa que significa, literalmente, “cartão” ou “sinalização”. Seu conceito está 
relacionado ao uso de cartões — posteriormente de post-it, luzes, caixas vazias etc. — para indicar o status de 
transportes ou fluxos de produção em companhias de fabricação em série. 
Scrum 
Scrum consiste em uma metodologia ágil para planejamento e gerenciamento de projetos (especialmente de 
software). Nele, cada projeto é segmentado em ciclos, geralmente mensais, conhecidos como sprints. O Sprint 
consiste em um time box (caixa de tempo), ou um intervalo, em que um conjunto de atividades deve ser 
realizado. 
Lean 
A Metodologia Lean é anterior ao manifesto ágil, tendo surgido no Japão do pós-guerra, em indústrias 
automobilísticas que desejavam ser mais produtivas. Contudo, projetos Lean que incorporam conceitos ágeis em 
sua realização se tornam muito eficientes. Por compreender modelos de processos enxutos, com poucos 
desperdícios, essa abordagem é compatível com as metodologias ágeis. 
Fonte: www.totvs.com 
 
https://www.totvs.com/blog/scrum-o-que-e-e-como-aplicar-o-metodo-agil-entre-desenvolvedores/
http://www.totvs.com/
 
Práticas XP dentro do Scrum 
O Scrum é um processo de produção iterativo e incremental para gerenciamento de projetos e desenvolvimento 
ágil de software (e de qualquer outro projeto). Geralmente o Scrum é adotado por uma equipe de 
desenvolvimento de produtos. 
O Scrum pode ser encarado como um framework com objetivo de organizar um conjunto de tarefas a ser 
realizadas objetivando a execução de um projeto. 
No Scrum todas as tarefas são aglutinadas na Product Backlog – este artefato é caracterizado como uma lista 
de tudo aquilo que é necessário para executar o projeto. 
A Product Backlog é fracionada, gerando listas menores – as Sprints Backlog. Estas listas são inseridas nas 
Sprints. 
As Sprints caracterizam como ciclos temporais de trabalho, a duração de cada Sprint é de 2 a 4 semanas. 
Diariamente, os envolvidos com o projeto realizam as Daily Scrum Meeting – reuniões diárias com o objetivo 
de verificar, junto aos membros da equipe (Scrum Team): 
1. O que você foifeito ontem? 
2. O que você vai fazer hoje? 
3. Existe algum impedimento? 
Importante: Todos os membros Scrum Team devem participar destas reuniões. 
Após o término das Sprints, o proprietário do produto (Product Owner) recebe parte do produto pronto gerado 
pelo projeto. É importante salientar que esta parte deve possuir um valor agregado. 
Outro fator a ser destacado, o Scrum prevê também quw todo o projeto seja gerenciado pelo Scrum Master 
(“responsável por garantir que o Scrum Team se orienta pelos valores e práticas do Scrum”). 
Programação extrema (do inglês eXtreme Programming – (XP)), é uma metodologia ágil para equipes pequenas 
e médias e que irão desenvolver projetos com requisitos vagos e em constante mudança. A estratégia de constante 
acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software é uma constante 
na metodologia. 
O XP possui práticas interessantes, este texto destaca: 
Produção em Pares: O colaborador nunca trabalha sozinho. Sempre existem dois colaboradores (o piloto e o 
navegador) trabalhando, ao mesmo tempo, em um mesmo problema. 
Padronização: A utilização de um padrão é uma prática em empresas que possuem um processo 
institucionalizado. 
Refabricar: Esta prática recomenda tudo àquilo mal formulado sofra a nova fabricação, isto é, o artefato do projeto 
deve ser reescrito. 
Metáfora: Formalmente, metáfora é uma figura linguística, em que há a substituição de um termo por outro, 
criando-se uma dualidade de significado. A metáfora é utilizada para explicar a ideia central do projeto de forma 
simples e objetiva. A utilização de metáforas aumenta a comunicabilidade com o cliente. 
Design Simples: Desenvolva somente aquilo que foi solicitado. Não especule, a produção especulada, na maioria 
das vezes, não é utilizada pelo cliente. 
 
 
Jogo do Planejamento: Nas práticas ágeis as necessidades dos clientes são mapeadas em cartões de estórias. O 
cliente recebe um cartão, daqueles que você compra em uma livraria e nele é escrito tudo que uma determinada 
funcionalidade deve conter. O cliente juntamente com a equipe irá mapear o sequenciamento para o 
desenvolvimento das funcionalidades definidas nos cartões. 
Reuniões em pé. Para agilizar o processo, todas as reuniões devem ser realizada em pé e possuírem horário de 
início e término. As reuniões não devem ultrapassar 30 minutos. 
Após apresentar uma visão do Scrum e do XP, o texto propõe por meio de uma figura genérica a inserção das 
práticas XP dentro do Scrum. 
 
Perceba que as práticas do XP são grafadas em retângulos azuis, elas são inseridos no Scrum por meio das setas, 
por exemplo: 
A metáfora pode ser aplicada na construção da Product Backlog; 
As reuniões em Pé podem ser utilizadas para agilizar o Daily Scrum Meeting. 
Por fim é importante salientar que a figura pode ser instanciada para qualquer tipo projeto objetivando a sua 
construção de forma organizada, padronizada, qualitativa e ágil. 
Fonte: José Augusto Fabri – fabri@utfpr.edu.br 
 
mailto:fabri@utfpr.edu.br
 
Kanban 
O método Kanban foi concebido como um caminho alternativo à agilidade organizacional. Ao invés de grandes 
mudanças, o Kanban propõe uma abordagem evolucionária, onde pequenas melhorias são integradas na 
prestação de um serviço ou desenvolvimento de um produto. 
Nascido dentro do Sistema Toyota de Produção (TPS), o kankan (com k minúsculo) era um cartão utilizado para 
sinalizar conclusão de etapas do processo e tornar o fluxo puxado. Mais tarde, David J. Anderson criou o método 
Kanban (com K maiúsculo) e popularizou o seu uso no desenvolvimento de produtos e serviços. 
Entendendo um sistema Kanban 
Um sistema Kanban é composto por um fluxo de valor, onde unidades de trabalho trafegam da esquerda para a 
direita. Cada etapa do processo adiciona mais valor ao item, sendo que quando ele chega ao final do processo, 
ele está “concluído”. Esse fluxo de valor pode ser o desenvolvimento de um software, a prestação de um serviço 
(como atendimento ao cliente) ou até a criação de um produto físico. 
Vamos supor que fazemos parte de um time de desenvolvimento de um aplicativo. O nosso processo atual tem 
algumas etapas, que podemos mapear na forma de colunas “Backlog”, “Design”, “Desenvolvimento”, “Testes”, 
“Deploy” (implantação) e “Pronto”. Neste quadro Kanban, as unidades de trabalho representam coisas que geram 
algum benefício ao cliente/usuário final, como novas funcionalidades, correção de defeitos ou melhorias na 
interface do produto. O valor é gerado somente quando um item alcança a última etapa: 
 
Apesar de conter etapas sequenciais e cartões, isso ainda não é um sistema Kanban. Vamos fazer mais duas 
mudanças para tornar o fluxo puxado: 
1. Dividir as colunas intermediárias em dois estágios: “fazendo” e “pronto”; 
2. Adicionar limites de trabalho em progresso 
Feitas essas mudanças, o nosso quadro ficaria assim: 
 
 
 
 
 
Vamos analisar como isso funcionaria na prática. Supondo que você é o especialista em Design do time e que 
você está trabalhando em uma funcionalidade. Após você concluir a sua atividade, você movimenta o cartão para 
a etapa “Pronto” da coluna “Design”. Se um desenvolvedor (que atua na etapa “Desenvolvimento”) está livre, ele 
pode perceber que você sinalizou a conclusão da sua parte e então “puxar” o cartão para a etapa “Fazendo” da 
coluna “Desenvolvimento”. 
Repare que o limite “1” da coluna “Design” é válido tanto para “Fazendo” quanto “Pronto”. No caso acima, 
temos um item que foi concluído pelo Designer, mas ainda não foi puxado. O que o Designer faz nesse caso? 
Nada. Ele apenas aguarda alguém puxar o item para Desenvolvimento. Nesse caso o slot seria liberado e ele 
poderia trabalhar em outro item. 
Claro que na prática se não houver slot disponível o membro do time não vai ficar simplesmente parado. Em um 
sistema Kanban, estimulamos as pessoas a olharem para o fluxo como um todo e buscarem formas de aumentar 
a vazão. Pode ser que o Designer possa ajudar alguém no Desenvolvimento. Pode ser que ele use esse tempo para 
pensar em melhorias. O que importa é não ficar simplesmente trabalhando na própria função, pois isso aumentaria 
o estoque e prejudicaria o fluxo. 
Parece contra intuitivo, mas a teoria das filas comprova. A ociosidade no fluxo aumenta a vazão. Para entender 
os porquês, você vai precisar estudar um pouco de matemática (esse livro é um bom começo). 
Como os itens são puxados apenas quando há capacidade disponível, raramente há sobrecarga. Isso é que o 
chamamos de sistema puxado. Ele é um contraste à forma tradicional de trabalhar, que chamamos de sistema 
empurrado. Vamos entender a diferença entre os dois para compreender melhor um sistema Kanban. 😉 
Sistema Empurrado 
Um sistema empurrado é aquele em que a produção é baseada na demanda, sem respeito à capacidade do sistema. 
Em geral, no paradigma empurrado tenta-se produzir o máximo possível e em grandes lotes, sem considerar a 
real necessidade dos clientes. Neste tipo de abordagem, a estratégia de marketing e vendas também é focada em 
vender e “empurrar” os produtos para o cliente. 
No nosso exemplo do time de desenvolvimento de um aplicativo, um gestor poderia atribuir diversas tarefas aos 
membros do time, exigindo que todos se mantivessem ocupados e trabalhando 100% do tempo, cada um na sua 
função. Além disso, é provável que esse time desenvolvesse um grande número de funcionalidades inúteis e que 
não gerassem valor para o cliente final. Afinal, todos estariam preocupados em fazer bem a sua função, e não em 
entregar valor para o cliente. 
https://www.goodreads.com/book/show/6278270-the-principles-of-product-development-flow
 
Os principais efeitos colaterais de um sistema empurrado são sobrecarga, demoras nas entregas, grandes lotes e 
burnout das pessoas. 
Sistema Puxado 
Um sistema puxado é aquele em que os participantes “puxam” o trabalho quando há capacidade disponívelpara 
executá-lo. Isso é possível quando atribuímos limites para as unidades de trabalho em progresso. Um sistema 
puxado nunca irá sofrer com sobrecarga se os limites forem estabelecidos corretamente. Nesse paradigma busca-
se atingir um passo sustentável, ou seja, um equilíbrio entre a capacidade do time e o que é demandado dele. 
O método Kanban é apenas uma forma de construir um sistema puxado. Outras variações também existem, como 
CONWIP, DBR e CapWIP. 
Os princípios básicos do método Kanban 
Em seu livro Kanban: successful evolutionary change for your technology business, David J. Anderson descreve 
os princípios básicos do método Kanban: 
Comece com o que você tem hoje. O método Kanban propõe uma abordagem evolucionária e incremental. Por 
mais que você esteja muito insatisfeito com a forma como as coisas são feitas no processo atual, não mude tudo 
logo no início. Fazer grandes mudanças pode aumentar a resistência das pessoas, além de ser muito arriscado 
para a organização. 
Busque mudanças incrementais e evolucionárias. Depois de partir do seu processo atual, busque pequenas 
mudanças. Formule hipóteses com base na sua observação do comportamento do sistema. Seja curioso e faça 
experimentos. 
Vamos supor que o seu sistema possui uma coluna onde um grande documento é produzido que detalha o que 
deve ser feito. Talvez você desconfie que o nível de detalhe seja grande demais e que isso é um provável 
desperdício. Formule a hipótese: Se nós simplificarmos o documento, teremos uma redução do Lead Time do 
processo. Você pode estar certo ou não. Faça um experimento, meça os resultados e compare. 
Respeite o processo atual, papéis, responsabilidades e títulos. É provável que na organização em que você 
está implementando o método Kanban existam cargos e autoridades definidas. Talvez essa estrutura esteja 
atrapalhando o fluxo, na sua visão. Mas ao mesmo tempo, é também muito provável que boa parte dos processos 
atuais simplesmente funcione. Por isso é importante respeitar o que já está posto e perseguir a melhoria contínua 
a partir disso. 
As 6 práticas gerais de um sistema Kanban 
David J. Anderson descreve 6 práticas gerais das implementações de sucesso do método Kanban. Podemos dizer 
que sem elas, você ainda não está fazendo “Kanban”. Por isso que dissemos que o quadro inicial (que não tinha 
limites de trabalho em progresso) ainda não poderia ser considerado um sistema Kanban: ele falhava em uma das 
6 práticas gerais. 
As 6 práticas são: 
Visualize o fluxo de trabalho. Você não pode gerenciar o que não pode ver! E se tratando de trabalho do 
conhecimento, esta afirmação é ainda mais verdadeira. Na Toyota, o estoque excessivo de carros poderia ser 
facilmente visualizado, já que um carro é um produto físico. Mas e todas as funcionalidades de um sistema que 
foram começadas, mas não terminadas? Ou todos os tickets de atendimento que foram abertos, lidos, mas não 
respondidos? O trabalho do conhecimento é intangível. É por isso que precisamos estabelecer formas tangíveis 
de visualizar o fluxo e as unidades de trabalho. 
http://www.djaa.com/principles-general-practices-kanban-method
 
Limite o trabalho em progresso. Se você não estabelecer limites para o trabalho em andamento, é muito 
provável que você ainda esteja operando um sistema empurrado. Em geral, todas as etapas em um fluxo são 
limitadas, com exceção da última. Estabelecer limites vai impedir o acúmulo de estoque e também vai manter o 
Lead Time estável. Em geral, quanto mais itens houverem em andamento, maior é o tempo de entrega. 
Gerencie o fluxo. No Kanban, focamos os esforços na otimização do sistema como um todo. A gestão tradicional 
empurrada foca em manter todas as pessoas ocupadas e gerenciar o trabalho delas. Isso não é feito no método 
Kanban. Se tentarmos otimizar uma parte do sistema (o trabalho de um desenvolvedor), isso provavelmente levará 
a uma situação sub-ótima globalmente. Esse fenômeno chama-se otimização local. 
Torne as políticas de processo explícitas. Ao trabalhar com um fluxo Kanban, você vai perceber que muitas 
regras de processos, papéis e definições não são claras para os participantes do fluxo. Vai surgir muita confusão 
sobre o significado de uma determinada coluna do fluxo, por exemplo. É importante que você aproveite essas 
oportunidades para esclarecer as políticas do processo e torná-las explícitas. Isso significa registrá-las em algum 
local acessível para todos. Parte importante de jogar o jogo é conhecer as regras. 
Implemente ciclos de feedback. Nenhum processo pode evoluir sem ciclos de feedback. David J. Anderson 
propõe alguns rituais específicos para retroalimentar o sistema e permitir com que os participantes se adaptem 
comparando a situação atual do processo com as expectativas das partes interessadas. 
Melhore colaborativamente. No final, as limitações de trabalho em progresso irão introduzir desconfortos e 
iniciar conversas sobre o fluxo. O que se busca em um sistema Kanban é um fluxo suave e constante. No entanto, 
não é isso que vai acontecer no início. É importante estabelecer um processo de melhoria colaborativa, onde o 
grupo constrói um entendimento compartilhado sobre os problemas encontrados e a partir daí propõe 
experimentos para melhorar o fluxo. 
Quando usar o método Kanban? 
Praticamente qualquer processo de desenvolvimento ou prestação de serviço pode ser melhorado com o método 
Kanban. No entanto, quanto maior e mais complexa a cadeia de valor desse produto/serviço, maior é o benefício 
em aplicá-lo. 
Cadeias longas geralmente possuem muitas pessoas envolvidas, handovers e fontes de desperdício. Isso significa 
maiores oportunidades de melhoria. Por outro lado, se o processo for extremamente simples, provavelmente o 
esforço de aplicar o método é maior do que o benefício obtido. 
 
 
 
TDD (Test Driven Development / Desenvolvimento orientado a teste) 
Introdução 
Apesar de muitas empresas ainda não utilizarem técnicas de teste de software para o desenvolvimento dos seus 
produtos, alegando o atraso, o tempo ou o custo para esta tarefa, as pesquisas indicam que os testes ajudam na 
garantia de qualidade do software. 
Vamos a outra realidade, imagine você adquirindo um carro, que foi projetado, montado, mas sem ser testado, 
pois os testes sairiam muito caro, e de repente você está andando e nota que na curva o carro não é eficiente. 
Você ficaria contente com esta situação? O mesmo acontece com o cliente de um software ao adquirir um 
produto que não funciona adequadamente. O Standish group, no relatório de chaos, apresenta constantemente 
o resultado da pesquisa e demonstra que o percentual de software tido como completo e aceitável é muito 
baixo. Além disso, segundo Myers apud. Bartié, quanto mais tardiamente descobrirmos os erros, mais caros 
estes se tornam. Aplicando-se assim a regra dos 10 ao custo da correção, ou seja, encontrar um erro durante o 
requisito custa 1, por exemplo, durante a fase de análise e modelagem, custa 10, durante a codificação custa 
100, durante a fase de teste, pós desenvolvimento, custa 1.000 e durante a produção, ou seja, quando já está 
na mão do cliente, o processo custa 10.000. Desta forma, é importante que a fase de requisitos possua 
validações, evitando-se assim problemas de entendimento de requisito. 
Os problemas de requisitos são reduzidos quando utiliza-se de metodologias ágeis, isto por que o cliente 
acompanha o processo e como os ciclos são curtos, a velocidade da correção também o é. Mas como muitas 
empresas negligenciam o teste durante a fase de desenvolvimento, os erros só são encontrados tardiamente, 
elevando os custos dos produtos e criando impactos negativos aos processos e negócios. 
Temos de lembrar que qualidade não é uma etapa apenas, uma fase do desenvolvimento, é parte de todo o 
ciclo de vida de desenvolvimento do software. 
Mas o que é qualidade no processo de desenvolvimento de software? Segundo Bartié“Qualidade de software 
é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a 
conformidade de processos e produtos, prevenindo e eliminando defeitos”. 
A qualidade aplicada tardiamente não gera um produto com qualidade, Bartié afirma que a maioria das 
organizações aplicam em seus processos de desenvolvimento testes tardios, o que não garante a qualidade do 
produto, e como vimos na regra de Myers, o custo do produto aumenta consideravelmente. Ainda segundo 
Miller apud Presmann, “a motivação que está por trás do teste de programas é a confirmação da qualidade de 
software com métodos que podem ser economicamente e efetivamente aplicados a todos os sistemas, de grande 
e pequena escala”. Desta forma, utilizar uma metodologia que permita testes no processo de desenvolvimento, 
auxilia na garantia de qualidade. 
O TDD 
O TDD (Test Driven Development / Desenvolvimento orientado a teste) é parte da metodologia XP e também 
utilizado em diversas outras metodologias, além de poder ser utilizada livremente. 
O que você tem a perder utilizando o TDD? 
Bem segundo Freeman at al, você não tem nada a perder, a não ser os seus bugs. 
O TDD transforma o desenvolvimento, pois deve-se primeiro escrever os testes, antes de implementar o 
sistema. Os testes são utilizados para facilitar no entendimento do projeto, segundo Freeman os testes são 
usados para clarear a ideia em relação ao que se deseja em relação ao código. Segundo Kent Beck apud 
Freeman “Finalmente, consegui separar o projeto lógico do físico. Sempre me disseram para fazer isso, mas 
nunca ninguém tinha explicado como”, o TDD é a forma de se fazer isso. A criação de teste unitários ou de 
componentes é parte crucial para o TDD. Segundo Presmann, “Os componentes individuais são testados para 
garantir que operem corretamente. Cada componente é testado independentemente, sem os outros 
 
componentes de sistema. Os componentes podem ser entidades simples, tais como funções ou classes de 
objetos, ou podem ser grupos coerentes dessas entidades”. 
Mas não é só o teste unitário que vai trazer o sucesso a aplicação, é necessário testar o sistema como um todo, 
que segundo Sommerville, “Os componentes são integrados para compor o sistema. Esse processo está 
relacionado com a busca de erros que resultam das interações não previstas entre os componentes”. 
Um sistema é um conjunto de unidades integradas, por este motivo é importante os testes unitários para ver se 
no micromundo tudo funciona, mas também temos de testar a integração, ou seja, ao integrar dois ou mais 
componentes, devemos realizar testes para verificar se a integração funciona. Voltemos ao exemplo do carro, 
não adianta eu testar a roda, a porta, o volante, mas não testar o carro completo. Erros podem ocorrer, 
justamente no processo de montagem/integração de componentes. 
E qual o benefício em utilizar o TDD? 
Em primeira instância, torna o processo mais confiável, mas reduz custos, pois desenvolvemos e já sabemos 
o erro, pois como os testes são criados antes do processo de desenvolvimento, conseguimos testar 
constantemente. Outro ponto é que se os testes foram criados, isso quer dizer que foram entendidas as regras 
de negócio durante a fase de desenvolvimento dos testes unitários. 
Além disso, evita retrabalho da equipe, que ao final reduz custo e tem maior chance de sucesso. 
O Ciclo do TDD é simples: criamos um teste -> Fazemos a codificação para passar no teste -> Refatoramos 
nosso código, conforme figura a seguir: 
 
Figura 1: Ciclo do TDD 
Notemos aqui que o teste visa auxiliar a codificação, reduzindo consideravelmente os problemas na fase de 
desenvolvimento. No TDD é indicado que o projeto de teste unitário ocorra antes da fase de 
codificação/implementação. 
O Teste antes da codificação, ou test-first, segundo Sommerville, “a escrita de testes primeiro define 
implicitamente tanto uma interface como uma especificação do comportamento para a funcionalidade que está 
sendo desenvolvida”. 
Note que ao criar o teste antes de implementar a unidade, são reduzidos problemas como mal entendimento 
de requisitos ou interfaces, pois como criar um teste se eu não sei o que devo testar? 
 
 
Neste caso o desenvolvedor, para implementar os testes iniciais, deve compreender com detalhes a 
especificação do sistema e as regras de negócio, só assim, será possível escrever testes para o sistema. Imagine 
o caso de querer testar um pneu criado para o carro, se não entendi que o pneu é redondo, por exemplo, criarei 
um teste para um pneu quadrado, não podendo ser realizado o teste. Desta forma, é de extrema importância, 
para o desenvolvedor, o entendimento dos requisitos do cliente. Além disso, não adianta criar testes que não 
validem o código como um todo para reduzir o tempo, é necessário criar testes para o conjunto completo de 
unidades, só assim o TDD vai funcionar como deve, devendo fornecer uma cobertura completa aos testes. 
Além disso, os testes devem seguir o modelo F.I.R.S.T. 
 F (Fast) - Rápidos: devem ser rápidos, pois testam apenas uma unidade; 
 I (Isolated) - Testes unitários são isolados, testando individualmente as unidades e não sua integração; 
 R (Repeateble) - Repetição nos testes, com resultados de comportamento constante; 
 S (Self-verifying) - A auto verificação deve verificar se passou ou se deu como falha o teste; 
 T (Timely) - O teste deve ser oportuno, sendo um teste por unidade. 
Atualmente, existem diversas ferramentas que analisam as coberturas de teste, podendo ser baixadas 
gratuitamente da Internet. 
Outra vantagem de possuir testes é a chamada regressão. Imagine que criamos os testes, fizemos o sistema e 
tudo foi entregue ao cliente, mas posteriormente o cliente pediu pequenas modificações no sistema, mas não 
nas regras de negócio. Os testes já prontos servirão para validar se as modificações não criaram problemas nas 
regras de negócio que já estavam em funcionamento. Este procedimento exige que testes unitários estejam 
prontos, aguardando ser reutilizados. Logo, segundo Silveira at al., “Um teste de unidade deve garantir que a 
execução daquele trecho mínimo de código esteja correta.” 
Como implementar o processo de TDD ao desenvolvimento? 
 Para começar a desenvolver seus primeiros testes, pode ser mais fácil a utilização de bibliotecas 
XUnit's. Existem diversas ferramentas que possibilitam esta prática, vamos a algumas: 
 JUnit: O JUnit é um framework de teste para Java, que permite a criação de testes unitários. Além disso, está 
disponível como plug-in para os mais diversos IDE'S como Eclipse, Netbeans etc. 
 TesteNG: Outra ferramenta de teste unitária, disponível para Java; 
 PHPUnit: Framework XUnit para teste unitário em PHP, também é possível integrar aos IDE's assim como o 
JUnit; 
 SimpleTest: Outra ferramenta para realização de teste para PHP. Além de possibilitar os testes unitários, é 
possível realizar MOCKS e outros testes; 
 NUnit: Framework de teste no molde XUnit para a plataforma .NET; 
 Jasmine: Framework para teste unitário de JavaScript; 
 CUnit: Ferramenta para os testes unitários disponível para Linguagem C; 
 PyUnit: Framework Xunit para testes na linguagem Python. 
Depois, temos de iniciar a fase de desenvolvimento, criando primeiramente os testes. Nos sites das ferramentas existe 
documentação para saber como utilizá-las, mas é possível ver nestes tutoriais como utilizar algumas delas: 
 Introdução ao desenvolvimento guiado por teste: TDD com JUnit 
 Qualidade em desenvolvimento web: PHP com teste unitário 
 Utilizando o NUnit 
 Testes com Jasmine - melhore q qualidade do JavaScript 
 Testes unitários com PyUnit 
Como vimos, existem ferramentas para as mais diversas linguagens e plataformas, com integração a IDE's. E 
lembre-se: primeiro crie os testes, para posteriormente efetuar a sua implementação. 
 
 
http://junit.org/
http://testng.org/
http://phpunit.de/http://www.simpletest.org/
http://www.nunit.org/
http://pivotal.github.io/jasmine/
http://cunit.sourceforge.net/
http://pyunit.sourceforge.net/
http://www.devmedia.com.br/introducao-ao-desenvolvimento-guiado-por-teste-tdd-com-junit/26559
http://www.devmedia.com.br/qualidade-em-desenvolvimento-web-php-com-teste-unitario/27550
http://renatoduran.blogspot.com.br/2009/07/utilizando-o-nunit.html
http://www.devmedia.com.br/testes-com-jasmine-melhore-a-qualidade-do-javascript-revista-net-magazine-102/26957
http://www.franciscosouza.com.br/2009/07/24/testes-unitarios-com-pyunit/
 
Conclusão 
Neste artigo vimos o TDD e sua importância para a qualidade de software. Foram apresentadas ainda algumas 
ferramentas que permitem a utilização dos testes. Este artigo tem como principal objetivo apresentar 
fundamentos do por que utilizar testes na fase de codificação e sua importância para a redução de falhas. 
Vimos que a utilização de teste durante a fase de desenvolvimento melhora a qualidade e reduz custos de 
manutenção. 
Agora, você tem o que a perder? 
Seus bug's!!! 
Até a próxima e até o próximo artigo. 
Referencias bibliográficas 
 BARTIÉ, Alexandre. Garantia de qualidade de software. Rio de Janeiro: Campus, 2002. 
 FREEMAN, Steve. Pryce, Nat. Desenvolvimento de Software Orientado a objetos, Guiado por Testes. Rio de 
Janeiro: Alta Books, 2012. 
 PRESSMAN, Roger S. Engenharia de Software: Uma abordagem Profissional. Porto Alegre: Bookman, 2011. 
 SILVEIRA, Paulo et al. Introdução à arquitetura e design de software: uma visão sobre a plataforma Java. Rio 
de Janeiro: Campus, 2012. 
 SOMMERVILLE, Ian. Engenharia de software. São Paulo:Person, 2010.