UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE PROGRAMA DE … · 2.1 metodologias de desenvolvimento...

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

PROGRAMA DE PÓS-GRADUAÇÃO EM DESIGN

MESTRADO PROFISSIONAL EM DESIGN

MARCUS VINÍCIUS GUEDES GONÇALVES

O USO DA METODOLOGIA ÁGIL COMO PROCESSO DE DESENVOLVIMENTO

PARTICIPATIVO DE SISTEMAS

DISSERTAÇÃO

NATAL, RN

2017




Dissertação apresentada como requisito parcial à

obtenção do título de Mestre em Design, do

Programa de Pós-Graduação em Design da

Universidade Federal do Rio Grande do Norte.

Orientador: Prof. Dr. Olavo Fontes Magalhães

Bessa

NATAL, RN

2017

Universidade Federal do Rio Grande do Norte - UFRN

Sistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial do Departamento de Artes - DEART

Gonçalves, Marcus Vinícius Guedes.

O uso da metodologia ágil como processo de desenvolvimento

participativo de sistemas / Marcus Vinícius Guedes Gonçalves. -

2017.

105 f.: il.

Dissertação (mestrado) - Universidade Federal do Rio Grande

do Norte. Centro de Ciências Humanas, Letras e Artes. Programa

de Pós-Graduação em Design, Natal, 2017.

Orientador: Prof. Dr. Olavo Fontes Magalhães Bessa.

1. Scrum (Desenvolvimento de software). 2. Desenvolvimento

ágil de software. 3. Design. 4. Administração de projetos. I.

Bessa, Olavo Fontes Magalhães. II. Título.

RN/UF/BS-DEART CDU 004.6




Trabalho de Conclusão de Curso apresentado a

Universidade Federal do Rio Grande do Norte,

como requisito parcial à obtenção do título de

Mestre em Design.

Aprovado em

BANCA EXAMINADORA

__________________________________ Prof. Dr. Olavo Fontes Magalhães Bessa

Orientador Universidade Federal do Rio Grande do Norte

__________________________________ Profa. Dra Helena Rugai Bastos

Membro Interno Universidade Federal do Rio Grande do Norte

__________________________________ Prof. Dr. Marcos Antonio de Oliveira

Membro Externo Universidade Federal do Ceará

AGRADECIMENTOS

A Deus, pela minha vida e da minha família.

À minha família, pelo amor e apoio incondicional, pela compreensão pelos

momentos utilizados no desenvolvimento deste trabalho.

Ao meu orientador, Prof. Dr. Olavo Fontes Magalhães Bessa, pela confiança,

paciência, apoio e dedicação.

E, finalmente, à Superintendência de Informática da Universidade Federal do Rio

Grande do Norte, pela oportunidade de realizar este mestrado.

RESUMO

No contexto em que a equipe de desenvolvimento do SIGRH está inserida, em que a

quantidade de solicitações por novas melhorias é bem maior que a capacidade de

entrega, é necessária a adoção de um processo que priorize o que venha aumentar o

máximo possível o valor do sistema. Utilizar um processo com excesso de formalidade

pode diminuir a velocidade de progresso do projeto. Por outro lado, a falta total de

formalidade não garante que os objetivos do projeto sejam alcançados. Uma metodologia

de desenvolvimento ágil como o Scrum, consegue atender a esses requisitos, com

entregas frequentes, resultando no aumento da satisfação dos clientes, e melhorias no

comprometimento, motivação, colaboração e troca de conhecimento entre os membros da

equipe de desenvolvimento. O objetivo deste trabalho foi descrever o processo de

implantação do Scrum e, aplicando-se técnicas de design participativo, a criação e

utilização de uma ferramenta para apoiar as atividades segundo as práticas do Scrum,

possibilitando o registro colaborativo das informações, facilitando o acompanhamento do

progresso por toda a equipe e auxiliando na gestão do projeto.

Palavras-chave: Scrum, metodologia de desenvolvimento ágil, design participativo.

ABSTRACT

In a context in which the development team is not able to deliver the amount of requests

for new improvements, a process that prioritizes what will add maximum possible value for

the system is desired. Using a process with too much formality can slow the progress of

the project. On the other hand, the total lack of formality does not ensure that project

objectives are met. An agile development methodology such as Scrum can meet these

requirements, with frequent deliveries, resulting in increased customer satisfaction, and

improvements in commitment, motivation, collaboration and knowledge exchange among

the development team. The objective of this paper was to describe the Scrum

implementation process and, using participatory design techniques, the build and use of a

tool to support activities according to Scrum practices, enabling the collaborative

registration of information, facilitating the monitoring of progress by the entire team and

assisting in project management.

Keywords: Scrum, agile development methodology, participatory design.

LISTA DE ILUSTRAÇÕES

Figura 1 - Áreas de abrangência dos sistemas SIG-UFRN 12

Figura 2 - Rede IFES e Rede CICLO 13

Figura 3 - Sprint burndown chart 23

Figura 4 - Scrum task board 24

Figura 5 - Ciclo de vida do Scrum 27

Figura 6 - Design participativo 29

Figura 7 - Etapas do método utilizado neste trabalho 32

Figura 8 - Quadro Scrum utilizado no primeiro sprint 35

Figura 9 - Planilha com o sprint backlog utilizada no primeiro sprint 36

Figura 10 - Aba Atividades do segundo sprint 38

Figura 11 - Detalhes da aba Atividades do segundo sprint 39

Figura 12 - Aba Consumo do segundo sprint 40

Figura 13 - Aba Dashboard do segundo sprint 42

Figura 14 - Gráfico de Custo x Horas por tarefa do segundo sprint 43

Figura 15 - Aba Atividades do terceiro sprint 45

Figura 16 - Detalhes da aba Atividades do terceiro sprint 46

Figura 17 - Coluna Responsável na aba Atividades do quarto sprint 48

Figura 18 - Cálculo dos custos considerando 30 dias 49

Figura 19 - Cálculo dos custos considerando apenas dias úteis 50

Figura 20 - Cálculos dos custos por perfil 51

Figura 21 - Burndown chart de 30 dias 52

Figura 22 - Burndown chart considerando apenas dias úteis 53

Figura 23 - Burndown chart por tarefa 54

Figura 24 - Burndown chart por perfil de equipe 55

Figura 25 - Gráfico Atividades x Equipe 56

Figura 26 - Gráfico Horas x Membro 57

Figura 27 - Aba Quadro do quarto sprint 59

Figura 28 - Relação entre as atividades na aba Atividades e no scrum board 60

Figura 29 - Aba Atividades do quinto sprint 62

Figura 30 - Aba Quadro do quinto sprint 63

Figura 31 - Aba Quadro do quinto sprint exibindo tarefas finalizadas 64

Figura 32 - Aba Sprint Backlog do quinto sprint 65

Figura 33 - Aba Dashboard do quinto sprint 66

Figura 34 - Aba Atividades do sexto sprint 69

Figura 35 - Burndown chart exibindo dados das atividades de validação 70

Figura 36 - Aba Atividades do sexto sprint 71

Figura 37 - Aba Sprint do sexto sprint 72

Figura 38 - Aba Quadro do sexto sprint 73

Figura 39 - Detalhamento do scrum board 74

Figura 40 - Gráfico Pontos x Tipo de atividade do sexto sprint 75

Figura 41 - Aba Quadro do sexto sprint 76

Figura 42 - Aba Sprint Backlog do sexto sprint 77

Figura 43 - Aba Quadro da planilha template 79

Figura 44 - Aba Atividades da planilha template 81

Figura 45 - Burndown chart da aba Dashboard da planilha template 83

Figura 46 - Burndown chart da aba Dashboard da planilha template 84

Figura 47 - Gráfico Tipo de atividade x Número de atividades da aba Dashboard da

planilha template

85

Figura 48 - Aba Consumo da planilha template 87

Figura 49 - Aba Sprint Backlog da planilha template 89

Figura 50 - Aba Sprint Backlog da planilha template 90

Figura 51 - Aba Backlog da planilha template 91

Figura 52 - Aba Sprint da planilha template 92

Figura 53 - Aba REF da planilha template 93

LISTA DE TABELAS

Tabela 1 - Antes e depois da implantação do Scrum 94

LISTA DE ABREVIAÇÕES E SIGLAS

DP Design Participativo

IEEE Institute of Electrical and Eletronic Engineering

IFES Instituições Federais de Ensino Superior

PROGESP Pró-Reitoria de Gestão de Pessoas

RH Recursos Humanos

ROI Return Of Investiment

SIAPE Sistema Integrado de Administração de Recursos Humanos

SIGAA Sistema Integrado de Gestão de Atividades Acadêmicas

SIGRH Sistema Integrado de Gestão de Recursos Humanos

SINFO Superintendência de Informática

SIPAC Sistema Integrado de Patrimônio, Administração e Contratos

UFRN Universidade Federal do Rio Grande do Norte

SUMÁRIO

1 INTRODUÇÃO 11

2 FUNDAMENTAÇÃO TEÓRICA 16

2.1 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS 16

2.1.1 METODOLOGIA ÁGIL DE DESENVOLVIMENTO 17

2.1.2 SCRUM 20

2.2 DESIGN PARTICIPATIVO 28

2.3 PESQUISA-AÇÃO 30

3 METODOLOGIA APLICADA 32

4 DESCRIÇÃO DO PROCESSO DE IMPLANTAÇÃO DO MÉTODO 34

4.1 PRIMEIRA ITERAÇÃO 35

4.2 SEGUNDA ITERAÇÃO 37

4.3 TERCEIRA ITERAÇÃO 44

4.4 QUARTA ITERAÇÃO 47

4.5 QUINTA ITERAÇÃO 61

4.6 SEXTA ITERAÇÃO 67

4.7 PLANILHA TEMPLATE 78

4.7.1 ABA QUADRO 78

4.7.2 ABA ATIVIDADES 80

4.7.3 ABA DASHBOARD 82

4.7.4 ABA CONSUMO 86

4.7.5 ABA SPRINT BACKLOG 88

4.7.6 ABA BACKLOG 91

4.7.7 ABA SPRINT 91

4.7.8 ABA REF 93

5 RESULTADOS 94

6 CONSIDERAÇÕES FINAIS 97

REFERÊNCIAS 98

APÊNDICE A - SCRIPTS DA PLANILHA DE ACOMPANHAMENTO DE PROCESSO DE

DESENVOLVIMENTO DE SISTEMAS 101

11

1 INTRODUÇÃO

Os Sistemas Integrados de Gestão da Universidade Federal do Rio Grande do

Norte (UFRN), ou simplesmente SIG-UFRN, foram desenvolvidos pela Superintendência

de Informática (SINFO) da UFRN para auxiliar na gestão dos processos. Os sistemas

SIG-UFRN foram concebidos para funcionarem integrados uns aos outros, de forma a

possibilitar o compartilhamento de informações em uma base de dados comum, com

acesso unificado e um mesmo padrão de visualização. Visa atender às necessidades dos

gestores, servidores e alunos da instituição, na organização e informatização dos

processos de cada setor da UFRN e, assim, auxiliando na execução e planejamento de

suas atividades administrativas e acadêmicas.

Basicamente eles são divididos nos três principais sistemas: SIGAA (Sistema

Integrado de Gestão de Atividades Acadêmicas), utilizado para a execução das atividades

da área fim da UFRN, que é a área acadêmica; SIPAC (Sistema Integrado de Patrimônio,

Administração e Contratos), utilizado para a execução das atividades administrativas; e

SIGRH (Sistema Integrado de Gestão de Recursos Humanos), utilizado para auxiliar a

gestão e gerenciar as informações dos recursos humanos. Os sistemas SIG-UFRN

também se comunicam com os sistemas estruturantes do governo federal. A Figura 1

apresenta um diagrama de comunicação entre os sistemas desenvolvidos pela SINFO e

sistemas estruturantes do governo federal, e suas funcionalidades.

