Embed Size (px)
Citation preview
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
CENTRO DE ENSINO SUPERIOR DO SERIDÓ
DEPARTAMENTO DE COMPUTAÇÃO E TECNOLOGIA
PROGRAMA DE GRADUAÇÃO EM SISTEMAS DE INFORMAÇÃO
SÂMIA LORENA OLIVEIRA MEDEIROS
UTILIZAÇÃO DE MAPAS CAUSAIS E MENTAIS PARA A AVALIAÇÃO DA
METODOLOGIA ÁGIL DE DESENVOLVIMENTO ACADÊMICO (MADA) EM
PROJETOS ACADÊMICOS
Caicó - RN
2016
SÂMIA LORENA OLIVEIRA MEDEIROS
UTILIZAÇÃO DE MAPAS CAUSAIS E MENTAIS PARA A AVALIAÇÃO DA
METODOLOGIA ÁGIL DE DESENVOLVIMENTO ACADÊMICO (MADA) EM
PROJETOS ACADÊMICOS
Trabalho de conclusão de curso apresentado ao curso de
graduação em Sistemas de Informação, como parte dos
requisitos para obtenção do título de Bacharel em
Sistemas de Informação da Universidade Federal do Rio
Grande do Norte.
Orientadora: Adrianne Paula Vieira de Andrade, MSc.
Caicó – RN
2016
Catalogação da Publicação na Fonte Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial do Centro de Ensino Superior do Seridó -
Medeiros, Sâmia Lorena Oliveira.
Utilização de mapas causais e mentais para a
avalização da metodologia ágil de desenvolvimento (MADA)
em projetos acadêmicos / Sâmia Lorena Oliveira Medeiros.
- Caicó: UFRN, 2016. 60f: il.
Orientador: Msc. Adrianne Paula Vieira de Andrade. Monográfia (Bacharelado em Sistema de Informação)
Universidade Federal do Rio Grande do Norte.
1. Engenharia de software. 2. Metodologia de
desenvolvimento de software. 3. Metodologias ágeis. 4. MADA.
I. Andrade, Adriana Paula Vieira de. II. Título.
RN/UF/CERES-CAICÓ CDU 004.42
À minha família, por todo carinho, educação e
confiança em mim depositados. Em especial a
minha mãe Sandra, pelo exemplo de
determinação e força.
AGRADECIMENTOS
A Deus, em primeiro lugar, por minha vida. Por toda saúde, proteção e
persistência que me faz buscar novos caminhos e melhorar ao longo dessa jornada.
Aos meus avós, Mário Lucas de Medeiros e Francisca Romana de Oliveira que
me deram tanto carinho e amor em minha vida.
A minha mãe, Maria Sandra Oliveira Medeiros por ser mãe e pai, pelo esforço e
dedicação para me educar e pelo amor e carinho dados até hoje.
A minha irmã, Maria Samira Medeiros Souza pelas alegrias e descontrações que
me traz em muitos momentos difíceis.
As minhas orientadoras, Adrianne Paula Vieira de Andrade e Karliane Medeiros
Ovidio Vale pelas ideias, incentivos e concelhos não só para este trabalho, mas também para
toda a vida acadêmica e profissional.
Ao professor Flavius da Luz e Gorgônio, por todos os questionamentos não
apenas para este trabalho, como aos vários ensinamentos durante a caminhada nesse curso.
Ao meu noivo e amigo, Cássio Alves Galvão pela confiança depositada e
compreensão nos momentos de preocupação, além de todo amor, companheirismo e apoio
recebidos.
Aos alunos que aceitaram participar da aplicação deste trabalho, por toda
disponibilidade e paciência.
Aos colegas, por toda amizade e companheirismo ao passarmos pelas dificuldades
nessa jornada. Em especial, Narallynne Maciel, Jaqueline Santos, George Daniel, Hyago
Brendoll, Pablo Lopes, Állif Henrique, Olívia Emanuelle, Jane Cristine, Thayse Dayane e
toda família LABICAN. Amigos que contribuíram direta ou indiretamente para realização
deste trabalho.
RESUMO
Sabe-se que existem discrepâncias em relação ao uso de metodologias ágeis no âmbito
acadêmico e no mercado de trabalho. Nesse sentido, surgiram questionamentos que buscam a
combinação dessas utilizações. Dentro desse contexto existem estudos que realizaram
adaptações das metodologias com foco no mercado, além dos estudos que levaram a criações
de metodologias de base acadêmica, como a easYProcess (YP). Com a utilização da YP no
curso de Sistemas de informação (SI) da UFRN, foram realizadas adaptações nessa
metodologia. Com base nessa afirmação, pesquisas levaram a criação de uma metodologia
que satisfaça a necessidade do curso, então nasceu a Metodologia Ágil de Desenvolvimento
Acadêmico (MADA), direcionada para a realidade de SI. A mesma começou a ser aplicada
em SI nos projetos de estágio. Em sua segunda aplicação, a metodologia sofreu modificações,
mostrando lacunas que podem ser estudadas. Nessa circunstância, o presente trabalho
apresenta uma avaliação da utilização da MADA de acordo com os princípios ágeis através da
aplicação em algumas equipes disciplinares. Tal análise, realizada com os membros das
equipes dos projetos envolvidos, executando entrevistas com base nos princípios ágeis. Sendo
possível identificar as experiências dessas equipes nessa pesquisa, codificando os relatos dos
entrevistados e construindo mapas causais com linguagem sistêmica que se relacionam com
estes princípios. Com estes mapas foi possível identificar as características que influenciam
positiva e negativamente na utilização da metodologia, além da possibilidade de percepção de
aprendizagem dos alunos quanto ao uso de metodologias ágeis.
Palavras-chaves: 1. Engenharia de software. 2. Metodologia de desenvolvimento de software.
3. Princípios ágeis. 4. Metodologias ágeis. 5. MADA.
ABSTRACT
It is known that there are discrepancies regarding the use of agile methodologies in the
academic environment and the labor market. In this sense, questions have arisen that seek the
combination of these uses. In this context, there are studies that presented academic
adaptations of market focused methodologies, along with studies that led to the creation of
academic-based methodologies, such as easYProcess (YP). With the use of YP in the
Information Systems (IS) undergraduate course at UFRN, this methodology has been adapted.
Based on this assertion, research has led to the creation of a methodology that meets the needs
of the IS course, which brought about the conception of the Metodologia Ágil de
Desenvolvimento Acadêmico (MADA), specific to the scenario of SI. The said methodology
began to be applied in the Information Systems internship projects. In a second application,
the method has undergone modifications, bringing out gaps that can be studied. In this
circumstance, this paper presents an assessment of the use of MADA according to agile
principles by applying it in some disciplinary teams. This analysis, carried with the members
of the project teams involved, conducting interviews based on agile principles. In this
research, it is possible to identify the experiences of these teams, encoding the reports of
respondents and building causal maps with systemic language which are related to these
principles. With these maps it was possible to identify the characteristics that influence
positively and negatively on the use of the methodology, besides the possibility of perception
of student learning in the use of agile methodologies.
Keywords: 1. Software Engineering. 2. Software development methodology. 3. Agile
principles. 4. Agile methodologies. 5. MADA.
LISTA DE FIGURAS
Figura 1 – Fluxo do YP ............................................................................................................ 18
Figura 2 – Ciclo de vida Scrum ................................................................................................ 20
Figura 3 – Fluxo da MADA ..................................................................................................... 21
Figura 4 – Abordagem metodológica ....................................................................................... 30
Figura 5 – Exemplo de mapa mental ........................................................................................ 31
Figura 6 – Exemplo de mapa causal ......................................................................................... 31
Figura 7 – Proporcionalidade das influências........................................................................... 32
Figura 8 – Mapa cognitivo dos princípios ágeis. ...................................................................... 33
Figura 9 – Mapa causal da satisfação do cliente ...................................................................... 35
Figura 10 – Mapa causal do acolhimento às mudanças de requisitos ...................................... 37
Figura 11 – Mapa mental da frequência nas entregas .............................................................. 39
Figura 12 – Mapa causal das equipes trabalhando juntas ......................................................... 39
Figura 13 – Mapa causal da motivação .................................................................................... 41
Figura 14 – Mapa causal do compartilhamento de informações face a face ............................ 43
Figura 15 – Mapa causal do software funcional ....................................................................... 44
Figura 16 – Mapa causal do ritmo de desenvolvimento sustentável ........................................ 45
Figura 17 – Mapa causal da atenção contínua .......................................................................... 46
Figura 18 – Mapa causal da simplicidade ................................................................................ 48
Figura 19 – Mapa causal da organização.................................................................................. 49
Figura 20 – Mapa causal da reflexão do comportamento ......................................................... 50
LISTA DE SIGLAS
AM – Agile Modeling
BSI – Bacharelado em Sistemas de Informação
ES – Engenharia de Software
FDD – Feature Driven Development
LABICAN – Laboratório de Inteligência Computacional Aplicada a Negócios
MADA – Metodologia Ágil para Desenvolvimento Acadêmico
MPS.BR – Melhoria de Processos do Software Brasileiro
OTAN – Organização do Tratado do Atlântico Norte
PO – Product Owner
RUP – Rational Unified Process
SABIA – Sistema de Agrupamento Baseado em Inteligência Artificial
SAHARAS – Sistema para gestão de haras
SI – Sistemas de Informação
SICROWEB – Sistema de informação para controle da escala bibliotecária dos bolsistas
SIGVIAA – Sistema de Gestão de Viagens Administrativas e Acadêmicas
TI – Tecnologia da Informação
UFCG – Universidade Federal de Campina Grande
UFRN – Universidade Federal do Rio Grande do Norte
UML – Unified Modeling Language
XP – Extreme Programming
YP – easYProcess
11
Sumário
1. INTRODUÇÃO .................................................................................................................. 12
1.1. Tema .............................................................................................................................. 13
1.2. Contextualização e problema ........................................................................................ 13
1.3. Objetivos da pesquisa .................................................................................................... 15
1.3.1. Objetivo geral ......................................................................................................... 15
1.3.2. Objetivos específicos .............................................................................................. 15
1.4. Delimitação do estudo ................................................................................................... 15
1.5. Motivação e justificativa ............................................................................................... 16
2. METODOLOGIAS ÁGEIS ............................................................................................... 17
2.1. easYProcess (YP) .......................................................................................................... 17
2.2. Scrum ............................................................................................................................. 19
2.3. Mada .............................................................................................................................. 20
2.4. Trabalhos relacionados .................................................................................................. 24
3. PROCEDIMENTOS METODOLÓGICOS .................................................................... 28
3.1. Mapas causais e mentais ................................................................................................ 30
4. RESULTADOS ................................................................................................................... 33
4.1. Satisfação do cliente ...................................................................................................... 34
4.2. Acolhimento às mudanças de requisitos ........................................................................ 36
4.3. Frequência das entregas ................................................................................................. 38
4.4. Equipes trabalhando juntas ............................................................................................ 39
4.5. Motivação ...................................................................................................................... 40
4.6. Compartilhamento de informações face a face.............................................................. 42
4.7. Software funcional ......................................................................................................... 43
4.8. Ritmo de desenvolvimento constante ............................................................................ 44
4.9. Atenção contínua a excelência técnica .......................................................................... 46
4.10. Simplicidade ................................................................................................................ 47
4.11. Organização ................................................................................................................. 48
4.12. Reflexão do comportamento ........................................................................................ 50
5. CONSIDERAÇÕES FINAIS ............................................................................................. 52
REFERÊNCIAS ..................................................................................................................... 54
APÊNDICE A – MODELO DE TERMO DE CONSENTIMENTO ................................. 59
APÊNDICE B – MODELO DE TERMO DE CONFIDENCIALIDADE ......................... 60
APÊNDICE C – ROTEIRO DE ENTREVISTA ................................................................. 61
12
1. INTRODUÇÃO
O termo Engenharia de Software (ES) surgiu na conferência patrocinada pela
Comissão de Ciência da OTAN em 1968, onde tal termo se refere à abordagem altamente
disciplinada e sistemática para o desenvolvimento e manutenção de software. Nesta
conferência foi discutida a dificuldade e a complexidade das tarefas de produção de software,
com isso, iniciou-se uma busca por soluções concentrando nas melhores ferramentas e
metodologias (WIRTH, 2008).
Segundo Hirama (2011), a engenharia de software abrange ferramentas de apoio
para as atividades, métodos para orientar a realização das atividades, processo para definir as
atividades e os produtos, além da qualidade de processo e de produto de software. Essas
atividades abrangem técnicas de engenharia de sistemas, análise, projeto, codificação e testes.
Os métodos foram baseados em duas abordagens: Programação Estruturada e Orientada a
Objetos.
Ainda segundo Hirama (2011), as atividades de engenharia de sistemas têm por
objetivo entender as necessidades de negócio do cliente e especificar os requisitos do sistema
computacional. A análise procura entender e especificar os requisitos de sistema e software.
As atividades de projeto pretendem manter a arquitetura do software executável. A
codificação traduz as especificações de software em códigos de programa que possam ser
processados por um sistema computacional. Os testes têm por objetivo encontrar defeitos no
software, tanto no aspecto funcional quanto estrutural.
A necessidade de seguir uma diretriz para o desenvolvimento de software se
tornou fundamental para garantir a qualidade dos projetos e dos sistemas após o surgimento
da ES. Sendo assim, as primeiras metodologias, ditas atualmente como tradicionais, foram
introduzidas para orientar às equipes de desenvolvimento (ARAÚJO et. al., 2014).
Com o aumento na utilização de metodologias, seus métodos e processos foram
aprimorados após o advento de novos modelos (ARAÚJO, 2014). A partir de 2001, a
concepção com relação às metodologias de desenvolvimento ágeis começou a ser disseminada
por meio da criação do Manifesto Ágil, uma reunião onde dezessete líderes de ideias,
metodologias e processos, que apesar das diferentes práticas defendidas chegaram a um
conjunto de valores e princípios para essas metodologias que recebeu o termo “Ágil” (PHAM;
PHAM, 2011; SABBAGH, 2013).
13
Entendendo que a ES nos cursos da área de Tecnologia da Informação (TI), tem o
objetivo de expor vários aspectos quanto à construção de sistemas de forma prática, é
necessário a proximidade com as metodologias que estão sendo mais utilizadas no mercado e
adaptação destas para a academia (RODRIGUES; ESTRELA, 2012). A partir desse contexto,
metodologias foram criadas para levar aos alunos das disciplinas da área de ES, uma prática
que diminuísse as limitações do curto período de tempo para o desenvolvimento e o risco de
fugir do foco ágil das metodologias que são mais utilizadas no mercado de trabalho
(GARCIA; SILVA, 2013).
Duas dessas metodologias são: 1) a easYProcess (YP), derivada do eXtreme
Programming (XP), Rational Unified Process (RUP) e Agile Modeling (AM), usada na
Universidade Federal de Campina Grande (UFCG) onde surgiu, e também no curso
Bacharelado em Sistemas de Informação (BSI) da Universidade Federal do Rio Grande do
Norte (UFRN); 2) a Metodologia Ágil de Desenvolvimento Acadêmico (MADA) que foi
criada e desenvolvida no BSI da combinação de YP e Scrum. Sendo esta, uma junção de
metodologias muito utilizadas, o YP no ambiente acadêmico e o Scrum no mercado de
trabalho, esta pesquisa investiga a metodologia MADA com a finalidade de analisar seu uso a
partir dos princípios ágeis através da sua aplicação em algumas equipes.
1.1. Tema
Utilização de mapas causais e mentais para avaliação da Metodologia Ágil de
Desenvolvimento Acadêmico (MADA) em projetos acadêmicos executados em componente
curricular com base nos princípios ágeis.
1.2. Contextualização e problema
Com o desígnio de melhorar o aprendizado prático da engenharia de software e o
alinhamento do desenvolvimento entre a vida acadêmica e mercado, a MADA foi
desenvolvida combinando as metodologias de desenvolvimento ágil, YP e Scrum pela
Bacharela em Sistemas de Informação Narallynne Maciel de Araújo durante o trabalho de
conclusão de curso, na UFRN, sobre a orientação da Profa. MSc. Karliane Medeiros O. Vale.
Esta metodologia foi criada pela necessidade de impulsionar o aprendizado das práticas
metodológicas de desenvolvimento de software acadêmico abordando o mercado de trabalho
com uso de modelos ágeis (ARAÚJO, 2014).
14
Considerando que quanto mais estudos são realizados, melhorias e
aprimoramentos podem ser feitos para o uso de diversas tecnologias e ferramentas foi que
surgiu a necessidade da avaliação da MADA. Então partindo desse ponto, ter novos estudos
sobre a MADA, que teve aplicações durante sua criação, mas não teve análises posteriores a
tal trabalho, permite que sejam realizadas adaptações e melhorias tornando-a ainda mais fácil
de ser utilizada e aumentando suas vantagens. Portanto, fazem-se necessárias análises sobre
seu uso, através de novas aplicações nas disciplinas.
Das utilizações realizadas na criação da metodologia, foi efetuada a aplicação de
um questionário online junto às equipes dos projetos SIGVIAA (Sistema de Gestão de
Viagens Administrativas e Acadêmicas) e SABIA (Sistema de Agrupamento Baseado em
Inteligência Artificial), capaz de relacionar o uso das metodologias YP, Scrum e MADA,
quanto à execução dos princípios ágeis. Além de obter informações a respeito da prática da
MADA, tal como o grau de dificuldade de sua aplicação, a sua adequação à realidade do
ambiente de desenvolvimento e ao ciclo de vida do projeto (ARAÚJO, 2014).
A partir do questionário citado acima foram obtidos alguns resultados, como: 50%
nível de satisfação total para os princípios ágeis 1 e 2, que referem-se respectivamente, a
satisfação do cliente com entregas de software de valor contínuo e frequente, e a capacidade
de acolher mudanças de requisitos em qualquer fase do projeto. No princípio ágil 7, que
refere-se ao software funcional ser sinônimo de progresso no desenvolvimento, o MADA
mostrou-se igualmente satisfatória ao YP. E no princípio ágil 11, que diz respeito quanto à
organização da equipe pode promover melhores arquiteturas, requisitos e projetos, a tal
alcançou 62,5% para a satisfação total (ARAÚJO, 2014).
De acordo com esses resultados, a MADA mostrou-se melhor ou igualmente
satisfatória que a YP e a Scrum na maioria dos princípios ágeis. Em apenas um, no qual
defende que a atenção contínua a excelência técnica e um bom projeto aumentam a agilidade,
mostrou-se inferior. Porém justificado, por está visando não a excelência técnica e sim uma
melhor qualidade de planejamento (ARAÚJO, 2014). Sendo a MADA uma metodologia ágil
nova, que pode vir a ser uma metodologia adotada pelo curso BSI para desenvolvimento de
projetos, é possível que equipes consigam durante sua utilização seguir os valores e princípios
ágeis do Manifesto Ágil?
15
1.3. Objetivos da pesquisa
Os objetivos deste trabalho são divididos em objetivos geral e específicos.
1.3.1. Objetivo geral
O presente trabalho tem como objetivo geral avaliar a utilização da metodologia
MADA ágeis através da sua aplicação em algumas equipes durante componente curricular
com base nos princípios fazendo uso de mapas sistêmicos.
1.3.2. Objetivos específicos
a) Selecionar os projetos da disciplina Engenharia de software II que utilizaram a
MADA para serem acompanhados;
b) Acompanhar a utilização da metodologia durante a execução dos projetos,
participando das aulas da disciplina;
c) Realizar entrevistas junto às equipes de desenvolvimento que utilizam a MADA;
d) Criar mapas sistêmicos a partir dos relatos;
e) Analisar os dados obtidos dos relatos e dos mapas.
1.4. Delimitação do estudo
Nas disciplinas da área de Engenharia de Software, estuda-se sobre metodologias
de desenvolvimento tanto tradicionais quanto ágeis. Com isso, espera-se que os alunos de tais
disciplinas aprendam a desenvolver programas de computadores utilizando metodologias que
aproximem o desenvolvimento na academia com o desenvolvimento do mercado,
contribuindo para troca de experiências entre os alunos. Fazendo-se notar que a utilização de
metodologias do mercado de trabalho passa por várias adaptações para atender as
necessidades acadêmicas (ARAÚJO; GORGÔNIO; VALE, 2014).
Então, nesse contexto, foi desenvolvida no curso BSI da UFRN, uma metodologia
ágil, denominada Metodologia Ágil de Desenvolvimento Acadêmico (MADA), mais
adequada à realidade dos alunos, buscando essa aproximação no curso, que utiliza as
metodologias eXtreme Programming (XP), easYProcess (YP) e Scrum. A partir dessa
afirmação, delimita-se este trabalho a um estudo sobre a metodologia de desenvolvimento de
16
software MADA, limitado a dois casos que a utilizaram nos projetos desenvolvidos na
disciplina de Engenharia de Software II.
1.5. Motivação e justificativa
Como motivação pessoal para realizar este trabalho, o gosto pela engenharia de
software e pelas metodologias. Como motivação acadêmica, a contribuição com os testes da
metodologia a ser avaliada no decorrer deste trabalho.
Justifica-se este trabalho com a necessidade de testar a utilização da metodologia
em disciplinas, já que seu foco é acadêmico, o que dará mais experiência a mesma. Além de
facilitar o uso ao identificar onde estão as maiores dificuldades de utilização da metodologia
junto aos alunos.
17
2. METODOLOGIAS ÁGEIS
Para a engenharia de software, uma metodologia ágil, que é um modelo
fornecedor de informações técnicas para desenvolver software de forma mais flexível,
enfatiza quatro elementos-chave: 1) a importância da equipe ser auto-organizável, que
mantém o controle sobre o trabalho por ela realizado; 2) a comunicação e colaboração entre
os membros da equipe, bem como entre a equipe e o cliente; 3) o reconhecimento de que
mudanças representam oportunidades, ou seja, é adaptativa; 4) destaque para entrega rápida
do produto para atender o cliente (PRESSMAN, 2011; SOMMERVILLE, 2007).
Já as metodologias tradicionais, que são uma representação abstrata fornecedora
de um conjunto de informações técnicas predefinidas e mais estáveis, não possuem esses
elementos e são mais burocráticas (SOMMERVILLE, 2007). Há além dessas características,
outras distintas características entre metodologias ágeis e tradicionais, que são os seus
métodos serem orientados a pessoas e a processos, respectivamente (SBROCCO; MACEDO,
2012).
Ao utilizar metodologias de desenvolvimento de software para o ensino nas
universidades, uma tarefa frequente dos cursos de tecnologia tem sido adaptá-las a fim de
obter um desenvolvimento de projetos com maior qualidade e adequados à realidade
acadêmica (RODRIGUES; ESTRELA, 2012). No curso de BSI da UFRN, as metodologias
tradicionais são introduzidas teoricamente, e as metodologias ágeis XP, YP e Scrum são
muito utilizadas na prática (GARCIA; SILVA, 2013). Sendo que as mais utilizadas são XP e
Scrum por terem o foco no mercado de trabalho (ARAÚJO, 2014).
2.1. easYProcess (YP)
A metodologia easYProcess surgiu na UFCG em 2003, desenvolvida por
estudantes do curso Ciência da Computação, com o objetivo de auxiliar na gerência do
desenvolvimento de projetos acadêmicos de pequeno e médio porte. O principal motivo para
o surgimento dessa metodologia foram as dificuldades encontradas em adaptar as
metodologias existentes ao uso na academia (Garcia, et. al., 2004). A YP teve seu
desenvolvimento a partir de três fases: o estudo, a concepção e a implantação.
A primeira deu-se a avaliação e comparação das condutas e dos artefatos das
metodologias escolhidas para servirem de base para a YP por serem consideradas as mais
adaptáveis à academia que foram as metodologias Rational Unified Process (RUP), XP e
18
Agile Modeling (AM). Esta última tem foco na modelagem e documentação, podendo ser
usada como complemento ao uso de metodologias ágeis (AMBLER, 2001). O RUP prega a
prática de uma disciplina em tarefas. O XP visa garantir a satisfação do cliente e favorecer o
cumprimento das estimativas (SBROCCO; MACEDO, 2012). A segunda fase onde a
metodologia começou a nascer, então foi elaborado o fluxo básico do YP e suas fases que
estão sendo exibida na Figura 1. E a terceira, onde foi implantada, observada e testada para
ser avaliada sua utilização.
Figura 1 – Fluxo do YP
Fonte: adaptado de GARCIA et. al. (2004).
Analisando a Figura 1, pode-se ver na primeira fase, a Definição de Papéis,
reunião que deve durar em média 20 minutos, onde são delegadas as pessoas para os papéis
que o processo define como cliente, usuário, gerente, desenvolvedor e testador. Uma pessoa
pode ter mais de um papel por se tratar de equipes pequenas. Em seguida, temos a fase
Conversa com o Cliente, reunião que dura em média 2 horas e busca obter as informações
para criar os artefatos que podemos ver expostos em tópicos na figura, que são: documento de
visão, documento de requisitos, perfil do usuário e objetivos de usabilidade (GARCIA et. al.
2004).
A terceira fase compreende a Inicialização, que acontecem as atividades iniciais
de análise, além das estimativas de tempo estipuladas a partir das prioridades definidas pelo
19
cliente. Os artefatos dessa fase são: user stories (histórias de usuário), modelo de tarefa,
projeto arquitetural, testes de aceitação, protótipo de interface e modelo lógico de dados. Na
fase de Planejamento são definidas as atividades e a distribuição dos casos de uso nas
iterações. Na fase de Implementação, são desenvolvidas as atividades definidas em cada
iteração na fase do planejamento, durante essa fase realiza-se as reuniões de acompanhamento
e os artefatos Big chat, TAA completa e Análise dos riscos (GARCIA et. al. 2004).
2.2. Scrum
O Scrum foi desenvolvido por Jeff Sutherland e por sua equipe no início da
década de 1990. Mais tarde, Sutherland com a colaboração de Scwaber e Beedle
desenvolveram métodos adicionais. Seguindo as teorias de Takeuchi e Nonaka (1986) que
retratam que projetos com equipes pequenas e multifuncionais produzem melhores resultados,
chegaram assim, na metodologia Scrum que conhecemos hoje. Sua denominação provém de
uma atividade do rugby – esporte semelhante ao futebol americano (PRESSMAN, 2011).
A metodologia Scrum tem por base seis características principais: a flexibilidade
dos resultados e dos prazos, times pequenos, a colaboração, orientação a objetos e revisões
frequentes (SBROCCO; MACEDO, 2012). Além destas características elementares, o Scrum
possui seu fluxo orientado por ciclos, nomeado de sprints, que são iterações de trabalho com
duração variável entre uma a quatro semanas. E segue ainda o princípio básico de reconhecer
que o cliente pode mudar de ideia no decorrer do projeto, adotando então, uma abordagem
empírica ao aceitar que o problema do cliente não pode ser totalmente entendido ou definido
(SBROCCO; MACEDO, 2012).
Esta metodologia é conhecida por estabelecer papéis e cerimônias que geram seus
artefatos. Seus papéis são o Product Owner (PO), o Scrum Master, a Equipe Scrum e o
Cliente (SBROCCO; MACEDO, 2012). O PO representa o cliente, mediando seus interesses
e da equipe. O Scrum Master desempenha o papel de facilitador removendo impedimentos. A
equipe desenvolve o projeto e deve possuir característica multifuncional. O cliente analisa
durante o projeto os subprodutos gerados.
Os artefatos básicos gerados a partir das cerimônias são o Backlog do produto, o
Backlog da Sprint, e o Gráfico Burndown. O Quadro de tarefas complementa o backlog da
sprint (SBROCCO; MACEDO, 2012). Backlog do produto é uma lista de prioridades feita no
início do projeto e mantida pelo PO, contendo todos os itens que devem ser desenvolvidos
20
durante o projeto. Backlog da Sprint representa todas as tarefas a serem realizadas em uma
sprint. Gráfico Burndown exibe o esforço que resta para finalizar a sprint, além de como está
o desempenho da equipe em relação à meta. Quadro de tarefas é usado para acompanhar
como está a sprint, principalmente nas reuniões diárias.
As cerimônias que podemos identificar são o Planejamento da Sprint, a Reunião
Diária, a Revisão da Sprint, e a Retrospectiva da Sprint. O planejamento da Sprint é uma
reunião onde o PO elabora uma lista de prioridades, os itens do backlog do produto e a meta
da Sprint. E a equipe define a Sprint backlog. Reunião diária é uma reunião rápida para saber
como está a evolução das tarefas da Sprint. Revisão da Sprint é uma reunião onde tudo que foi
realizado na Sprint, é apresentado e ainda entregue um produto ou subproduto ao PO.
Retrospectiva da Sprint é uma forma de garantir a melhoria contínua do processo. Além
destas, o Scrum conta com a técnica pôquer do planejamento, utilizada no planejamento da
sprint, onde é estipulado o tempo do trabalho a ser realizado.
O ciclo de vida da metodologia, que pode ser visto na Figura 2 abaixo, inicia com
a reunião de planejamento da sprint, onde é definido o backlog do produto. Após isto, deve
ser decidido o backlog da sprint (SBROCCO; MACEDO, 2012). No decorrer da sprint
acontecem as reuniões diárias e no fim da sprint devem ocorrer revisão e retrospectiva da
Sprint. Ao final de cada sprint é entregue um subproduto até que finalize o produto completo
(ARAÚJO, 2014).
Figura 2 – Ciclo de vida Scrum
Fonte: ARAÚJO, 2014.
2.3. Mada
A Metodologia Ágil de Desenvolvimento Acadêmico (MADA) surgiu a partir das
discordâncias encontradas na utilização das metodologias XP, YP, RUP e Scrum no BSI, bem
21
como pela necessidade de desenvolver uma abordagem que seja mais adequada ao curso. A
partir deste contexto, a Bacharela em Sistemas de Informação, Narallynne Maciel de Araújo,
desenvolveu a MADA através da combinação das metodologias YP e Scrum, que foram
selecionadas para esse processo por suas finalidades: a YP voltada para a academia e a Scrum
voltada para o mercado com processos mais enxuto, adaptativo, auto-organizável e com
mecanismos orientados para motivação e redução de riscos (ARAÚJO, 2014).
O objetivo da MADA é promover uma perspectiva da realidade do mercado de
trabalho voltada para o ambiente acadêmico. Segundo Araújo (2014), a MADA teve a criação
de seu fluxo com base no YP e no ciclo de vida do Scrum, onde se optou por deixá-lo mais
semelhante ao YP. Podemos perceber essa combinação na Figura 3.
Figura 3 – Fluxo da MADA
Fonte: adaptado de ARAÚJO, 2014.
Pode-se ver que, o fluxo começa na fase Reuniões Iniciais, onde são elaborados os
artefatos Formação da Equipe, Definição dos Objetivos e Distribuição das Atividades, que
podem ser mantidas juntas em documento único. A formação da equipe é a seleção dos
integrantes da equipe do projeto, realizada pelo gerente de projetos e as partes interessadas no
projeto. A definição dos objetivos é o ponto da reunião onde se define o escopo do problema e
os objetivos gerais do projeto, que deve ser feita pela equipe e o cliente. Na distribuição das
atividades, ocorre uma discussão dos membros da equipe sobre suas habilidades e
especialidades, a partir delas, definem os papéis e responsabilidades de cada membro da
equipe (ARAÚJO, 2014).
Após essa fase ser realizada, segue-se para a fase Conversa com o Cliente, onde
serão elaborados os seguintes artefatos: Documento de Visão, Documentos de Requisitos e
Perfil do Usuário. Estes artefatos também podem ficar em um único documento. O documento
22
de visão, assim como o documento de requisitos, é de responsabilidade do cliente e a equipe,
e o documento de perfil do usuário a responsabilidade fica para a equipe e os usuários
(ARAÚJO, 2014).
O documento de visão é uma descrição geral sobre o que o sistema se propõe a
fazer, identificando os usuários e características. O documento de requisitos são listas dos
requisitos funcionais e não funcionais necessários para o desenvolvimento do software, onde
os funcionais são partes ou funções do software, e não funcionais são tecnologias, questões de
desempenho, usabilidade, confiabilidade, segurança, manutenibilidade e restrições. No perfil
do usuário contém a descrição das características dos potenciais usuários do sistema,
apontando suas habilidades e limitações (ARAÚJO, 2014).
Finalizada a fase anterior, parte-se para a etapa de Inicialização, onde são
desenvolvidas as atividades de análise do software. E são produzidos os seguintes artefatos:
protótipo de interface, projeto arquitetural, modelo lógico de dados, diagramas UML e
especificações dos casos de uso. As três primeiras fases relatadas até aqui, são gerados
documentos baseados na metodologia YP (ARAÚJO, 2014).
O protótipo de interface é um modelo de interface que pode chegar a ser a
interface gráfica do software e serve de apoio aos desenvolvedores, podendo sofrer alterações
ao longo do projeto e deve ser criada pela equipe e cliente. O projeto arquitetural descreve as
ações do sistema com informações inalteráveis durante o projeto. Deve possuir a estrutura
arquitetural do sistema com as dependências e relacionamentos. Sendo produzido pelos
desenvolvedores, assim como, o modelo lógico de dados que exibe a representação da
estrutura lógica do banco de dados, caso o sistema precise dessa tecnologia (ARAÚJO, 2014).
Os diagramas UML apresentam a produção dos diagramas de casos de uso e de
classes. Outros diagramas, como o de sequência, ficam a critério da equipe, responsáveis pela
elaboração. As especificações expõem as funções para os casos de uso levantados. Sua
criação fica atribuída para os analistas, desenvolvedores e o cliente. O modelo de
especificação fica a critério da equipe, sendo escolhido o que mais se adequar ao projeto
(ARAÚJO, 2014).
As próximas fases são respectivamente Planejamento e Implementação, ambas
são baseadas no Scrum. Na fase de Planejamento, planeja-se o que foi analisado na fase de
inicialização e em seguida será implementado na próxima fase. A cerimônia que ocorre nessa
23
fase é a reunião de planejamento que produz os artefatos: matriz de competências; backlog do
produto; pôquer de planejamento; backlog da Sprint; análise dos riscos (parcial) (ARAÚJO,
2014).
A matriz de competências é uma tabela contendo os membros da equipe, os papéis
(Product Owner – PO, Scrum Master e equipe Scrum) e as competências de cada um. Os
responsáveis por essa tabela são equipe e cliente. O backlog do produto é uma lista com os
casos de uso e deve conter as informações de releases, sprints, descrições dos casos de uso,
pontos, prioridade, número de atividades, datas, responsáveis e status. Essa lista é de
responsabilidade do Scrum Master, da equipe e do cliente (ARAÚJO, 2014).
O pôquer de planejamento é uma técnica utilizada para determinar os pontos e
prioridades a partir da complexidade de cada caso de uso para criar o backlog do produto. Os
envolvidos no pôquer são Scrum Master, membros da equipe e PO. O backlog da sprint é
uma lista de itens do backlog do produto selecionados para serem desenvolvidos em uma
sprint. Deve conter informações minuciosas de cada uma. Para cada nova sprint é realizado
um backlog da Sprint. E assim como no backlog do produto, seus responsáveis são: Scrum
Master, equipe e o cliente. A análise dos riscos (parcial) é uma lista ou tabela dos possíveis
riscos que podem acontecer durante a implementação, informando a descrição do risco, o
responsável e uma possível solução. Essa lista fica ao encargo do Scrum Master e a equipe
Scrum (ARAÚJO, 2014; SBROCCO; MACEDO, 2012).
A próxima fase, a Implementação, é composta da realização de uma Sprint, uma
iteração de trabalho de tamanho fixa (entre 1 e 4 semanas), que deve ser decidida no
planejamento. As cerimônias que acontecem nessa fase são: reuniões periódicas Scrum;
revisão e retrospectiva da Sprint. Os artefatos gerados nessa fase são: quadro de tarefas;
gráfico burndown e análise dos riscos final (ARAÚJO, 2014).
As reuniões periódicas são como as reuniões diárias do Scrum devem durar 15
minutos, porém acontecem a cada 48 horas e nessas reuniões o quadro de tarefas é atualizado
pelo Scrum Master. Participam da reunião periódica a equipe e o Scrum Master. A revisão da
Sprint é uma reunião realizada ao fim de uma Sprint, onde se apresenta ao PO e a equipe o
que foi feito durante a Sprint. Os participantes da revisão são o PO, o Scrum Master e a
equipe. Após a revisão, realiza-se a retrospectiva da Sprint, onde a equipe faz uma
autoavaliação sobre o andamento da Sprint, levantando os pontos positivos e negativos que
24
ocorreram na mesma. Nesse momento é atualizado o gráfico burndown pelo Scrum Master e
ainda a análise dos riscos final com a ajuda da equipe (ARAÚJO, 2014).
O quadro de tarefas exibe as atividades do projeto divididas nas seguintes
categorias: a fazer, fazendo e feito. Como será esse quadro é o Scrum Master que decide,
escolhendo uma ferramenta ou o objeto físico. O gráfico burndown exibe a quantidade de
trabalho realizado e o quanto está faltando para a conclusão da Sprint. A análise dos riscos
final é uma lista com os riscos que ocorreram de fato durante a fase de implementação, e
devem conter as informações: sprint que ocorreu, descrição do risco, responsável por resolver,
solução, e status (superado ou não superado) (ARAÚJO, 2014).
Ao se finalizar uma sprint, as próximas são planejadas voltando para a fase de
planejamento, e devem ser desenvolvidos os artefatos da fase para a nova sprint. Ao fim de
um release (uma ou mais sprints finalizadas e aprovadas pelo PO) é entregue um subproduto
ou o produto final, para o caso do fim do projeto. Com a entrega dos subprodutos, os usuários
podem realizar os testes de usabilidade e os mesmos darem o feedback, avisando se está bom,
se necessita de alguma alteração ou acrescentar alguma funcionalidade. Após a entrega de
todos os releases, o projeto é concluído oficialmente e a equipe escolhe como será feita essa
formalidade (ARAÚJO, 2014; SBROCCO; MACEDO, 2012).
2.4. Trabalhos relacionados
Em meio à elaboração desta pesquisa foram encontrados cinco trabalhos
relacionados à temática desta pesquisa, são eles: Design e Agile: Análise da Metodologia
XPlus (BARBOSA, et. al., 2012); Análise das Metodologias Ágeis XP e Scrum no
desenvolvimento de um software de gerenciamento de abastecimento (VIDOR, et. al., 2013);
Uma análise das Metodologias Ágeis FDD e Scrum sob a Perspectiva do Modelo de
Qualidade MPS.BR (SILVA; HOENTSCH; SILVA, 2009); Análise de Metodologias de
Desenvolvimento de Software aplicadas ao Desenvolvimento de Jogos Eletrônicos
(BARROS, 2007); Estudo do uso de Metodologias Ágeis no Desenvolvimento de uma
Aplicação de Governo Eletrônico (LUDVIG; REINERT, 2007).
Os quatro primeiros trabalhos não usam metodologias de foco acadêmico em suas
análises, essa é a principal diferença em relação a este trabalho, porém Ludvig e Reinert
(2007) utilizam o YP em sua análise voltada para o mercado de instituição pública.
25
O trabalho de Barbosa et. al. (2012) faz uma análise sobre a metodologia XPlus,
que propõe inserir técnicas de design e usabilidade nas principais fases do fluxo da
metodologia XP. Analisa a contribuição do design e da usabilidade incorporados,
identificando quais técnicas de design e usabilidade foram utilizadas, em que fases do
processo foram introduzidos e qual o objetivo, que adaptações foram feitas e porquê, quais os
resultados esperados e quais foram atingidos em sua aplicação (BARBOSA, et. al., 2012).
Pela maneira como essas técnicas de design e usabilidade foram inseridas no XP,
por profissionais de TI sem nenhuma avaliação necessária para atingir os objetivos que visam
essas técnicas, Barbosa et. al. (2012) concluiu que o processo realizado e sua viabilidade
foram desconsiderados.
O trabalho de Vidor et. al. (2013) analisa a utilização das metodologias ágeis XP e
Scrum no desenvolvimento de um programa de gerenciamento de abastecimento e identifica
as contribuições das metodologias ágeis para o desenvolvimento de um sistema que gerencie
o abastecimento. Com isso tenha aumento na produtividade da empresa pesquisada. Esse
trabalho se utiliza da visão dos funcionários para adotar um novo método de desenvolvimento
de sistemas (VIDOR, et. al., 2013).
Após a utilização das metodologias Vidor et. al. (2013) constatou a boa adesão
das metodologias e melhorias no desenvolvimento de sistemas na empresa envolvida com as
entregas o que trouxe diminuição de gastos. Segundo o ponto de vista dos entrevistados a
empresa deve continuar a usá-las.
O trabalho de Silva, Hoentsch e Silva (2009) analisa a viabilidade da utilização
das metodologias ágeis FDD e Scrum em empresas que pretendem implantar o modelo de
qualidade MPS.BR. Fornece assim um guia para estas empresas. Analisa também os
processos que compõe os níveis do MPS.BR que é a base para a pesquisa, e então ter uma
percepção se essas metodologias atingem os níveis de maturidade do MPS.BR (SILVA;
HOENTSCH; SILVA, 2009).
Analisados todos os processos dos níveis G ao A do MPS.BR, obteve-se que
metodologia FDD atendeu a 87 resultados esperados, e o Scrum a 60 resultados, concluindo
que FDD é mais robusta que Scrum no que diz respeito à implantação do MPS.BR. Mesmo
assim, nenhuma das duas conseguiram satisfazer completamente os níveis A, B e G do
MPS.BR, por não ficar claros os procedimentos a serem realizados após a entrega final do
26
sistema ao cliente. Sugerindo que a adoção pura de FDD ou Scrum é inapropriada para
empresas que visem alcançar sistematicamente todos os níveis de maturidade do MPS.BR
(SILVA; HOENTSCH; SILVA, 2009).
O trabalho de Barros (2007) faz uma análise sobre metodologias de
desenvolvimento de jogos existentes na Literatura e utilizadas por empresas locais de Recife,
visando à criação de um “Manual de Boas Práticas para Desenvolvimento de Jogos”. Neste
trabalho Barros (2007) aplicou um questionário junto às empresas e em sua análise obteve um
conjunto de práticas, artefatos e papéis sugeridos para seu manual. Além de identificar pontos
de divergência entre esses conjuntos.
O trabalho de Ludvig e Reinert (2007) realiza uma análise comparativa entre as
metodologias ágeis YP e Scrum bem como as diferenças entre a abordagem ágil e tradicional
de desenvolvimento de software. Para isto, realiza a aplicação dessas metodologias na
construção parcial de um componente de software para prefeituras.
Ludvig e Reinert (2007) perceberam na prática que, o YP foca em artefatos e
especificação técnica e o Scrum no processo em si. Identificou como pontos negativos durante
a utilização YP a criação de artefatos que julgaram desnecessários ou improdutivos. Já no uso
do Scrum, perceberam que é mais concentrada em pessoas que já tenham um grau de
conhecimento em projetos de software e que queiram aperfeiçoá-lo. Na Tabela 1 abaixo se
pode ver um resumo dos cinco trabalhos relacionados.
Tabela 1 – Trabalhos relacionados resumidos
Autor Metodologia
trabalhada
Foco de
aplicação
Resultado da pesquisa
BARBOSA, et.
al., 2012
XPlus Ambiente
acadêmico
Desconsiderou o processo e sua
viabilidade.
VIDOR, et. al.,
2013
XP e Scrum Empresa
privada
Boa adesão das metodologias,
melhorias nas entregas e
diminuição de gastos.
27
Autor Metodologia
trabalhada
Foco de
aplicação
Resultado da pesquisa
SILVA;
HOENTSCH;
SILVA, 2009
FDD e Scrum em
MPS.BR
Empresa
privada
Não adoção do FDD ou Scrum
quando se tentar alcançar todos
os níveis de maturidade do
MPS.BR.
BARROS,
2007
Game Waterfall
Process , Extreme
Game
Development,
Scrum, Game
Unified Process
Empresa
privada
Conjunto de práticas, artefatos e
papéis para seu manual,
identificando as divergências
nesse conjunto.
LUDVIG;
REINERT,
2007
YP e Scrum Empresa
pública
Julgaram alguns artefatos do YP
dispensáveis. Scrum pede um
grau de conhecimento em
projetos e aperfeiçoamento.
28
3. PROCEDIMENTOS METODOLÓGICOS
A fim de avaliar a metodologia MADA através de novos resultados, este trabalho
se propôs realizar um estudo de caso de abordagem qualitativa na utilização da MADA em
sala de aula. E para realizar essa tarefa foi necessário aplicar a metodologia em projetos
acadêmicos práticos desenvolvidos na disciplina Engenharia de Software II.
Ao iniciar a realização desta pesquisa foi preciso selecionar algumas equipes de
desenvolvimento que fossem iniciar seus projetos e que seus membros estivessem pelo menos
no quinto semestre do curso BSI, uma limitação para que essas equipes já tivessem maior
contato e experiência com o desenvolvimento de software dentro da academia. Outro ponto
principal é que essas equipes estivessem dispostas a utilizar a MADA como metodologia do
projeto.
Então dentro dos pré-requisitos citados anteriormente foram selecionadas duas
equipes: a equipe do projeto SAHARAS – Sistema para gestão de haras e a equipe do projeto
SICROWEB – Sistema de informação para controle da escala bibliotecária dos bolsistas. As
equipes eram formadas por quatro membros cada.
O projeto SAHARAS tem o objetivo de auxiliar no controle de contas da empresa
fictícia HarasCaicó, possibilitando um maior controle e diminuição do tempo gastos com as
atividades gerenciais. O sistema deve emitir relatórios de contas a pagar e a receber por
período indicado pelo usuário. A empresa conta com três pacotes de hospedagem dos animais:
básico, plus e premium. As principais funcionalidades do sistema são: emissão de boletos
para os clientes; emissão de relatórios; histórico de vacinação por animal.
O projeto SICROWEB possui o objetivo de trazer praticidade para a geração das
escalas dos bolsistas da Biblioteca Setorial do CERES/UFRN de Caicó, que se divide nos
setores de serviço aos usuários: empréstimo/devolução, conferência e guarda volumes. A
escala é gerada pelo (a) bibliotecário (a). A principal funcionalidade desse sistema é: gerar
escala.
Para acompanhar a utilização da MADA nos projetos da disciplina citada
anteriormente, foi preciso participar das aulas práticas destinadas à produção do projeto da
disciplina durante o semestre. Ao estar presente nas aulas foi possível visualizar como os
alunos realizaram as cerimônias e produziram os artefatos da metodologia envolvida.
29
Com relação a coletar as informações dos membros desses projetos sobre a
experiência de utilizar a metodologia, realizou-se uma entrevista individual com os membros
de cada projeto, chegando ao total de oito entrevistas com duração média de 9 minutos cada.
Esta entrevista foi baseada nos doze princípios ágeis do Manifesto ágil com perguntas
semiestruturadas, no ambiente do LABICAN (Laboratório de Inteligência Computacional
Aplicada a Negócios).
Antes de iniciar as entrevistas foi preenchido o termo de confidencialidade por
parte do entrevistador para com os dados dos entrevistados. Após isso, iniciaram-se as
entrevistas, onde cada entrevistado assinou o termo de consentimento, para que seu relato
pudesse ser gravado e utilizar os dados para fins acadêmicos.
Em seguida, esses dados foram transcritos. As transcrições foram realizadas de
forma auditiva, através dos áudios das gravações, transcritos manualmente. Em cada princípio
ágil foram agrupadas todas suas respostas para facilitar encontrar semelhanças entre as
características. Ao final chegou-se a 26 páginas de transcrições. A partir dessas transcrições
foi possível codificar em categorias cada princípio. Cada característica citada durante na
entrevista foi transformada em subcategorias ou aspectos e relacionada à categoria a qual foi
citada.
A partir dos dados obtidos através da entrevista, tornou-se possível analisar a
metodologia com base nos pontos de maiores dificuldades (fases, cerimônias ou produção de
artefatos) dos alunos em segui-la. Para a análise a técnica utilizada foi a de análise de
conteúdo, analisando numericamente a frequência de ocorrência de cada categoria encontrada
nos textos de todos os princípios.
Ao final foi possível montar mapas causais para quase todos os princípios ágeis,
apenas para o princípio ágil 3 não foi possível devido a falta de aspectos que identificassem as
relações de causa-efeito. Então se montou um mapa mental. A Figura 4 ilustra todos os
procedimentos metodológicos deste capítulo, iniciando na seleção das equipes, explicada
anteriormente até a avaliação dos resultados. O levantamento dos dados engloba
sequencialmente o acompanhamento das aplicações, a realização das entrevistas e as
transcrições dos relatos das entrevistas. Após essas etapas segue para a criação dos mapas.
30
Figura 4 – Abordagem metodológica
Fonte: a autora.
Então, pudemos observar o porquê destas objeções e avaliar a metodologia.
Seguindo esse contexto, foi legítimo responder se a MADA está bem adequada a projetos
acadêmicos, comprovando o seu bom desempenho de utilização quanto ao cumprimento de
suas cerimônias e produção de seus artefatos.
3.1. Mapas causais e mentais
Mapas mentais são as crenças, opiniões, interesses, pressupostos, valores, regras
de comportamentos, teorias a respeito da realidade e histórias que carregamos em nossas
mentes sobre nós mesmos, outras pessoas e o mundo em geral. Um conjunto de ideias mais ou
menos compartilhadas também conhecido como modelos mentais (ANDRADE et. al., 2006).
Na Figura 5 pode ser visto um exemplo desse conceito de mapa mental.
O mapa mental pode ser visto como sendo a maneira mais fácil adicionar e obter
informações do seu cérebro, de forma criativa e eficaz de anotar, literalmente mapeando.
Possibilitam organizar fatos e pensamentos de tal maneira que o cérebro se envolve
naturalmente, ou seja, lembrar e recuperar informações se tornam processos mais confiáveis
31
do que usando formas tradicionais de anotações e registros (BUZAN, 2005). E não possui
características de causa e efeito.
Figura 5 – Exemplo de mapa mental
Fonte: adaptado de BUZAN (2005).
Os mapas cognitivos causais, ou apenas mapas causais, são grafos onde cada nó é
um conceito e as ligações indicam causalidade, representando as causas e os efeitos sobre uma
determinada situação. Esses mapas são construídos a partir de discursos de um ou mais atores
envolvidos em um determinado processo. Na Figura 6 se pode ver um exemplo de mapa
causal.
Figura 6 – Exemplo de mapa causal
Fonte: adaptado de ANDRADE et. al. (2006).
Geralmente denotam as relações entre conceitos com uma influência positiva (+),
de proporcionalidade direta, ou com uma influência negativa (-), de proporcionalidade
inversa, isto é, quando respectivamente há um aumento/diminuição em uma causa gera um
32
aumento/diminuição em um efeito ou um aumento/diminuição em uma causa gera uma
diminuição/aumento em um efeito (ENSSLIN; MONTIBELLER NETO, 1999).
A Figura 7 complementa o entendimento desse conceito. Onde a seta está possui
uma relação com sinal positivo (+) há uma influência diretamente proporcional da variável da
esquerda para com a variável da direita. Onde a seta possui a relação com sinal negativo (-) há
uma influência inversamente proporcional entre as variáveis da esquerda para a direita.
Figura 7 – Proporcionalidade das influências
Fonte: adaptado de ANDRADE el. al. (2006).
33
4. RESULTADOS
No decorrer das falas dos entrevistados, foi possível identificar suas dificuldades e
limitações sobre a utilização da metodologia MADA referente aos doze princípios ágeis. Após
a realização da entrevista, foram criadas sentenças que resumem os doze princípios ágeis,
levando ao mapa cognitivo da pesquisa visto na Figura 8, onde cada sentença é referente ao
aspecto predominante de cada princípio ágil para seguir analisando a utilização da
metodologia MADA.
Para cada elemento foi feito um detalhamento analítico e criado o seu mapa causal
ou mental usando características elaboradas a partir dos relatos dos entrevistados pertinentes a
cada princípio ágil. Assim, foi avaliada a metodologia MADA em relação aos princípios,
observando impressões dos entrevistados ao utilizá-la. Nos mapas de cada princípio ágil
encontram-se os números de citações embaixo de cada aspecto, destacado em vermelho e
simbolizado da seguinte forma: {0 – N}. O zero (0) encontrado em todos os elementos
significa que há relatos em que não aparece e o (N) significa a quantidade de relatos que foi
encontrado o fato.
Figura 8 – Mapa cognitivo dos princípios ágeis.
Fonte: a autora.
34
4.1. Satisfação do cliente
Este princípio ágil está relacionado com a satisfação do cliente com as entregas de
software de valor contínuo e frequente. O cliente é o foco primordial das equipes de
desenvolvimento ágil, devendo realizar as entregas de forma rápida e eficaz (SBROCCO;
MACEDO, 2012).
O cliente em um projeto acadêmico varia muito, depende do projeto ao qual o
aluno está envolvido. Podendo ser: um professor (com projetos em disciplina ou em
laboratório); um monitor de uma disciplina; um coordenador de curso ou de algum
departamento; ou até mesmo um cliente “real” (representante de uma empresa). Este último
pode está em projetos de todos os tipos, tanto de disciplinas quanto em laboratórios. Nesses
casos de clientes acadêmicos, não necessariamente tenham que ser do curso do discente.
A Figura 9 exibe as percepções dos entrevistados sobre este princípio que foram
colhidas por meio dos relatos. Dois aspectos principais foram encontrados nesse princípio:
atraso nas entregas e experiência. Constatou-se a relação entre a satisfação do cliente e o
atraso, quanto mais atraso menos satisfação. Além de perceber que a experiência influencia no
uso da metodologia e depois na satisfação do cliente. Nenhuma das equipes tem certeza da
satisfação do cliente, mas acreditam que foi possível alcançá-la por terem entregado o produto
completo no final da disciplina.
Um ponto de vista citado algumas vezes para este princípio foi a falta de
experiência, visto como um ponto crucial para que a equipe não tenha conseguido realizar as
entregas de forma frequente e com tudo que foi planejado. Tal ponto foi encontrado em três
citações, simbolizadas em vermelho na Figura 6 por {0 – 3}, sobre dificuldades de estipular
prazos, afetando negativamente na satisfação do cliente. Essa fala expressa bem o que as
equipes passaram:
Algumas entregas extrapolaram o prazo, por questão de experiência. Às vezes você
prever fazer uma atividade e não dar tempo, justamente por falta de experiência. A
gente ainda não sabe medir de uma forma mais exata o período de entrega de uma
determinada funcionalidade (ENTREVISTADO 4).
35
Figura 9 – Mapa causal da satisfação do cliente
Fonte: a autora.
O não cumprimento dos prazos estipulados perante o cliente gera indecisão sobre
a finalização do projeto, levando insatisfação ao cliente. Porém, Sbrocco e Macedo (2012)
falam que a equipe deve assumir os problemas em cumprir os prazos, mantendo o cliente
sempre bem informado para evitar desconforto e cobranças.
Pham e Pham (2011) dizem que para uma equipe consiga planejar bem, de
maneira efetiva, o tempo das atividades no uso do pôquer de planejamento, é necessário que a
equipe seja composta por generalistas que possuam experiência com as diferentes tarefas de
desenvolvimento de software, como coleta de requisitos, análise, projeto, codificação e teste.
Então, a falta de experiência aumenta a dificuldade de estipular prazos para essas tarefas.
Outra causa também bem citada foi a falta de tempo, por durante o semestre os
membros terem várias disciplinas algumas com projetos diferentes. Com isso, a divisão do
tempo de cada um pode não ser bem realizada. Um entrevistado relata bem isso: “Houve
alguns atrasos por falta de tempo. Estava muito sobrecarregado no semestre, não consegui
dividir bem o tempo para todas as disciplinas.” (ENTREVISTADO 7). Não conseguir dividir
bem seu tempo pode levar a não realizar as tarefas que lhe são determinadas, gerando atrasos
nas entregas dos subprodutos que a equipe se responsabilizou em fazê-los e tais atrasos
podem gerar insatisfação ao cliente.
Além desses motivos, os atrasos foram justificados por falta de comunicação e
alinhamento entre a equipe. Trago uma das citações: “O atraso tem vários motivos, às vezes
36
faltava comunicação entre a equipe, devido a isso, faltava chegar a um acordo”
(ENTREVISTADO 2).
Sbrocco e Macedo (2012) falam que gerenciar a comunicação é importante para
assegurar que geração, captura, distribuição, armazenamento e apresentação das informações
do projeto sejam feitos de forma adequada e no tempo correto. Além de afirmar que um
planejamento organizacional identifica e designa responsabilidades e relacionamentos do
projeto.
A falta de foco dos membros da equipe também foi citada como um dos motivos
por atrasos na entrega de alguma parte do produto. Vejamos a citação: “A cada Sprint a gente
entregava uma parte do projeto, mas não entregava tudo. Por falhas nossas e não da
metodologia” (ENTREVISTADO 7).
Sobre o foco da equipe Sabbagh (2013) relata que a equipe deve manter o foco de
trabalho nas metas estabelecidas para sprint, dedicando o máximo de tempo útil ao projeto. E
que uma forma para as equipes manterem o foco é trabalhando em mais de uma tarefa ao
mesmo tempo, ou seja, sendo multitarefa. Além disso, afirma que durante as reuniões diárias,
que no caso da MADA são reuniões periódicas, os membros devem prestar total atenção ao
que é dito durante as reuniões pelos colegas.
4.2. Acolhimento às mudanças de requisitos
Este princípio diz que mudanças de requisitos são aceitas em qualquer fase do
projeto, e espera que tragam vantagem competitiva ao cliente. Porém, só devem ser aceitas as
mudanças que agreguem valor e tragam vantagem ao negócio do cliente, devendo ser
descartadas as mudanças que não colaboram com a evolução do projeto (SBROCCO;
MACEDO, 2012).
A maioria dos entrevistados teve algum tipo de dificuldade em realizar o
acolhimento às mudanças de requisitos de seus projetos, e dessas dificuldades foram
relacionadas à falta de experiência e o acúmulo de trabalho, como pode ser visto na Figura 10.
Devido à falta de experiência, os membros das equipes não conseguem realizar o acolhimento
às mudanças, e o acúmulo de trabalho traz dificuldades e limita esse acolhimento.
37
Figura 10 – Mapa causal do acolhimento às mudanças de requisitos
Fonte: a autora.
A falta de experiência foi citada como um dificultador para a realização do
acolhimento as mudanças de requisitos, e pode realmente ser um obstáculo, pois, Martins
(2010) diz que um Corpo de Controle de Mudanças (Change Control Board – CCB) que deve
controlar essas mudanças de requisitos.
Pode-se ver uma das cinco citações sobre a falta de experiência, representadas em
vermelho na Figura 8 no trecho: “Tivemos mudanças de requisitos, agora conciliar o que foi
mudado com o tinha para fazer a gente não conseguiu. Talvez seja pela falta de experiência
da equipe.” (ENTREVISTADO 3).
Apenas duas pessoas disseram que conseguiram adicionar as mudanças de
requisitos de forma agradável. É possível ver alguns relatos: “Teve algumas mudanças e a
gente se adaptou a cada uma delas de forma bem tranquila e agradável.” (ENTREVISTADO
7). “Não me lembro de haver muitas mudanças, mas as que houveram a gente conseguiu
encaixar razoavelmente bem.” (ENTREVISTADO 4).
Segundo Sabbagh (2013) as mudanças acolhidas compreendem a descoberta de
detalhes do produto incrementado durante o projeto, e que esses incrementos descobertos e
reavaliados a partir do retorno do cliente. Assim, o produto é construído e modificado fazendo
a mudança ser garantia de um produto que signifique valor para os clientes.
O acúmulo de trabalho foi citado como uma situação que dificulta o acolhimento
das mudanças de requisito. É possível ver no trecho: “Mudanças teve, mas não foram
38
acolhidas, porque cada sprint era pra gente entregar uma coisa, não fazia tudo e ia
acumulando.” (ENTREVISTADO 2).
Uma solução para esse acúmulo é autonomia. Segundo Sabbagh (2013) essa
autonomia ajuda a equipe a criar um senso de propriedade sobre seu trabalho, de maneira que
os membros da equipe estimulam e ajudam uns aos outros a fazerem seu melhor para
alcançarem a meta.
4.3. Frequência das entregas
Este princípio refere-se a entrega do software funcional com frequência de
algumas semanas ou meses, preferindo sempre um período curto. O tempo de
desenvolvimento é algo que possibilita a flexibilidade, levando em consideração as
necessidades do cliente e da equipe de desenvolvimento. Deve-se buscar uma entrega de
produto funcional com qualidade e rápida, dentro do possível (SBROCCO; MACEDO, 2012).
Para essa questão a maioria dos entrevistados afirmou que a frequência de suas
entregas ao cliente foi definida semanalmente, como pode ser visto na Figura 11 que o
elemento semanal foi o mais citado com até seis citações ({0 – 6}). Podemos entender bem
como foi realizado esse trabalho no trecho seguinte: “A gente tinha reuniões semanais, onde
apresentávamos a professora. Fazíamos toda a simulação de apresentação ao PO, então a
gente sempre entregava alguma coisa funcionando toda semana.” (ENTREVISTADO 4).
O próprio princípio já diz que as entregas devem ser feitas o mais rápido possível.
Na Scrum, umas metodologias base para MADA, é variável de 1 ou 2 podendo chegar a 4
semanas dependendo do projeto (BROD, 2013; SBROCCO; MACEDO, 2012). Então, pode-
se dizer que as equipes estavam seguindo o princípio.
Há também outros dois aspectos, o quinzenal ou mensal e o por unidade, porém
foram citados apenas uma vez cada, e de acordo com os relatos eram entrevistados que não
lembravam como tinha sido o período de entregas de seus projetos, como pode ser lido nos
trechos: “Acho que nosso planejamento foi quinzenal ou mensal. Entregamos funcionando
nesse prazo.” (ENTREVISTADO 8). “Era entregue sempre no final de cada unidade, no
prazo da disciplina, se não me engano.” (ENTREVISTADO 2). Esses aspectos estão dentro
do prazo definido pelo princípio ágil 3.
39
Figura 11 – Mapa mental da frequência nas entregas
Fonte: a autora.
4.4. Equipes trabalhando juntas
Neste princípio as equipes de desenvolvimento e de negócio devem trabalhar
juntas diariamente no decorrer do projeto. Deve haver uma comunicação frequente entre essas
equipes e as partes interessadas no projeto. Deve-se manter o cliente presente no
acompanhamento do projeto (PHAN, 2011; SBROCCO; MACEDO, 2012).
Os pontos positivos nesse mapa cognitivo, Figura 12, foram a união da equipe, e a
comunicação. Sobre a união esse trecho explica bem como as equipe se ajudaram. “O Scrum
master programou um pouco também. As duas equipes se misturavam, mas se mantiveram
trabalhando juntas dessa forma.” (ENTREVISTADO 6). O Scrum master deve auxiliar a
equipe, removendo obstáculos que aparecem na execução do projeto (BROD, 2013). Mas essa
foi a forma que encontram de manter as equipes juntas.
Figura 12 – Mapa causal das equipes trabalhando juntas
Fonte: a autora.
Sobre a comunicação com a gerência a fala do entrevistado 3 explica como se
deu: “Sempre tinha uma reunião por semana e o gerente era da equipe, a gente sempre se
40
comunicava.”. Manter a comunicação entre as pessoas no desenvolvimento é muito
importante, mas não se deve perder mais tempo na comunicação do que no desenvolvimento
em si (BROD, 2013). Por isso, para manter essas equipes juntas, o tempo dessa equipe da
citação não foi falho nem excessivo.
Outras citações abordaram a má divisão de trabalho da equipe. Membros que não
se envolvem com o projeto ou ficam isolado dos outros membros da equipe. É possível
identificá-las nos próximos trechos: “Geralmente estávamos trabalhando juntos. [...] Às vezes
algum membro ficava isolado.” (ENTREVISTADO 4). “A gente dividia o trabalho em partes
para todos e muitas vezes alguns membros ficavam de fora e outro membro fazia as tarefas
deles.” (ENTREVISTADO 2). Por isso, identifica-se que a divisão do trabalho nem sempre
era efetiva.
Brod (2013) diz que é normal que uma equipe comece trazendo hábitos de outros
trabalhos em equipe ou individuais, mas é importante que, o mau hábito ao ser identificado
seja corrigido de imediato. Com esses hábitos corrigidos é possível melhorar a convivência
dos membros da equipe entre si como com a equipe de negócio.
Com as discussões que surgem numa equipe sobre quem deve fazer o quê, por que
e por quanto tempo, torna-se crucial que todos os integrantes dessa equipe saibam como
trabalhar adequadamente em conjunto. Todos devem depender de todos para trabalharem
como equipe, pois nada é mais indispensável do que os membros da equipe trabalhar bem em
grupo (PHAM; PHAM, 2011).
4.5. Motivação
Este princípio diz respeito a construir projetos mantendo a equipe motivada,
fornecendo ambiente, apoio e confiança necessários para a realização do trabalho. Os
membros da equipe de desenvolvimento, os líderes e gerentes de projetos devem transmitir
confiança e apoio uns aos outros. A equipe deve ter características autogerenciáveis em um
ambiente organizado e estimulante, prezar o crescimento dos integrantes e manter a qualidade
do trabalho (SBROCCO; MACEDO, 2012).
Nessa categoria há alguns elementos bem positivos para a metodologia citados
algumas vezes, a ajuda mútua e simultânea, e a convivência da equipe. Na ajuda mútua e
simultânea, um dos entrevistados tem uma visão bem clara sobre.
41
Na verdade a gente sabe que na academia todo mundo faz tudo. Se não me engano,
a gente reversava os papéis da metodologia, mas acabou que todos programaram.
[...] Todos trabalhamos em tudo, mesmo assim, a gente trabalhava junto e ajudando
um ou outro (ENTREVISTADO 1).
Cohn (2011) diz que deve ser incentivada a colaboração por meio do
compromisso, manter a equipe como unidade, estimulá-la e direcioná-la constantemente para
objetivos compartilhados.
Para a convivência da equipe é possível ver dois trechos que a identifica.
“Acredito que é uma questão mais pessoal de convivência entre os participantes da equipe,
do que algo proporcionado pela metodologia.” (ENTREVISTADO 3). “A gente sempre
entrava em um consenso sobre o que fazer, como devia ser feito, divisão do trabalho, etc.”
(ENTREVISTADO 6).
A falta de confiança também foi citada algumas vezes, podendo ser vista na
Figura 13. Apesar de Pham e Pham dizerem que a confiança é o elemento necessário para
manter todos unidos em torno do trabalho em equipe, essa fala a seguir expressa bem como a
equipe se relacionou com esse elemento: “A gente tinha confiança que ia entregar o projeto
em si, mas o apoio um ao outro acho que foi falho. Um membro da equipe não apoiava e nem
tinha confiança no trabalho do outro.” (ENTREVISTADO 5).
O trabalho em equipe realmente carece de confiança que deve construída com o
tempo, conforme se trabalha com as pessoas e passa a conhecê-las (AMBLER, 2004). Essa
falta de confiança leva desunião para a equipe.
Figura 13 – Mapa causal da motivação
Fonte: a autora.
42
No trecho seguinte é possível notar a falta de participação de membros da equipe.
“Nas reuniões tinha hora que a gente estava tão por fora que ao tentar dar alguma opinião,
só conseguia dar opinião superficial. Sobre o negócio só se a gente fosse estudar os códigos e
os documentos para entender.” (ENTREVISTADO 2).
A participação é um ponto muito importante, Varella e Moura (2013) dizem ser
ótimo que exista colaboração e participação de todos os envolvidos, que são aspectos básicos
das atividades de execução de tarefas e obtenção de resultados. Significa que a equipe estar
realizando seu papel e fará as entregas.
O entrevistado 5 relata de forma bem sucinta sobre a crença no projeto, falta de
apoio e falta de confiança: “A gente tinha confiança que ia entregar o projeto em si, mas o
apoio um ao outro acho que foi falho. Um membro da equipe não apoiava e não tinha
confiança no trabalho o outro.”(ENTREVISTADO 5). Demonstre confiança os integrantes da
equipe, assim trabalharão melhor, mais motivados e focados (NASCIMENTO, 2014). É
preciso sempre adaptar a trajetória e manter o foco, a motivação e a dedicação (Varella;
Moura, 2013).
4.6. Compartilhamento de informações face a face
Este princípio diz que o método mais eficiente e efetivo de transmitir informações
para uma equipe de desenvolvimento é conversando cara a cara. O cliente deve estar presente
sempre ao discutirem aspectos sobre o projeto. Essas conversas devem ser frequentes e
rápidas para facilitar o entendimento das necessidades do cliente e do negócio (SBROCCO;
MACEDO, 2012).
As citações, vistas na Figura 14, mostram as formas de compartilhar informações
face a face das equipes, que foram em reuniões semanais ou no contato face a face, além de
complementar com o uso de ferramentas online ou redes sociais.
Analisando as entrevistas deste princípio foi possível identificar os elementos
reuniões semanais e complemento com ferramentas online, exibido no seguinte trecho:
A gente sempre tentava se reunir e as conversas eram sempre preferidas que fossem
presenciais, por mais que tivéssemos reuniões e debates através de redes sociais.
Mas a gente se reunia durante a semana para discutir sobre o trabalho
(ENTREVISTADO 7).
43
Figura 14 – Mapa causal do compartilhamento de informações face a face
Fonte: a autora.
Os elementos complemento com ferramentas online e contato face a face podem
ser vistos no seguinte trecho: “A gente utilizou muito ferramentas online, porque como o
pessoal é de turmas diferentes tem muito choque de horário. Tínhamos conversas presenciais
principalmente nas aulas.” (ENTREVISTADO 3).
Quanto mais comunicação melhor, porém deve mais realizada pessoalmente. Essa
comunicação à distância ou online não deve ser a mais usada pela equipe. Segundo
Prikladnicki, Willi e Milani (2014) quanto menos comunicação indireta, menores serão as
chances haver a má interpretação e quanto mais frequentes forem as conversas presenciais,
menos conflitos surgirão.
4.7. Software funcional
Este princípio afirma que ter um software funcionando é a medida primária para o
progresso do projeto. Almeja-se que as funcionalidades ao serem validadas, sejam
implementadas e entregues ao cliente (PHAN, 2011; SBROCCO; MACEDO, 2012).
Uma característica que foi bastante citada e influencia o progresso do projeto são
os incrementos, que podem ser vistos na Figura 15 com as cinco citações em vermelho. Esse
entrevistado relata sobre ela: “O projeto estava sempre funcionando e aos poucos a gente ia
adicionando funcionalidades” (ENTREVISTADO 6). A entrega de subprodutos funcionado
gera desde cedo retorno ao investimento do cliente, possibilita o feedback e reduz os riscos do
projeto (SABBAGH, 2013).
44
Figura 15 – Mapa causal do software funcional
Fonte: a autora.
A definição do escopo do projeto foi citada no trecho seguinte: “A gente
desconsiderou algumas coisas, mas foram colocadas no projeto, nas restrições. Então dentro
do escopo que a gente definiu o projeto progrediu e foi finalizado.” (ENTREVISTADO 1).
De acordo com Beck (2008) é possível esse ajuste no escopo, os programadores
que se descobrirem comprometidos demais pedem por ajuda de cinco formas: reduzindo o
escopo de algumas tarefas; solicitando que o cliente reduza o escopo de algumas histórias;
largando tarefas não essenciais; obtendo mais, ou melhor, ajuda; e como um último recurso,
solicitando ao cliente para postergar algumas histórias para uma iteração posterior.
“Claro que tivemos algumas dificuldades no decorrer do projeto, mas o projeto
nunca ficou parado. Algumas funcionalidades nós tivemos que adaptar para manter o
software funcionando.” (ENTREVISTADO 3). Esse trecho mostra a realização de adaptações
nas funcionalidades para manter o software funcionando, ou seja, a resolução de problemas ou
correção de erros (bugs) da Figura 15. A resolução de problemas em qualquer sistema é muito
importante para que o sistema não fique sem funcionar por um longo tempo. Um cliente não
quer um produto que não funciona ou não funciona corretamente.
4.8. Ritmo de desenvolvimento constante
Este princípio fala que os processos ágeis promovem o desenvolvimento
sustentável. Devendo patrocinadores, desenvolvedores e usuários serem capazes de manter
um ritmo constante, sustentável (SBROCCO; MACEDO, 2012).
O que mais pôde se perceber analisando a Figura 16 foi que poucos membros das
equipes mantiveram o ritmo constante, mesmo sendo o que pede este princípio. Esta citação
mostra o ritmo constante: “Mantemos o ritmo porque a gente programou sempre para
45
entregar toda semana, mesmo quando não ia ter aula em alguma semana, a gente entreva
como se fosse para sempre tentar seguir o Product Backlog.” (ENTREVISTADO 6).
Figura 16 – Mapa causal do ritmo de desenvolvimento sustentável
Fonte: a autora.
As falas seguintes de alguns dos entrevistados mostram como foi aplicado o ritmo
de desenvolvimento, porém não foi constante, variou. “Estava oscilando bastante no ritmo, e
como disse, ficou muitas atividades para o final. Começamos em um ritmo mais leve e no fim
tivemos que acelerar.” (ENTREVISTADO 2).
“Teve algumas sprints que dava para terminar com mais facilidade e outras que
tinha que correr contra o tempo. Muitas vezes entregando em cima da hora.”
(ENTREVISTADO 5). “Teve alguns momentos que o ritmo teve que ser acelerado um pouco
mais, porque em outros estava mais lento. Oscilou um pouco o ritmo de trabalho, motivado
por descuido de organizar o tempo.” (ENTREVISTADO 7).
Segundo Brod (2013) a perda do ritmo acontece quando a sprint passa a ter
duração variável e que a tendência de isso ocorrer é quando o time é formado por
desenvolvedores que têm muitos outros compromissos. Além do mais, se for preciso, pode-se
conversar com o patrocinador do projeto exigindo a participação dos mesmos ou sugerir
trocá-los. Esse último em projeto acadêmico em sala fica difícil, pois todos os alunos da turma
já devem estar em uma equipe, tornando-se complicado a troca.
Outra justificativa que apareceu nas transcrições para a perda ritmo foi o acúmulo
de trabalho de uma sprint para outra, pode-se ver nesse trecho:
A última parte foi a mais crítica, que nós mais demoramos, mas na parte inicial a
gente conseguiu manter o ritmo direitinho. A quantidade de atividades foi bem
46
definida, o que acontecia é que às vezes ficava faltando uma coisinha, e com isso
acumulava (ENTREVISTADO 1).
O acúmulo de atividades de uma sprint vira uma situação de bola de neve,
aumentando sempre a quantidade de tarefas para a próxima sprint. Com isso, as sprints
posteriores tendem a não serem concluídas totalmente.
4.9. Atenção contínua a excelência técnica
Este princípio afirma que atenção contínua a excelência técnica e a um bom
projeto aumenta a agilidade. Seguir padrões de projeto que preze pela qualidade e design
serve para manter a excelência técnica da equipe de desenvolvimento. Assim, entregar
software com qualidade rapidamente (SBROCCO; MACEDO, 2012).
As características de usabilidade, padronização dos códigos e foco o software,
vistas na Figura 17, podem ser agrupadas como sendo ideias de manter a alta qualidade do
produto. São a busca pela melhor forma de fazer o trabalho e produzir com mais qualidade. A
padronização pode ser encaixada na manutenibilidade, facilita a manutenção e o foco no
software é para que o produto final a ser entregue seja um bom produto, eficiente.
Figura 17 – Mapa causal da atenção contínua
Fonte: a autora.
Sobre a falta de conhecimento da metodologia esse trecho descreve bem. “Nós
não estudamos a metodologia a fundo. Nós conhecíamos melhor o Scrum. Foram as fases que
usam as técnicas do Scrum que conseguimos usar bem.” (ENTREVISTADO 2).
Segundo Pham e Pham (2011) se a equipe for nova na utilização da metodologia,
isso pode ser um problema a menos que haja alguém na equipe que tenha experiência com a
47
metodologia. Se houver, então essa pessoa deve servir de Scrum Master. Caso não exista, a
equipe precisa de um treinamento. No caso de equipes acadêmicas, é possível solicitar ajuda
ao professor ou monitor, se a disciplina dispuser.
A falta de experiência foi relatada da seguinte forma: “A excelência técnica nem
sempre foi possível, até mesmo por conta da experiência do grupo. A gente acaba fazendo
uma coisa que tem uma forma mais rápida, só que fizemos de outra forma que era a que a
gente conseguia. Até mesmo pra poder entregar o projeto no prazo.” (ENTREVISTADO 4).
Segundo Sabbagh (2013) esse princípio reforça a ideia de que os integrantes da
equipe devem ter uma boa qualificação técnica para trabalharem conscientemente entregando
produtos de qualidade. Além disso, afirma que problemas técnicos podem se acumular devido
à falta dessa qualificação.
“O fato de a gente ter desconsiderado algumas funcionalidades que sabíamos que
não conseguíamos fazer, ajudou também na agilidade. E a própria metodologia o que ela
exige, era uma metodologia ágil, forçava a gente a ter excelência, mas com agilidade.”
(ENTREVISTADO 1). Esse trecho relata a existência da restrição no escopo do projeto.
Nesse caso das restrições, foi utilizada uma abordagem com base no tempo, que
estabelece como prioridade o prazo de entrega perdendo de adicionar uma funcionalidade.
Assim, com essa abordagem é possível fazer uso da técnica timeboxing, que estabelece uma
data final para o projeto e entrega o produto nessa data, independente do que ocorra, mesmo
que para isso seja preciso reduzir a funcionalidade (DENIS; WIXOM; ROTH, 2014).
4.10. Simplicidade
A simplicidade é essencial para este princípio. Buscar soluções mais simples para
os requisitos do cliente que possam ser aperfeiçoadas posteriormente. Não buscar trabalhos
desnecessários para o sistema. Arquiteturas complexas podem não agregar valor ao cliente,
além de contribuir para atrasar as entregas (PHAN, 2011; SBROCCO; MACEDO, 2012).
Analisando as transcrições e a Figura 18, pôde ser visto que onde os entrevistados
mais aplicaram a simplicidade foi na implementação, mantendo o código o mais simples e
realizaram essa adequação da melhor maneira que conseguiam.
Nas transcrições foram encontrados trechos que explicam bem essa afirmação. “A
gente buscava a maneira mais simples. Tentava não colocar muita dificuldade e nem arranjar
48
problema demais sem necessidade.” (ENTREVISTADO 5). “Mantemos a simplicidade na
medida do possível, na nossa cabeça era o mais simples, mas nem sempre é simples
realmente. Era o mais simples a gente conseguia fazer.” (ENTREVISTADO 3).
Figura 18 – Mapa causal da simplicidade
Fonte: a autora.
Outro elemento citado foi a refatoração do código também incluída na
implementação, o que melhorou a simplicidade como diz esse trecho: “Geralmente a gente no
início foi fazendo as atividades em grosso modo, mas com o passar do tempo nós fomos
refatorando para deixar mais simples.” (ENTREVISTADO 8). Esse outro trecho mostra
sobre o planejamento simples. “No geral foi simples, a implementação foi bastante simples e
o planejamento bem tranquilo.” (ENTREVISTADO 4).
Essa afirmação Brod (2013) serve para confirmar todos os elementos deste
princípio, onde ele diz que se deve evitar prever necessidades futuras e quando se deparar
com uma estrutura complexa no sistema, faça a substituição por outra mais simples o mais
rápido possível. Porque essas estruturas tendem a se tornar mais caras e difíceis de manter.
Utilizando essa estratégia a equipe manteve a simplicidade do projeto.
4.11. Organização
De acordo com esse princípio uma equipe organizada promove melhores
arquiteturas, requisitos e projetos. Uma metodologia ágil pede uma equipe auto-organizável
que se adapta facilmente às mudanças do projeto, reinventam e reestruturam o negócio de
forma criativa conforme a demanda do cliente (SBROCCO; MACEDO, 2012).
49
Vendo a Figura 19, pode-se ver que foram encontrados dois elementos com
influência direta na organização, a refatoração e a documentação bem organizada. E o outro
elemento com influência inversamente proporcional de acordo com Andrade (2006).
Figura 19 – Mapa causal da organização
Fonte: a autora.
A refatoração além de simplificar os códigos, possibilita a reorganização dos
mesmos. Então quanto mais refatoração mais chances de melhorar a organização. O trecho
seguinte fala sobre. “A gente procurou sempre suprir os requisitos com uma melhor
arquitetura, tentando diminuir a complexidade do projeto. E sempre refatorando o sistema
para que ficasse numa forma melhor e trabalhar melhor” (ENTREVISTADO 7).
O YP que serve de base para a MADA indica o uso da refatoração. Durantes as
reuniões os desenvolvedores podem solicitar refatoração em seus códigos quando esses não
foram gerados da melhor forma possível, prática chamada de refatoração explícita (LUDVIG;
REINERT, 2007).
A documentação bem organizada foi a característica mais citada, e pode ser vista
nesse relato: “A gente tinha bem definido o que era para ser feito, o que deveria usar, quais
os objetivos e os requisitos.” (ENTREVISTADO 5). As equipes focaram a organização no
momento do planejamento, ao elaborarem os documentos propostos pela metodologia.
Sobre dificuldades de manter a organização na implementação é possível
identificá-la no relato: “Até por questão de todo mundo fazer tudo, às vezes ficava meio
bagunçado a implementação. Um membro fazia uma atividade e outro por vezes
desmanchava o que estava feito e fazia de outra forma, por não compreender o que estava
antes.” (ENTREVISTADO 1).
50
Segundo Schach (2009) essa dificuldade pode ser explicada pelo fato das equipes
terem uma carga de trabalho mais intensa durante a fase de implementação, os problemas de
organização de equipe são sentidos de maneira mais acentuada nessa fase.
4.12. Reflexão do comportamento
Este princípio diz que a equipe deve refletir sobre como se tornar mais eficaz,
então se alinha e ajusta seu comportamento, em intervalos regulares. Realizar reflexões
periódicas sobre o desempenho da equipe é importantes para detectar processos falhos e
desnecessários, bem como planejar melhorias futura, propostos pela própria equipe
(SBROCCO; MACEDO, 2012).
Analisando o mapa se pode ver que a característica mais citada foi a retrospectiva
da sprint ser feita semanalmente, como pode ser visto na Figura 20. Esse fato já era esperado,
pois que a retrospectiva deve ser realizada sempre após o final da sprint, que foi citada em
outros momentos das entrevistas como sendo semanalmente (SABBAGH, 2013). A citação
abaixo mostra a afirmação.
Cada semana a gente tinha pelo menos uma reunião em que a gente refletia sobre o
que foi feito no período, podia apontar as dificuldades e ajustar aqueles erros para
que não voltassem nas próximas sprints (ENTREVISTADO 3).
Figura 20 – Mapa causal da reflexão do comportamento
Fonte: a autora.
Outra citação que mostra como estava sendo realizada a reflexão do
comportamento dos membros das equipes através das reuniões Revisão e Retrospectiva da
Sprint, pode ser lida abaixo:
51
A gente tinha um dia definido para ter a reunião sobre o andamento do projeto.
Conversar sobre o que estava dando certo, o que não estava e definir coisas futuras
para sempre melhorar o projeto (ENTREVISTADO 8).
A revisão da sprint é um balanço de tudo que foi feito na sprint, apresentando o
resultado dela. E a retrospectiva da sprint é uma análise da equipe sobre a sprint, respondendo
as perguntas: o que foi bom na sprint em questão e o que deve melhorar, ajustando-se para a
próxima sprint (COHN, 2011; SBROCCO; MACEDO, 2012). Então seguindo essas
cerimônias, durante o acontecimento das mesmas é o momento de refletir e adaptar o
comportamento.
As reuniões frequentes a primeira vista parecem ser as retrospectivas da
metodologia, mas analisando melhor, foram identificadas como reuniões periódicas, pois a
retrospectiva deve ser feita após o fim de uma sprint e as reuniões periódicas são cada 48
horas na MADA. No trecho a seguir se pode ver:
A gente tinha algumas reuniões com as metas de melhorar o projeto, como agir
melhor. Discutíamos a troca de função vendo qual membro ficava melhor em qual
função, para poder ajudar mais no projeto. Buscando sempre ser mais eficaz e
eficiente no projeto. (ENTREVISTADO 7).
52
5. CONSIDERAÇÕES FINAIS
Neste trabalho, foi possível notar a importância da observação e acompanhamento
da aplicação da metodologia MADA em projetos disciplinares da área da Engenharia de
Software no BSI. Dessa forma, pode-se perceber como está o aprendizado dos alunos não
somente com relação à metodologia em questão, mas também as outras metodologias ágeis
utilizadas no curso, principalmente YP e Scrum que compõem a MADA.
Com base nos resultados obtidos através das entrevistas realizadas com os
integrantes das equipes envolvidas nesse trabalho, foi possível identificar que as equipes dessa
aplicação da MADA em relação à satisfação do cliente com as entregas, não alcançaram
totalmente o objetivo do princípio, pois houve entregas onde o produto que deveria ser
entregue não estava pronto.
Em relação ao acolhimento às mudanças de requisitos, os alunos ainda possuem
dúvidas de como realizar tal procedimento. Para facilitar essa questão, as equipes poderiam
utilizar um fluxograma do processo durante o levantamento de requisitos, com isso, identifica
como é o processo atual e como deve ser o sistema, devendo encontrar mais clareza onde uma
mudança deve ser inserida. Já sobre a frequência das entregas, as duas equipes conseguiram
cumprir bem o que declara esse princípio, com entregas entre semanas ou meses.
Sobre as equipes de desenvolvimento e negócio trabalhando juntas, as equipes
acadêmicas ainda possuem dificuldades, pois há alunos que não interagem bem em conjunto,
separando as equipes. Uma forma de melhorar a interação entre os membros da equipe é
realizar dinâmicas de grupo, porém, isso não tem relação direta com uma metodologia e sim o
comportamento de cada indivíduo. Mas pode afetar a comunicação e o trabalho em equipe.
A motivação ocorreu dessa mesma forma, algum membro das equipes não deu
apoio e confiança suficientes para motivar os outros membros. Normalmente isso ocorre
porque alguns alunos subestimam a capacidade para realizar alguma tarefa de outros alunos.
Então não os estimulam a fazerem o seu melhor. Dinâmicas de grupo nesse caso também
podem ajudar a equipe nesse entrosamento.
O compartilhamento de informações face a face foi positivo, as equipes
mantiveram as conversas presenciais e ainda complementaram a comunicação com
ferramentas online ou redes sociais. O progresso do projeto mantendo o software funcionando
53
foi positivo, as equipes limitaram o projeto ao que poderia ser feito, realizaram as atividades
aos poucos e resolveram os problemas que surgiam.
O ritmo de desenvolvimento para as duas equipes foi variando, a cada momento
podia ser diferente, e cada membro vê esse ritmo de uma forma distinta. O que pode fazer
diferença no ritmo de desenvolvimento é a definição de atividades por sprints. Os alunos
costumam alocar muitas atividades numa sprint, não fica espaço para quando é necessário
adicionar uma mudança de requisitos, ficando sem entregar o que foi planejado ao P.O.
A atenção contínua para ter agilidade, foi equilibrada, alguns tiveram dificuldades
e outros conseguiram buscar a qualidade do produto. Alguns alunos não dão a devida
importância para excelência técnica, buscam apenas entregar e finalizar a disciplina. A
simplicidade foi obtida pelas equipes, em sua maioria, através do código e outros pela
documentação.
Sobre manter a organização poucos entrevistados relataram dificuldades. A
maioria manteve essa organização por meio de refatoração de código e organização dos
artefatos da metodologia. A reflexão do comportamento foi sempre realizada pelas equipes,
todas fizeram como estabelece a MADA, mesmo que algumas vezes não tenham adaptado
seus comportamentos, apenas identificado as falhas.
Com essa avaliação, chega-se a conclusão de que a metodologia MADA está bem
embasada nos princípios ágeis, porém os estudantes não estudam seu fluxo antes de começar a
utilizá-la e não seguem totalmente suas etapas e cerimônias. Sendo assim, é preciso que
equipes de desenvolvimento de software acadêmico analisem melhor se a MADA é adequada
ao seu projeto e se envolvam mais com a metodologia que pretendem utilizar.
Para trabalhos futuros, pretende-se realizar um estudo para analisar a
possibilidade da criação de uma ferramenta de gerenciamento de projetos que atue em
conjunto com a metodologia, traga praticidade e dissemine a utilização da MADA em
projetos disciplinares.
REFERÊNCIAS
AMBLER, S. W. Agile Modeling (AM): Effective practices for modeling and
documentation. Ambysoft Copyright, 2001. Disponível em: <http://www.agilemo
deling.com/>. Acesso em 15 maio 2015.
AMBLER, S. W. Modelagem ágil: práticas eficazes para a Programação Extrema e o
Processo Unificado. – Bookman, 2004.
ANDRADE, A. L.; et. al. Pensamento sistêmico: caderno de campo: o desafio da mudança
sustentada nas organizações e na sociedade. – Porto Alegre: Bookman, 2006.
ARAÚJO, N. M. de. MADA: Uma combinação de metodologias de desenvolvimento ágil
com focos distintos para execução de projetos de software acadêmicos. Monografia
(Graduação em Sistemas de Informação) – Universidade Federal do Rio Grande do Norte,
Centro de Ensino Superior do Seridó, Caicó, 2014.
ARAÚJO, N. M.; GORGÔNIO, F. L.; VALE, K. M.O. Combinando Metodologias Ágeis
para Execução de Projetos de Software Acadêmicos. Anais da I Escola Regional de
Sistemas de Informação do Rio de Janeiro, p. 9. Rio de Janeiro, 2014.
ARAÚJO, N. M. de; et. al. Combinando Metodologias Ágeis com Focos Distintos para
Execução de Projetos de Software Acadêmicos. In: VII Escola Potiguar de Computação e
suas Aplicações. TI como fator de Desenvolvimento Regional. Santa Cruz, 2014.
BARBOSA, F. V. V. T.; et. al. Design e Agile: Análise da Metodologia XPlus. InfoDesign:
Revista Brasileira de Design da Informação/Brazilian Journal of Information Design, v.
9, n. 3, p. 153 – 159. São Paulo, 2012.
BARROS, R. L. B. de. Análise de Metodologias de Desenvolvimento de Software
aplicadas ao Desenvolvimento de Jogos Eletrônicos. Monografia (Graduação em Ciências
da Computação) – Universidade Federal de Pernambuco, Centro de Informática, Recife, 2007.
BECK, K. Programação Extrema (XP) Explicada. Tradução: Adriana Picoral Sarandy
Machado, Natália Nunes Pinto Lopes. – São Paulo: Bookman, 2008.
BROD, C. Scrum Guia Prático para Projetos Ágeis. – São Paulo: Novatec Editora, 2013.
BUZAN, T. Mapas mentais e sua elaboração: um sistema definitivo de pensamento que
transformará a sua vida. Tradução: Euclides Luiz Calloni, Cleusa Margô Wosgrau. – São
Paulo: Cultrix, 2005.
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com
sucesso. Tradução: Aldir José Coelho Corrêa da Silva. – Porto Alegre: Bookman, 2011.
DENIS, A; WINXOM, B. H.; ROTH, R. M. Análise e projeto de sistemas. Tradução: Amir
Elias Abdalla Kurban. – 5. Ed. – Rio de Janeiro: LTC, 2014.
ENSSLIN, L; MONTIBELLER NETO, G. Inferência Causal em Mapas Cognitivos. In: XIX
ENEGEP – Encontro Nacional de Engenharia de Produção, Rio de Janeiro, 1999. Anais
do XIX ENEGEP, v. Único. Rio de Janeiro: Microservice, 1999.
GARCIA, A. A.; SILVA, T. M. Melhoria da Qualidade dos Projetos das Disciplinas
Engenharia de Software e Banco de Dados. X Seminário de Iniciação a Docência. VII
Encontro Integrativo do PIBID - UFRN/FACISA/CERES. Exposição e Apresentação de
Pôsteres do X SID. Caicó, 2013.
GARCIA, F. P.; et. al. easYProcess: Um Processo de Desenvolvimento para Uso no
Ambiente Acadêmico. In: XII Workshop de Educação em Informática – XXIV
Congresso da Sociedade Brasileira de Computação. Salvador, 2004.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. – Rio
de Janeiro: Elsevier, 2011.
LUDVIG, D; REINERT, J. D. Estudo do uso de Metodologias Ágeis no Desenvolvimento
de uma Aplicação de Governo Eletrônico. Monografia (Graduação em Sistemas de
Informação) – Universidade Federal de Santa Catarina, Florianópolis, 2007.
MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software com PMI,
RUP e UML. 5 ed. – Rio de Janeiro: Brasport, 2010.
NASCIMENTO, A. W. O PASSO CERTO PARA O SUCESSO: Curso de formação e
desenvolvimento de líderes e gestores de pessoas. – São Paulo: Baraúna, 2014.
PHAM, A; PHAM, P. Scrum em Ação: gerenciamento e desenvolvimento ágil de projetos
de software. Tradução: Edgard B. Damiani. – São Paulo: Novatec Editora: Cengage
Learning, 2011.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. Tradução:
Ariovaldo Griesi, Mario M. Feccio. 3. ed. – Porto Alegre: AMGH, 2011.
PRIKLADNICKI, R; WILLI, R; Milani, F. Métodos Ágeis para desenvolvimento de
software. – Porto Alegre: Bookman, 2014.
RODRIGUES, N. N.; ESTRELA, N. V. A. Simple Way: Ensino e Aprendizagem de
Engenharia de Software Aplicada através de Ambiente e Projetos Reais. In: VIII Simpósio
Brasileiro de Sistemas de Informação, 2012, São Paulo. Biblioteca Digital Brasileira de
Computação, São Paulo: BDComp, 2012. p. 722 – 733.
SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. – São Paulo: Casa do
Código, 2013.
SBROCCO, J. H. T. C. de; MACEDO, P. C. de. Metodologias ágeis: Engenharia de
software sob medida. – Brasil: Erica, 2012.
SCHACH, S. R. Engenharia de Software: Os Paradigmas Clássico e Orientado a
Objetos. – 7. ed. – São Paulo: McGraw, 2009.
SILVA, F. G.; HOENTSCH, S. C. P.; SILVA, L. Uma análise das Metodologias Ágeis FDD e
Scrum sob a Perspectiva do Modelo de Qualidade MPS.BR. Revista Scientia Plena, v. 5, n.
12, 2009.
SOMMERVILLE, I. Engenharia de Software. Tradução: Selma Shin Shimuzu Melnikoff,
Reginaldo Arakaki, Edilson de Andrade Barbosa. 8ª Edição. – São Paulo: AddisonWesley,
2007.
TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard business
review, v. 64, n. 1, p. 137-146, 1986.
VARELLA, L; MOURA, G. Aprimorando Competências de Gerente de Projetos: O
Sucesso no Desempenho Pessoal. Vol. 2. – Rio de Janeiro: Brasport, 2013.
VIDOR, J. J. S.; et. al. Análise das Metodologias Ágeis XP e Scrum no Desenvolvimento de
um Software de Gerenciamento de Abastecimento. In: XXXIII Encontro Nacional de
Engenharia de Produção. A Gestão dos Processos de Produção e as Parcerias Globais para o
Desenvolvimento Sustentável dos Sistemas Produtivos. Salvador, 2013.
WIRTH, N. A brief history of software engineering. IEEE Annals of the History of
Computing, v. 1, n. 3, p. 32-39, 2008.
APÊNDICES
APÊNDICE A – MODELO DE TERMO DE CONSENTIMENTO
TERMO DE CONSENTIMENTO
Eu, ______________________________________________________________, sendo
conhecedor do tema e metodologia utilizados pela aluna do Programa de Graduação em
Sistemas de Informação da Universidade Federal do Rio Grande do Norte (UFRN), consinto
em participar da pesquisa conduzida pela mesma.
Entendo que toda e qualquer informação prestada por mim no decorrer da(s) entrevista(s)
pode ser utilizada na elaboração e escrita de relatórios referentes à pesquisa. Também sei que
as entrevistas podem ser gravadas. É acordado entre a pesquisadora, signatário deste termo, e
a aluna, que todas as possibilidades de identificação pessoas minhas enquanto entrevistado
devem ser impedidas.
Caicó, _____ de ___________ de ________.
Assinatura:__________________________________
(Assinatura do entrevistado)
APÊNDICE B – MODELO DE TERMO DE CONFIDENCIALIDADE
TERMO DE CONFIDENCIALIDADE
Pelo presente documento, a signatária, _______________________________________,
aluna do Programa de Graduação em Sistemas de Informação da Universidade Federal do Rio
Grande do Norte (UFRN), em fase de pesquisa de campo, se compromete a manter as suas
fontes de informação em total anonimato. Neste sentido, não será feita a identificação do
entrevistado na redação final dos relatórios.
Caicó, ___ de ________ de ______.
Assinatura:__________________________________
(Nome do entrevistador).
APÊNDICE C – ROTEIRO DE ENTREVISTA
Pergunta 1: A equipe conseguiu satisfazer o cliente com entregas de valor contínuo e
frequentes? Como foram as entregas?
Pergunta 2: Em seu projeto houve mudanças de requisitos? Como foi realizado o acolhimento
a essas mudanças?
Pergunta 3: A equipe realizou as entregas de software funcional com que frequência?
Pergunta 4: De acordo com o formato de sua equipe, as equipes de desenvolvimento e de
negócio se mantiveram trabalhando juntas? Como esse trabalho acontecia?
Pergunta 5: Os membros mantiveram a equipe motivada fornecendo apoio e confiança para a
realização do trabalho? Como era essa relação?
Pergunta 6: Como ocorreu o compartilhamento de informações entre os membros da equipe?
Pergunta 7: A equipe manteve o software funcional para ter progresso no projeto? Em algum
momento o software não foi funcional? Qual?
Pergunta 8: Como foi o ritmo de desenvolvimento da equipe?
Pergunta 9: Como a equipe manteve a excelência técnica e um bom projeto para aumentar a
agilidade?
Pergunta 10: Como a equipe manteve a simplicidade na resolução de erros, pendências,
planejamento, etc.?
Pergunta 11: Como foi a organização da equipe para manter melhores arquiteturas, requisitos
e projetos?
Pergunta 12: Como ocorreu a reflexão do comportamento da equipe para ajustar e adaptar seu
comportamento?
