O documento descreve a implementação do framework SAFe em uma equipe de TI para melhorar os processos ágeis. Detalha como critérios de aceite mal escritos estavam causando atrasos e bugs, e como a empresa melhorou ao envolver toda a equipe na criação dos critérios seguindo padrões similares a casos de uso.

1. Melhores Práticas para Estabelecimento de Critérios de
Aceite no SAFe: estudo de caso em uma empresa de TI de
grande porte
Caroline Seara Vieira da Cunha, Anita Maria da Rocha Fernandes,
Fábio Trierveiler
Universidade do Vale do Itajaí (UNIVALI)
Florianópolis – SC – Brasil
carolseara@gmail.com, anita.fernandes@univali.br, fabiotr@gmail.com
Abstract. The primary objective of this article is to showcase the results of the
implementation of SAFe, a framework geared towards agile methodologies,
into an IT development team’s workflow. Apart from the experience reports
focused on the project acceptance criteria, the improvements to the team’s
pipeline will also be reported, as well as what changes the company adopted
as to better adapt to their new work style.
Resumo. Este artigo tem como objetivo expor algumas experiências após a
implantação do SAFe, um framework voltado para metodologias ágeis, em
uma equipe de desenvolvimento na área de Tecnologia da Informação situada
na cidade de Florianópolis. Além dos relatos de experiências focados nos
critérios de aceite, também serão mencionadas quais foram as melhorias que
a empresa adotou em utilizar para melhor se adaptarem ao novo estilo de
trabalho.
Introdução:
Com as recentes mudanças que vem ocorrendo no ramo da tecnologia, uma dada
empresa de TI (Tecnologia da Informação) de grande porte em Florianópolis optou por
imergir e investir nas metodologias ágeis.
Segundo Grandro (2010): “desenvolvimento ágil é o método de engenharia
usado para desenvolver produtos (hardware, software ou serviços) de forma iterativa e
incremental com flexibilidade para reagir ao feedback dos clientes. Ele reconhece que as
necessidades do cliente e que a especificação do produto final não pode ser totalmente
definida a priori. Agile é a antítese do Desenvolvimento Cachoeira”.
E foi seguindo essas abordagens, que a empresa optou por adotar uma
ferramenta denominada SAFe (Scaled Agile Framework) que é um framework escalável
para grandes empresas. Por ser uma empresa de grande porte, apenas utilizando o
Scrum acabaria se tornando uma abordagem limitada. Hoje a equipe de
desenvolvimento que vem adotando essa metodologia, tem em média 150
colaboradores. Porém, elas foram subdivididas e cada uma possui no máximo 10
representantes.
Após realizarem a implantação do SAFe, que nesse primeiro semestre de 2016
completou-se um ano, alguns problemas começaram a ficar evidentes. Tais como,