O SIGRH nasceu da necessidade de se organizar e informatizar os processos dos

diversos setores da Pró-Reitoria de Gestão de Pessoas (PROGESP) da UFRN, auxiliando

na execução e planejamento de suas atividades de gestão e, disponibilizando para os

servidores da instituição uma ferramenta para comunicação com os gestores. São áreas

suportadas pelo SIGRH: marcação/alteração de férias, cálculos de aposentadoria,

avaliação funcional, dimensionamento de força de trabalho, controle de frequência,

concursos, capacitações, atendimentos on-line, serviços e requerimentos, registros

funcionais, relatórios de RH, dentre outros. A maioria das operações possui algum nível

de interação com o sistema SIAPE (sistema de âmbito nacional), enquanto outras são

somente de âmbito interno (UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE,

2016a).

12

Figura 1 - Áreas de abrangência dos sistemas SIG-UFRN

Fonte: UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE (2016a)

Em 2008, a UFRN passou a disponibilizar seus sistemas para outras instituições

federais, oferecendo apoio técnico e transferência de conhecimento para implantação e

uso desses sistemas. Essas instituições passaram a formar as redes de cooperação IFES

e CICLO. A rede IFES é composta por instituições federais de ensino superior, enquanto

a rede CICLO é composta por instituições da administração direta. Para dar suporte às

diferentes regulamentações e processos das várias instituições das redes, os sistemas

SIG-UFRN foram adaptados para permitir que uma mesma funcionalidade tenha

13

comportamentos diferentes por meio de parametrizações. A Figura 2 exibe todas as

instituições que fazem parte das redes CICLO e IFES.

Figura 2 - Rede IFES e Rede CICLO

Fonte: UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE (2016b)

Desde que foram iniciados, em 2004, os sistemas estão em constante evolução,

com o desenvolvimento de novas funcionalidades solicitadas tanto pelos gestores da

UFRN quanto pelas instituições das redes de cooperação. Para tentar atender a essa

demanda crescente, a SINFO tem procurado um modelo ideal de equipe e de

metodologia de desenvolvimento de sistemas. Inicialmente, as equipes eram divididas por

função: a equipe de analistas de requisitos, responsável por coletar e analisar as

demandas; a equipe de desenvolvedores, responsável por implementar as demandas

com base nas especificações da equipe de analistas de requisitos; a equipe de analistas

14

de testes, responsável por testar se as funcionalidades estão de acordo com o que foi

especificado e com a padronização dos sistemas; a equipe de suporte, responsável em

dar suporte aos usuários da UFRN; e a equipe de cooperação, responsável por dar

suporte técnico para as instituições das redes de cooperação. As equipes eram

independentes e não havia um planejamento sobre o que seria priorizado e quando seria

a próxima entrega de novas funcionalidades. Além disso, as equipes ficavam em prédios

separados, o que dificultava a interação entre elas.

Tentando mudar esse cenário de incertezas em relação às entregas das

demandas, as equipes foram divididas por sistemas. Cada sistema passou a ter uma

equipe própria de analistas de requisitos, desenvolvedores, analistas de testes e

cooperação. Com isso, as equipes de cada sistema passaram a ter mais autonomia sobre

o planejamento das demandas. Essa nova configuração, em que todos os membros da

equipe ocupavam um mesmo espaço físico, criou-se um ambiente ideal para a

implantação de uma metodologia ágil de desenvolvimento de sistemas.

O uso de metodologias ágeis em projetos de desenvolvimento de sistemas tem

crescido bastante em um mercado cada vez mais exigente com soluções que apresentem

produtos com qualidade em prazos cada vez menores. Dentre essas metodologias,

destaca-se o Scrum, uma abordagem enxuta de gerenciamento de projetos de softwares,

que tem se mostrado eficiente no que se refere à satisfação dos clientes e diminuição de

atrasos em projetos, se comparados aos métodos tradicionais (MANN; MAURER, 2005).

Diante disso, a equipe do SIGRH decidiu implantar o Scrum no processo de

desenvolvimento do seu sistema, o que contribuiu para o envolvimento de toda a equipe

na avaliação e no aprimoramento do processo e das ferramentas de apoio, com as

reuniões de acompanhamento constantes. Uma dessas ferramentas é a planilha de

acompanhamento de desenvolvimento de sistemas, que foi idealizada e aprimorada com

a participação da equipe, isto é, dos próprios usuários. Segundo Preece, Rogers e Sharp

(2011), o design participativo ajuda a diminuir a distância entre o projetista e os usuários

do sistema.

Apesar de a equipe ser composta por experts na área de desenvolvimento de

sistemas e, portanto, com capacidade para contribuir também no desenvolvimento,

apenas o pesquisador atuou como desenvolvedor na construção da planilha durante a

15

pesquisa-ação realizada. Os outros membros da equipe participaram como usuários do

processo.

Este trabalho tem como objetivo geral descrever o processo de criação de um

procedimento para acompanhamento de desenvolvimento de sistemas durante a

implantação da metodologia ágil de desenvolvimento Scrum na equipe do SIGRH,

detalhando as etapas de melhorias com a participação efetiva dos usuários e do próprio

pesquisador, por meio de uma pesquisa-ação realizada.

O presente documento está organizado em seis capítulos: o Capítulo 1 apresenta,

de maneira geral, o conteúdo do trabalho, contextualizando onde ocorreu a pesquisa-ação

e seu objetivo; no Capítulo 2, são apresentados os conceitos necessários para a

compreensão deste trabalho, tais como metodologias ágeis de desenvolvimento e design

participativo; o Capítulo 3 aborda a metodologia aplicada neste trabalho; no Capítulo 4

pode-se observar como foi realizada a pesquisa-ação, descrevendo detalhadamente

todas as suas iterações e concluindo com a descrição da planilha template, utilizada para

criar as planilhas de acompanhamento do processo; os resultados são apresentados no

Capítulo 5, fazendo um comparativo do antes e depois da adoção do Scrum; a conclusão

deste trabalho e sugestões de trabalhos futuros são apresentadas no Capítulo 6.

No final do documento é exibido um apêndice com o código do script utilizado para

realizar algumas automatizações na planilha de acompanhamento de desenvolvimento de

sistemas.

16

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo são apresentados os conceitos necessários para a compreensão do

trabalho realizado descrito nesta dissertação. A seção 2.1 discorre sobre o que são

metodologias de desenvolvimento de software, a seção 2.1.1 apresenta a metodologia

ágil de desenvolvimento de sistemas e o Scrum, enquanto que a seção 2.2 aborda o

design participativo.

2.1 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS

Sistemas de informação têm sido utilizados por muitas organizações com o objetivo

de auxiliar seus gestores no processo de tomada de decisões. Produzir informações

corretas ou incorretas pode ser a diferença entre o sucesso e o fracasso do sistema.

Atualmente, é senso comum que a utilização de uma metodologia de trabalho é

essencial para o sucesso na obtenção dos resultados esperados. Segundo Pompilho

(2002), "uma metodologia pode ser entendida como uma dissertação sobre a maneira de

se utilizar um conjunto coerente e coordenado de métodos para atingir um objetivo, de

modo que se evite, tanto quanto possível, a subjetividade na execução do trabalho". Ou

ainda, o uso de procedimentos que seguem um roteiro dinâmico e interativo para se

atingir um objetivo, visando a qualidade e produtividade no desenvolvimento de um

produto ou software, chamamos de metodologia. Segundo o dicionário Webster (1998),

metodologia é o conjunto de métodos, regras e postulados empregado por uma disciplina:

um procedimento particular ou um conjunto de procedimentos. A metodologia visa definir

o papel dos envolvidos diretamente ou não no projeto, isto é, quem faz o quê, quando,

como e onde.

O desenvolvimento de um sistema de informação é uma atividade complexa.

Segundo Rezende (2005), os sistemas de informação atuais têm como características:

grande volume de dados, processamento de informações complexo, vários usuários

envolvidos, contexto abrangente, mutável e dinâmico, interligação de várias técnicas e

tecnologias, suporte à tomada de decisões, auxílio na qualidade, efetividade,

competitividade e inteligência organizacional. Envolve requisitos rígidos, restrições de

17

integridade e grande conhecimento dos processos da aplicação para permitir a descrição

mais precisa das interações entre o sistema e o ambiente. Quando não se consegue

compreender, registrar e comunicar totalmente os requisitos, é quase certo que haverá

divergência entre o que o sistema desenvolvido faz e o que ele deveria fazer.

O desenvolvimento de um sistema de informação requer a participação de uma

equipe de profissionais especialistas em várias áreas da engenharia de software.

Segundo o Institute of Electrical and Eletronic Engineering, a engenharia de software é a

aplicação sistemática, disciplinada e com abordagem quantitativa para o

desenvolvimento, operação e manutenção de software (IEEE, 1990). Tem como objetivo

auxiliar no processo de desenvolvimento de software, visando produzir um produto de alta

qualidade com um tempo e custo menores. O desenvolvimento de um sistema deixou de

ser apenas produção de código.

Até o final do século XX, as metodologias usadas para desenvolvimento de

sistemas eram baseadas em métodos considerados rígidos, que não se adequavam

facilmente às mudanças de requisitos. O processo não era claro para o cliente,

dificultando o acompanhamento do projeto e deixando-o, muitas vezes, inseguro sobre o

que seria entregue. Foi então que surgiram as metodologias de desenvolvimento ágil.

2.1.1 METODOLOGIA ÁGIL DE DESENVOLVIMENTO

Segundo Tumbas (2006), as metodologias ágeis de desenvolvimento de sistemas

foram concebidas com base nos seguintes pensamentos:

● Desenvolvimento de um sistema de informação é um trabalho criativo, e

atividades de projeto ocupam uma posição de destaque;

● Processos de desenvolvimento têm que ser flexíveis para permitir que

usuários mudem frequentemente seus requisitos sem grandes

consequências;

● As características dos indivíduos participantes no desenvolvimento têm

influência na qualidade das atividades do projeto.

Os métodos ágeis de desenvolvimento de software surgiram como uma resposta

às cobranças por inovação em prazos cada vez mais reduzidos, constantes

18

necessidades de mudanças de requisitos e mal desempenho de grande parte dos

projetos de desenvolvimento de software. Nesta época, as metodologias

tradicionais começaram a ser questionadas devido ao grande volume de

documentação, e um crescente número de organizações passou a adotar um ou

mais métodos ágeis para produzir software com menos documentação, sob

condições de mudanças rápidas e com foco na satisfação do cliente (MOL, 2007).

Foi a partir de reuniões de um grupo de representantes das mais diversas técnicas

e metodologias de desenvolvimento ágil que se definiu quais características uma

abordagem ágil teria na aplicação ao desenvolvimento de projetos. O objetivo era discutir

e identificar padrões e valores comuns a todas as técnicas e metodologias existentes.

Embora cada participante tivesse práticas e teorias próprias sobre como desenvolver um

software, era consenso que alguns princípios sempre eram respeitados quando se

obtinha sucesso nos projetos. Com base nisso, eles criaram o manifesto para o

desenvolvimento ágil de software (MANIFESTO ÁGIL, 2001), ou somente manifesto ágil.

Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o nós

mesmos e ajudando outros a fazer o mesmo. Através deste trabalho devemos

valorizar:

● indivíduos e interações mais que processos e ferramentas;

● software desenvolvido mais que documentação abrangente;

● a colaboração do cliente mais que negociação de contratos;

● respondendo a mudanças mais que seguir um plano;

ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à

esquerda. (MANIFESTO ÁGIL, 2001)

Segundo o Manifesto Ágil (2001), existem 12 princípios que devem ser respeitados

quando se aplica uma metodologia ágil. São eles:

● Nossa maior prioridade é satisfazer o cliente através da entrega contínua e

adiantada de software com valor agregado.

● Mudanças nos requisitos são bem-vindas, mesmo tardiamente no

desenvolvimento. Processos ágeis tiram vantagem das mudanças visando

