Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
MARCUS VINÍCIUS GUEDES GONÇALVES
O USO DA METODOLOGIA ÁGIL COMO PROCESSO DE DESENVOLVIMENTO
PARTICIPATIVO DE SISTEMAS
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
MARCUS VINÍCIUS GUEDES GONÇALVES
O USO DA METODOLOGIA ÁGIL COMO PROCESSO DE DESENVOLVIMENTO
PARTICIPATIVO DE SISTEMAS
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
Fonte: Autoria própria (2017)
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
Fonte: Autoria própria (2017)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
39
Figura 11 – Detalhes da aba Atividades do segundo sprint
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
43
Figura 14 - Gráfico de Custo x Horas por tarefa do segundo sprint
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
46
Figura 16 – Detalhes da aba Atividades do terceiro sprint
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
49
Figura 18 - Cálculo dos custos considerando 30 dias
Fonte: Autoria própria (2016)
Custo médio para conclusão das
atividades em 30 dias
50
Figura 19 - Cálculo dos custos considerando apenas dias úteis
Fonte: Autoria própria (2016)
Custo médio para conclusão
das atividades considerando
apenas os dias úteis
51
Figura 20 - Cálculos dos custos por perfil
Fonte: Autoria própria (2016)
Custo das atividades de
cada perfil
Des = Desenvolvimento
Req = Requisitos
Tes = Testes
52
Figura 21 - Burndown chart de 30 dias
Fonte: Autoria própria (2016)
53
Figura 22 - Burndown chart considerando apenas dias úteis
Fonte: Autoria própria (2016)
54
Figura 23 – Burndown chart por tarefa
Fonte: Autoria própria (2016)
55
Figura 24 - Burndown chart por perfil de equipe
Fonte: Autoria própria (2016)
56
Figura 25 - Gráfico Atividades x Equipe
Fonte: Autoria própria (2016)
57
Figura 26 - Gráfico Horas x Membro
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
60
Figura 28 - Relação entre as atividades na aba Atividades e no scrum board
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
Apenas dias úteis
63
Figura 30 - Aba Quadro do quinto sprint
Fonte: Autoria própria (2016)
64
Figura 31 - Aba Quadro do quinto sprint exibindo tarefas finalizadas
Fonte: Autoria própria (2016)
65
Figura 32 - Aba Sprint Backlog do quinto sprint
Fonte: Autoria própria (2016)
66
Figura 33 - Aba Dashboard do quinto sprint
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
71
Figura 36 - Aba Atividades do sexto sprint
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
Registro de
feriados
Contabilização de horas
trabalhadas no sprint
Dados gerais do sprint
Data atual
73
Figura 38 - Aba Quadro do sexto sprint
Fonte: Autoria própria (2016)
74
Figura 39 - Detalhamento do scrum board
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
76
Figura 41 - Aba Quadro do sexto sprint
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
84
Figura 46 - Burndown chart da aba Dashboard da planilha template
Fonte: Autoria própria (2016)
85
Figura 47 - Gráfico Tipo de atividade x Número de atividades da aba Dashboard da planilha template
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
90
Figura 50 - Aba Sprint Backlog da planilha template
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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
Fonte: Autoria própria (2016)
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.
Fonte: Autoria própria (2017)
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.
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.
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 ""; }