2. atrasos nas entregas de desenvolvimento e um aumento nos bugs de software. Uma das
falhas identificadas nos problemas citados acima se deu por conta de critérios de aceite
maus escritos e maus interpretados.
Os critérios de aceite são escritos, na sua maioria das vezes pelos POs (Product
Owner) e eventualmente por analistas de testes. Entretanto, a metodologia do SAFe
propõe que todos os membros da equipe participem da criação dos critérios. Por se
tratar de uma metodologia recente na empresa, muitas vezes até por uma questão de
mudanças de posturas e hábitos, os resultamos positivos levam certo tempo até
aparecerem.
Através desses problemas relatados, este artigo tem como intuito demonstrar
com exemplos práticos de como critérios de aceites válidos devem ser desenvolvidos,
levando em conta um padrão semelhante a um caso de uso.
2. Metodologias Ágeis
Com as mudanças repentinas do mercado consumidor, onde cada vez mais visam
exigência, recursos tecnológicos e competitividade, surgiu a necessidade de utilizarem
metodologias diferentes para construir não apenas um produto melhor, mas também um
produto no qual os clientes estejam dispostos a utilizar e pagar por ele. É nesse contexto
que entram as metodologias ágeis [Roriz Filho; Milani; Conforto, 2015].
O Manifesto ágil partiu da preposição de que embora cada envolvido tivesse
suas próprias convenções sobre como realizar um projeto de software de sucesso, todos
chegaram à conclusão que em suas experiências anteriores um pequeno conjunto de
princípios sempre se ressaltavam quando os projetos davam certo [Luna 2011].
Com isso, foram definidos doze princípios de um processo ágil, são eles:
1. A prioridade é a satisfação do cliente, mediante o rápido e contínuo
fornecimento de software que agregue um valor ao negócio
2. As mudanças são bem-vindas, mesmo no final do desenvolvimento,
principalmente se as alterações darão vantagem competitiva para os nossos
clientes.
3. Fazer entregas frequentes de software que funcione a partir de um par de
semanas a um par de meses, sempre procurando o menor intervalo de tempo
entre as entregas.
4. As pessoas de negócio (executivos) e os desenvolvedores devem trabalhar juntos
diariamente e ao longo de todo o projeto.
5. Construir o projeto em torno de indivíduos motivados. Fornecer todo o apoio
necessário ao ambiente do projeto e confiar plenamente na equipe.
6. O diálogo face a face é a mais eficiente e eficaz forma de comunicar as
informações dentro da equipe de desenvolvimento.
7. Software que funciona é a principal medida de progresso.

3. 8. Os processos ágeis promovem um desenvolvimento sustentável. Os promotores,
usuários e desenvolvedores devem ser capazes de manter um ritmo de trabalho
constante por tempo indeterminado.
9. A atenção contínua à qualidade técnica e ao bom design melhora a agilidade.
10. A simplicidade é essencial. É preciso saber maximizar o trabalho que não deve
ser feito.
11. As melhores arquiteturas, requisitos e desenhos surgem a partir da própria
equipe através de sua pro atividade e auto-organização.
12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz
e ajustar o seu comportamento para alcançar este objetivo.
Segundo Lobo (2008), a metodologia ágil surgiu como uma alternativa aos
processos tradicionais de desenvolvimento de software, também conhecido como
modelo espiral, onde nele são levantados os requisitos do sistema com o cliente, em
seguida é realizada a sua análise e posteriormente desenvolve-se o software para
prosseguir com a implementação.
Os métodos ágeis de desenvolvimento de software utilizam uma metodização
mais rápida e objetiva para se construir um software. Uma das suas principais
características é realizar iterações em curtos períodos de tempo. As iterações geralmente
são de períodos pequenos, permitindo assim a diminuição dos riscos do projeto [Lobo
2008].
As metodologias ágeis visam às prioridades dos projetos, pois consideram que
as funcionalidades mais urgentes devem ser as primeiras a serem implementadas [Lobo
2008].
Complementando o contexto, tem-se a Figura I que explica sobre as principais
características da metodologia ágil de desenvolvimento de software [Lobo 2008].

4. Figura 1. Metodologia Ágil de Desenvolvimento de Software.
Fonte: Lobo [2008]
Nessa esfera, uma das metodologias ágeis mais difundidas é o Scrum.
Segundo Cruz (2015), “o Scrum é um framework para gerenciamento de
projetos ágeis que, apesar de muito comum na área de desenvolvimento de software,
pode ser utilizado também para o planejamento, gerenciamento e desenvolvimento de
qualquer produto, principalmente por ser um framework iterativo e incremental.”
O Scrum basicamente baseou-se no desenvolvimento iterativo, que é uma
técnica que procura antecipar o lucro do projeto de uma forma controlada. Ele foca no
que é realmente importante: gerenciar o projeto e criar um produto que possa
acrescentar valor ao negócio. O valor decorre da própria funcionalidade, ou seja, do
prazo em que ela é necessária, do custo e da sua qualidade [Cruz 2015].
Outas duas características importantes no Scrum é que ele é adaptativo e
empírico. Entretanto o próprio Scrum, tem como objetivo administrar equipes menores,
geralmente entre 7 a 10 pessoas [Cruz 2015].
Seguindo as tendências atuais, empresas de grande porte, incluindo está que está
sendo mencionada neste artigo, começaram a aderir os métodos ágeis e é nesse cenário
que o SAFe começa a fazer parte.