vantagem competitiva para o cliente.

● Entregar frequentemente software funcionando, de poucas semanas a

poucos meses, com preferência à menor escala de tempo.

19

● Pessoas de negócio e desenvolvedores devem trabalhar diariamente em

conjunto por todo o projeto.

● Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente

e o suporte necessário e confie neles para fazer o trabalho.

● O método mais eficiente e eficaz de transmitir informações para e entre

uma equipe de desenvolvimento é através de conversa face a face.

● Software funcionando é a medida primária de progresso.

● Os processos ágeis promovem desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes de manter

um ritmo constante indefinidamente.

● Contínua atenção à excelência técnica e bom design aumenta a agilidade.

● Simplicidade - a arte de maximizar a quantidade de trabalho não realizado -

é essencial.

● As melhores arquiteturas, requisitos e designs emergem de equipes auto-

organizáveis.

● Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e

então refina e ajusta seu comportamento de acordo.

Quais as vantagens de se adotar uma metodologia ágil para desenvolvimento de

sistemas? Com metodologias ágeis os participantes do projeto estão constantemente em

contato. Equipe, clientes e patrocinadores trabalham em colaboração uns com os outros

para o sucesso do projeto, o que ajuda na compreensão dos requisitos e execução do

projeto. Esse contato torna o processo transparente, já que os clientes e patrocinadores

têm conhecimento sobre o andamento do projeto, quais funcionalidades serão entregues

e qual o custo de cada etapa do desenvolvimento. Outra vantagem das metodologias

ágeis é a flexibilidade. Mudanças são bem-vindas, pois um novo planejamento é

realizado a cada iteração que dura, no máximo, um mês, tornando possível uma fácil

implementação. Como o nome já diz, agilidade também é uma das vantagens.

Funcionalidades são desenvolvidas e entregues a cada iteração, facilitando o

acompanhamento do que falta para a conclusão do projeto. Como o planejamento é feito

mensalmente, riscos podem ser previstos e minimizados de maneira mais eficaz e falhas

podem ser detectadas com antecedência e corrigidas antes da conclusão do produto. A

cada iteração, é possível controlar os custos, priorizando as funcionalidades que mais

agregarão valor ao produto. E, finalmente, com a aplicação dos princípios do Manifesto

Ágil (MANIFESTO ÁGIL, 2001) e a realização de testes frequentes para garantir a

20

qualidade do produto e que, o que está sendo entregue, é o que foi acordado com os

clientes.

2.1.2 SCRUM

A metodologia ágil de desenvolvimento Scrum foi criada por 3 dos signatários do

Manifesto Ágil (MANIFESTO ÁGIL, 2001): Mike Beedle, Jeff Sutherland e Ken Schwaber.

Eles foram influenciados por um artigo chamado "New New Product Development Game",

escrito por Hirotaka Takeuchi e Ikujiro Nonaka em 1986, que descreve o Scrum como um

estilo de desenvolvimento de produtos. O artigo se baseia em estudos de caso na

indústria automobilística e de impressoras, nas quais pequenas equipes multidisciplinares

trabalham como uma unidade para atingir um objetivo comum (TAKEUCHI; NONAKA,

1986). Seu nome é inspirado em uma jogada do Rugby para reiniciar o jogo após uma

interrupção. Os jogadores de cada time se juntam em formação e se esforçam para

ganhar a posse da bola, quando ela é lançada entre os dois times. Cada jogador tem uma

função específica e todos atuam em conjunto, de forma integrada, para realizar um

objetivo comum.

O seu objetivo é definir um processo de desenvolvimento de sistemas com foco

nas pessoas (SCHWABER, 2002). O Scrum se baseia em: flexibilidade dos resultados,

flexibilidade dos prazos, times pequenos, revisões frequentes e colaboração

(SCHWABER, 1995). A metodologia Scrum tem foco na melhoria contínua, pois se baseia

no ciclo PDCA (Plan, Do, Check, Act) e produz os benefícios dos métodos de

desenvolvimento ágil, com a vantagem de ser uma implementação simples (YOSHIMA,

2007).

O Scrum funciona com iterações, chamadas de sprints, que dividem o

desenvolvimento em ciclos curtos, que devem ser de 2 a 4 semanas (time-box). Cada

iteração deve produzir a entrega do produto ou de parte dele, de forma que os clientes

recebam uma versão dos sistemas que agregue valor ao seu negócio (DANTAS, 2003).

Cada sprint deve ter a mesma duração, para que seja possível acompanhar o progresso

do projeto e medir a produtividade da equipe, verificando, ao final de cada sprint, se os

requisitos estão sendo desenvolvidos conforme acordado com os clientes. O ciclo de vida

21

de cada sprint é composto por 3 fases: planejamento, desenvolvimento e avaliação. Na

sprint são executadas atividades de requisitos, análise, desenvolvimento, testes e

entrega.

O Scrum se baseia em papéis bem definidos e responsabilidades, que são mais

abrangentes, com o objetivo de alcançar o sucesso do projeto (YOSHIMA, 2007). Os

papéis, no Scrum, possuem uma curva de aprendizado relativamente baixa. O product

owner, o scrum team e o scrum master.

● Product owner: É o “dono do produto”. Ele representa todos os

interessados no sucesso do projeto. Responsável pelo retorno do

investimento (ROI - return of investiment) do projeto e por definir os

requisitos e suas prioridades, podendo modificá-los a cada sprint. O product

owner tem a função de aceitar ou rejeitar a entrega de cada sprint.

● Scrum team: ou simplesmente time. Equipe multidisciplinar composta de 5

a 9 membros. Responsável por selecionar, dentre os itens priorizados, os

que serão executados dentro da sprint. Tem autonomia para tomar

decisões, visando cumprir os objetivos da sprint.

● Scrum master: responsável por gerenciar os interesses do product owner

dentro da sprint, exercendo um papel de liderança. Seria o gerente de

projetos, na abordagem tradicional (YOSHIMA, 2007). Também é

responsável por proteger o time de interferências externas, facilitar a

comunicação e colaboração dentro do time e eliminar o quanto antes os

impedimentos, garantir o cumprimento dos prazos, acompanhar o

andamento da sprint, controlar o status das atividades, divulgando para

conhecimento de todo o time.

No Scrum, existem dois conceitos importantes: o product backlog e o sprint

backlog. O product backlog nada mais é que a lista das tarefas que foram coletadas junto

aos gestores e usuários. Ela representa todas as necessidades apontadas pelos clientes,

ordenadas por prioridades. O product owner é o responsável por definir a ordem de

priorização do product backlog, considerando o que irá agregar um maior valor ao

produto, o que terá maior impacto positivo para os usuários ou para cumprir mudanças na

legislação. Ele não precisa estar completo no início do projeto e pode mudar durante o

22

desenvolvimento do projeto. Por isso, a ordem de priorização deve ser refeita antes de

cada sprint. Para Schwaber (2002), o product backlog é a prática responsável pelo

armazenamento e gerenciamento dos requisitos coletados. O sprint backlog é a lista de

tarefas que o scrum team se compromete a realizar durante o sprint. O sprint backlog é

um subconjunto do product backlog. O time determina a quantidade de itens que serão

extraídos do product backlog, com base na ordem de prioridade e na capacidade da

equipe de realizar a execução das tarefas dentro do sprint.

O progresso de um sprint é calculado diariamente, com o scrum master

monitorando quais tarefas são concluídas e quais ainda estão pendentes. O resultado

desse cálculo é apresentado em um gráfico chamado sprint burndown chart. A linha azul

do gráfico da Figura 3 representa esse cálculo. À medida que o desenvolvimento ocorre, a

linha azul sofre alteração, com a diminuição do valor do esforço necessário para

conclusão do sprint. O eixo horizontal representa os dias do sprint e o vertical indica o

esforço total para concluir todas as tarefas da sprint. O esforço de um sprint pode ser

indicado em horas ou em pontos a serem determinados pelo time. Uma linha diagonal é

traçada do valor máximo até o valor zero do eixo vertical e do primeiro dia até o último dia

do sprint. Essa diagonal é representada pela linha cinza clara na Figura 3. Essa linha

serve para indicar se o trabalho está adiantado ou atrasado. Se a linha azul estiver acima

da linha cinza, significa que o desenvolvimento está atrasado e necessita que seja

tomada alguma atitude para o sucesso do sprint. O sprint burndown chart deve estar

visível para que o time possa acompanhar o andamento do sprint.

23

Figura 3 - Sprint burndown chart

Fonte: Autoria própria (2016)

Outra ferramenta importante para o acompanhamento do sprint é o scrum task

board, ou somente scrum board. O sprint backlog pode ser disponibilizado para o time

colocando-o em um scrum board. O scrum board tanto pode ser físico como virtual. O

time deve atualizar o scrum board constantemente, tão logo algum item seja concluído.

Ele exibe todos os itens que deverão ser executados durante o sprint. O scrum board

deve estar visível, a qualquer momento, para todo o time poder acompanhar o que já foi

concluído e o que está pendente no sprint. Cada linha do scrum board representa um item

do sprint backlog, ou uma user story, ou ainda uma tarefa. Cada user story é subdividida

em task cards, ou atividades, para facilitar a execução da user story e possibilitar que

mais de um desenvolvedor trabalhe na mesma user story. O scrum board dá uma visão

geral do sprint com relação ao status das atividades.

O scrum board é composto pelas seguintes colunas:

● To Do (A Fazer): coluna na qual são colocadas todas as atividades que não

foram iniciadas. Todas as atividades são posicionadas nessa coluna no

início do sprint. Outros nomes para essa coluna são: not started, planned,

backlog.

● Doing (Fazendo): coluna das atividades que foram iniciadas, mas não

concluídas. O desenvolvedor retira a atividade da coluna to do e coloca na

24

coluna doing no momento que for iniciar a atividade. Outros nomes para

essa coluna são: started, in process, in progress.

● Done (Feito): colunas das atividades que já foram concluídas. Outros nomes

para essa coluna são: completed, finished.

É possível encontrar scrum boards com variações que adicionam colunas para

atividades em teste (testing) e para atividades que estão em impedimento (to verify), isto

é, que não é possível o seu desenvolvimento. O scrum master deve eliminar o

impedimento o quanto antes, para que a conclusão do sprint não seja prejudicada. A

Figura 4 mostra um exemplo de um scrum task board.

Figura 4 - Scrum task board

Fonte: JUNIOR (2017)

O método possui algumas reuniões, que acontecem durante cada ciclo de vida do

sprint. Esses eventos são chamados de cerimônias: sprint planning meeting, daily scrum

meeting, sprint review meeting e sprint retrospective meeting.

A sprint planning meeting é uma reunião dividida em duas partes, cada uma delas

com um time-box de 4 horas. Na primeira parte, o scrum master e o product owner se

reúnem para analisar o product backlog e definir a ordem prioridade, sempre observando

o que agrega mais valor para o projeto. Na segunda parte, participam o scrum master, o

product owner e o scrum team com objetivo de definir o sprint backlog. Durante a reunião,

o product owner apresenta as funcionalidades de maior prioridade para a equipe. A

equipe faz perguntas, para que se possa estimar o esforço para a execução de cada

25

funcionalidade. Levando-se em consideração o tempo do sprint e capacidade da equipe,

são escolhidas as funcionalidades que farão parte do sprint backlog. O restante dos itens

do product backlog ficarão para as próximas sprints. O time é quem decide quanto eles

podem se comprometer a entregar ao final da sprint.

Uma das técnicas utilizadas para determinar a estimativa de esforço de cada

funcionalidade é o planning poker. Segundo Cohn (2006), o planning poker possibilita

estimativa em grupo em forma de um jogo. O jogo é baseado no consenso de todos os

participantes. Cada participante deve ter um conjunto de cartas, que chamamos de

planning poker cards, com os valores 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 e infinito, que são

as estimativas válidas. O 0 significa que não há nada a ser feito e infinito, que não se

