SlideShare uma empresa Scribd logo
1 de 13
Baixar para ler offline
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,
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.
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].
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.
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]
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.
• 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
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
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
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
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
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.
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.

Mais conteúdo relacionado

Mais procurados

Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumRaphael Donaire Albino
 
Guia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de FunçãoGuia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de FunçãoFernando Palma
 
Metodologia ágil
Metodologia ágilMetodologia ágil
Metodologia ágilrolfczekus
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareEverton vitor
 
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...André Luis Celestino
 
Metodologia ágil das Desenvolvimento Adaptativo Software
Metodologia ágil das   Desenvolvimento Adaptativo SoftwareMetodologia ágil das   Desenvolvimento Adaptativo Software
Metodologia ágil das Desenvolvimento Adaptativo SoftwareMarilainny Martins da Silva
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrumjrompkovski
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANFernando Palma
 
Métodos ágeis de desenvolvimento de software
Métodos ágeis de desenvolvimento de softwareMétodos ágeis de desenvolvimento de software
Métodos ágeis de desenvolvimento de softwareJerônimo Medina Madruga
 

Mais procurados (20)

Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando ScrumGerenciando Projetos De Software De Forma áGil Utilizando Scrum
Gerenciando Projetos De Software De Forma áGil Utilizando Scrum
 
Guia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de FunçãoGuia Prático em Análise de Ponto de Função
Guia Prático em Análise de Ponto de Função
 
Metodologia ágil
Metodologia ágilMetodologia ágil
Metodologia ágil
 
Scrum
ScrumScrum
Scrum
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Agil - artigo cientifico
Agil - artigo cientificoAgil - artigo cientifico
Agil - artigo cientifico
 
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
Múltiplas equipes ágeis com o framework Large Scale Scrum - um estudo de caso...
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 
Metodologia ágil das Desenvolvimento Adaptativo Software
Metodologia ágil das   Desenvolvimento Adaptativo SoftwareMetodologia ágil das   Desenvolvimento Adaptativo Software
Metodologia ágil das Desenvolvimento Adaptativo Software
 
Programa de Treinamento e Certificacao
Programa de Treinamento e CertificacaoPrograma de Treinamento e Certificacao
Programa de Treinamento e Certificacao
 
Artigo corrigido
Artigo corrigidoArtigo corrigido
Artigo corrigido
 
Métodos ágeis
Métodos ágeisMétodos ágeis
Métodos ágeis
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrum
 
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBANDesenvolvimento ágil de software: análise sintética a partir de KANBAN
Desenvolvimento ágil de software: análise sintética a partir de KANBAN
 
Desenvolvimento ágil com scrum
Desenvolvimento ágil com scrumDesenvolvimento ágil com scrum
Desenvolvimento ágil com scrum
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Métodos ágeis de desenvolvimento de software
Métodos ágeis de desenvolvimento de softwareMétodos ágeis de desenvolvimento de software
Métodos ágeis de desenvolvimento de software
 
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
O Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias ...
 
Gestao agil de projetos
Gestao agil de projetosGestao agil de projetos
Gestao agil de projetos
 

Semelhante a Artigo Pós graduação_Caroline Seara (2)

Artigo-Alex_Warmling
Artigo-Alex_WarmlingArtigo-Alex_Warmling
Artigo-Alex_WarmlingChaordic
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareThiago Reis da Silva
 
Erika questionario pt 2 (Eng Software III).
Erika questionario pt  2 (Eng Software III).Erika questionario pt  2 (Eng Software III).
Erika questionario pt 2 (Eng Software III).Érika Santos
 
Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Clavius Tales
 
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"Alessandro Almeida
 
Gerenciamento Ágil de Startups
Gerenciamento Ágil de StartupsGerenciamento Ágil de Startups
Gerenciamento Ágil de StartupsElton Nascimento
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL Gjrnavarro
 
Desenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas LeanDesenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas LeanRenan Daré
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven developmentIzabel Rodrigues
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4André Vidal
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Agile Think® Share
 
Artigo piramide lean final
Artigo piramide lean   finalArtigo piramide lean   final
Artigo piramide lean finalStartupi
 

Semelhante a Artigo Pós graduação_Caroline Seara (2) (20)

Metodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de SistemaMetodologia de Desenvolvimento de Sistema
Metodologia de Desenvolvimento de Sistema
 
Artigo-Alex_Warmling
Artigo-Alex_WarmlingArtigo-Alex_Warmling
Artigo-Alex_Warmling
 
Artigo
ArtigoArtigo
Artigo
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
 
Erika questionario pt 2 (Eng Software III).
Erika questionario pt  2 (Eng Software III).Erika questionario pt  2 (Eng Software III).
Erika questionario pt 2 (Eng Software III).
 
Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009Governança Ágil - Ágiles 2009
Governança Ágil - Ágiles 2009
 
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
[Gestão da TI] Governança de TI: Modelos, certificações e "melhores práticas"
 
Os 12 Princípios Ágeis
Os 12 Princípios ÁgeisOs 12 Princípios Ágeis
Os 12 Princípios Ágeis
 
Gerenciamento Ágil de Startups
Gerenciamento Ágil de StartupsGerenciamento Ágil de Startups
Gerenciamento Ágil de Startups
 
Startup em Scrum
Startup em ScrumStartup em Scrum
Startup em Scrum
 
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL GPROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
PROPOSTA DE ADAPTAÇÃO DAS PRÁTICAS DO SCRUM PARA O MPS.BR NIVEL G
 
DevOps - Reduza o tempo de entrega da sua TI
DevOps - Reduza o tempo de entrega da sua TIDevOps - Reduza o tempo de entrega da sua TI
DevOps - Reduza o tempo de entrega da sua TI
 
Vantagens agil 3
Vantagens agil 3Vantagens agil 3
Vantagens agil 3
 
Desenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas LeanDesenvolvimento ágil e práticas Lean
Desenvolvimento ágil e práticas Lean
 
Feature driven development
Feature driven developmentFeature driven development
Feature driven development
 
Iplantação
IplantaçãoIplantação
Iplantação
 
Agile explicacao 18
Agile explicacao 18Agile explicacao 18
Agile explicacao 18
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
 
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4Cursos Agile Think - Feature Driven Development (FDD) - 4/4
Cursos Agile Think - Feature Driven Development (FDD) - 4/4
 
Artigo piramide lean final
Artigo piramide lean   finalArtigo piramide lean   final
Artigo piramide lean final
 

Artigo Pós graduação_Caroline Seara (2)

  • 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.