5. 3. SAFe
O SAFE é um framework que foi desenvolvido com a finalidade de implantar práticas
ágeis em empresas de grande porte. Sua interface é representada através de um gráfico,
a Big Picture, onde nela estão representados os papéis, as equipes, atividades e artefatos
para dimensionar uma equipe ágil tomando como referência o nível da empresa
[Leffingwell 2001].
Atualmente o SAFe opera em três níveis: portfólio, programa e time. O nível de
portfólio é onde os programas estão alinhados à estratégia de negócio da empresa. Ele é
composto por times que definem, junto ao cliente, quais serão as demandas necessárias
e suas precedências [Leffingwell 2001].
O nível de programa, chamado de ART (Agile Release Train), é composto por
múltiplos times que trabalham juntos a fim de possuir uma entrega maior e com um
destaque ao cliente. A entrega denomina-se incremento de programa e ocorre
geralmente a cada cinco sprints [Leffingwell 2001].
No nível de Time são realizadas atividades equivalentes a um Scrum através de
sprints, realizando entregas em um período menor. O time é composto essencialmente
por programadores e testadores. Na Figura 2 tem-se a Big Picture do SAFE, onde são
representados os níveis e os principais elementos oferecidos no framework [Leffingwell
2001].
Figura 2. Big Picture do SAFe.
Fonte: Leffingwell [2001]

6. A seguir serão mencionados alguns elementos característicos que são utilizados no dia a
dia do SAFe, com base em [Leffingwell 2001].
Características:
• Interação
Interação é equivalente a uma Sprint. Ela possui um tempo fixado que dura em torno
de duas semanas. Nessa fase, o time deve entregar um incremento do programa
funcional e testado.
• História
Toda a implementação é dividida detalhadamente através de histórias. Elas são os
pontos iniciais que compõem o backlog do time. Geralmente as histórias são
derivadas das features, entretanto outras histórias podem ser criadas dependendo do
contexto local do time. Cada história deve ser implementada de forma incremental e
deve providenciar valor ao usuário. As histórias devem ser testáveis e divididas o
quanto for necessário para que possam ser completas em uma única interação.
• Feature
Features são demandas que realizam as necessidades dos stakeholders. Elas ficam
imersas no backlog do time e devem obter o tamanho de um incremento de
programa. As features devem possuir critérios de aceite para que a equipe de
homologação possa realizar os testes em cada um desses critérios e assim validar se
o que estava especificado está funcionando de acordo com o que foi definido.
• Agile release train
O nível de programa é composto por múltiplos times trabalhando em conjunto para
realizar entregas maiores, o tamanho desse grupo varia entre 50 a 125 pessoas, no
SAFe isto é chamado de Agile release train (ART). O incremento de programa
possui um tamanho padrão de 5 sprints, podendo ser ajustado para mais ou para
menos.
O SAFe chama este incremento de trem devido a chegada de intervalos
constantes. Se um trem é perdido, basta embarcar no próximo. O mesmo acontece
com o ART, por ser constante e relativamente curto, é fácil explicar aos
stakeholders porque itens que não couberam neste trem não foram entregues e que
simplesmente devem aguardar pelo próximo.
• Release train engineer
O release train engineer é semelhante a um scrum master do ART, ele tem como
responsabilidade manter os processos, os planos, as features, os prazos, escalar
impedimentos, resolver os riscos e todas as responsabilidades relacionadas ao ART
para que ele chegue com sucesso até o cliente.