consegue estimar. Os valores podem ser em story points, dias ou outra unidade. Deve ser

definida a estimativa de uma funcionalidade base para que todos possam estimar com a

mesma referência. O planning poker é jogado para cada item do product backlog. Após

apresentada a funcionalidade, os participantes tiram dúvidas, caso existam. Após a

funcionalidade esteja totalmente entendida por todos, cada participante seleciona uma

carta que representa sua estimativa. Todos revelam sua carta ao mesmo tempo. Se todos

selecionaram o mesmo valor, a estimativa está definida para a funcionalidade. Caso

contrário, os participantes com a estimativa mais alta e a mais baixa devem compartilhar

suas razões. Com base nessas explicações e após nova discussão, todos selecionam sua

carta e, novamente, são reveladas ao mesmo tempo. Esse processo é repetido até que

um consenso seja alcançado, ou até que os participantes cheguem a conclusão de que a

estimativa de um item particular necessite ser adiado, para que informações adicionais

sejam coletadas para ajudar na estimativa.

A cada dia da sprint, acontece a daily scrum meetings. Ela é realizada no mesmo

local e na mesma hora do dia e não devem passar de 15 minutos. Todos os membros da

equipe devem estar presentes e participar. Outras pessoas podem estar presentes, mas

apenas como ouvintes. A daily scrum meeting não deve ser usada para resolução de

problemas. Problemas devem ser tratados imediatamente após a reunião com o grupo

relevante. Durante a reunião, cada membro deve responder às seguintes questões:

● O que fez ontem?

● O que fará hoje?

● Existe algum impedimento?

26

É o momento em que a equipe tem conhecimento do que foi feito e o que falta fazer.

Declarando o que vai fazer, cada membro se compromete com o time em realizá-lo.

Qualquer impedimento relatado se torna responsabilidade do scrum master resolvê-lo o

quanto antes. Se ele próprio não conseguir resolver, ele tem a responsabilidade de

encaminhar para quem possa resolver.

Cada sprint deve resultar em uma entrega de um produto ou parte dele. Isso

significa que ao final de cada sprint, o time produziu um "pedaço" do sistema codificado,

testado e pronto para ser usado. Ao final de cada sprint é realizada a sprint review

meeting, onde o time apresenta o que conseguiu realizar durante o sprint. A reunião é

intencionalmente informal, com regras que proíbem o uso de ferramentas de

apresentação e permitindo não mais que 2 horas de preparação. Participantes dessa

reunião incluem o scrum master, o product owner, o scrum team e clientes. Durante o

sprint review meeting, é feita uma avaliação se os objetivos definidos na sprint planning

meeting foram atingidos.

O sprint se encerra com a sprint retrospective meeting. É o momento para o time

identificar o que funcionou e o que precisa ser melhorado. O scrum master e o product

owner também devem participar. Uma forma de conduzir essa reunião uma sprint

retrospective meeting é uma reunião do tipo "comece-pare-continue". Usando essa

abordagem cada membro é perguntado para identificar coisas específicas que o time

deveria:

● Começar a fazer.

● Parar de fazer.

● Continuar fazendo.

A próxima sprint retrospective meeting se iniciará revisando os pontos levantados na

última sprint retrospective meeting. A Figura 5 apresenta os eventos de um sprint

completo.

27

Figura 5 - Ciclo de vida do Scrum

Fonte: ACADÊMICOS (2017)

O ciclo de vida do Scrum, representado na Figura 5, pode ser resumido como:

● O product owner prioriza a lista de demandas (product backlog).

● Na sprint planning meeting, o time retira algumas demandas do topo da lista

(sprint backlog).

● Durante o tempo definido (sprint) para completar o trabalho, o time se reúne

diariamente para avaliar o progresso (daily meeting).

● O scrum master mantém o time focado nos objetivos durante todo o tempo.

● No final do sprint, o resultado deve ser algo pronto para entregar ao cliente.

● O sprint termina com a sprint review e sprint retrospective meetings.

● No início do próximo sprint, o time retira mais um conjunto do product

backlog e começa o trabalho novamente.

O ciclo se repete até que não existam mais demandas no product backlog, os

recursos financeiros tenham se esgotado ou uma data limite tenha chegado. Qualquer

que seja a situação que marque o final dos trabalhos, o Scrum garante que o maior valor

agregado ao produto final tenha sido entregue.

No SIGRH, o tempo para cada sprint é definido em 4 semanas. O product owner

participa das daily meetings duas vezes por semana e ajuda a resolver impedimentos em

28

relação a regras de negócio. O product backlog do SIGRH está em constante mudança,

com novas demandas tanto da UFRN, como das instituições cooperadas, e, portanto,

precisa ser priorizado a cada sprint.

2.2 DESIGN PARTICIPATIVO

O Design Participativo (DP) é utilizado para projetar interfaces interativas e

sistemas com a participação dos usuários, com o objetivo de entender suas necessidades

e as funcionalidades desejáveis, a fim de se construir um sistema computacional

(PREECE; ROGERS; SHARP, 2011). O DP visa coletar, analisar e projetar um sistema

em conjunto com várias pessoas. Usuários, clientes, funcionários, desenvolvedores e

outros interessados podem ser participantes de uma metodologia de desenvolvimento

utilizando DP, enquanto outras metodologias restringem-se à participação de profissionais

especializados (CAMARGO; FAZANI, 2014). Esses usuários são considerados como

parte da equipe de design e stakeholders do sistema e devem ser convidados a contribuir

com opiniões e sugestões (NIELSEN, 1993). O uso do DP é recomendado quando os

usuários estão disponíveis para participarem no processo de construção do sistema. Para

Baranauskas & Mantoan (2001), o design participativo se caracteriza pelo envolvimento

dos usuários finais do sistema ativamente durante todo o processo de design e

desenvolvimento, e não apenas ao processo de testes de protótipos ou avaliação.

A participação ativa dos usuários que irão utilizar o sistema posteriormente durante

todo o processo de desenvolvimento faz com que aumente o seu interesse no sucesso do

sistema. Ninguém melhor que os usuários finais do sistema para indicar quais são as

prioridades e funções são úteis para a prática do seu dia-a-dia. O conhecimento adquirido

sobre o funcionamento do sistema facilita a implantação, já que diminui o impacto das

mudanças que se enfrenta ao se adotar um sistema computacional no ambiente de

trabalho. De acordo com Bonacin (2004), "o interesse direto do trabalhador na introdução

de novas tecnologias e seu impacto (positivo ou negativo) no ambiente de trabalho é

requisito básico para a aplicação do Design Participativo". Müller, Haslwanter e Dayton

(1997) destacam as seguintes motivações para o design participativo:

● Democracia;

29

● Eficiência, perícia e qualidade;

● Confiança e aceitação interna.

Figura 6 - Design participativo

Fonte: CYEXPERIENCE (2017)

Várias técnicas podem ser adotadas no design participativo. A Figura 6 mostra

usuários do sistema participando do processo de desenvolvimento. A seguir, são

apresentadas algumas técnicas, que podem ser consideradas como participativas:

● Protótipos: representações visuais das telas do sistema. Podem ser em

papel ou virtual.

● Card-sorting: técnica usada para ajudar no design da arquitetura da

informação em um sistema ou site.

● Brainstorming: técnica em que várias ideias são apresentadas

espontaneamente, com o objetivo de encontrar uma solução para um

problema específico.

● Braindraw: tipo de brainstorming visual em que são apresentadas ideias

sobre telas, ícones ou outros conceitos visuais.

● Oficinas: reuniões presenciais com os interessados com o objetivo de

detalhar os requisitos do projeto.

● Análise da experiência do usuário: técnica de observações dos atributos de

uso do sistema, além dos aspectos cognitivos, socioculturais e afetivos.

30

No processo implantado na equipe do SIGRH, o DP foi usado para a criação da

planilha de acompanhamento do processo de desenvolvimento de sistemas. Os usuários

da ferramenta, isto é, os membros do scrum team, estavam disponíveis para contribuir

com ideias e sugestões sobre quais funcionalidades deveriam ser incluídas. Técnicas de

DP, como braindraw e oficinas, foram aplicadas com o objetivo de coletar os requisitos

para a ferramenta. As daily meetings e, principalmente, as retrospective meetings

funcionaram como oficinas quando eram apresentadas e discutidas as propostas de

melhorias para a ferramenta. Até mesmo detalhes sobre implementação eram discutidos

com a participação de todos os usuários. Em algumas situações foram apresentadas

opções de elementos visuais a serem utilizadas na planilha (braindraw) para apreciação e

seleção pelos usuários, como, por exemplo, os ícones para representar os status das

atividades.

2.3 PESQUISA-AÇÃO

O pesquisador esteve envolvido em todas as etapas deste trabalho, inserido no

ambiente da pesquisa desde a sua concepção, participando do processo de implantação

do scrum, como scrum master e como desenvolvedor da planilha de acompanhamento do

processo de desenvolvimento de sistemas, objeto de estudo do presente trabalho. Para

este trabalho foi realizada uma pesquisa-ação. Segundo Thiollent (1988), a pesquisa-ação

é um tipo de pesquisa social com base empírica, em que os pesquisadores e os

participantes representativos da situação ou do problema estão envolvidos de modo

cooperativo ou participativo.

Tripp (2005) define pesquisa-ação "como toda tentativa continuada, sistemática e

empiricamente fundamentada de aprimorar a prática". Segundo Filippo (2011), a

pesquisa-ação pode ser utilizada em uma pesquisa na qual a ação é o ponto central e o

pesquisador faz parte do ambiente da pesquisa. O pesquisador pode aplicar seus

conhecimentos para resolver um problema específico ou ter sido chamado por uma

instituição para resolver um problema conhecido de forma colaborativa.

Ciclos de pesquisa são realizados durante a pesquisa-ação (DICK, 1993). A cada

ciclo são adquiridos novos conhecimentos. Existem várias definições para os ciclos de

31

pesquisa-ação. McKay (2001) define que um ciclo de pesquisa-ação é composto por duas

etapas: refletir (diagnóstico) e agir (terapêutico) sobre o problema.

No capítulo a seguir será abordada a aplicação do método utilizado neste trabalho.

32

3 METODOLOGIA APLICADA

A pesquisa-ação realizada nesse trabalho teve como objetivo resolver um

problema real e, portanto, pode ser classificada como de natureza aplicada. Além de

procurar definir um procedimento para o acompanhamento do desenvolvimento de

sistemas, existia a necessidade de encontrar uma solução para o espaço reduzido do

ambiente de trabalho, e a falta de um local adequado para fixar o scrum board e o

burndown chart, ferramentas básicas utilizadas no Scrum. Em relação aos seus objetivos,

classificamos essa pesquisa como descritiva, pois procura identificar, registrar e analisar

as características do objeto de estudo e estabelecer relações entre suas variáveis. Este

tipo de pesquisa procura descrever os fatos e fenômenos de uma determinada realidade.

A pesquisa-ação foi realizada na SINFO, unidade organizacional da UFRN, com a

participação das equipes de desenvolvimento dos sistemas SIGRH. O trabalho se iniciou

simultaneamente com a implantação da metodologia ágil de desenvolvimento Scrum no

processo de evolução do SIGRH. A Figura 7 apresenta as etapas do método utilizado

neste trabalho.

Figura 7 - Etapas do método utilizado neste trabalho


As etapas do método são:

● Implantação do Scrum no processo de desenvolvimento do SIGRH.

Realização do primeiro sprint com o scrum board físico;

● Definição da ferramenta de apoio para acompanhamento do processo de

desenvolvimento do SIGRH. A ferramenta Google Sheets foi escolhida por

ser online, colaborativa e gratuita;

33

● Diagnosticar - nesta etapa são identificados e analisados os problemas que

motivam melhorias no processo. Os problemas podem ser levantados por

qualquer membro da equipe. A maioria dos problemas e sugestões são

