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.
À 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
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
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 ... 283.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
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).
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).
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?
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
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.
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
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
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
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
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
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
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
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.
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
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
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.
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.
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.
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
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
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
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.
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).
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
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.
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
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 pode-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
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
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.
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