7. • Release planning
O release planning ocorre antes do lançamento de cada Agile release train. Todas as
equipes se reúnem em um mesmo local e definem quais features cada time irá se
comprometer a desenvolver e entregar. Outros fatores que também são
diagnosticados são os riscos e as dependências entre as equipes.
Todo esse processo é conduzido pelo release train engineer, que entrega todas as
features que o ART irá desenvolver, além de apresentar quais são as 10 mais
importantes. Ainda nesta abordagem, todos os times dividem as features em
histórias do usuário e junto com a equipe de testes escrevem os critérios de aceite
destas histórias.
4. Critérios de Aceite
Critério de aceite é uma maneira tradicional de definir quando o produto está aceitável
para uma entrega. Os critérios de aceite são capturados para cada história no início de
cada iteração. Eles também são definidos para features no início de cada ciclo [Crispin,
Grgory, 2009].
Segundo Gärtner (2012), para obter uma boa especificação de requisitos e
garantir que sua equipe esteja realizando o trabalho corretamente conforme a exigência
do cliente, os critérios de aceite devem ser definidos junto a equipe, fazendo com que
haja um entendimento global sobre os requisitos que deverão ser implementados.
Os critérios também devem ser documentados para futuras revisões e/ou
aplicações. Visando conter todas as necessidades que não são obvias. Novaes (2016)
expõe alguns itens que o documento deve englobar:
• Liberar todos os artefatos identificados como produtos liberados para o
cliente;
• Listar dos participantes necessários ao teste de aceitação;
• Locais de teste necessários;
• Concluir com êxito das avaliações de artefato identificadas no Plano de
Aceitação do Produto;
• Concluir com êxito do treinamento do cliente;
• Concluir com êxito da instalação no local;
• Medidas que identificarão até que ponto as especificações originais do
projeto foram atendidas; e
• Medidas que identificarão até que ponto os objetivos do caso de negócio
foram atingidos.
Além disso, os critérios devem ser explícitos, caso contrário é muito difícil
determinar a complexidade do que foi desenvolvido. Como resultado de todos esses
artefatos, quanto mais claros esses critérios forem escritos, maiores serão as chances de

8. o software apresentar todas as funcionalidades exigidas e menor será o seu retrabalho
[Novaes 2016].
Para enfatizar sobre a importância de uma boa construção de critérios de aceite,
é importante citar também a relevância deles na criação dos casos de testes, bem como
na própria execução dos mesmos. Segundo Pugh (2011), depois de estabelecidos e
definidos os critérios de aceite, eles servem como um guia para os desenvolvedores,
antes mesmo de começarem o desenvolvimento. Todo esse suporte é considerado que os
critérios foram baseados nos requisitos coletados pelos clientes.
Como garantia de que todo os critérios de aceite foram cobertos pelo projeto,
vale salientar as exigências do cliente e realizar uma tomada de testes automatizados
sobre todo o sistema assim que for finalizado [Novaes 2016].
A partir da especificação dos critérios de aceite, os desenvolvedores tornaram-se
mais envolvidos na automação de testes. Com isso, obtiveram um melhor feedback dos
testes funcionais, pois os mesmos foram executados em suas próprias máquinas [Adzic
2011].
A vantagem de construir critérios de aceite antes mesmo da implementação é a
diminuição no retrabalho e nos próprios testes manuais. O resultado disso é uma entrega
de qualidade e também de maior eficácia para o cliente [Adzic 2011].
O processo de desenvolvimento de um critério de aceite inicia-se junto ao
gerente de projeto, ou Scrum Master, que é responsável por selecionar as Stories no
início de uma Iteração. Os analistas de negócio, junto com as partes interessadas,
começam a trabalhar em cima dos critérios de aceites, antes mesmo da iteração iniciar.
Eles baseiam se nas especificações de requisitos de software [Adzic 2011].
Esse cenário citado por Adzic (2011), é muito próximo ao cenário atual que se
utiliza hoje na empresa desse estudo de caso. No tópico a seguir, tem-se uma
contextualização de cenários e realidades do dia a dia vividos por essa empresa.
5. Cenário Atual
O SAFe ainda é recente na empresa. A sua implantação completou um ano nesse
primeiro semestre de 2016. Após a sua introdução, as equipes de desenvolvimento, que
formavam um total de 125 pessoas, agora foram segmentadas em equipes menores, de
no máximo 10 pessoas, onde cada uma é composta por um PO (Product Owner) que é o
analista de negócio, um analista de sistemas, analistas de testes, analistas
implementadores e um scrum master.
No release planning e nas sprints planning as features são divididas em uma ou
mais histórias de usuário, onde todas as features que foram definidas e criadas devem
possuir critério de aceite que foram definidos pelo time com a participação dos analistas
de negócio e analistas de testes.
Quando a implementação e os testes são finalizados pelo time, é realizado uma
entrega para a equipe de homologação que deverá supostamente realizar os testes
baseados nos critério de aceitação da feature. Os analistas de sistemas testam e validam

