Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software
Uso de Metodologias de Desenvolvimento de
Software e de Engenharia de Requisitos em
empresas de Tecnologia: um estudo a partir de
um Survey
Uso de Metodologias de Desenvolvimento de Software e
de Engenharia de Requisitos em empresas de
Tecnologia: um estudo a partir de um Survey
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Universidade Federal do Rio Grande do Norte como requisito parcial para a ob-tenção do grau de bacharel em Engenharia de Software.
Orientador(a)
Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena
Universidade Federal do Rio Grande do Norte – UFRN Departamento de Informática e Matemática Aplicada – DIMAp
Natal-RN
ware e de Engenharia de Requisitos em empresas de Tecnologia: um estudo a partir de um Survey apresentada por Fernanda Chacon Fontoura e aceita pelo Departamento de Informática e Matemática Aplicada do Centro de Ciências Exatas e da Terra da Univer-sidade Federal do Rio Grande do Norte, sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena
Orientador(a)
Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte
Profa. Dra. Lyrene Fernandes Da Silva
Departamento de Informática e Matemática Aplicada Universidade Federal do Rio Grande do Norte
Profa. Dra. Isabel Dillman Nunes
Instituto Metrópole Digital
Universidade Federal do Rio Grande do Norte
Primeiramente agradeço a Deus por ter conseguido chegar até aqui.
Agradeço a minha família, em especial a minha mãe que sempre esteve ao meu lado me apoiando em todos os momentos.
À Layssa, por sempre estar ao meu lado, por todo companheirismo e ter acreditado em mim, mesmo quando eu não acreditava.
Ao meu chefe, André Santiago, por toda compreensão e pela amizade durante esse tempo de trabalho juntos.
À minha orientadora, Márcia Lucena, por ter me orientado e compreendido minhas dificuldades ao longo do trabalho, por ter me ajudado nas dúvidas.
Aos meus amigos de faculdade e trabalho, que estiveram comigo em todos os momentos durante minha graduação em Tecnologia da Informação e Engenharia de Software. E meus amigos de vida que estiveram comigo nos momentos fora da faculdade.
melhores, para fazer melhor ainda. Mário Sergio Cortella
de Engenharia de Requisitos em empresas de
Tecnologia: um estudo a partir de um Survey
Autor: Fernanda Chacon Fontoura Orientador(a): Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena
Resumo
Por volta de 2001 surgiu o Manifesto Ágil, que tinha por objetivo diminuir as formalizações de documentos e focar nas entregas contínuas, equipes multidisciplinares e facilitar as mudanças de requisitos. As atividades da engenharia de requisitos são fundamentais no processo de desenvolvimento de software, que influencia diretamente na qualidade do produto. Então para não ser deixado de lado alguns documentos e artefatos feitos nas metodologias tradicionais é necessário uma boa relação entre as Metodologias Ágeis e a Engenharia de Requisitos. Com isso, surgiu a motivação de pesquisar como atividades de Engenharia de Requisitos são feitas nas empresas de Tecnologia da Informação que utilizam Metodologias Ágeis. Para isso foi elaborado um survey que foi respondido por diversos profissionais de Tecnologia da Informação. Através das respostas foi possível identificar qual a metodologia utilizada na empresa, quais as técnicas das metodologias ágeis são usadas e como a Engenharia de Requisitos é usada nestas empresas pesquisadas. Com os resultados obtidos do questionário foi feita uma comparação com o resultados de surveys de trabalhos relacionados a este.
Palavras-chave: Engenharia de Requisitos, Requisitos Ágeis, Metodologias Ágeis, Mani-festo Ágil, Scrum, Survey, Empresas de Tecnologia da Informação.
Requirements Engineering in Technology Companies: a
study based on a Survey
Author: Fernanda Chacon Fontoura Advisor: Profa. Dra. Marcia Jacyntha Nunes Rodrigues Lucena
Abstract
Around 2001 came the Agile Manifesto, which aimed to reduce document formalizations and focus on continuous deliveries, multidisciplinary teams, and facilitate requirements changes. Requirements engineering activities are fundamental in the software development process, which directly influences the quality of the product. So not to leave aside some documents and artifacts made in traditional methodologies, a good relationship between Agile Methodologies and Requirements Engineering is necessary. With this, the motivation to research as Requirements Engineering activities was made in Information Technology companies that use Agile Methodologies. For this, a survey was elaborated that was answered by several professionals of Information Technology. Through the answers it was possible to identify the methodology used in the company, which techniques of agile methodologies are used and how the Requirements Engineering is used in these companies surveyed. With the results obtained from the questionnaire, a comparison was made with the results of surveys of works related to this questionnaire.
Keywords: Requirements Engineering, Agile Requirements, Agile Methodologies, Agile Manifesto, Scrum, Survey, Information Technology Companies.
1 Dados do CHAOS Report de 2011 até 2015 . . . p. 15 2 Backlog do Produto . . . p. 23 3 Backlog da Sprint . . . p. 24 4 Ciclo Scrum . . . p. 26 5 Ciclo de Vida do XP . . . p. 31 6 Ciclo do Kanban . . . p. 33 7 Metodologia da Pesquisa . . . p. 39 8 Sexo dos entrevistados . . . p. 40 9 Idade dos participantes . . . p. 41 10 Função do participante na empresa . . . p. 42 11 Experiência do participante na função . . . p. 42 12 Local da Empresa . . . p. 43 13 Quantidade de colaboradores na empresa . . . p. 44 14 Domínio, na área de tecnologia da informação (TI), da empresa . . . . p. 45 15 Método de desenvolvimento dos projetos . . . p. 46 16 Atuação em mais de uma função na equipe . . . p. 47 17 Frequência da entrega dos produtos . . . p. 48 18 Frequência de reuniões com os clientes . . . p. 49 19 Frequência de mudanças dos requisitos . . . p. 50 20 Custo da mudança dos requisitos para o projeto . . . p. 51 21 Técnicas de Levantamento de Requisitos . . . p. 52 22 Comparação de Resultados - Elicitação de Requisitos . . . p. 53
24 Comparação de Resultados - Documentação de Requisitos . . . p. 54 25 Frequência da atualização dos requisitos a cada mudança . . . p. 55 26 Fatores que mais causam dificuldade no contexto de documentação . . p. 56 27 Problemas ocasionados pela má gestão dos requisitos . . . p. 57
ER – Engenharia de Requisitos XP – Extreme Programming TI – Tecnologia da Informação
1 Introdução p. 13 1.1 Contexto . . . p. 13 1.2 Motivação . . . p. 14 1.3 Problema . . . p. 16 1.4 Questões de Pesquisa . . . p. 16 1.5 Objetivos . . . p. 16 1.5.1 Objetivo Geral . . . p. 16 1.5.2 Objetivos Específicos . . . p. 16 1.6 Estrutura do Documento . . . p. 17 2 Revisão Bibliográfica p. 18 2.1 Engenharia de Requisitos . . . p. 18 2.2 Metodologias Ágeis . . . p. 19 2.2.1 Contexto . . . p. 19 2.2.2 Principais metodologias ágeis . . . p. 21 2.2.2.1 SCRUM . . . p. 21 2.2.2.2 XP . . . p. 26 2.2.2.3 Kanban . . . p. 31
3 Trabalhos Relacionados p. 34
3.1 Estudo Exploratório sobre a Engenharia De Requisitos em Projeto Ágeis
sults from an International Survey (WAGNER et al., 2017) . . . p. 35 3.3 Considerações Finais . . . p. 36 4 Metodologia p. 37 4.1 Classificação da Pesquisa . . . p. 37 4.2 Questionário . . . p. 38 4.3 Público Alvo . . . p. 39 4.4 Etapas da Pesquisa . . . p. 39 5 Resultados p. 40 5.1 Caracterização do Entrevistado . . . p. 40 5.2 Caracterização da Empresa . . . p. 43 5.3 Metodologia de Desenvolvimento de Software . . . p. 45 5.4 Atividades de Engenharia de Requisitos . . . p. 51
6 Considerações finais p. 58 6.1 Principais contribuições . . . p. 58 6.2 Limitações . . . p. 58 6.3 Trabalhos Futuros . . . p. 59 Referências p. 60 Apêndice A p. 61
1
Introdução
Neste capítulo é feita a contextualização da Engenharia de Requisitos no processo de desenvolvimento de software e do surgimento das metodologias ágeis. Também é explicada a motivação do trabalho, o problema, as questões de pesquisa, o objetivo geral e objetivos específicos da pesquisa.
1.1
Contexto
Segundo Sommerville (2013), a Engenharia de Software é uma área que se preocupa com todos os aspectos relacionados à produção de software. Ela inclui técnicas que apoiam a especificação, desenvolvimento, validação e evolução de software. O objetivo dos projetos de software é atender as necessidades dos clientes dentro dos prazos e custos estabelecidos. O ciclo da engenharia de software é iniciado com a especificação dos requisitos, depois projeto de sistema e software, implementação e testes, finalizando com a operação e ma-nutenção.
A atividade de especificação de requisitos é composta por quatro fases: estudo de viabilidade, levantamento e análise de requisitos, especificação de requisitos e validação de requisitos. Esse processo da engenharia de requisitos pode ser feito de diferentes maneiras de acordo com o modelo de processo de desenvolvimento utilizado. Como é explicado em Sommerville (2013), no modelo cascata as atividades de especificação de requisitos são realizadas no início do projeto e é uma atividade distinta das outras. Já no modelo de desenvolvimento iterativo e incremental as atividades de especificação são intercaladas entre as fases de desenvolvimento e validação.
As empresas de desenvolvimento de software com o intuito de desenvolver software de qualidade, além de buscar lucros e eficiência, procuram novas metodologias para melhor administrar sua equipe e o tempo. As empresas procuram entregar os produtos espera-dos pelo cliente e no prazo planejado. Neste contexto as metodologias ágeis surgem com o
objetivo de diminuir os problemas causados pelas metodologias tradicionais. O desenvolvi-mento de software ágil surgiu nos meados de 2001 com o manifesto ágil, esse novo modelo de processo deixa de lado as metodologias tradicionais em que só era possível começar trabalhar em uma fase se a anterior fosse finalizada. Ao contrário dessa metodologia, no desenvolvimento iterativo e incremental as entregas são frequentes, pois cada incremento ou versão do sistema incorpora alguma funcionalidade necessária para o cliente e inclui todas as fases do processo (Sommerville, 2013).
Um dos princípios das metodologias ágeis é o software funcionando ao invés de docu-mentação abrangente. Essa metodologia deixa de lado a docudocu-mentação formal que existe nos métodos tradicionais e entrega soluções de forma contínua, propondo que os clientes estejam interagindo diretamente com os desenvolvedores.
Diante disso a forma de desenvolver software mudou, pois as entregas frequentes e feed-back contínuo do cliente são princípios da metodologia para minimizar os riscos causados pelas constantes mudanças nos requisitos (Beck, 1999). A boa relação com as mudanças de requisitos, se dá no processo ágil porque tem-se em mente que os requisitos do sistema vão mudar, por isso os sistemas são projetados para acomodar as mudança (PRIKLADNICKI; WILL; MILANI, 2004).
É necessário existir uma abordagem eficiente entre as metodologias ágeis e a engenha-ria de requisitos, pois os documentos e artefatos utilizados nas metodologias tradicionais não podem ser deixados de lado. Nesse contexto, foi feita uma pesquisa com objetivo de investigar como a engenharia de requisitos tem sido utilizada nas empresas de desen-volvimento de software e como as empresas que utilizam as metodologias ágeis usam a engenharia de requisitos.
1.2
Motivação
Uma definição para fracasso de um projeto é “quando este não atinge as metas de desempenho técnico, custo, prazo ou escopo” (Cleland Ireland, 2002). Com essa definição podemos relacionar o fracasso de projetos com requisitos que não foram levantados corre-tamente, pois de acordo com o processo de desenvolvimento de software é na especificação de requisitos que é feita a descrição das funcionalidades que o software irá oferecer e seus requisitos de desempenho e confiança (SOMMERVILLE, 2013).
Além disso, quanto mais demorar para detectar os problemas associados aos requisitos, mais custoso será a resolução do problema, levando ao atraso do projeto e
consequente-mente não será finalizado no prazo. Desse modo, o sucesso de um projeto de software está diretamente relacionado a fazer elicitação e especificação de requisitos de forma mais completa [5]. A etapa de requisitos é fundamental no processo de desenvolvimento de software pois, de acordo com estudos, os principais problemas de fracassos de projetos de software estão relacionados com a etapa da engenharia de requisitos. Segundo o CHAOS Report - 2015, do Standish Group, ainda existem projetos de software que falham. Assim, de acordo com a pesquisa temos que apenas 29% dos projetos de software foram entregues dentro do prazo.
do orçamento e com funcionalidades completas (successful); 52% foram entregues fora do prazo, fora do orçamento ou com funcionalidades incompletas (challenged); e 19% foram cancelados, de acordo com a figura 1.
Figura 1: Dados do CHAOS Report de 2011 até 2015
Fonte: (LINCH, 2015)
Segundo (PAETSCH; EBERLEIN; MAURER, 2003), na maioria das vezes a ER e os mé-todos ágeis são considerados incompatíveis. A ER está na maioria das vezes dependendo muito de documentação para o compartilhamento de conhecimento, enquanto os métodos ágeis estão focados na colaboração de clientes e desenvolvedores para atingir um software de qualidade que atenda as necessidades dos clientes.
Por estes motivos, surgiu a motivação de examinar como as etapas da engenharia de software estão sendo feitas nas empresas de desenvolvimento de software e como estão sendo utilizadas junto com as metodologias ágeis. Além disso, o trabalho também vai investigar se as empresas utilizam os valores dos métodos ágeis de acordo com o livro Métodos Ágeis para Desenvolvimento de Software (PRIKLADNICKI; WILL; MILANI, 2004).
1.3
Problema
Apesar da engenharia de requisitos ser um dos fatores mais importante na engenharia de software, de acordo com as pesquisas citadas na introdução esse ainda é um dos pro-blemas que leva ao insucesso dos projetos de software. Além disso, ainda pouco se sabe como essas metodologias estão sendo conduzidas junto com a engenharia de requisitos.
1.4
Questões de Pesquisa
Com base na contextualização apresentada, o objetivo deste trabalho consiste em responder às seguintes questões de pesquisa:
• As empresa que dizem utilizar metodologias ágeis de desenvolvimento seguem as boas práticas dessas metodologias?
• Como estão sendo realizadas a elicitação e documentação de requisitos nas empresas que utilizam metodologias ágeis?
• Como está sendo feita a elicitação e documentação de requisitos nas empresas de Tecnologia da Informação?
• Quais os principais problemas encontrados no contexto de documentação? • Quais os problemas são ocasionados pela má gestão dos requisitos?
1.5
Objetivos
1.5.1
Objetivo Geral
Este trabalho de conclusão de curso tem como objetivo geral investigar como a en-genharia de requisitos está sendo utilizada em empresas de tecnologia que utilizam ou não metodologias ágeis. Também é objetivo do questionário identificar se as empresas que dizem utilizar metodologias ágeis, praticam os princípios base dos métodos ágeis.
1.5.2
Objetivos Específicos
• Realizar estudos semelhantes na literatura; • Elaborar um questionário para:
– Identificar as metodologias que estão sendo usadas nas empresa; – Identificar se os princípios de métodos ágeis estão sendo aplicados; – Identificar as técnicas e métodos utilizados na engenharia de requisitos; – Identificar possíveis problemas pela má gestão dos requisitos;
• Realizar um survey em empresas de Tecnologia da Informação; • Analisar as evidências encontradas;
• Comparar os resultados com trabalhos correlatos.
1.6
Estrutura do Documento
Este trabalho é composto por 6 capítulos, incluindo este capítulo de introdução. O capítulo 2 é voltado para à revisão bibliográfica do trabalho, no qual possui os con-ceitos de Engenharia de Software, metodologias ágeis e são detalhadas três metodologias de desenvolvimento de software: Scrum, Extreme Programming (XP) e Kanban.
No capítulo 3 são apresentados os trabalhos relacionados. No capítulo 4 contempla a metodologia utilizada na pesquisa, com a classificação da pesquisa, o questionário utilizado para obter as informações, o público alvo utilizado no questionário, uma seção para as etapas da pesquisa e outra para protocolos e artefatos que foram utilizados.
O capítulo 5 apresenta os resultados da pesquisa e é feita a análise e discussão das respostas, além de apresentar uma comparação do resultado com o resultado de trabalhos relacionados.
No capítulo 6 temos as considerações finais, em que retomo o problema, falamos das principais contribuições (considerando as perguntas de pesquisa), limitações e ameaças a validade e trabalhos futuros.
2
Revisão Bibliográfica
Este capítulo resume os principais conceitos de Engenharia de Requisitos e as Meto-dologias Ágeis mais utilizadas.
2.1
Engenharia de Requisitos
A Engenharia de Requisitos (ER) é reconhecida como uma das fases mais importante do processo de engenharia de software. Este reconhecimento decorre da descoberta que a maior parte dos problemas e geralmente os que mais possui impacto negativo no desen-volvimento de software, são de origem na etapa inicial do desendesen-volvimento. Esta etapa constitui o processo de engenharia de requisitos, no qual, as principais atividades podem ser definidas como: concepção, elicitação e análise, especificação, validação de requisitos e gerenciamento (KOTONYA; SOMMERVILLE, 1998).
Existem diversas definições para ER . De acordo com Sommerville, a engenharia de requisitos é o processo de compreensão e definição dos serviços requisitos do sistema e a identificação de restrições relativas à operação e ao desenvolvimento do sistema.
Outra definição é dada pelo IEEE (1984), segundo a qual a ER corresponde ao processo de aquisição, refinamento e verificação das necessidades do cliente para um sistema de software, com o objetivo de ter uma especificação completa e correta dos requisitos de software.
Um conceito importante na ER é o requisito. Os requisitos são as descrições do que o sistema deve fazer, os serviços que oferece. Outra definição para requisito sugere que é uma necessidade do usuário ou uma característica, função ou atributo necessário do sistema (Davis 1993). De acordo com alguns autores, os requisitos são classificados em dois tipos: funcionais e não-funcionais.
Os requisitos funcionais são as funções que um sistema ou um componente do sistema deve ter. Eles descrevem as transformações que serão realizadas nas entradas de um
sis-tema a fim de produzir as saídas. Os requisitos não-funcionais estão relacionados com as restrições, interfaces com o usuário, confiabilidade, aspectos de desempenho, segurança, manutenibilidade, portabilidade e outras propriedades que o sistema deve possuir. A dife-rença entre eles é que enquanto requisitos funcionais descrevem o que sistema deve fazer, os requisitos não-funcionais restringe como os requisitos funcionais serão implementados. O processo de ER tem o objetivo de descobrir as necessidades dos stakeholders, que são as pessoas ou organizações que serão afetadas pelo sistema e têm influência sobre os requisitos (SOMMERVILLE, 2011). Por isso é necessário a fase de concepção para entender o problema e o contexto em questão. Depois da concepção e estudo da viabilidade a próxima etapa da ER é a elicitação e análise dos requisitos, nesta fase são usadas técnicas para obter os requisitos dos stakeholders e de outras fontes e para desenvolver os requisitos em mais detalhes (POHL, 2010). Depois da análise de requisitos é feita a negociação dos requisitos, nessa fase é feita a análise da importância, necessidade e prioridade dos requisitos. Depois disso os requisitos são documentados e validados. Em paralelo com estas atividades é realizado o gerenciamento de requisitos, que tem por objetivo controlar a evolução e mudanças e também rastrear os requisitos ao longo do processo de desenvolvimento.
2.2
Metodologias Ágeis
2.2.1
Contexto
Por volta dos anos 90, começaram surgir processos de desenvolvimento de software diferentes dos tradicionais que eram mais burocráticos. Essas metodologias leves só come-çaram ser chamadas de ágeis em 2001, quando um grupo de especialistas se reuniram em um cidade dos Estados Unidos para pensar em alternativas de como deixar o processo de desenvolvimento de software mais leve. Foram esses especialistas que criaram os termos “Desenvolvimento Ágil de Software” e “Métodos Ágeis”. Também criaram o manifesto ágil que foi composto pela declaração de alguns valores e doze princípios (PRIKLADNICKI; WILL; MILANI, 2004).
Os valores do Manifesto Ágil são:
• Indivíduos e interação mais que processos e ferramentas: a comunicação passa ser mais importante nas metodologias ágeis, não que os processos e ferramentas deixem de ser importantes, mas no lugar de receber especificações escritas existem conversas e reuniões entre cliente e desenvolvedor e entre os próprios desenvolvedores.
• Software em funcionamento mais que documentação abrangente: no início da engenharia de software não existia uma documentação e o conhecimento dos softwa-res estavam apenas com os desenvolvedosoftwa-res e se algum desses membros da equipe não fizessem mais parte seria complicado entender a parte do software que ele de-senvolveu. Então foram criados os documentos e as pessoas responsável por apenas elaborar essa documentação. Já nas metodologias ágeis procura um equilíbrio e entregar software funcionando do que uma documentação rígida. Os documentos existem, porém é analisado o que é necessário documentar.
• Colaboração com o cliente mais que negociação de contratos: a definição de escopo de um sistema é algo complexo e ainda mais difícil quando precisa ser escrita em um contrato. Desse modo o manifesto admite que é muito complicado colocar todas as questões de desenvolvimento em contratos. Então no lugar de incluir novos termos no contrato para resolver as coisas, é aconselhável trabalhar em colaboração com o cliente. Por outro lado as partes contratantes precisam de alguma segurança e esse se torna um dos pontos fracos dos métodos ágeis.
• Responder a mudanças mais que seguir o plano: na maioria dos projetos, no início, traçamos um plano que vamos seguir até o final. Porém mudanças são ine-vitáveis ao longo de projetos na área de tecnologia, até para melhor satisfação do cliente precisamos nos adequar a essas mudanças para que no final o produto satis-faça o cliente.
Tabela 1: Doze princípios do software ágil
1 A maior prioridade é satisfazer o cliente mediante entregas de software de valor em tempo hábil e continuamente
2 Aceitar mudanças de requisitos, em qualquer fase do projeto 3 Entregar software funcionando na menor escala possível de tempo
4 Equipe de desenvolvimento e cliente são do mesmo time, as pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto, durante todo o curso do projeto
5 Construir projetos com indivíduos motivados e comprometidos com o resultado. Dando a eles ambiente e suporte necessário
6 Comunicação efetiva, pois o método mais eficiente e eficaz de transmitir informações é uma conversa pessoalmente
7 Software funcionando é a principal medida de progresso 8 Promover o desenvolvimento sustentável
9 Atenção contínua à excelência técnica e bom design , aumenta a agilidade 10 Simplicidade
11 As melhores arquiteturas, requisitos e projetos provêm de equipes organizadas 12 Refletir sobre como se tornar mais eficaz, ajustando e adaptando o comportamento
da equipe
2.2.2
Principais metodologias ágeis
2.2.2.1 SCRUM
Em 1986, Takeuchi e Nonaka publicaram um estudo na Harvard Business Review que comparavam equipes de alto desempenho e multidisciplinares com a formação Scrum existente nas equipes rugby. Nesse estudo foi descoberto que equipes menores e multidis-ciplinares produzem resultados melhores.
Depois de sete anos, Jeff Sutherlan, John Scumniotales e Jeff Mckenna definiram o Scrum para empresa Easel Corporation, incorporando os estilos de gerenciamento observa-dos no estudo de Takeuchi e Nonaka (1986). Neste contexto surgiu a metodologia Scrum. Dois anos depois em 1995, Jeff Sutheland trabalhou com Ken Schwaber para formalizar o processo para a indústria mundial de software no primeiro artigo sobre Scrum.
O Scrum é uma metodologia ágil que auxilia no gerenciamento de projetos complexos e no desenvolvimento de produtos. O Scrum prescreve um conjunto de práticas leves e objetivas, muito utilizadas na área de engenharia de software.
O Scrum tem como premissa a existência de um processo iterativo e incremental para o desenvolvimento, trazendo uma nova dimensão na capacidade da gestão dos processos (SCHWABER, 2004). Outra característica do Scrum é maximizar a entrega do software de modo eficaz, adaptando-se a realidade das mudanças. Em projetos que executam o Scrum, existem três papéis, três artefatos e quatro cerimônias:
1. Papéis no Scrum
Diferente de outras metodologias de desenvolvimento, em que existe apenas um responsável pelo projeto, o Scrum distribui a gestão de projetos entre três papéis: o Dono do Produto, o ScrumMaster e a Equipe de Desenvolvimento, formando a equipe de gestão, batizada como equipe Scrum. Abaixo será detalhado a responsa-bilidade de cada papel da equipe.
(a) Dono do Produto
Algumas responsabilidades do dono do produto são: gerenciar o backlog do produto, garantir retornos do investimento, definir a visão do produto, geren-ciar a entrada de novos requisitos e definir sua ordem, gerengeren-ciar o plano de releases, gestão de orçamento e riscos do produto e aceitar ou rejeitar o que será entregue ao final de cada iteração. Ou seja, o dono da sprint é responsável por gerenciar o projeto de forma a assegurar o valor do trabalho executado pela equipe de desenvolvimento. Se caso uma sprint não fizer mais sentido, somente o dono do produto tem autoridade para cancelar a sprint.
(b) Equipe de Desenvolvimento
A equipe de desenvolvimento é responsável por desenvolver os incrementos, que serão entregues ao final de cada iteração. Essa equipe também tem a res-ponsabilidade de estimar quanto ao tamanho dos itens do backlog do produto a serem desenvolvidos. Por trabalhar diariamente com as tarefas da iteração, a equipe também é responsável pelo seu microgerenciamento, controlando o andamento e a distribuição das tarefas, a qualidade e os prazos.
Uma equipe de desenvolvimento deve ser pequena o suficiente para se manter ágil e produtiva, é grande o suficiente para que a coordenação dos membros não seja um problema.
(c) ScrumMaster
O ScrumMaster é a pessoa que mais conhece o Scrum dentro todos os papéis. As responsabilidades são: orientar o dono do produto na criação e ordenação do backlog do produto, garantir que as regras do scrum estão sendo cumpridas e que os valores estão sendo seguidas. O ScrumMaster também é responsável por ajudar remover impedimentos que a equipe de desenvolvimento enfrentar. 2. Artefatos do Scrum
(a) Backlog do Produto
É uma lista ordenada, criada pela equipe scrum, contendo todas as funcio-nalidades desejadas para o produto. Além dos itens funcionais, o backlog do produto também contém itens não funcionais. Os itens mais importantes ficam no topo da lista e são implementados primeiro. Somente o dono do produto pode inserir, remover e reordenar os itens. O formato para descrever esses itens podem ser: histórias de usuário, descrições textuais, cenários de casos de us, entre outros. A figura 2 mostra o backlog do produto twitter.
Figura 2: Backlog do Produto
Fonte: (PRIKLADNICKI; WILL; MILANI, 2004)
(b) Backlog da Sprint
O backlog da sprint é o conjunto de itens selecionados para serem implemen-tados durante a sprint. É criado ao final de cada reunião de planejamento. O
objetivo é tornar visível o trabalho necessário para que a equipe de desenvol-vimento atinja a meta da sprint, por isso apenas a equipe de desenvoldesenvol-vimento pode adicionar tarefas que julguem ser necessárias e remover tarefas que não são necessárias para atingir a meta da sprint. A figura 2 mostra como ficaria o backlog da sprint que foi planejada com os dois primeiros itens do backlog do produto.
Figura 3: Backlog da Sprint
Fonte: (PRIKLADNICKI; WILL; MILANI, 2004)
(c) Incremento do Produto
Ao final de cada Sprint, a equipe de desenvolvimento entrega um incremento do produto, resultado do que foi produzido durante a Sprint. Para a equipe de desenvolvimento é importante entender que o incremento deve ser algo po-tencialmente entregável. Então a equipe deve produzir código com qualidade e todos da equipe Scrum devem entender o que significa “pronto”. Uma funcio-nalidade é considerada pronta quando passa por todas as etapas definidas pela equipe de desenvolvimento. Se uma funcionalidade não estiver pronta no final da sprint, ela deve retornar ao backlog do produto.
3. As Cerimônias do Scrum (a) Sprint
O desenvolvimento em Scrum é feito de forma iterativa e incremental, ou seja, ciclos completos de desenvolvimento de duração fixa que, ao final, resultam em incrementos potencialmente entregáveis do produto. A iterações são cha-madas de Sprint. Cada sprint tem duração no máximo de um mês. A Sprint é composta por: reunião de planejamento da sprint, scrum diária, trabalho de desenvolvimento, revisão da sprint e a retrospectiva da sprint.
(b) Reunião do Planejamento da Sprint
É a reunião que é feita no início da sprint para planejar o que será feito durante a sprint, a reunião tem duração fixa de oito horas para sprints que duram um mês. A reunião tem como base duas perguntas e cada uma delas dura a metade da reunião. As perguntas são: o que será entregue no incremento resultante da sprint? e como faremos para entregar o incremento nesta sprint?
Na primeira parte da reunião a equipe de desenvolvimento faz uma previsão das funcionalidades que serão desenvolvidas durante a sprint, o dono do produto apresenta os itens que estão no topo do backlog do produto e a equipe de desenvolvimento escolhe a quantidade de itens que consegue realizar durante a sprint. Depois de escolher os itens a equipe scrum define a meta da sprint. Na segunda parte da reunião, a equipe de desenvolvimento decide como trans-formará os itens selecionados em produto entregável no final da sprint.
(c) Reunião Diária
A reunião diária é feita pela equipe de desenvolvimento e tem duração no máximo de quinze minutos. Cada membro responde essas três perguntas:
• O que fiz desde a última reunião diária?
• O que pretendo fazer até a próxima reunião diária? • Existe algo me impedindo de concluir alguma tarefa? (d) Revisão da Sprint
No final da sprint é feita a cerimônia chamada de revisão da sprint. Além da equipe scrum qualquer pessoa interessada no produto pode participar. Os objetivos da reunião são: demonstrar as novas funcionalidades feitas durante a sprint, o dono do produto vai validar ou não as entregas da sprint, de acordo com a meta acordada na reunião de planejamento, a equipe de desenvolvimento discute sobre a sprint, o que ocorreu bem, os problemas enfrentados e depois da demonstração a equipe responde às dúvidas.
(e) Retrospectiva da Sprint
A retrospectiva da sprint é o último evento da sprint e ocorre logo após a revisão da sprint. Participam todos os membros da equipe scrum e o objetivo é aprimoramento do processo, o que funcionou e o que precisa ser melhorado para a próxima sprint.
interagem. A primeira etapa no scrum é elaborar o backlog do produto, depois de defi-nidos os itens, ocorre a reunião de planejamento para definir quais itens do backlog do produto irão compor a sprint, depois a sprint é executada de duas até quatro semanas, durante essas semanas, todo dia é feita uma reunião rápida para os membros da equipe de desenvolvimento mostrarem o que estão fazendo, o que vão fazer e se estão com alguma dificuldade na sua tarefa. Depois de finalizada a sprint é feita uma reunião de revisão, nessa reunião são apresentadas as nova funcionalidades feitas durante a sprint e o dono do produto vai validar se a entrega está de acordo com a meta da sprint. A última fase do ciclo é a reunião de retrospectiva, o objetivo é o aprimoramento do processo, ver o que funcionou na sprint e o que precisa melhorar. Por fim é entregue o incremento do produto ao cliente.
Figura 4: Ciclo Scrum
Fonte: (FARIAS, 2018)
2.2.2.2 XP
A metodologia Extreme Programming(XP) foi criada para solucionar os problemas causados pelo ciclos grandes das metodologias tradicionais de desenvolvimento (FRANCO, 2007). O XP é ideal para equipes pequenas e médias em que os requisitos são vagos e se modificam rapidamente (BECK, 1999). As boas práticas de programação são usadas de forma intensiva no XP, por exemplo: se revisar código é uma boa prática, então no XP o código vai passar por revisão constante através da programação em pares. Esta abordagem faz sentido somente em um ambiente onde as mudanças de requisitos do sistema são fatores dominantes (OSHIRO, 2001).
• Apresentar feedback contínuos em pequenos ciclos
• Abordar planejamento incremental, apresentando rapidamente um plano global, que evolui durante o ciclo de vida do projeto
• Ter habilidade flexível de implementar as funcionalidades, respondendo as mudanças de requisitos
• Confiar nos testes automatizados escritos pelos programadores e clientes, para moni-torar o progresso do desenvolvimento, permitindo a evolução do sistema e detectando antecipadamente os problemas
• Acreditar na comunicação oral, na colaboração íntima dos programadores, nos testes e no código fonte, definindo a estrutura do sistema e os objetivos
• Confiar no processo de evolução do projeto, que dura tanto quanto o sistema • Acreditar nas práticas que trabalham tanto com as aptidões, a curto prazo, dos
programadores, quanto os interesses, a longo prazo, do projeto
Depois de aplicado e ter tido sucesso real o XP foi formalizado em quatro princípios e doze práticas (BECK, 1999). Os quatro princípios são:
• Comunicação
A comunicação é importante para qualquer equipe e problemas podem ocorrer em um projeto devido a falta de comunicação entre os participantes, tanto entre os desenvolvedores em uma equipe multidisciplinar e também entre a equipe do projeto e o cliente.
Existem algumas práticas no XP que a comunicação é essencial, são elas: progra-mação em pares, cálculo de esforço das tarefas e testes de unidade.
• Simplicidade
O XP se fundamenta no fato de que é mais barato fazer algo mais simples que funcione, sem adicionar requisitos até que sejam realmente necessários. Fazendo a coisa mais simples que funcione e a medida que os requisitos novos surgirem serão adicionados ao projeto.
Quanto mais demorar um feedback, mais tempo pode levar para consertar um erro e mais trabalho perdido pode ter. Então os feedback precisam ser frequentes de acordo com o desenvolvimento.
• Coragem
É necessário coragem para inovar, criar, pedir ajuda quando precisa, identificar pro-blemas no projeto, mudar código que já estava funcionando e gerar novos propro-blemas, comunicar ao cliente que não vai entregar o projeto no prazo que foi combinado.
As principais práticas executadas no XP são:
• Cliente sempre disponível
O cliente é bastante importante para o desenvolvimento do projeto e precisa ter disponibilidade para tirar dúvida, definir escopo e determinar prioridades.
• Jogo do planejamento
São feitas reuniões enre a equipe de desenvolvimento e cliente, utilizando um quadro branco pra definir as histórias de usuário, estimando quando tempo será gasto na execução dessas histórias.
• Pequenas versões
Em cada fim de iteração, uma versão do sistema é entregue ao cliente para validação. Dessa forma, mais cedo podem detectar a necessidade de alterações nos requisitos. • Programação em pares
Todo código implementado é produzido por duas pessoas que usam o mesmo teclado, mouse e monitor. Os pontos positivos dessa prática são: diminui a ocorrência de erros no código, pois tem uma pessoa supervisionando e orientando o trabalho do outro, compartilamento de conhecimentto entre os membros da equipe, aumenta da prática de coletividade do código e nivelamento de conhecimento técnico dos programadores. • Simplicidade
Padrões serão definidos pela equipe de desenvolvimento e devm ser seguidos por todos os membros da forma mais simples e clara, facilitando a compreensão e con-tinuidade.
• Refatoração
Sempre que possível, levando em consideração o tempo e prazo do projeto, a cada nova funcionalidade implementada o código é reafatato até que o design esteja da forma mais simples.
• Integração Contínua
Os módulos do sistema são inegrados várias vezes por dia, sendo feitos testes uni-tários e o código só é aprovado quando passar por todos os testes.
• Padronização do código
Todo código é desenvolvido seguindo um padrão, toda equipe deve seguir o mesmo padrão. Dessa modo, todos da equipe terão a mesma visão do código.
• Rodízio de pessoas
As duplas da programação em pares é periodicamente revezadas, com o objetivo de deixar todos os módulos do sistema com o mesmo padrão e compartilhar o código com todos da equipe.
• Semana de 40 horas
Os programadores não deve fazer horas extras. É necessário que a equipe descanse nas horas livres, para não diminuir a produtividade.
• Testes
Os testes são elaborados antes da funcionalidade, onde se intercala testar e codificar. • Propriedade coletiva
Uma vez aplicados a Programação em Pares e o Rodízio de Pessoas, a equipe como um todo é responsável por todo o código. Não é preciso pedir autorização para alterar, mas é necessário a comunicação entre a equipe.
O ciclo de vida do XP (figura 5) é formado por 6 fases: exploração, planejamento, iterações para o lançamento, produção, manutenção e morte. A figura 5 ilustra este ciclo de vida.
A primeira fase do ciclo de vida é a exploração, o objetivo dessa fase é entender o que o sistema vai fazer. O cliente vai escrever cartões de histórias. Enquanto os clientes escrevem os cartões, os programadores buscam ferramentas, tecnologias e práticas capazes de prover uma solução adequada às expectativas do cliente.
A segunda fase é o planejamento, o objetivo da fase é definir a menor data e o maior conjunto de histórias que serão realizadas na primeira versão. Esta definição é feita de acordo com estimativas entre cliente e programadores (BECK, 2000). O cliente decide quais histórias são prioridade e devem está na primeira versão. Pode ser feita uma lista das histórias de maior prioridade até a menor. Os programadores reúnem-se para estimar o volume de trabalho de cada user sotry usando a técnica de plannig poker. A estimativa é anotada no cartão, junto com a prioridade de entrega definida pelo cliente, que pode ser: alta, média-alta, média-baixa e baixa.
A fase de releases e iterações é a terceira fase. Release é um conjunto de funcionalidades que representa uma pequena versão do sistema e está pronto para ser utilizado pelo cliente. A versão é colocoda em produção o mais rápido possível para o cliente usar e retornar um feedback sobre a release (TELES, 2006). Além de dividir o projeto em releases, cada release é dividido em iterações. O fluxo de atividades na iteração é o seguinte: escrita dos casos de teste; projeto e refatoração; codificação; realização dos testes e integração. O tempo de cada release e iteração depende da complexidade do projeto, mas geralmente, releases duram até oito semanas e iterações duram em torno de duas semanas (BORBOREMA, 2017).
A quarta fase do XP é a de manutenção. Nessa fase novas funcionalidades são im-plementadas em paralelo que o sistema é mantido rodando, novas pessoas podem ser incorporadas na equipe e código é melhorado. A técnica de refatoração é utilizada nessa fase, essa técnica tem o objetivo de reorganizar o código fonte para melhorar a quali-dade interna, diminuindo o tempo gasto com manutenção, sem prejudicar o desempenho e alterar o comportamento externo.
A última fase é chamada de morte, é nessa fase que termina o projeto. Existem duas possibilidades de terminar um projeto. A primeira é quando o cliente não enxerga nenhuma funcionalidade nova e já está satisfeito com o sistema existente. Outra possibilidade do projeto acabar é quando ele se torna economicamente inviável, devido a dificuldade de adicionar funcionalidades.
Figura 5: Ciclo de Vida do XP
Fonte: Autor
2.2.2.3 Kanban
A primeiras indústrias surgiram no final do século XIX, durante o período da revolução industrial. Naquela época o controle de estoque de materiais era uma tarefa realizada por uma pessoa que não trabalhava diretamente com as linhas de produção. Isso quer dizer que a pessoa que trabalhavam diretamente com a produção não precisam se preocupar com o material para seu trabalho, porque eles sabiam que tinham uma pessoa de fora preocupada em controlar o estoque. A falta de comunicação entre o pessoal das linhas de produção e o pessoal do controle de estoques, podia provocar duas situações: sobrar muitas peças perto do montador, faltar peças e a produção parar (AGUIAR; PEINADO, 2007).
Com o fim da Segunda Guerra Mundial, o Japão percebeu que para reequilibrar sua economia era necessário melhorar a qualidade a produtividade. Então o Japão foi o pri-meiro país a observar as desvantagens do sistema tradicional utilizado para abastecer linhas de produção. Um executivo da área industrial da Toyota do Japão, se inspirou no sistema de abastecimento das prateleiras de um supermercado norte-americano, que acontecia da seguinte forma: o produtos estavam distribuídos em prateleiras e eram reti-rados pelo consumidor, as informações mais importantes do produto estavam em cartões e a reposição era feita a medida que os produtos eram vendidos e tudo era controlado visualmente.
Com base na filosofia de controle visual, a Companhia Toyota em 1953, implantou o sistema de abastecimento do supermercado americano, que tinha seguintes características:
os montadores que trabalham na área de produção começaram a desempenhar o papel de “clientes” ou de “repositores” e a linha de produção era abastecida à medida que as peças e matérias-primas eram utilizadas.
Kanban é uma palavra japonesa e seu significado literal é “cartão” ou “sinalização”. É um método para a implantação de mudanças que não prescreve papéis ou práticas espe-cíficas. Em vez disso, oferece uma série de princípios que buscam melhorar o desempenho e reduzir desperdício, eliminando atividades que não agregam valor para a equipe.
Os principais fundamentos do Kanban são:
• Produção nivelada
• Redução do tempo de preparação • Padronização do trabalho
• Aperfeiçaoamento do trabalho
O Kanban foi adaptado para equipes de desenvolvimento de software, para isso exxe-cuta uma metodologia visual para gerenciar o fluxo do trabalho, na figura 6 é mostrado uma exemplo de um quadro Kanban. Para entender um pouco melhor o kanban, seguem os principais conceitos dessa metodologia:
• Ticket: unidades de trabalho que devem ser desenvolvidas(cartões)
• Just-in-Time: nada deve ser feito antes da hora exata, evitando estoques parados ou clientes esperando.
• Work in progress: são as tarefas que estão sendo executadas
• Quadro: é o local aonde o fluxo é visualizado, onde estão os tickets, as etapas e quantidades de tarefas disponíveis por etapa.
Figura 6: Ciclo do Kanban
3
Trabalhos Relacionados
Nesse capítulo é apresentado dois trabalhos relacionados na área de engenharia de requisitos em conjunto com metodologias ágeis.
3.1
Estudo Exploratório sobre a Engenharia De
Requi-sitos em Projeto Ágeis na Indústria Brasileira de
Desenvolvimento de Software (
FILHO
, 2017)
Wanderson (2017) investiga no seu trabalho como os procedimentos da Engenharia de Requisitos estão sendo usados em conjunto com as Metodologias Ágeis na indústria brasileira de desenvolvimento de software. O objetivo da pesquisa é identificar os desa-fios enfrentados na área de engenharia de requisitos aplicada em metodologias ágeis por empresas brasileiras de desenvolvimento de software.
No trabalho é elaborado um survey que foi respondido por vinte e sete profissionais da área de Tecnologia da Informação de várias partes do Brasil. O resultado da pesquisa mos-tra quais são os desafios que as empresas enfrentam na área de Engenharia de Requisitos junto com as Metodologias Ágeis.
Algumas perguntas do questionário que Wanderson elaborou foi em relação às técnicas de levantamento de requisitos utilizadas em projetos ágeis, tais como: quais eram as técnicas de especificação de requisitos nos projetos que usam metodologias ágeis, os pontos positivos e negativos das técnicas assinaladas.
O survey também possui uma parte para investigar quais os pontos podiam provocar problemas em projetos, foi perguntando em relação ao cliente, documentação, processo de desenvolvimento de software, técnicas utilizadas na engenharia de requisitos e a gestão dos requisitos. Depois de aplicado o survey e analisados os resultados, o trabalho compara os resultados do questionário com as respostas das perguntas de pesquisa presentes nas revisão sistemática da literatura feita por MEDEIROS et al. (2015).
3.2
Requirements Engineering Practice and Problems
in Agile Projects: Results from an International
Survey (
WAGNER et al.
, 2017)
Com a motivação de existirem poucos estudos relacionados as práticas e problemas na engenharia de requisitos em conjunto com as metodologias ágeis, o artigo internacional faz uma pesquisa em relação a ER ágil. Foi feito um questionário com o objetivo de responder essas quatro questões:
• Como os requisitos são elicitados e documentados? • Como os requisitos são alterados e alinhados aos testes? • Porque e como a engenharia de requisitos é aprimorada?
• Quais são os problemas comuns na engenharia de requisitos ágil?
O questionário foi respondido por 228 pessoas, porém para o estudo foram selecio-nadas 92 organizações que responderam Scrum e/ou XP como modelo de processo de desenvolvimento. Os locais das empresas que responderam o questionário foram: Canadá, EUA, Brasil, Áustria, Alemanha, Irlanda, Estônia, Finlândia, Noruega, Suécia.
Através das respostas do questionário foi descoberto que a engenharia de requisitos ágil concentra-se na documentação em texto livre e os requisitos são elicitados com uma variedade de técnicas. As técnicas mais utilizadas de elicitação são: entrevistas, proto-tipagem e reuniões facilitadas. Os autores do artigo acreditam que estas técnicas estão associadas aos métodos ágeis, pois o product owner no Scrum usaria entrevistas para entender os requisitos do produto.
Em relação às documentações das mudanças de requisitos, a maioria respondeu que muda o backlog do produto quando os requisitos mudam. Foi perguntado também como os respondentes analisam o efeito das mudanças de requisitos e a maioria dos entrevistados faz uma análise de impacto entre requisitos, uma boa parte respondeu que analisam o impacto das mudanças de requisitos no código.
Também foi identificado os principais problemas em relação a engenharia de requisitos e os considerados mais críticos foram: requisitos não claros, incompletos, pouca comuni-cação entre os membros da equipe de desenvolvimento e pouca comunicomuni-cação também com o cliente.
3.3
Considerações Finais
Os trabalhos citados acima serviram de base para esse TCC, nos dois foi elaborado e aplicado um survey de Engenharia de Requisitos em empresas que utilizam metodologias ágeis. Do trabalho de Wanderson(2017) foram usadas as perguntas de técnicas de elicitação e técnicas de documentação de requisitos e os resultados do survey dele foram comparados com os resultados desta pesquisa, isso será mostrado nos próximos capítulos. Uma das diferenças do survey desta pesquisa para os dos trabalhos relacionados é um seção que investiga se as empresas são ágeis através de questões sobre os valores dos métodos ágeis.
4
Metodologia
Neste capítulo será explicada a classificação da pesquisa, as características do questi-onário utilizado, o público alvo e as etapas da pesquisa.
4.1
Classificação da Pesquisa
Segundo Gil (2007) esta pesquisa é definida como um procedimento racional e siste-mático que tem como objetivo proporcionar respostas aos problemas que são propostos. A pesquisa desenvolve-se por um processo constituído de várias fases, desde a formulação do problema até a apresentação e discussão dos resultados. A pesquisa pode ser caracterizada por diversos pontos de vista.
Sob enfoque da natureza, a pesquisa caracteriza-se por ser aplicada, pois o objetivo é gerar conhecimento para solução de problemas específicos. Além disso a pesquisa é dirigida à busca da verdade para determinada aplicação prática em situação particular. A pesquisa em questão tem o propósito de investigar como as empresas de tecnologia da informação usam engenharia de requisitos em seus projetos e como é feita essa prática de requisitos em conjunto com as metodologias ágeis.
De acordo com GIL (2008), cada pesquisa possui um objetivo específico, contudo é possível agrupar as investigações em certos números de agrupamentos amplos. Desta forma, quanto aos objetivos a pesquisa pode ser: exploratória, descritiva e explicativa. A pesquisa deste trabalho é descritiva pois tem o objetivo de descrever características de uma população, um fenômeno ou experiência para o estudo realizado. Além disso, é realizado um estudo detalhado, com coleta, análise e interpretação dos dados.
Quanto aos procedimentos de pesquisa, foi adotada a técnica de levantamentos de dados ou survey. Essa pode ser descrita como a obtenção de dados ou informações sobre características, ações ou opiniões de determinado grupo de pessoas, indicado como repre-sentante de uma população-alvo, por meio de um instrumento de pesquisa, normalmente
um questionário (Tanur apud Pinsonneault Kraemer,1993).
Quanto ao método ou abordagem a pesquisa é quantitativa pois os dados das respostas será traduzidos em números para serem analisados.
4.2
Questionário
De acordo com GIL(2009), questionário é uma técnica de investigação composta por um conjunto de questões que são submetidas a pessoas com o propósito de obter infor-mações sobre um determinado assunto que precisa ser investigado. As respostas dessas questões que irão proporcionar os dados requeridos para descrever as características da população pesquisada e as hipóteses construídas.
Com relação ao questionário desta pesquisa, o objetivo dele é obter informações desse público em relação a metodologia utilizada no desenvolvimento de software, como é usada a engenharia de software nessas empresas e quais os problemas enfrentados.
Na primeira sessão do questionário as perguntas são feitas em relação ao entrevistado e a empresa que ele trabalha. Por exemplo, a função do entrevistado na empresa, o tempo de experiência, qual o domínio e a quantidade de colaboradores da empresa.
Na segunda parte, o objetivo é investigar como é feito o processo de desenvolvimento de software, então foram buscadas características das metodologias de desenvolvimento ágeis durante a pesquisa para montar essa sessão, os princípios dos métodos ágeis usados foram: a frequência de entregas de produtos, a frequência de reuniões com os interessados, se o membro da equipe realizava mais de uma função e o custo de mudanças dos requisitos. Essas perguntas tem como base os princípios dos Métodos Ágeis (PRIKLADNICKI; WILL; MILANI, 2004).
A terceira parte do questionário busca investigar como é utilizada a engenharia de requisitos nos projetos da empresa. Nessa parte as perguntas estão relacionadas com as técnicas de levantamento, documentação dos requisitos, se os documentos são atualizados frequentemente, se a cada mudança de requisitos é feita essa atualização e também busca examinar alguns problemas que podem ocorrer na engenharia de requisitos. Essa seção as perguntas foram baseadas no TCC de Filho (2017).
Antes de compartilhar o questionário para obter as respostas foi feito um piloto com uma Analista de Requisitos para validar o questionário, verificar se todas as perguntas estavam claras. Algumas alterações foram feitas, por exemplo: explicar cada técnica de
elicitação.
O questionário foi compartilhado no formato de formulário através da plataforma Google Forms. O formulário foi enviado por diversos meios de comunicações para que os profissionais de Tecnologia respondessem. O questionário completo está disponível no final desse documento, no apêndice A.
4.3
Público Alvo
O questionário foi elaborado para ser aplicado aos profissionais da área de TI em empresas de Tecnologia.
4.4
Etapas da Pesquisa
• Etapa 1 - Revisão bibliográfica: nesta etapa foi realizado um estudo sobre as metodologias ágeis e a engenharia de software. Além disso, foram escolhidos traba-lhos relacionados com o tema desta pesquisa, que estão descritos no capítulo 2 para fazer o cruzamentos dos resultados das respostas do questionário.
• Etapa 2 - Construção do questionário: depois de ter uma base teórica com a revisão bibliográfica, foi possível entender o problema da pesquisa e foi possível construir o questionário.
• Etapa 3 - Análise e comparação dos dados: com as respostas do questionário, essa etapa foi responsável por analisar esses dados coletados e responder às questões de pesquisa. Depois de feita a análise as respostas foram comparados com os dados de outros trabalhos relacionados.
• Etapa 4 - Conclusão dos resultados: nessa fase final foi feita a interpretação e conclusão dos resultados da comparação feita na etapa anterior.
Figura 7: Metodologia da Pesquisa
5
Resultados
O questionário produzido para gerar material para esta pesquisa foi compartilhado por vários canais de comunicação para que pessoas da área de Tecnologia da Informação de diferentes empresas tivessem acesso para responder. Após a conclusão da divulgação do questionário, trinta pessoas de empresas diferentes e tempos de experiência diferentes na área de Tecnologia da Informação responderam o questionário. O questionário foi dividido em quatro partes: caracterização do entrevistado caracterização da empresa, metodologia de desenvolvimento de software e a seção de Engenharia de Requisitos.
5.1
Caracterização do Entrevistado
Figura 8: Sexo dos entrevistados
Ao perguntar pela idade dos entrevistados foi obtido que: 46,7% dos participantes têm entre 22 e 25 anos, 26,7% têm entre 26 e 28 anos, 16,7% têm entre 29 e 32 anos, 6,7% têm entre 33 e 35 anos e 3,3% estão acima de 35 anos. Por meio da análise verifica-se que
80% dos respondentes são do sexo masculino e 20% são do sexo feminino (Figura 7).
Figura 9: Idade dos participantes
Com relação a função do entrevistado na empresa, a maioria respondeu que trabalha como desenvolvedor de software, correspondendo a 56,7% do total. Em seguida estão os analista de sistema com 23,3%, os analistas de testes de software são 10% dos participan-tes, 6,7% são analista de business intelligence e por último com 3,3% são os analista de requisitos (Figura 9).
Figura 10: Função do participante na empresa
Além da função de cada participante foi perguntando o nível de experiência em meses dos profissionais nessa função que está atuando, na Figura 10 mostra que 46,7% dos participantes possuem nível de experiência superior a 12 meses. Enquanto 23,3% possuem de 8 a 12 meses de experiência, 25% possui de 4 a 7 meses e 10% dos participantes possuem até 3 meses de experiência na sua função).
5.2
Caracterização da Empresa
De acordo com os resultados do gráfico da Figura 11, a maioria dos entrevistados é do estado do Rio Grande do Norte, parcela essa que significou 60% dos entrevistados, do estado de São Paulo foram 10% dos participantes, o Paraná também com 10%. Pernam-buco, Minas Gerais e o Ceará foram 3,3% dos entrevistados cada um. E os que colocaram a opção outros (10%), são de empresas fora do País.
Figura 12: Local da Empresa
A pesquisa também buscou saber qual o porte da empresa na qual os seus entrevistados estão desempenhando suas funções, conforme exposto no gráfico da Figura 12. Dessa forma, constatou-se que 46,67% dos entrevistados trabalham em empresas de pequeno porte (de 10 a 49 colaboradores), seguido por 26,67% dos entrevistados trabalham em microempresas(até 9 colaboradores), 23,33% dos participantes trabalham em empresa de grande porte(mais de 100 colaboradores) e 3,33% trabalham em empresas de médio porte (de 50 a 99 colaboradores).
Figura 13: Quantidade de colaboradores na empresa
A pesquisa ainda mostrou o domínio de cada empresa (Figura 13) onde: 31,5% res-pondeu que a empresa trabalha com aplicativos, 27,8% resres-pondeu que trabalham com sistema de informação gerencial, 11,1% respondeu que o domínio da empresa é sistema de apoio à decisão. Das empresas que os entrevistados trabalham, 7,4% lidam com sistema de gestão empresarial, 7,4% o domínio é data warehouse ou data mining, 5,7% trabalham com sistemas operacionais. Apenas 3,7% trabalham com hardware.
Figura 14: Domínio, na área de tecnologia da informação (TI), da empresa
5.3
Metodologia de Desenvolvimento de Software
A pesquisa também buscou saber quais as metodologias de desenvolvimento de soft-ware os profissionais da área de TI utilizam. De acordo com os dados obtidos, observou-se que 50% dos participantes utilizam Scrum como metodologia de desenvolvimento. Tam-bém foi colocada uma opção nessa pergunta para os profissionais que usam o Scrum adaptado, e foi obtido 26,7%, 10% dos entrevistados utilizam Kanban (Figura 14). E 10% dos participantes falaram que a empresa usa Scrum e Kanban. Em resumo a maioria dos entrevistados responderam que utilizam metodologias ágeis nas empresas que trabalham. Em relação aos profissionais que utilizam o Scrum adaptado pedimos que eles escrevessem quais eram as adaptações e foi relatado que a seguintes técnicas não são utilizadas: não é feita a estimativa de tempo das atividades, não é aplicado o daily meeting, a equipe não é multidisciplinar.
Figura 15: Método de desenvolvimento dos projetos
Com relação ao gráfico da Figura 14, que mostra as metodologias de desenvolvimento de software das empresas e também levando em consideração os estudos feitos ao longo da pesquisa, vimos que algumas empresas poderiam dizer utilizar metodologias ágeis, no entanto não seguir regras básicas das metodologias ágeis, então foi feito um estudo das técnicas dos métodos ágeis e foram elaboradas perguntas para investigar se elas são utilizadas.
De acordo com Nunes(2016), as metodologias ágeis possuem uma infinidade de pro-cessos, mas todos são regidos pelos mesmos princípios que estabelecem a base desses processos e com base nesses princípios essa seção foi elaborada.
A primeira pergunta em relação às técnicas usadas nas metodologias ágeis é se o entre-vistado possui mais de uma função na sua equipe, ou seja, se a equipe é multidisciplinar. E 63,33% dos participantes afirmaram que possuem mais de função na equipe, os outros 36,7% disseram que não possuem. Os resultados são mostrados na Figura 15.
Na Figura 14, mostra que 96,7% dos participantes responderam utilizar metodologias ágeis e na Figura 15 mostra que 36,7% não realizam mais de uma função na sua equipe de desenvolvimento. Então percebemos que os entrevistados falam que a empresa trabalha com ágil, mas um dos princípios fundamentais não é seguido.
Figura 16: Atuação em mais de uma função na equipe
A segunda pergunta da seção busca identificar a frequência de entregas dos produtos da empresa. As metodologias ágeis pregam que software em funcionamento é mais im-portante que documentações. E vemos na Figura 16 que 30% dos profissionais de TI não fazem entregas de seus produtos até trinta dias, ou seja, as sprints são mais longas que trintas dias. Novamente referenciando o gráfico(Figura 14) que mostra as metodologias utilizadas, 96,7% dizem utilizar ágeis. Dentro dos 30% dos entrevistados que responde-ram entregar produto em mais de 30 dias de desenvolvimento, 13,3% responderesponde-ram que depende do tipo de demanda, pode depender também da complexidade do sistema.
Figura 17: Frequência da entrega dos produtos
Em relação a frequência de reuniões com os clientes a maioria dos profissionais res-ponderam que fazem encontros frequentes com os clientes (Figura 17). Apenas 16,7% relataram que as reuniões são mensais e 3,3% relatou que depende do projeto e da etapa que o projeto está, deixando claro que apenas na etapa de requisitos que os encontros com os interessados do produto são mais constantes.
Figura 18: Frequência de reuniões com os clientes
As Figuras 18 e 19 mostram as respostas dos entrevistados em relação às mudanças de requisitos durante o desenvolvimento dos produtos. Com relação a frequência de mudanças dos requisitos, 60% afirmaram que existem mudanças nos requisitos, 20% afirma que os requisitos não mudam. E 20% relatam que é imprevisível, depende do projeto, é difícil de definir uma regularidade ou não sabe informar.
Figura 19: Frequência de mudanças dos requisitos
Para os que responderam que havia mudança nos requisitos, foi perguntado o custo dessas mudanças. Segundo Beck(2011), um dos doze princípios da metodologia ágil é aceitar mudanças de requisitos e processos ágeis se adequam a mudanças. A Figura 19 mostra que 40% disseram que é custoso mudar os requisitos e 10% diz que é muito custoso, somando assim 50% dos participantes. Fazemos novamente uma análise com o gráfico da Figura 14 que mostra 96,7% dos entrevistados trabalharem com métodos ágeis, porém os princípios básicos não são seguidos.
Figura 20: Custo da mudança dos requisitos para o projeto
O objetivo dessa terceira parte do questionário foi identificar quais dos princípios base das metodologias ágeis são seguidos nas empresas que trabalham os profissionais de TI que responderam o questionário e disseram utilizar metodologias ágeis. Concluiu-se que apesar dos entrevistados disseram utilizar ágil nos projetos as práticas principais não são utilizadas. Também foi observado que a prática menos utilizada é em relação ao custo de mudança de requisitos, a maioria dos entrevistados respondeu ser custoso mudar os requisitos. Foi feito uma análise separando os entrevistados que disseram utilizar todos os princípios de ágil e o resultado foi cinco participantes. Então pode-se inferir que esses profissionais realmente utilizam metodologias ágeis no processo de desenvolvimento de software, as metodologias citadas por eles citaram foram Scrum e Kanban. Todos esses profissionais afirmaram fazer a especificação de requisitos ao longo do desenvolvimento, isso se dá pois nos métodos ágeis a especificação não ser apenas no início do projeto e sim em todo o processo.
5.4
Atividades de Engenharia de Requisitos
A quarta seção do survey buscou informações relacionadas à opinião dos profissionais em relação a engenharia de requisitos. Conforme as respostas obtidas através da pergunta de número dezesseis do questionário disponível no apêndice B, os entrevistados
infor-maram que as três técnicas de elicitação mais utilizadas são brainstorming com 26,7%, protótipos e entrevistas com 17,5% cada uma (Figura 20).
Para os entrevistados que disseram utilizar todas as práticas que foram perguntadas no questionário das metodologias ágeis, foi filtrado como eles elicitam os requisitos do projeto. E as técnicas mais utilizadas por eles são cenários de brainstorming e protótipos.
Figura 21: Técnicas de Levantamento de Requisitos
A respeito das técnicas de levantamento de requisitos, foi comparado com os resul-tados do survey realizado no trabalho de conclusão de Filho(2017), no trabalho dele as técnicas mais utilizadas foram: entrevista, brainstorming e questionário. Nos dois estudos observamos que a prática de entrevista e brainstorming são bastante utilizadas.
Também foi feita uma análise com o survey aplicado em empresas internacionais ( WAG-NER et al., 2017) e a maioria dos profissionais respoderam utilizar entrevistas e protótipos para elicitar os requisitos dos projetos. Podemos concluir que a entrevista é uma técninca bastante utilizadas, pois nas três pesquisas ela é apontada como uma das mais utilizadas.
Figura 22: Comparação de Resultados - Elicitação de Requisitos
Também foi questionado aos entrevistados como são documentados os requisitos do projeto e as três formas mais usadas são documento de especificação de requisitos com 21%, a segunda forma mais utilizada é casos de uso com 17,3% e em terceiro lugar proto-tipação com 14,8% (Figura 21).
Também foi feita a análise dos entrevistados que disseram utilizar todas as práticas ágeis, para a especificação dos requisitos. E as técnicas mais utilizadas por eles são histórias de usuário, cenários e protótipos.
Figura 23: Como os requisitos são documentados
As técnicas de especificação de requisitos também foi comparada com o trabalho de conclusão de curso de Filho(2017) e no trabalho dele as técnicas mais utilizadas para a
especificação de requisitos foram: histórias de usuário, casos de uso e protótipos. Nos dois estudos a prática de casos de uso e protótipos são as mais usadas. Um ponto que chamou a atenção é que no trabalho de Filho(2017) a técnica mais utilizada é a história de usuário, já nesse trabalho aqui a técnica não é muito usada pelos profissionais.
Em relação ao survey aplicado nas empresas internacionais (WAGNER et al., 2017), a maioria dos participantes também mencionaram utilizar documento de especificação de requitos e diagramas de casos de uso. Diferente do survey aplicado no trabalho em questão poucos disseram utilizar modelo de processo de negócio, já no sruvey internacional foi o com maior porcentagem de uso.
Figura 24: Comparação de Resultados - Documentação de Requisitos
Outra pergunta relacionada a documentação de requisitos é relacionado as atuali-zações dos documentos. E a maioria dos profissionais responderam que são atualizados quando julga-se necessário, que corresponde a 80% dos participantes. Apenas 3,3% res-ponderam que atualizam diariamente e 6,7% mensalmente. Também tiveram participantes que responderam que nunca atualizam as documentações (Figura 22).
Figura 25: Frequência da atualização dos requisitos a cada mudança
Além de perguntar a frequência das atualizações, investigamos qual estratégia adotada para as atualizações e quais as dificuldades encontradas pela empresa. Com base nisso foi observado que muitas vezes os documentos não são atualizados. O participante P01 conta que às vezes finaliza a implementação de tarefas e não tem a documentação dela em nenhum lugar. O entrevistado P11 informa que muitas vezes as mudanças ficam registradas em e-mails ao invés de um documento. Outros participantes relataram que têm dificuldade na atualização por grande volume de trabalho, equipe muito grande e prazos apertados.
A presente pesquisa também buscou junto aos entrevistados saber o que mais causa problemas nos projetos , mediante os seguintes quesitos: documentação e gestão de requi-sitos. Com isso, no quesito documentação, foi detectado que os fatores que mais causam problemas nos projetos é não saber identificar quais documentos e conhecimentos preci-sam ser preservados. Além disso, é difícil treinar novos membros da equipe por falta de documentação e também problemas podem ser causados por insuficiência para implemen-tar e fazer manutenção. Para uma melhor visualização destes dados, a Figura 23 mostra a recorrência de relatos dos usuários com relação a este ponto.
Figura 26: Fatores que mais causam dificuldade no contexto de documentação
Com relação à problemas ocasionados pela má gestão dos requisitos, a maior parte dos entrevistados relataram que os principais fatores que ocasionam dificuldades nesse contexto é a baixa motivação da equipe quando o assunto é documentação de requisitos. Além disso, há dificuldade na especificação de requisitos não funcionais e também no reuso dos artefatos gerados, conforme mostrado na Figura 24.