reportados durante a retrospective meeting, que é o momento da avaliação

do sprint. O pesquisador era responsável pelas anotações dos problemas e

sugestões;

● Planejar ação - nesta etapa são planejadas as ações para resolver os

problemas indicados na etapa anterior. Toda a equipe pode contribuir nesta

etapa, mas cabe ao pesquisador alinhar os objetivos que se quer alcançar,

utilizar os conhecimentos teóricos estudados e trocar ideias com os

participantes sobre possíveis soluções;

● Atuar - nesta etapa são executadas as ações planejadas anteriormente.

Com base nos objetivos e nas possíveis soluções, o pesquisador decide

qual solução implementar;

● Avaliar - nesta etapa é feita uma avaliação sobre o resultado das ações,

visando identificar até que ponto os problemas foram resolvidos ou se as

sugestões foram implementadas ou não, nesse caso, justificando o motivo

da não implementação.

As etapas Diagnosticar, Planejar ação, Atuar e Avaliar ocorrem em ciclos até a

finalização da última iteração. Apesar de um processo de desenvolvimento de sistemas

como o Scrum ter sempre algo a ajustar e melhorar e, portanto, não ter um fim,

consideraremos como conclusão da pesquisa-ação o final da sexta iteração e a

construção da planilha template.

34

4 DESCRIÇÃO DO PROCESSO DE IMPLANTAÇÃO DO MÉTODO

Como foi a primeira experiência da equipe com o Scrum, não tínhamos uma

referência para saber quantos pontos a equipe conseguiria entregar no prazo de 1 mês

definido para o sprint. Então, o scrum master sugeriu que o custo/esforço para o

desenvolvimento de uma funcionalidade simples de cadastro, com um campo código e um

campo descrição equivaleria a 3 pontos, o que foi aceito pela equipe. O desenvolvimento

envolve atividades de especificação, implementação e validação da funcionalidade. Com

isso, ficou estabelecido que, caso a tarefa seja mais simples que uma funcionalidade

simples, o esforço para desenvolvê-la é menor que 3 pontos. Caso seja mais complexa, o

esforço será maior que 3 pontos.

A equipe de desenvolvimento do SIGAA usou uma planilha para gerenciar as

tarefas e atividades do sprint, registrando as horas que cada membro da equipe levava

para concluí-las. Com base nessa planilha, a equipe do SIGRH começou a desenvolver a

sua própria planilha de acompanhamento.

Inicialmente, o acompanhamento dos primeiros sprints foi feito com o scrum board

físico na janela de vidro por trás da bancada dos computadores. Além disso, só era

possível acomodar apenas 12 user stories por sprint. Também foi utilizado o burndown

chart, já que não estava definido como medir a evolução das atividades. Logo se

percebeu que, em razão do tamanho reduzido da sala, o acesso ao scrum board para as

atualizações frequentes das atividades do sprint não era muito prático. Então, surgiu a

ideia de procurar uma solução informatizada, em que fosse possível o acompanhamento

online dos sprints e que permitisse a alimentação dos dados de forma colaborativa. A

Figura 8 mostra o quadro Scrum utilizado no primeiro sprint do SIGRH. Outro fator

complicador foi que os Post-its não se sustentavam sobre a superfície lisa do vidro.

35

Figura 8 - Quadro Scrum utilizado no primeiro sprint


4.1 PRIMEIRA ITERAÇÃO

A ferramenta Google Sheets (planilha) foi escolhida por ser gratuita, online e de

colaboração, que eram requisitos para a solução proposta. Para o primeiro sprint, a

planilha foi utilizada apenas para listar o sprint backlog e o custo associado a cada item,

conforme mostrado na Figura 9. A lista continha apenas as tarefas do sprint backlog e seu

custo associado, definido na sprint planning meeting.

Nesse sprint não houve nenhum controle ou acompanhamento do progresso do

sprint pela planilha. Tudo foi feito com o uso do scrum board físico.

36

Figura 9 - Planilha com o sprint backlog utilizada no primeiro sprint


37

4.2 SEGUNDA ITERAÇÃO

Na retrospective meeting do primeiro sprint, foi reportada pela equipe a dificuldade

de manter o scrum board físico atualizado e a necessidade de dividir as user stories em

atividades menores, para facilitar o desenvolvimento e o acompanhamento da evolução

do sprint. Essa divisão possibilitaria que mais de um desenvolvedor pudesse trabalhar na

mesma user story. A Figura 10 exibe parte do conteúdo da aba Atividades utilizada no

segundo sprint e a Figura 11 explica cada parte da aba.

Nessa aba foram utilizadas cores para diferenciar os tipos das atividades. A cor de

fundo das células das atividades de requisitos é vermelha, a cor das células das

atividades de desenvolvimento é verde e a de testes é amarela. O objetivo era facilitar a

identificação de quais atividades cada equipe deveria trabalhar. Foi adicionada uma

coluna para que fosse associado o percentual correspondente à atividade em relação ao

esforço para a conclusão da user story. Também foram adicionadas colunas que

representam os dias do sprint. Cada membro deve preencher a quantidade de horas

trabalhadas em uma determinada atividade. Este preenchimento é feito diariamente e, ao

final do desenvolvimento, a atividade é sinalizada com o símbolo "-" no dia seguinte à

conclusão da mesma. Cada tarefa tem uma linha com o somatório de horas registradas

por dia.

38

Figura 10 - Aba Atividades do segundo sprint


39

Figura 11 – Detalhes da aba Atividades do segundo sprint


Dias do sprint Cores diferentes para

diferenciar tipos de atividades

Horas trabalhadas

Percentual da atividade em

relação ao custo da tarefa

Total de horas

trabalhadas no dia

Indica a conclusão da

atividade

40

Figura 12 - Aba Consumo do segundo sprint


Dias do sprint Custo do sprint Média = Custo (65) /

Quantidade de dias

(30)

Pontos restantes

do sprint por dia

Pontos restantes

da média por dia

41

A coluna % indica o percentual de cada atividade em relação ao custo total da

tarefa. Essa informação é utilizada para a atualização do burndown chart. A fórmula para

o cálculo do custo de uma atividade é:

A aba Consumo, mostrada na Figura 12, foi então criada para calcular o custo restante

para a conclusão das atividades em cada dia do sprint. Para identificar se uma atividade

foi concluída em um determinado dia, a célula da coluna do dia seguinte, na aba

Atividades, deve conter o símbolo "-". A fórmula abaixo realiza essa verificação, em que o

valor do custo restante de um determinado dia (X) é igual ao valor restante do dia anterior

(Y), menos a soma dos custos de cada atividade que tem o símbolo "-" na coluna do dia

seguinte, isto é, na coluna J da aba Atividades. A coluna J representa o dia seguinte ao

dia que se quer calcular o custo e a coluna AH contém o custo das atividades.

Com os valores calculados da aba Consumo, foi criada a aba Dashboard para a

exibição dos burndown charts, representada na Figura 13. A linha vermelha representa o

consumo diário necessário para que o custo restante no último dia do sprint seja zero, isto

é, a média. A linha azul representa o consumo real durante o sprint. Enquanto a Figura 14

mostra um gráfico com o tempo trabalhado e o custo de cada tarefa, que servirá de

parâmetro para a estimativa de custo nos próximos sprints.

X=Y-SUMIF(Atividades!J$1:J$184, "-", Atividades!AH$1:AH$184)

Custo da atividade = custo da user story * percentual da atividade / 100

42

Figura 13 - Aba Dashboard do segundo sprint


43

Figura 14 - Gráfico de Custo x Horas por tarefa do segundo sprint


44

4.3 TERCEIRA ITERAÇÃO

O registro das horas foi importante para saber quanto tempo cada atividade e,

consequentemente, cada user story leva para ser concluída. Na retrospective meeting do

segundo sprint, o scrum master relatou que gostaria de saber quanto cada equipe demora

para concluir suas atividade durante o sprint. No time, existem três tipos de perfis:

analistas de requisitos, desenvolvedores e testadores. Então, para atender a essa

necessidade, foi adicionada uma coluna para identificar o tipo da atividade, como

mostrado na Figura 15. O tipo “Des” significa que a atividade é de desenvolvimento,

enquanto que “Req” indica a atividade como sendo de requisitos e, por fim, “Tes”, de

testes.

Durante as daily meetings, os usuários reportaram que o preenchimento manual

das cores não era uma atividade agradável. Então, para facilitar o preenchimento das

cores das atividades, foi adicionada uma coluna para indicar o tipo da atividade. Quando o

usuário digita o tipo da atividade a célula muda de cor automaticamente, utilizando o

recurso conditional formatting do Google Sheets. Além disso, uma coluna para indicar a

situação da atividade foi adicionada. O símbolo ✓ com fundo verde significa que a

atividade foi finalizada e o símbolo ✖ indica que a atividade está pendente. A célula do

cabeçalho de cada tarefa da coluna ✓ exibe o somatório dos custos das atividades

finalizadas. Caso esse somatório seja igual ao custo da tarefa, o que significa que todas

as atividades estão finalizadas, a célula ficará verde, indicando que a tarefa foi finalizada.

Caso contrário, a cor da célula será vermelha, indicando que a tarefa possui atividades

pendentes. Foi adicionada uma coluna com a data de conclusão da atividade. Essa data é

preenchida automaticamente, com base no registro das horas trabalhadas na atividade. O

último dia que possui horas é a data de conclusão da atividade. Além disso, os dias

correspondentes a finais de semana e feriados foram marcados manualmente com uma

cor de fundo cinza, para que não sejam preenchidos com horas de trabalho. A Figura 16

detalha as alterações descritas acima.

45

Figura 15 - Aba Atividades do terceiro sprint


46

Figura 16 – Detalhes da aba Atividades do terceiro sprint


Tipo da atividade

Total de horas

trabalhadas na atividade

Dia da conclusão

da atividade

Indica que a tarefa

foi concluída

Indica que a tarefa possui

atividades pendentes

Status da atividade Fim de semana e

feriado

Cabeçalho

47

4.4 QUARTA ITERAÇÃO

Ainda em relação ao registro de horas, o scrum master sugeriu, durante a

retrospective meeting do terceiro sprint, a inclusão da informação do responsável pela

atividade, possibilitando, assim, saber quanto cada membro da equipe levou trabalhando

durante o sprint. Para isso, foi incluída a coluna responsável pela atividade para indicar

quem está trabalhando na atividade. O time questionou se o burndown chart com 30 dias

não poderia confundir o time quanto ao custo restante do sprint, já que, na verdade,

apenas 21 ou 22 dias são utilizados. Então, a aba Consumo foi ajustada para calcular o

custo restante, considerando apenas os dias úteis. A Figura 17 mostra a coluna

responsável com as opções de preenchimento válidas, com o nome de todos os membros

do time. Também foi adicionada restrição de preenchimento para a coluna tipo da

atividade. Os valores válidos são: “Des”, “Req” e “Tes”. A Figura 18 mostra os dados da

aba Consumo para o burndown chart de 30 dias e a Figura 19, os dados com apenas os

dias úteis. Com esse ajuste, percebeu-se que o custo médio diário no gráfico de 30 dias

era quase 30% menor que no gráfico de dias úteis. A Figura 20 mostra o cálculo do custo

restante para cada tipo de atividade. As Figuras 21 e 22 mostram, respectivamente, o

burndown chart de 30 dias e o de dias úteis. É possível perceber que, no gráfico de 30

dias, existem algumas partes horizontais, que são os fins de semana, onde não foram

registradas horas de trabalho. A aba Dashboard também exibe um burndown chart por

tarefa, isto é, o consumo só vai ser percebido quando todas as atividades da tarefa forem

finalizadas. A Figura 23 mostra o burndown chart de tarefas. A Figura 24 mostra um

burndown chart por perfil de equipe. Cada equipe tem o custo restante calculado com

base no tipo das atividades. A Figura 25 mostra um gráfico relacionando o número de