9. se todas as histórias sincronizadas no mesmo código fonte atendem aos critérios de
aceite da feature.
Entretanto, começaram a surgir alguns problemas relacionados aos critérios de
aceite, que passaram a gerar impactos diretamente na equipe de homologação e como
consequência, os problemas começaram a refletir no usuário final.
Como por exemplo, tem-se o critério da Figura 3:
1) Alterar o valor do parâmetro para "TRIBUNAL DE JUSTIÇA <NOME DO
ESTADO>"
2) Todos os clientes devem apresentar o nome especificado como cedente.
Considerar pelo menos o TJ/MS, o TJ/SC e outro cliente qualquer nos testes.
Figura 3. Exemplo de Critérios de aceite mal escrito.
Problemas identificados:
• Qual o número do parâmetro que deverá ser modificado?
• Qual era a antiga descrição do parâmetro?
• Qual o nome/s que são especificados como cedente? Qual outro ‘cliente
qualquer’ que deve ser considerado nos testes?
Outro exemplo de um critério de aceite mal escrito é mostrado na Figura 4:
1) Consulta de todos os indicadores sintético, deve apresentar o indicador mesmo
que com valor zero.
2) Consulta de todos os indicadores detalhado.
3) Ordenação correta dos campos na tela.
Figura 4. Exemplo de Critérios de aceite mal escrito.
Problemas identificados:
• Como que funciona essa consulta de indicador?
• Como eu faço para apresentar uma consulta que retorne um indicador com valor
zaro?
• Quais são os valores que deverão ser verificados para certificar que o indicador
está vindo detalhado?
• Como saber qual seria a ordenação correta nos campos de tela?
Como pode verificar nos exemplos mencionados, não é possível realizar os
testes, com todas essas informações incompletas. Como consequência disso, muitos

10. testes são realizados de maneira errônea ou então, é gerado um atraso para coletar
informações mais completas e condizentes com a implementação.
Outro problema envolvendo os critérios deu-se por conta de correções nas
Especificações de Requisitos. Quando um requisito, eventualmente é alterado e
corrigido na Especificação, muitas vezes a equipe não realizava a atualização desses
requisitos nos critérios de aceite, gerando uma má interpretação nos testes da equipe de
homologação. E após realizada a entrega para o cliente, esse problema era diretamente
refletido no uso do seu dia a dia.
Com isso, o comitê de ágil da empresa sugeriu que algumas medidas fossem
tomadas. Uma delas é que os implementadores só poderão iniciar suas implementações
após finalizado os critério de aceite, junto com a aprovação do PO. Outra melhoria foi
definir um padrão de como escrever esses critério, que será apresentado no tópico a
seguir.
6. Melhores Práticas Sugeridas
Com os problemas eminentes na escrita dos critérios de aceite, o comitê ágil da empresa
estabeleceu treinamentos, junto com um consultor da área de testes e outro da área de
UML (Unified Modeling Language). O treinamento tem como foco visar à boa escrita
de um critério de aceite, trazendo junto um modelo de como deverão ser escritos e
definidos.
Os treinamentos estão ocorrendo no período de um mês, que equivalem a duas
sprints e já estão sendo colocados em prática. No primeiro dia é feito uma introdução
dos problemas ocorrentes da equipe, como atrasos na entrega, quantidade de bugs
elevada, demora na implementação, gerando como consequência disso um gargalo nos
testes. No segundo dia é feito uma leitura da especificação de requisitos com todos os
membros do time, junto ao comitê ágil e consultores. Durante a leitura, são extraídos
todos os requisitos necessários para a nova entrega. Após o entendimento, são separados
por situações de uso as partes que serão de nova implementação. Feito isso, os
requisitos são separados por cenários como exemplificado na Tabela 1:
Envolvidos:
Distribuidor
Processador de pedidos de diligência
Situações de Uso:
• Recebimento de pedido de diligência de originário no PG
Caminho correto
# Envolvido Situação de uso
1 Processador
de pedidos de
diligência
É processado um pedido de diligência de originário vindo do SG
Cenário: Recebimento do pedido de diligência de Originário no PG
Dado um pedido de diligência de originário enviado pelo SG
E o processo <tramitar> no PG

11. Quando o processador receber o pedido de diligência
Então o processo PG é <ação> com as informações de foro, classe, assunto e partes
conforme o pedido de diligência do SG.
E o processo PG foi inserido no fluxo de trabalho na fila “Processos recebidos de 2º grau”
E o processo PG foi inserido no fluxo de trabalho na fila inicial configurada
E o processo PG recebeu uma movimentação “Recebimento da diligência”
E o processo PG recebeu uma tarja “Pedido de diligência”
E é inserido no histórico de integração do PG
Tramitar Ação
Tramitou Reaberto
Não tramitou Cadastrado
Impactos / Riscos
- Sincronização de peças PG-SG .
- Montagem do ambiente de teste para foros em outras bases.
Tabela 1. Tabela de cenários de critérios de aceite
A estrutura é semelhante a um caso de uso. Ela é subdividida pelos seguintes
tópicos:
• Envolvidos: Informa o tipo de perfil que irá realizar a situação de uso.
• Situação de uso: Nova implementação que foi especificada na especificação de
requisito de software.
• Tabela: é composta pelo cenário, que será desenvolvido e em seguida as
informações são detalhadas, para obter o caminho da ação que será
implementada.
Também são informados os impactos e riscos que supostamente essa implementação
poderá sofrer.
7. Conclusão
Nota-se que existem muitos problemas identificados com a má escrita dos critérios de
aceite. Percebe-se também que a maneira como ele é identificado e exposto, faz toda a
diferença no resultado final de uma implementação, independente da fase que o
software estiver, seja ela na implementação, ou nos testes.
Os critérios devem ser objetivos, claros e devem ser escritos junto à equipe e não
somente por um responsável. Na empresa deste caso de estudo, tem-se dado pouca
importância nos critérios de aceite e com isso decidiu-se realizar uma estrutura
padronizada em como defini-los.
Com o treinamento que foi realizado a algumas das equipes, algumas melhorias
já foram detectadas. Uma das vantagens com essa nova mudança, deu-se em conta de