atividades com perfil de equipe. O gráfico exibe o número de atividades, diferenciando-os

por status. Uma atividade pode ter um dos três status a seguir: “A fazer”, quando a

atividade não possui responsável; “Fazendo”, quando a atividade possui um responsável,

mas ainda não foi finalizada; e “Feito”, quando a atividade foi finalizada. A Figura 26

mostra um gráfico com a quantidade de horas trabalhadas no sprint por cada membro do

time. Esse gráfico ajuda o scrum máster a identificar quais membros estão produzindo

dentro do esperado e quais precisam de uma atenção maior.

48

Figura 17 - Coluna Responsável na aba Atividades do quarto sprint


49

Figura 18 - Cálculo dos custos considerando 30 dias


Custo médio para conclusão das

atividades em 30 dias

50

Figura 19 - Cálculo dos custos considerando apenas dias úteis


Custo médio para conclusão

das atividades considerando

apenas os dias úteis

51

Figura 20 - Cálculos dos custos por perfil


Custo das atividades de

cada perfil

Des = Desenvolvimento

Req = Requisitos

Tes = Testes

52

Figura 21 - Burndown chart de 30 dias


53

Figura 22 - Burndown chart considerando apenas dias úteis


54

Figura 23 – Burndown chart por tarefa


55

Figura 24 - Burndown chart por perfil de equipe


56

Figura 25 - Gráfico Atividades x Equipe


57

Figura 26 - Gráfico Horas x Membro


58

Desde a retrospective meeting do primeiro sprint foi identificada a dificuldade de

atualização e uso do scrum board físico. No quarto sprint, foi criada a aba Quadro, na qual

é exibido um scrum board virtual. A partir desse momento, deixou de ser utilizado o scrum

board físico. A Figura 27 mostra o scrum board virtual utilizado no quarto sprint. A

atualização do scrum board acontece automaticamente, de acordo com o status da

atividade, definido na aba Atividades. A célula correspondente à atividade segue a mesma

ordem das colunas em cada status do quadro, que vai de 1 a 5. Caso uma user story

possua mais de cinco atividades, o que é comum de acontecer, a ordem das atividades

seguintes continua na linha abaixo. No scrum board virtual, as células que representam

uma atividade exibem o tipo da atividade e sua cor correspondente. A Figura 28 mostra a

correspondência entre as atividades na aba Atividades e no scrum board. Também foi

criada

59

Figura 27 - Aba Quadro do quarto sprint


60

Figura 28 - Relação entre as atividades na aba Atividades e no scrum board


61

4.5 QUINTA ITERAÇÃO

Na scrum planning meeting do quinto sprint, foram apresentadas algumas

modificações na planilha. Todas as modificações foram sobre como a informação é

exibida. Foram retirados os finais de semana da aba Atividades, como mostrado na Figura

29. Na aba Quadro, as células referentes às atividades passaram a exibirem apenas a cor

correspondente ao tipo da atividade. O número e o título da tarefa saíram de uma célula à

esquerda para uma linha acima. A ideia foi tornar o scrum board mais compacto. A linha

com o número e o título da tarefa fica verde automaticamente quando todas as atividades

da tarefa são finalizadas e as linhas correspondentes às atividades são escondidas. As

Figuras 30 e 31 mostram as modificações realizadas no scrum board no quinto sprint.

Para facilitar o controle do scrum board, foi criada a aba Sprint Backlog, que armazena

informações sobre as atividades das tarefas, como mostrado na Figura 32. Os burndown

charts de atividades e de tarefas foram consolidados em apenas um gráfico, como

mostrado na Figura 33.

Na retrospective meeting do quarto sprint, o time questionou a utilidade do gráfico

Horas x Membro, pois alguns membros do time trabalhavam apenas meio período e em

tarefas de diferentes complexidades. O time decidiu que ele fosse retirado da aba

Dashboard, pois poderia causar alguma desmotivação. O time aceitou que o scrum

master poderia continuar monitorando as horas trabalhadas por membro, mas que

qualquer problema em relação à produtividade fosse trabalhada individualmente.

62

Figura 29 - Aba Atividades do quinto sprint


Apenas dias úteis

63

Figura 30 - Aba Quadro do quinto sprint


64

Figura 31 - Aba Quadro do quinto sprint exibindo tarefas finalizadas


65

Figura 32 - Aba Sprint Backlog do quinto sprint


66

Figura 33 - Aba Dashboard do quinto sprint


67

4.6 SEXTA ITERAÇÃO

O tempo gasto com correção de erros pode ter um impacto significativo no tempo

total de trabalho do sprint. A equipe questionou se esse tempo deveria ser levado em

consideração para a estimativa de custo de uma tarefa. Para tentar mensurar quanto se

leva corrigindo erros em um sprint, foi criado o tipo de atividade “Err” e adicionada uma

atividade “Corrigir erros”, do tipo “Err”, em cada tarefa, para o registro das horas

trabalhadas na correção dos erros. Além disso, para a validação das tarefas pela equipe

de requisitos, foi criado o tipo de atividade “Val”. Para facilitar a comunicação entre as

equipes, foi criado um novo status para indicar a existência de erros na tarefa: (erro).

A atividade “Corrigir erros”, inicialmente, fica escondida e é exibida automaticamente

quando alguma atividade da tarefa é marcada com o status “erro”. Na retrospective

meeting do sprint passado, foi informada a dificuldade em identificar células com

comentários sobre as tarefas. Para suprir essa dificuldade, foi adicionada uma coluna

para indicar a existência de comentários, para tal, o usuário seleciona a opção na

atividade. A Figura 34 detalha as melhorias descritas acima na aba Atividades. O

burndown chart foi adaptado para exibir as atividades de erro e de validação, como

mostrado na Figura 35.

Em uma retrospective meeting da equipe do SIPAC, foi reportada a situação em

que dois desenvolvedores trabalharam em uma mesma atividade. Mas, se o responsável

for alterado, não é possível saber quem era o responsável anterior e quantas horas cada

um trabalhou na atividade. Para dar suporte à mudança de responsável, e não perder a

informação de quem trabalhou na atividade anteriormente, foi utilizado um script na

planilha para adicionar automaticamente uma nota à célula com o nome do responsável,

assim que o registro das horas trabalhadas for realizado. Também foram retirados os dias

de feriados da aba Atividades. A Figura 36 mostra os ajustes citados acima. A aba Sprint

foi criada para armazenar informações gerais sobre o sprint, por exemplo, a data de início

e fim do sprint, a lista de feriados, a quantidade de atividades e data atual. A informação

da data fim na aba Sprint é utilizada para destacar o último dia do sprint na aba

Atividades. A Figura 37 mostra os dados da aba Sprint.

68

Na aba Quadro, o scrum board, passou a exibir o nome do responsável pela

atividade, tornando mais fácil a visualização de quais atividades o time está trabalhando

no momento. As atividades da coluna “A Fazer” exibem apenas um “.”, já que não têm

responsável associado. Também foi adicionada uma coluna para exibir as atividades de

correção de erros. A Figura 38 mostra o scrum board do sexto sprint. A Figura 39 mostra

detalhadamente o scrum board do sexto sprint. A Figura 40 mostra o gráfico Pontos x

Tipo de atividade incluindo as tarefas com erro. Além da cor verde, adicionada no sprint

anterior, que indica a finalização da tarefa, foi adicionada a cor cinza para indicar o

cancelamento da tarefa no scrum board. Uma tarefa pode ser cancelada por falta de

tempo para concluí-la dentro do sprint ou por algum impedimento. Para isso, foi

adicionada uma coluna na aba Sprint Backlog para indicar se a tarefa está ativa no sprint.

A Figura 41 mostra o scrum board com uma tarefa cancelada e a Figura 42 mostra a aba

Sprint Backlog com a coluna “Ativa?”.

69

Figura 34 - Aba Atividades do sexto sprint


Diferentes status:

Trabalhando na atividade

Atividade concluída

Atividade com erro

Atividade de correção de

erros

Coluna indicando a

existência de comentários

na atividade

Atividades de validação

70

Figura 35 - Burndown chart exibindo dados das atividades de validação


71

Figura 36 - Aba Atividades do sexto sprint


Indicação do último dia

do sprint

Células com nota sobre

quem registrou as horas

Dias do sprint retirando

feriados

72

Figura 37 - Aba Sprint do sexto sprint


Registro de

feriados

Contabilização de horas

trabalhadas no sprint

Dados gerais do sprint

Data atual

73

Figura 38 - Aba Quadro do sexto sprint


74

Figura 39 - Detalhamento do scrum board


Nome do responsável

pela atividade

Coluna das atividades

com erro

Atividades sem

responsável

Atividades de validação

75

Figura 40 - Gráfico Pontos x Tipo de atividade do sexto sprint


76

Figura 41 - Aba Quadro do sexto sprint


Cores para indicar o

status da tarefa

Cor verde: indica que todas as

atividades da tarefa foram finalizadas

Cor cinza: indica que a tarefa foi retirada

do sprint

77

Figura 42 - Aba Sprint Backlog do sexto sprint


Indicação se a tarefa

está ativa no sprint

78

4.7 PLANILHA TEMPLATE

A cada sprint, é necessário criar uma nova planilha a partir de uma existente,

limpando os dados do sprint anterior. Para facilitar esse processo, foi desenvolvida uma

planilha que serve como modelo para a criação das novas planilhas, isto é, uma planilha

template. A planilha template contém todas as fórmulas e formatações necessárias para

os cálculos e geração dos gráficos do sprint. Com isso, qualquer adaptação de melhoria

da planilha passou a ser executada apenas na planilha template, para ser adotada nos

sprints futuros. A seguir estão apresentadas as abas da planilha template resultante

desse trabalho.

4.7.1 ABA QUADRO

A aba Quadro apresenta um scrum board virtual com todas as tarefas (user stories)

do sprint. Cada linha representa uma tarefa do sprint. Cada tarefa possui atividades que

podem ocupar uma das quatro colunas do scrum board. As colunas representam os

estados que uma atividade pode assumir durante o sprint. São eles: “A Fazer”, “Fazendo”,

“Erro” ou “Feito”. As atividades mudam de coluna de acordo com o seu estado definido na

aba Atividades. Quando se é atribuído um responsável para a atividade, seu nome é

exibido no quadro. Para facilitar a visualização, as linhas do quadro que não possuem

atividades são escondidas automaticamente. Só são exibidas as tarefas ativas. A Figura

43 mostra o conteúdo da aba Quadro da planilha template.

A aba Quadro é apenas para consulta sobre o andamento do Sprint, destacando

visualmente a quantidade de tarefas que ainda não foram iniciadas, que estão em

desenvolvimento e que já foram concluídas. Dessa forma, todo o time tem uma noção de

quanto trabalho ainda falta para a conclusão do sprint.

79

Figura 43 - Aba Quadro da planilha template


80

4.7.2 ABA ATIVIDADES

É na aba Atividades que acontece a maioria das interações dos membros da

equipe durante um sprint. Após a definição das tarefas na sprint planning meeting, o time

precisa detalhar cada tarefa em atividades menores. As equipes de requisitos,

desenvolvimento e testes alteram ou adicionam as atividades, informando o percentual

delas em relação ao esforço para a conclusão da tarefa. O somatório do percentual das

atividades deve ser igual a cem. As informações da tarefa são recuperadas da aba Sprint

Backlog e não devem ser alteradas nessa aba. A cor de fundo das células das atividades

varia de acordo com o tipo da atividade. As atividades de requisitos são vermelha, as de

desenvolvimento são verde, as de testes são amarelas, as de validação são azuis e as de

erro são brancas, mas com a cor da letra em vermelho. Caso precise adicionar outras

atividades, o usuário deve inserir uma linha “em branco” e usar o recurso de copiar e colar

de uma atividade existente da tarefa. Isso deve ser feito para aproveitar as fórmulas e

formatações necessárias para o funcionamento correto da planilha. Os dias do sprint são