12. toda a equipe participar da escrita dos critérios e também da leitura em conjunto das
especificações de requisitos. Após a leitura, toda a equipe participa da criação dos casos
de uso voltados para os critérios de aceite.
Essa mudança mostra que a teoria de um time ágil agora se faz também na
prática. Que significa equipes auto gerenciáveis trabalhando e definindo suas próprias
particularidades em uma fase de processo de software.
8. Referências
RORIZ FILHO, Heitor; MILANI, Fabiano; CONFORTO, Edivandro. O que são
metodologias ágeis? 2015. Disponível em: <http://massimus.com/2015/06/o-que-sao-
metodologias-ageis-2/>. Acesso em: 05 dez. 2015.
LUNA, Alexandre. Implantando Governança Ágil: Uma visão crítica, uma abordagem
prática. Rio de Janeiro: Brasport, 2011. Disponível em:
<https://books.google.com.br/books?
id=zmeECgAAQBAJ&pg=PA120&dq=Implantando+Governança+Ágil&hl=pt-
BR&sa=X&ved=0ahUKEwj-
_o_0_MLKAhVM4CYKHe51BvAQ6AEIHDAA#v=onepage&q=Implantando
Governança Ágil&f=false>. Acesso em: 05 dez. 2015.
LOBO, Edson J. R.. Curso de Engenharia de Software: Métodos e processos para
garantir a qualidade no desenvolvimento de softwares. São Paulo: Digerati Books,
2008. Disponível em: <https://books.google.com.br/books?
id=ZJznA9UrtVAC&pg=PA42&dq=metodologias+ageis&hl=pt-
BR&sa=X&redir_esc=y#v=onepage&q=metodologias ageis&f=false>. Acesso em: 05
dez. 2015.
CRUZ, Fábio. Scrum e Agile em Projetos Guia Completo: Conquiste sua certificação e
aprenda a usar métodos ágeis no seu dia a dia. Rio de Janeiro: Brasport, 2015.
Disponível em: <https://books.google.com.br/books?
id=NW2LBgAAQBAJ&printsec=frontcover&dq=scrum&hl=pt-
BR&sa=X&redir_esc=y#v=onepage&q=scrum&f=false>. Acesso em: 20 dez. 2015.
LEFFINGWELL, Dean. et al. Scaled Agile Framework. 2001. Disponível em:
<http://www.scaledagileframework.com/>. Acesso em: 22 julho 2015.
NOVAES, Rafael. Critérios de aceitação e sua relação com os pontos explícitos e
implícitos. Disponível em: <http://www.psafe.com/blog/criterios-de-aceitacao-e-sua-
relacao-com-os-pontos-explicitos-e-implicitos/>. Acesso em: 03 mar. 2016.
ADZIC, Gojko. SPECIFICATION BY EXAMPLE: How successful teams deliver the
right software. Shelter Island: Manning Publications Co, 2011.
PUGH, Ken. Lean-Agile Acceptance Test-Driven Development: Better Software
Through Collaboration. Boston: Nel Objectives, 2011.

13. CRISPIN, Lisa; GRGORY, Janet. Agile testing: A Practical Guide for Testers and Agile
Teams. Boston: Addison-wesley, 2009. Disponível em:
<https://books.google.com.br/books?
id=68_lhPvoKS8C&printsec=frontcover&dq=Agile+testing&hl=pt-
BR&sa=X&redir_esc=y#v=onepage&q=Agile testing&f=false>. Acesso em: 14 dez.
2015.
GÄRTNER, Markus. ATDD by Example: A Practical Guide to Acceptance Test-Driven
Development. Boston: Addison-wesley Professional, 2012. Disponível em:
<https://books.google.com.br/books?
id=XYU5R9Win1UC&printsec=frontcover&dq=ATDD+by+Example+A+Practical+
Guide+to+Acceptance+Test-Driven+Development&hl=pt-
BR&sa=X&redir_esc=y#v=onepage&q=ATDD by Example A Practical Guide to
Acceptance Test-Driven Development&f=false>. Acesso em: 14 dez. 2015.
GRANDO, Nei. Metodologias Ágeis no Desenvolvimento de Projetos de
Software. 2010. Disponível em:
<https://neigrando.wordpress.com/2010/09/06/metodologias-ageis-no-
desenvolvimento-de-projetos-de-software/>. Acesso em: 09 mar. 2016.