preenchidos automaticamente através de script, com base no período cadastrado na aba

Sprint. Durante o sprint, o dia corrente é destacado em cinza para facilitar o registro das

horas pelos usuários.

A aba Atividades ainda apresenta outras colunas. A coluna com o ícone é

utilizada para informar que a atividade possui comentário em alguma de suas células.

Comentários são utilizados para comunicar alguma observação relevante entre membros

do time que trabalham na mesma tarefa ou para o scrum master. A coluna status ( )

indica o estado da atividade. Uma atividade pode ter os seguintes status:

A Figura 44 mostra o conteúdo da aba Atividades da planilha template com as

células das atividades destacadas em diferentes cores.

● Vazio: a atividade não tem responsável e, portanto, não foi iniciada;

● : trabalhando na atividade;

● : atividade contém erros de testes;

● : atividade finalizada.

81

Figura 44 - Aba Atividades da planilha template


82

O status das atividades reflete automaticamente no scrum board na aba Quadro.

Quando o status da atividade for vazio, a célula correspondente à atividade estará na

coluna “A Fazer”; quando o status passar a ser , a atividade será movida para a coluna

“Fazendo”; quando for indicado o status , a atividade passará para a coluna de “Erro”,

e quando for , a atividade será movida para a coluna “Feito”.

Além disso, a aba Atividades contém uma coluna para cada dia do sprint. O time

preenche essas colunas com as horas utilizadas para a execução das atividades. Quando

as horas são registradas, uma nota é cadastrada automaticamente com o responsável

pela atividade. Assim, é possível registrar as horas que cada membro do time que

trabalhou em uma mesma atividade.

4.7.3 ABA DASHBOARD

A aba Dashboard, mostrada nas Figuras 45, 46 e 47, é composta por gráficos que

exibem a situação do progresso do sprint. Os gráficos são atualizados automaticamente,

de acordo com as informações registradas na aba Atividades. Um burndown chart, que

possibilita ao time visualizar se o sprint está atrasado, ou se está trabalhando dentro do

prazo estabelecido. Caso a linha preta, que representa o custo restante das atividades,

estiver acima da linha cinza, que representa o custo restante médio, o sprint está

atrasada. Caso contrário, o sprint está adiantando. Um burndown chart por tipo de

atividade, que divide os pontos com base nos tipos de cada atividade do sprint; e um

gráfico de barras que exibe a quantidade de atividades por status: “A Fazer”, “Fazendo”,

“Erro” e “Feito”.

Esses gráficos ficam disponíveis, para que o time possa consultá-los a qualquer

momento do sprint e para identificar atrasos, a tempo de reagir e para que o scrum master

e product owner possam tomar decisões sobre a retirada ou não de tarefas, para garantir

a conclusão do sprint.

83

Figura 45 - Burndown chart da aba Dashboard da planilha template


84

Figura 46 - Burndown chart da aba Dashboard da planilha template


85

Figura 47 - Gráfico Tipo de atividade x Número de atividades da aba Dashboard da planilha template


86

4.7.4 ABA CONSUMO

A aba Consumo é composta basicamente de fórmulas que contabilizam o consumo

de pontos durante o sprint. Os resultados dos cálculos são utilizados pelos gráficos da

aba Dashboard. Além do consumo dos pontos por atividade, são calculados também o

consumo por tarefa, que contabiliza o consumo apenas quando todas as atividades da

tarefa são concluídas, e por cada equipe. A Figura 48 exibe o conteúdo da aba Consumo

da planilha template. Como todos os dados da aba Consumo estão representados na aba

Dashboard, ela pode ser ocultada.

87

Figura 48 - Aba Consumo da planilha template


88

4.7.5 ABA SPRINT BACKLOG

A aba Sprint Backlog contém a lista de tarefas selecionadas para o sprint. O sprint

backlog é resultado da sprint planning meeting, na qual o time analisa a lista de tarefas e,

com base na sua capacidade de produção, seleciona as que são mais prioritárias para o

product owner e que cabem no sprint, isto é, que o time consegue entregar no período do

sprint. A aba Sprint Backlog é utilizada durante o início de cada sprint. É nessa aba em

que são registrados o número, o título, o módulo e o custo de cada tarefa. Caso o sprint

tenha menos tarefas do que o encontrado na aba, as tarefas “excedentes” devem ser

desativadas através da coluna “Ativa?”. Isso fará com que essas tarefas não sejam

exibidas nas abas Atividades e Quadro. Todas as outras colunas da aba são atualizadas

automaticamente, com base nos dados registrados na aba Atividades. As Figuras 49 e 50

mostram o conteúdo da aba Sprint Backlog da planilha template.

89

Figura 49 - Aba Sprint Backlog da planilha template


90

Figura 50 - Aba Sprint Backlog da planilha template


91

4.7.6 ABA BACKLOG

A aba Backlog lista as tarefas candidatas para o sprint. O product owner ordena as

tarefas com base na prioridade para serem analisadas e estimadas pelo time. A Figura 51

mostra o conteúdo da aba Backlog da planilha template.

Figura 51 - Aba Backlog da planilha template


4.7.7 ABA SPRINT

A aba Sprint contém alguns dados do sprint que são utilizados para automatizar

algumas operações da planilha. As colunas Início e Fim servem para o preenchimento

automático dos cabeçalhos das colunas dos dias do sprint. A coluna Hoje é utilizada para

destacar a coluna correspondente ao dia corrente. A coluna Feriados é utilizada para que

as datas dessas colunas não sejam adicionadas nos cabeçalhos da aba Atividades. A

Figura 52 mostra o conteúdo da aba Sprint da planilha template.

92

Figura 52 - Aba Sprint da planilha template


93

4.7.8 ABA REF

A aba REF contém informações auxiliares para compor as opções de

preenchimento de algumas células da planilha. A coluna responsável contém a lista de

pessoas que poderão trabalhar no sprint, isto é, o time. A coluna TIPO contém as opções

de preenchimento do tipo da atividade. A coluna Status contém as opções de

preenchimento do status da atividade. A Figura 53 exibe o conteúdo da aba REF da

planilha template.

Figura 53 - Aba REF da planilha template


94

5 RESULTADOS

Neste capítulo, apresentamos os resultados da pesquisa-ação, comparando o

processo de desenvolvimento do SIGRH antes e depois da implantação do Scrum e da

planilha de acompanhamento de desenvolvimento de sistemas. Também são enumeradas

as lições aprendidas, que serão úteis para aplicá-las em trabalhos futuros.

A primeira análise realizada foi sobre mudanças no processo de desenvolvimento

com a implantação do Scrum, comparando alguns aspectos importantes no

desenvolvimento de um sistema informatizado. O Quadro 1 mostra essas mudanças.

Quadro 1 - Antes e depois da implantação do Scrum

Item Antes Depois

Responsabilidade pelo projeto O gerente de projetos é o único responsável pelo controle do projeto.

Todos os membros do time tem a responsabilidade sobre projeto, se comprometendo com o seu sucesso.

Gerenciamento de riscos O gerente de projetos é o único responsável pela gerência de riscos.

Todos os membro do time assumem os riscos e encontram soluções em conjunto.

Comunicação com o cliente O gerente de projetos e o analista de requisitos se comunicam com o cliente. Geralmente, apenas em reuniões antes do início do desenvolvimento.

O product owner representa o cliente durante todo o desenvolvimento. A comunicação é diária.

Entregas Não havia um planejamento prévio sobre as datas para as entregas.

As entregas são realizadas mensalmente.

Progresso Não havia forma de visualizar o progresso. A única forma de medir o progresso era quando uma entrega era realizada.

O progresso pode ser visualizado a qualquer momento por todos da equipe.

Revisão do processo Não havia revisão do processo. O processo é revisado ao final de cada sprint.

Priorização das demandas O gerente de projetos definia a ordem de desenvolvimento das demandas. Muitas vezes sem o conhecimento do cliente.

O product owner, representante do cliente, define a ordem de desenvolvimento das demandas, priorizando o que irá agregar maior valor ao produto.


Além disso, pôde ser constatada pelo pesquisador uma melhoria na integração

entre os membros da equipe. A comunicação constante e o objetivo comum de concluir as

demandas no prazo aumentou a colaboração consideravelmente. Antes, cada

95

desenvolvedor era responsável pelas suas demandas individuais e havia pouca

colaboração. Outro fator que merece ser destacado foi o aumento da motivação da equipe

com o uso do Scrum. Com as entregas frequentes das demandas, é possível ver o

resultado do trabalho mais rapidamente. Com isso, a equipe passou a se sentir mais

produtiva e, consequentemente, mais motivada.

A seguir, são listados alguns pontos que foram consenso geral entre os membros

da equipe:

● A implementação do Scrum no processo de desenvolvimento do SIGRH foi

uma decisão acertada, por ter seu foco nos resultados, na comunicação

entre os membros da equipe e na interação com os gestores da instituição e

usuários;

● O uso de uma ferramenta de colaboração para o acompanhamento do

processo tornou viável a implantação do Scrum com as limitações do

ambiente físico apresentadas;

● As oficinas utilizadas na elaboração da ferramenta de acompanhamento de

processo de desenvolvimento do SIGRH facilitou a comunicação entre os

usuários e o projetista, que nesse caso foi o próprio pesquisador, e a

identificação das funcionalidades necessárias. Desde a primeira iteração, foi

possível perceber a comunicação direta e aprofundada entre o projetista e

os usuários;

● Todos devem estar cientes de que sua participação e opinião são essenciais

para que não haja qualquer tipo inibição;

● A participação dos usuários na construção leva a uma aceitação mais fácil

da ferramenta;

● O uso do burndown chart de 30 dias confundiu o time, já que considerava

também os fins de semana e feriados, que não eram dias de trabalho e,

portanto, a sua média de consumo não refletia a realidade;

● O uso do gráfico Horas x Membro, no quarto sprint, que contabilizava as

horas trabalhadas, causou desconfiança no time, já que o time era muito

heterogêneo em relação ao horário disponível para o sprint. Além disso, as

tarefas tinham complexidades diferentes e, portanto, poderia causar

96

desmotivação no time. O scrum master passou a monitorar as horas de

cada membro, mas não exibir o gráfico na aba Dashboard;

● Alguns membros do time trabalhavam em horários diferentes e isso

dificultou a realização das daily meetings. Algumas vezes foi necessário

fazer a daily meeting mais de uma vez no dia.

Durante as iterações da pesquisa-ação, foi possível coletar as seguintes lições

aprendidas:

● Qualquer ação para ajudar a melhorar a integração da equipe foi

considerada como positiva. Música no ambiente de trabalho e as reuniões

sociais em locais fora do ambiente de trabalho ajudaram neste aspecto;

● Não deve haver diferenças no nível de responsabilidade e comprometimento

entre os membros da equipe. Ninguém é mais ou menos importante dentro

da equipe;

● Não deve haver restrição na comunicação entre o scrum master, o product

owner e o time;

● Qualquer mudança no processo deve ser uma decisão em conjunto com

todos os membros da equipe;

● A equipe é quem deve definir sua capacidade de produção na escolha das

demandas do sprint, mesmo que haja pressão do product owner ou dos

stakeholders para aumentar o sprint backlog;

● O tempo de correção de erros deve ser considerado na estimativa do custo

de uma tarefa. Esse aspecto não foi levado em conta nos primeiros sprints,

o que levou ao não cumprimento do prazo estabelecido.

97

6 CONSIDERAÇÕES FINAIS

Diante do que foi apresentado, podemos concluir que os objetivos deste trabalho

foram alcançados. Foi realizada uma descrição detalhada da implantação do Scrum como

processo de desenvolvimento de sistemas do SIGRH e a construção, com a participação

efetiva dos usuários, de uma ferramenta de acompanhamento para dar apoio ao

processo.

Pode-se verificar que a implantação do Scrum trouxe benefícios para a equipe de

desenvolvimento, no que diz respeito ao acompanhamento do projeto e na comunicação

entre os membros. A participação efetiva em decisões sobre o processo leva a um

interesse em melhorá-lo. Os gestores também ganharam com entregas mais frequentes

de melhorias a cada sprint.

Também foi descrita a participação efetiva dos usuários na construção da

ferramenta de acompanhamento do processo de desenvolvimento de sistemas. Destaca-

se a importância da experiência do usuário no design da ferramenta.

Como trabalho futuro, podemos destacar a criação de uma planilha que se integre

às planilhas de cada sprint, para que se tenha uma visão geral de todo o processo e sua

evolução. Outra sugestão de trabalho seria realizar um comparativo com ferramentas de

acompanhamentos do Scrum existentes no mercado para mensurar o ganho real da

ferramenta, verificando como o design participativo contribuiu efetivamente com

problemas enfrentados na utilização dessas ferramentas.

98

REFERÊNCIAS

ACADÊMICOS da Unifenas. Funcionamento do Scrum - Lição 2. Disponível em: <http://ned.unifenas.br/cursosgratuitos/201302/scrum/funcionamento.html>. Acesso em: 24 abr. 2017. BARANAUSKAS, M. C. C.; MANTOAN, M. T. E. Acessibilidade em ambientes educacionais: para além das guidelines. Rev. Online da Bibl. Prof. Joel Martins, v. 2, n. 2, p. 13-23, 2001. BONACIN, R. Um modelo de desenvolvimento de sistemas para suporte a cooperação fundamentado em design participativo e semiótica organizacional (Tese de Doutorado). Disponível em: Biblioteca Digital da UNICAMP: <http://www.bibliotecadigital.unicamp.br/document/?code=vtls000319294&fd=y>. Doutorado em Ciência da Computação)–Instituto de Computação, Universidade Estadual de Campinas, Campinas. 2004. CAMARGO, L., FAZANI, A. Explorando o design participativo como prática de desenvolvimento de sistemas de informação. 2014. CYEXPERIENCE, Usability. Disponível em: <http://cyexperience.com/usability.html>. Acesso em: 19 jan 2017. DICK, B. You want to do an action research thesis? 1993. Disponível em: <http://www.aral.com.au/resources/arthesis.html>. Acesso em: jan. 2016. FILIPPO, D. Pesquisa-ação em sistemas colaborativos. In: Pimentel, M. and Fulks, H. (orgs.). Sistemas colaborativos. [S.l.: s.n.], p. 449-466. 2011. HIGHSMITH, J, COCKBURN A. Agile software development: The business of innovation. Computer. Sep;34(9):120-7. 2001. IEEE Standards Association. Standard glossary of software engineering terminology. lEEE Std. 1990:610-12. JUNIOR, R. Melhorando o Entendimento “Como fazer?”. Disponível em: <http://blogdoabu.blogspot.com/2010/09/melhorando-o-entendimento-como-fazer.html> Acesso em 24 abr. 2017. L'HOTE, A. The Zühlke blog. The Ideal Scrum Master (Part 2). Disponível em: <http://blog.zuehlke.com/en/the-ideal-scrum-master-part-2/>. Acesso em: 10 jan. 2017. MANIFESTO ÁGIL. 2001. Disponível em: <http://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: nov. 2016.

http://www.aral.com.au/resources/arthesis.html

http://blog.zuehlke.com/en/the-ideal-scrum-master-part-2/

99

MANN, C.; MAURER, F. A Case study on the impact of Scrum on overtime and customer satisfaction. In: AGILE DEVELOPMENT CONFERENCE, 2005. Proceedings... IEEE Computer Society, p. 70-79. 2005. MCKAY, J. MARSHALL, P. "The dual imperatives of action research", Information Technology & People. v. 14, n. 1, p. 46-59, 2001. MÜLLER, M. J., HASLWANTER, J. H., & DAYTON, T. “Participatory Pratices in the Software Lifecycle”. In Handbook of Human-Computer Interaction, M. Helander, T. K. Landauer and P. Prabhu, eds., Elsevier Science, 2 ed, pp. 255-297. 1997. NIELSEN, J. Usability engineering. Elsevier, 1994. PREECE, J., ROGERS, Y., SHARP, H., Interaction Design: Beyond Human - Computer Interaction. 3 ed. 2011. PRIKLADNICKI, R., WILLI, R., MILANI, F. Métodos ágeis para desenvolvimento de software. Bookman Editora; jul. 2014. REZENDE, D. A. Engenharia de software e sistemas de informação. Brasport; 2005. SCHWABER, K. Agile project management with Scrum. Microsoft press; 2004 Feb 11. SCHWABER, K., BEEDLE, M. Agile Software Development with Scrum. 2002. SCHWABER, K. Scrum development process. In Business Object Design and Implementation (pp. 117-134). Springer London. 1997. TAKEUCHI, H., NONAKA, I. "The new new product development game". Harvard Business Review, 1986. THIOLLENT, M. Metodologia da pesquisa-ação. São Paulo: Cortez & Autores Associados, 1988. TRIPP, D. Pesquisa-ação: uma introdução metodológica. Educ. Pesqui., São Paulo , v. 31, n. 3, p. 443-466, dez. 2005 . Disponível em <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1517-97022005000300009&lng=pt&nrm=iso>. Acesso em: 16 jan. 2017. TRIVIÑOS, A. N. S. Introdução à pesquisa em ciências sociais: a pesquisa qualitativa em educação. São Paulo: Atlas, 1987. UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE. Suporte[]. Disponível em: <https://docs.info.ufrn.br/doku.php>. Acesso em: 20 mar. 2016a. UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE. Portal da Cooperação. Disponível em: <http://www.portalcooperacao.info.ufrn.br/pagina.php?a=parceiros>. Acesso em: 20 mar. 2016b.

http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1517-97022005000300009&lng=pt&nrm=iso

http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1517-97022005000300009&lng=pt&nrm=iso

https://docs.info.ufrn.br/doku.php

100

WOODSON, W.; TILLMAN, B.; TILLMAN, P. Human factors design handbook. 2nd. ed. New York: McGraw-Hill, p. 846 , 1992.

101

APÊNDICE A - SCRIPTS DA PLANILHA DE ACOMPANHAMENTO DE PROCESSO DE

DESENVOLVIMENTO DE SISTEMAS

function onOpen() { var spreadSheet = SpreadsheetApp.getActiveSpreadsheet(); var hoje = new Date(); var sheetSprints = spreadSheet.getSheetByName("Sprints"); sheetSprints.getRange(2, 14).setValue(hoje); } function onEdit(event) { var spreadSheet = SpreadsheetApp.getActiveSpreadsheet(); var sheet = SpreadsheetApp.getActiveSheet(); var cell = sheet.getActiveCell(); var range = sheet.getActiveRange(); if (sheet.getName() == "Atividades") { var rResponsavel = sheet.getRange(range.getRow(), 3); var rStatus = sheet.getRange(range.getRow(), 8); var rAtividade = sheet.getRange(range.getRow(), 1); // Registro das horas if (isNaN(parseFloat(rResponsavel.getValue())) && (range.getRow() > 1 && range.getColumn() >= 9) && range.getColumn() < 50 && sheet.getRange(1, range.getColumn()).getValue() !== "Pts.") { if (range.isBlank()) { range.clearNote(); var bTop = !range.offset(-1, 0).isBlank(); var bLeft = !range.offset(0, -1).isBlank(); var bBottom = !range.offset(1, 0).isBlank(); var bRight = !range.offset(0, 1).isBlank(); range.setBorder(bTop, bLeft, bBottom, bRight, false, false, "#D3D3D3", null); } else if (!isNaN(parseFloat(range.getValue())) && isFinite(range.getValue())) { var usuario = rResponsavel.getValue(); if (usuario !== "") { range.setNote(usuario); range.setBorder(true, true, true, true, false, false, "#D3D3D3", null); if (rStatus.getValue() !== spreadSheet.getSheetByName("REF").getRange(5, 4).getValue()) rStatus.setValue(spreadSheet.getSheetByName("REF").getRange(3, 4).getValue()); } else { range.clearContent(); var bTop = !range.offset(-1, 0).isBlank(); var bLeft = !range.offset(0, -1).isBlank(); var bBottom = !range.offset(1, 0).isBlank();

102

var bRight = !range.offset(0, 1).isBlank(); range.setBorder(bTop, bLeft, bBottom, bRight, false, false, "#D3D3D3", null); } } else if (range.getValue() == "-") { rStatus.setValue(spreadSheet.getSheetByName("REF").getRange(5, 4).getValue()); range.clearContent(); } // Alteração de responsável } else if (range.getA1Notation() == rResponsavel.getA1Notation() && isNaN(parseFloat(rResponsavel.getValue()))) { if (rResponsavel.isBlank()) rStatus.clearContent(); else rStatus.setValue(spreadSheet.getSheetByName("REF").getRange(3, 4).getValue()); // Alteraçao de status } else if (range.getA1Notation() == rStatus.getA1Notation()) { if (rStatus.getValue() == spreadSheet.getSheetByName("REF").getRange(4, 4).getValue()) { for (var i = 1; i <= 25; i++) { var tipo = sheet.getRange(cell.getRow() + i, 2).getValue(); if (tipo == "Err") { sheet.showRows(cell.getRow() + i); break; } } } // Alteraçao de atividade } else if (range.getA1Notation() == rAtividade.getA1Notation()) { if (spreadSheet.getSheetByName("Sprints").getRange(2, 5).getValue() !== spreadSheet.getSheetByName("Sprint Backlog").getRange(1, 6).getValue()) { // Atualizar quadro Scrum var sheetQuadro = spreadSheet.getSheetByName("Quadro"); sheetQuadro.getRange("A:A").getValues().forEach(function (r, i) { if (r[0] !== '') { if (r[0] == 0) sheetQuadro.hideRows(i + 1); else if (r[0] == 1 || r[0] == "2" || r[0] == "-" || r[0] == "+") sheetQuadro.showRows(i + 1); } }); // Atualizar quantidade de atividades spreadSheet.getSheetByName("Sprints").getRange(2, 5).setValue(spreadSheet.getSheetByName("Sprint Backlog").getRange(1, 6).getValue()); }

103

} } else if (sheet.getName() == "Sprints") { if (cell.getColumn() == 2 && cell.getRow() == 2) { var sheetAtividades = spreadSheet.getSheetByName("Atividades"); var data = cell.getValue(); var row = 1; var column = 9; // I if (isDate(data)) { var col = 0; var f = 2; var feriado = sheet.getRange(f, 15).getValue(); // Atualizar dias da sprint sheetAtividades.getRange("I1:AG1").getValues().forEach(function (r) { r.forEach(function (i) { while (isDate(feriado) && feriado.valueOf() == data.valueOf()) { data = new Date(data.setDate(data.getDate() + 1)); f = f + 1; feriado = sheet.getRange(f, 15).getValue(); } sheetAtividades.getRange(1, column + col).setValue(data); sheetAtividades.getRange(1, column + col).setNumberFormat("dd/MM") if (data.getDay() == 5) data = new Date(data.setDate(data.getDate() + 3)); else data = new Date(data.setDate(data.getDate() + 1)); col = col + 1; }); }); } } } } function isDate(v) { if (Object.prototype.toString.call(v) === "[object Date]") { if (isNaN(v.getTime())) { return false; } else { return true; } } else { return false; } } function nomeUsuario(email) {

104

var spreadSheet = SpreadsheetApp.getActiveSpreadsheet(); var sheet = spreadSheet.getSheetByName("REF"); var nomes = sheet.getRange(2, 1, 15).getValues(); var emails = sheet.getRange(2, 2, 15).getValues(); for (var row in emails) { if (emails[row] == email) return nomes[row]; } return ""; }

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE PROGRAMA DE … · 2.1 metodologias de desenvolvimento...

Documents

Transcript of UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE PROGRAMA DE … · 2.1 metodologias de desenvolvimento...