INSTITUTOFEDERALDESANTACATARINA · 2019. 3. 8. · Buscando introduzir uma nova visão sobre como...

INSTITUTO FEDERAL DE SANTA CATARINA

NATAN MARTINS JORY

Métodos Híbridos para Gerenciamento deProjetos de Desenvolvimento de Software

São José / SC

Dezembro/2018

MÉTODOS HÍBRIDOS PARA GERENCIAMENTO DEPROJETOS DE DESENVOLVIMENTO DE SOFTWARE

Trabalho de conclusão de curso apresentado àCoordenação de Engenharia de Telecomunica-ções do Instituto Federal de Santa Catarina,Campus São José, para a obtenção do títulode Bacharel em Engenharia de Telecomunica-ções.

Orientador: Prof. Clayrton Monteiro Henri-que, Me.

São José / SC

Dezembro/2018

Natan Martins JoryMétodos Híbridos para Gerenciamento de Projetos de Desenvolvimento de Softwa-

re/ Natan Martins Jory. – São José / SC, Dezembro/2018-84 p. : il. (algumas color.) ; 30 cm.

Orientador: Prof. Clayrton Monteiro Henrique, Me.

Monografia (Graduação) – , Dezembro/2018.

1. Gerenciamento de projetos. 2. Métodos ágeis. 3. Métodos tradicionais. 4.Métodos híbridos. 5. Desenvolvimento de software. I. Orientador. II. Instituto Federalde Santa Catarina. III. Campus São José. IV. Métodos Híbridos para Gerenciamentode Projetos de Desenvolvimento de Software

NATAN MARTINS JORY

MÉTODOS HÍBRIDOS PARA GERENCIAMENTO DEPROJETOS DE DESENVOLVIMENTO DE SOFTWARE

Este trabalho foi julgado adequado para obtenção do título de Bacharel em Engenheiro deTelecomunicações, pelo Instituto Federal de Educação, Ciência e Tecnologia de SantaCatarina, e aprovado na sua forma final pela comissão avaliadora abaixo indicada.

São José / SC, 12 de dezembro de 2018:

Prof. Clayrton Monteiro Henrique,Me.

(Orientador)

Prof. Ederson Torresini, Me.(Membro Interno)

Prof. Pedro Paulo Corrêa de Souza,Esp.

(Membro Interno)

Profa. Fernanda Dias de Oliveira daRocha, Esp.

(Membro Externo)

São José / SCDezembro/2018

AGRADECIMENTOS

Agradeço a Deus, por me dar saúde e disposição para enfrentar todos os desafiosda vida.

À família, principalmente, a minha Mãe, Heloísa Jory, que sempre me apoiou e deuforça em todos os momentos desta caminhada, e meu Pai, Francisco Jory, que apesar denão estar conosco há mais de 10 anos, foi quem fez eu me tornar o ser humano que souhoje. Amo vocês!

A minha princesa, Louisi Müller, por escutar, compreender e dividir todos os meusanseios e reclamações neste período de muito estudo e trabalho. Nossa vida juntos é, esempre será, de abundante companheirismo e amor!

A todos os colegas de curso, por suas contribuições e trocas de experiência. Semdúvidas, sem vocês eu não chegaria aqui. Juntos somos mais fortes!

A minha sogra, Nádia Müller, pelos deliciosos feijões feitos sempre com muitocarinho.

Um especial agradecimento a meu orientador e mentor, Clayrton Monteiro Henrique,por abraçar a causa desde o princípio, sempre me apoiando e instruindo ao longo destesúltimos 14 meses, sua disposição e disciplina são admiráveis.

A todos os profissionais e organizações que auxiliaram nos estudos de caso, vocêsforneceram um embasamento técnico extremamente importante para este projeto.

Por fim, a todos os membros da CTIC, por quebrarem paradigmas do serviçopúblico e mostrarem excelência nos seus serviços prestados, grande parte do resultadodeste trabalho é fruto da colaboração de vocês. Meu imenso agradecimento!

“Um homem que não se alimenta de seus sonhosenvelhece cedo.

(William Shakespeare)

RESUMOO gerenciamento de projetos vem sendo amplamente utilizado pelas empresas para reduziros problemas com prazos, entregas, comunicação e gerenciamento. Na área de desenvol-vimento de software, o gerenciamento ágil de projetos tem o objetivo de fazer entregasincrementais do produto em curtos espaços de tempo, sempre tendo em mente o valoragregado. Este estudo visa pesquisar métodos híbridos de gerenciamento de projetos,combinando diferentes abordagens tradicionais e ágeis. Foram realizados estudos de casoem organizações públicas e privadas da Grande Florianópolis com o intuito de identificar aspráticas de gerenciamento de projetos mais utilizadas. Com base na pesquisa bibliográficae nos estudos de caso, foi aplicada uma solução híbrida na Coordenadoria de Tecnologiada Informação e Comunicação (CTIC) do IFSC Câmpus São José, de forma a otimizar aentrega dos seus serviços, principalmente os relacionados ao desenvolvimento de software. Ametodologia consistiu em avaliar a evolução das métricas de eficiência, eficácia e qualidade,assim como acompanhar o nível de maturidade da equipe em relação aos princípios degerenciamento de projetos, identificando o método híbrido mais adequado para a organiza-ção ao longo da execução do trabalho. Como resultado principal, a CTIC agregou valor econhecimento para gerenciar mais apropriadamente os seus futuros projetos, focando ementregas contínuas, de qualidade e em curtos espaços de tempo.

Palavras-chave: Gerenciamento de projetos. Métodos ágeis. Métodos tradicionais. Méto-dos híbridos. Desenvolvimento de software.

ABSTRACTProject Management has been widely used by companies to reduce problems with deadlines,delivery, communication and management. In the area of software development, agileproject management aims to make incremental deliveries of product in short time, alwayskeeping in mind value-adding. This study seeks to research hybrid methods of projectmanagement, combining differents agile and traditional approaches. Case studies werecarried out in both public and private organizations in Florianópolis, Brazil, in order toidentify the most project management practices used. Based on the research and casestudies a hybrid solution was applied at Communication and Information TechnologyCoordination (CTIC) of IFSC campus São José, in order to optimize the delivery of itsservices, especially those related to the software development. The used methodology wasto evaluate the evolution of efficient, efficacious and quality metrics, as well as to monitorthe team’s level of maturity in relation to the project management principles identifyingthe most appropriate hybrid method for the organization during the execution of the work.As a key result, CTIC has added value and knowledge to more appropriately manage itsfuture projects, focusing on continuous deliveries, quality and shorter time frames.

Keywords: Project Management. Agile methods. Traditional methods. Hybrid methods.Software development.

LISTA DE ILUSTRAÇÕES

Figura 1 – Registro de um possível termo de abertura de projeto antigo . . . . . . 26Figura 2 – Transição e evolução do gerenciamento de projetos. . . . . . . . . . . . 27Figura 3 – Características do gerenciamento de projetos tradicionais. . . . . . . . 28Figura 4 – Modelo waterfall de desenvolvimento de software. . . . . . . . . . . . . 29Figura 5 – Ciclo de vida dos projetos. . . . . . . . . . . . . . . . . . . . . . . . . . 30Figura 6 – Relacionamento entre os principais fundamentos do guia PMBoK. . . . 31Figura 7 – Utilização dos métodos ágeis nos projetos de desenvolvimento de software. 34Figura 8 – Fluxo Scrum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 9 – Quadro Kanban. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figura 10 – Quadro Kanban de maior maturidade da equipe. . . . . . . . . . . . . 40Figura 11 – Ciclo de vida de projeto com Scrum e PMBoK. . . . . . . . . . . . . . 41Figura 12 – Ciclo PDCA de uma métrica ágil. . . . . . . . . . . . . . . . . . . . . . 42Figura 13 – Gráfico burndown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figura 14 – Quadro no Trello da equipe de desenvolvimento do Tribunal Regional

Eleitoral de Santa Catarina (TRE-SC). . . . . . . . . . . . . . . . . . . 49Figura 15 – Quadro no JIRA da equipe de desenvolvimento da Intelbras. . . . . . . 50Figura 16 – Quadro físico com o Backlog do Produto. . . . . . . . . . . . . . . . . . 56Figura 17 – Quadro físico ao fim da Reunião de Planejamento da Sprint 1. . . . . . 57Figura 18 – Quadro online da Sprint 1. . . . . . . . . . . . . . . . . . . . . . . . . 58Figura 19 – Gráfico burndown da Sprint 1. . . . . . . . . . . . . . . . . . . . . . . . 59Figura 20 – Quadro físico da Sprint 2. . . . . . . . . . . . . . . . . . . . . . . . . . 61Figura 21 – Gráfico burndown da Sprint 2. . . . . . . . . . . . . . . . . . . . . . . . 62Figura 22 – Gráfico burndown da Sprint 3. . . . . . . . . . . . . . . . . . . . . . . . 63Figura 23 – Lead time da Sprint 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Figura 24 – Gráfico burndown da Sprint 4. . . . . . . . . . . . . . . . . . . . . . . . 65Figura 25 – Lead time da Sprint 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

LISTA DE ABREVIATURAS E SIGLAS

BP Backlog do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

BS Backlog da Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

CTIC Coordenadoria de Tecnologia da Informação e Comunicação . . . . . . . . . . . . . . . . . . 23

CFD Cumulative Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

DevTeam Time de Desenvolvimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

EAP Estrutura analítica do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

GP Gerente de Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

HTML HyperText Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

IFSC-SJ Instituto Federal de Santa Catarina Campus São José . . . . . . . . . . . . . . . . . . . . . 23

MCVS migrar módulos de configuração virada semestre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

MIT Massachusetts Institute of Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

MPCN migrar módulos de programas de configuração normal . . . . . . . . . . . . . . . . . . . . . . 55

MPFC1 migrar módulos de programas com file (compactados) 1. . . . . . . . . . . . . . . . . . . .55

MPFC2 migrar módulos de programas com file (compactados) 2. . . . . . . . . . . . . . . . . . . .55

MPPL migrar módulos de programas padrão dos laboratórios. . . . . . . . . . . . . . . . . . . . . . .55

MPRNO migrar módulos de programas em repositórios não oficiais. . . . . . . . . . . . . . . . .55

MPRP migrar módulos de programas em repositório padrão . . . . . . . . . . . . . . . . . . . . . . . . 55

P&D Pesquisa e Desenvolvimento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

PP Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

PMBoK Project Management Body of Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

PO Product Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

QA Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

RUV repositório com url verdadeiro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

SM Scrum Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

SVN Apache Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

TAP termo de abertura do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

TDD Test Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

TEP termo de encerramento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

TRE-SC Tribunal Regional Eleitoral de Santa Catarina . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

TSE Tribunal Superior Eleitoral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

XP Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

WIP Work in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.3 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 252.1 Conceitos e características dos projetos . . . . . . . . . . . . . . . . . 252.2 Métodos tradicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.1 Guia Project Management Body of Knowledge (PMBoK) . . . . . . . . . . 292.2.1.1 Ciclo de vida e fases de um projeto . . . . . . . . . . . . . . . . . . . . . . . 302.2.1.2 Grupos de processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3 Métodos ágeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.1.1 Papéis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.3.1.2 Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.3.1.3 Artefatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.1.4 Planning Poker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.3.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.3.2.1 Descrevendo o fluxo do sistema . . . . . . . . . . . . . . . . . . . . . . . . 382.4 Métodos híbridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.5 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.5.1 Velocidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.5.2 Gráfico burndown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.5.3 Lead time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.5.4 Taxa de reincidência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3 ESTUDOS DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . 473.1 Formulário de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Tribunal Regional Eleitoral de Santa Catarina . . . . . . . . . . . . . 483.3 Intelbras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4 Neoway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . 534.1 Coordenadoria de Tecnologia da Informação e Comunicação . . . . 534.1.1 Escolha e descrição geral do projeto . . . . . . . . . . . . . . . . . . . . . 534.1.2 Definição dos papéis da equipe . . . . . . . . . . . . . . . . . . . . . . . . 54

4.1.3 Criação do Backlog do Produto . . . . . . . . . . . . . . . . . . . . . . . 554.2 Implementação do projeto . . . . . . . . . . . . . . . . . . . . . . . . 554.2.1 termo de abertura do projeto (TAP) . . . . . . . . . . . . . . . . . . . . . 554.2.2 Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.3 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2.4 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.5 Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2.6 Encerramento do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

APÊNDICE A – TERMO DE ABERTURA . . . . . . . . . . . . . . 75

APÊNDICE B – FORMULÁRIO . . . . . . . . . . . . . . . . . . . . 77

APÊNDICE C – TERMO DE ENCERRAMENTO . . . . . . . . . . 83

21

1 INTRODUÇÃO

Projetos podem ser definidos como um esforço temporário empreendido para criarum produto, serviço ou resultado exclusivo. O gerenciamento de projetos é, portanto, aaplicação de conhecimentos, habilidades e técnicas para execução de projetos de maneiraeficiente (PMBOK, 2013). As abordagens de projetos podem ser encontradas em diversasatividades como, por exemplo, no desenvolvimento de software.

Desenvolver software é uma atividade relativamente recente, porém a área desoftware tem evoluído rapidamente e se tornou uma das mais importantes indústrias da eramoderna. O software está presente em inúmeras atividades, desde as mais simples, comocriar um link em uma página HyperText Markup Language (HTML), até as mais complexas,como controlar o tráfego de aeronaves em aeroportos (PRIKLADNICKI R. WILLI, 2014).

Na década de 70, visando melhorar a qualidade do software desenvolvido, asempresas começaram a aplicar metodologias de gerenciamento de projetos (SHARMA;KOTWAL, 2016). Neste período foi desenvolvido a metodologia Waterfall, na qual osoftware é desenvolvido passando por várias etapas desde o levantamento de requisitosà implantação, sendo que uma etapa é iniciada somente após o término da anterior(ROYCE, 1987). Nos anos 90, novos processos e metodologias apareceram e, devido as suascaracterísticas particulares, tais metodologias de desenvolvimento foram classificadas emduas grandes categorias: tradicionais e ágeis (ROBIOLO; GRANE, 2014, grifo nosso).

Dentre as vantagens de se utilizar os métodos tradicionais, estão o maior enfoquena etapa de planejamento, visando minimizar os riscos de impactos negativos no projeto,além de fornecer um detalhamento de cronograma e custos mais precisos para o cliente,facilitando a criação de propostas financeiras por parte da empresa. Outro ponto relevantese deve ao fato de tal abordagem sugerir uma documentação abrangente, no caso de saídade funcionários envolvidos no projeto, este artefato auxiliará na integração dos novosparticipantes (NPWIT, 2017).

Já as principais críticas à abordagem citada acima, são as dificuldades de coletarcorretamente todos os requisitos no início do projeto, o tempo elevado entre o seu início e adisponibilização da primeira versão minimamente utilizável do sistema e, consequentemente,a demora em detectar algum eventual erro ocorrido durante a fase de execução do projeto(PRESSMAN, 1995).

Nas abordagens tradicionais de desenvolvimento de software, geralmente a parte dedocumentação e análise dos requisitos são executadas pelo analista de negócio no início doprojeto. É nesse momento que existe a maior interação entre cliente e empresa. Em muitoscasos, na fase inicial do projeto, nem mesmo o cliente sabe exatamente o que quer ou o

22 Capítulo 1. Introdução

que precisa. De posse de toda análise de requisitos, o analista de negócio encaminha asinformações para que o time de desenvolvimento possa implementar o software. Durante afase de desenvolvimento do projeto existem poucas interações entre analistas de negócio,equipe de desenvolvimento e o cliente, o que pode acarretar, ao fim do projeto, na entregade um produto mais complexo do que o necessário, com funcionalidades que pouco ou,por vezes, nunca serão utilizadas. Tal situação pode gerar custos excessivos de recursos,entregando um produto que não satisfaz por completo a necessidade (ou requisitos) docliente.

Em 2002, foi divulgado um relatório da GROUP et al. (2008), no qual divulgaramque 45% das funcionalidades dos sistemas nunca eram utilizadas e 19% raramente utilizadasà época. Neste contexto, podemos considerar que 64% do escopo do projeto não agregavalor, sendo desperdício de recursos por parte da empresa de desenvolvimento.

Atendendo a esta demanda de mercado surgiram as metodologias ágeis, uma novamaneira de desenvolver software, de forma a entregar software funcional e de qualidade,fechando um ciclo menor para feedbacks, tornando o processo iterativo e incremental, semprebuscando a melhoria contínua e, consequentemente, entregando novas funcionalidadesde software em um menor período de tempo. As metodologias ágeis de desenvolvimentoaceitam a hipótese que a única certeza, no decorrer de um projeto, é a sua constantemudança, logo, elas criam mecanismos para se adaptar da melhor forma possível a essasmudanças. Como disse Prikladnicki R. Willi (2014, p.30):

Ser ágil está associado a uma mudança cultural, a uma nova forma depensar. O que diferencia dos outros métodos é o enfoque maior naspessoas e não em processos, e o seu conjunto de valores, princípios epráticas. Isso possibilita a adaptação a novos fatores decorrentes dodesenvolvimento do projeto (em vez de procurar prever tudo o que podeacontecer) e a rápida resposta às constantes mudanças do mercado.

Em projetos de desenvolvimento de software é essencial que as ferramentas degerenciamento de projetos utilizadas sejam escolhidas com foco no que é melhor paraaquele projeto específico, não o contrário. Em alguns casos, o erro é acreditar que o projetodeve se adaptar para utilizar o máximo de métodos e ferramentas no seu desenvolvimento,o que pode tornar um desafio encontrar a medida certa.

1.1 JustificativaA região da Grande Florianópolis conta, atualmente, com aproximadamente 900

empresas e startups1 na área de tecnologia, com faturamento de cerca de R$11,4 bilhõespor ano, sendo o terceiro maior polo tecnológico do Brasil (ACATE, 2016). Geralmente,1 Instituição de pessoas tentando criar algo novo sob condições de extrema incerteza (RIES, 2014).

1.2. Objetivos 23

os problemas dessas empresas estão associados a prazos, entregas, comunicação e geren-ciamento. Para mitigar essas dificuldades, boa parte delas já utiliza frameworks2 para ogerenciamento ágil de seus projetos, com foco principalmente nos projetos de desenvolvi-mento de software. O objetivo é tornar os projetos mais dinâmicos e inovadores, agregandovalor ao seu resultado de forma mais significativa.

O gerenciamento ágil de projetos tem a importância de satisfazer o cliente, fazendocom que as entregas ocorram em curtos espaços de tempo, de maneira adiantada, sem-pre tendo em mente o valor agregado. Empresas que estão utilizando os conceitos dasmetodologias ágeis, como por exemplo, os modelos de reuniões com timebox3, passama otimizar o tempo e manter o foco no verdadeiro objetivo, não deixando as reuniõesse tornarem exaustivas e pouco produtivas. As metodologias ágeis também incentivamo contato frequente com os stakeholders4 durante todo o desenvolvimento do projeto,tornando o processo mais eficiente.

Os frameworks de metodologias tradicionais e ágeis podem ser utilizados em diversostipos de desenvolvimento como, por exemplo: sistemas embarcados, aplicações para redesde computadores, software comercial, websites, aplicações para smartphones, controladoresde satélite, entre outros.

1.2 ObjetivosEste trabalho apresenta uma visão prática da combinação de diferentes referenciais

metodológicos, de forma que se complementem, sendo os objetivos elencados a seguir:

• Pesquisar formas híbridas que sejam eficientes e eficazes, combinando métodos ágeise tradicionais na aplicação do gerenciamento de projetos, usando a mais adequadapara cada projeto;

• Investigar estudos de caso de organizações que utilizam métodos de gerenciamentode projetos, de modo a encontrar formas eficientes de desenvolvimento incrementalde software;

• Aplicar o resultado da pesquisa na Coordenadoria de Tecnologia da Informaçãoe Comunicação (CTIC) do Instituto Federal de Santa Catarina Campus São José(IFSC-SJ), aproximando sua realidade ao mercado que a cerca, de modo que contribuapara a melhoria de suas atividades e entrega de serviços, passando a atuar naabordagem de projetos.

2 Conjunto de conceitos usado para resolver um problema de um domínio específico (DUTRA, 2011).3 Tempo máximo pré-determinado para realização da atividade (SCHWABER; SUTHERLAND, 2017).4 Pessoas e organizações, como clientes, patrocinadores, organizações executoras e o público, que estejam

ativamente envolvidas no projeto ou cujos interesses possam ser afetados, de forma positiva ou negativa,pela execução ou término do projeto (GUIDE, 2017).

24 Capítulo 1. Introdução

Em alguns casos, é possível perceber que determinada prática pode ser maisadequada para alguma fase do projeto, como na iniciação ou durante a execução. Outrasituação é a característica do projeto, podendo ser mais apropriado para algum métodoespecífico. Eventualmente, uma metodologia mais preditiva pode estar dentro de outramais abrangente, porém sempre mantendo o Lean Mindset5 para não sobrecarregar demaisos processos e, principalmente, as pessoas envolvidas neles.

1.3 OrganizaçãoVisando a melhor organização na apresentação deste trabalho, este foi estruturado

em cinco capítulos, os quais serão apresentados a seguir: no Capítulo 1 são apresentadas aintrodução do tema do trabalho, bem como a sua justificativa e os objetivos. No Capítulo2 são apresentados os conceitos e características dos projetos, além de expostos os métodostradicionais de gerenciamento de projeto através do guia PMBoK, os métodos ágeis com oframework Scrum e o Método Kanban, e os métodos híbridos por meio da combinação dediferentes métodos. Ainda é discorrido neste capítulo sobre a utilização de métricas ágeis eintroduzidos os conceitos de velocidade, gráfico burndown, lead time e taxa de reincidência.No Capítulo 3 são apresentados estudos de casos realizados em três organizações, sendoelas: Tribunal Regional Eleitoral de Santa Catarina, Intelbras e Neoway, no intuito deidentificar as práticas utilizadas no gerenciamento dos seus projetos de desenvolvimentode software. No Capítulo 4 é discorrido o desenvolvimento do trabalho, contextualizando olocal de aplicação, a descrição do projeto escolhido, a definição da equipe, a criação doBacklog do Produto e a implementação da abordagem híbrida de gerenciamento durante oandamento do projeto. Por fim, no Capítulo 5 são apresentadas as conclusões do trabalhoe sugerido proposições para trabalhos futuros.

5 Maneira de pensar sobre como organizar atividades humanas para entregar mais benefícios à sociedadee valor para os indivíduos, eliminando o desperdício de recursos (GOUVEIA, 2017).

25

2 FUNDAMENTAÇÃO TEÓRICA

Neste capítulo serão apresentados os conceitos e características dos projetos, osdiferentes métodos para gerenciamento de projetos, incluindo os chamados tradicionais,ágeis e híbridos, com foco no desenvolvimento de software. São apresentados inicialmente adefinição do que é um projeto e gerenciamento de projetos. Em seguida, é abordado o guiaPMBoK como um método tradicional, apresentado o ciclo de vida e as fases de um projeto,além dos processos envolvidos no referido guia. É apresentado ainda, dentro dos métodoságeis, o Scrum, incluindo seus papéis, eventos e artefatos, além do Kanban, descrevendo-seo fluxo do método. Por fim, são definidas as abordagens híbridas de gerenciamento deprojetos e métricas de desempenho voltadas para o desenvolvimento de software.

2.1 Conceitos e características dos projetos

Apesar de os primeiros conteúdos científicos publicados sobre o tema de gerenci-amento de projetos serem relativamente recentes, é possível mostrar que, ainda que deforma rudimentar, projetos vêm sendo realizados desde o início das civilizações. Assim, éconhecido que qualquer tipo de esforço que requer trabalho em equipe, visando atingir umobjetivo, exige planejamento. Nas civilizações antigas, os grandes projetos eram, na grandemaioria, relacionados à construção civil, onde podemos citar, por exemplo: as Pirâmidesdo Egito, a Muralha da China e o Coliseu (VALLE, 2015). Essas grandes obras já eramdesenvolvidas seguindo um plano de projeto e tinham ciclos de vida em fases, as quais sãocaracterísticas que permeiam os projetos até os dias de hoje (KOZAK-HOLLAND, 2011).A Figura 1 apresenta um registro daquela época que é análogo ao termo de abertura de umprojeto de hoje, o documento foi esculpido em mármore e pesava mais de uma tonelada(VALLE, 2015).

A seguir são apresentadas as definições de alguns autores sobre o que é um projeto:

Processo único, consistindo em um grupo de atividades coordenadas econtroladas com datas para início e término, empreendido para alcancede um objetivo conforme requisitos específicos, incluindo limitações detempo, custo e recursos. (ISO, 2000)

Um empreendimento com objetivo identificável, que consome recursos eopera sob pressões de prazos, custos e qualidade. (KERZNER, 2002)

É um esforço temporário empreendido para criar um produto, serviço ouresultado exclusivo. (PMBOK, 2013)

26 Capítulo 2. Fundamentação Teórica

Figura 1 – Registro de um possível termo de abertura de projeto antigo

Fonte: Valle (2015)

Com o passar dos tempos a área de gerenciamento de projetos ganhou destaque,visto que muito do que fazemos no dia a dia pode ser compreendido como um projeto, e asua aplicação melhora os resultados obtidos. Os anos 80 ficaram marcados pelo uso desoftware no gerenciamento de projetos, enquanto que a partir dos anos 90 foram integradastécnicas para gerenciamento de partes específicas dos projetos: escopo, riscos, recursos,comunicação. Também nos anos 90 surgiram os métodos chamados de ágeis, primeiramenterestringidos a projetos de software e, posteriormente, expandido para diferentes áreas. NaFigura 2 pode ser observada a evolução do gerenciamento de projetos nos últimos anos,com a predominância dos métodos tradicionais até a década de 90, depois a divisão domercado com os métodos ágeis e, mais atualmente, o surgimento do termo híbrido a partirdo século XXI.

O gerenciamento de projetos, segundo Bentley (2012), é o desenvolvimento dasentregas do projeto, que produzem os resultados, controlando o trabalho especializadonecessário para a criação dos produtos do projeto. A função do gerenciamento de projetosé por em prática o plano de projeto, alcançar suas metas, objetivos, propósitos e atingiras expectativas dos stakeholders, tornando-o bem sucedido. Na Tabela 1 é apresentado umconjunto de indicadores criados por Candido (2008) que podem avaliar se o projeto é bemsucedido ou não.

2.2 Métodos tradicionaisOs métodos de gerenciamento de projetos chamados de tradicionais apresentam

algumas características, como definir boa parte do escopo antes de inciar o projeto,

2.2. Métodos tradicionais 27

Figura 2 – Transição e evolução do gerenciamento de projetos.

Fonte: MENEZES (2018)

Tabela 1 – Análise de resultados do projeto.

Evidências de sucesso Evidências de fracassoO orçamento foi cumprido integralmente. O projeto excedeu o orçamento previsto.

Os prazos foram cumpridos nas etapas e natotalidade.

Os prazos não foram cumpridos nas etapas e/ouna totalidade.

O cliente teve atendidas todas as expectativasoferecidas pelo projeto.

O cliente não teve atendidas as expectativasoferecidas pelo projeto.

Todos os stakeholders tiveram suas expectativasalcançadas pelo projeto.

Os stakeholders não tiveram atendidas suasexpectativas em relação ao projeto.

A qualificação dos participantes foi adequada àproposta do projeto.

Houve participante no projeto com falta dehabilitação às atividades propostas pelo projeto.

O projeto resultou em vantagem competitivapara o cliente frente à concorrência.

O projeto não trouxe vantagem competitivaalguma ao cliente frente à concorrência.

Fonte: Candido (2008)

ter as fases de ciclos de vida de desenvolvimento bem definidas, maior formalização dacomunicação através de uma documentação abrangente e padronização de processos. Prazose custos são definidos na fase inicial do projeto, o que pode causar desconforto aos gestoresdo projeto, criando barreiras para eventuais mudanças de escopo. O trabalho é orientadopara as atividades, marcos1 e entregas documentais (MENEZES, 2018).

Na abordagem tradicional, as atividades são organizadas hierarquicamente, ou seja,possuem uma sequência de execução em todo o projeto, conforme a fase em que se encontra.Geralmente, as atividades são estipuladas e distribuídas pelo Gerente de Projetos (GP),o qual também é responsável por gerar os relatórios de acompanhamento. O progressodas atividades é avaliado por diferentes indicadores, os mais comuns se referem a tempo,custo, homem-hora e percentual do escopo realizado. O cliente não participa ativamentedo desenvolvimento do projeto, assumindo um papel passivo e recebendo informações1 Momento quando se conclui uma entrega de parte (ou fase) do projeto, funciona como uma previsão e

meta para a equipe.


sobre andamento do projeto através do GP (EDER et al., 2015). Os métodos tradicionaistambém são conhecidos por permitirem ser aplicados a qualquer tipo de projeto e seremmais seguros, pois requerem maior planejamento antes do início do projeto. As melhoresaplicações para as abordagens tradicionais são projetos nos quais geralmente o escoponão muda no decorrer da execução como, por exemplo, na construção civil. A Figura 3apresenta os principais itens considerados no gerenciamento de projetos tradicionais naárea do exemplo apresentado.

Figura 3 – Características do gerenciamento de projetos tradicionais.

Fonte: MENEZES (2018)

Por volta dos anos 70, devido ao aumento da complexidade e visando diminuir osproblemas recorrentes de "codificar e corrigir", foram implementados os primeiros métodosde gerenciamento de projetos no âmbito do desenvolvimento de software, por exemplo, omodelo waterfall, que posteriormente foi definido como um método tradicional (SHARMA;KOTWAL, 2016). Neste modelo o gerenciamento envolve muita disciplina e técnicas decontrole, as abordagens das fases de ciclo de vida do projeto são facilmente reconhecidas,como a coleta de requisitos, análise, arquitetura, desenvolvimento, teste e aceitação. Asatividades são completadas uma após a outra, ou seja, sequencialmente na ordem deplanejamento.

Balaji e Murugaiyan (2012) definem que não é necessário apenas desenvolver ocódigo, mas também uma documentação abrangente em cada fase, com o objetivo deajudar a entender de forma abstrata o funcionamento do código. A cada fase do projetosão gerados artefatos, o quais podem ser: declaração de escopo do projeto, documento devisão, Estrutura analítica do projeto (EAP), matriz de rastreabilidade dos requisitos, etc.

A abordagem assume que os eventos que afetam o projeto são previsíveis e asfases completadas não necessitam ser revisadas. Um dos pontos positivos do modelo, éque são estabelecidos exatamente a sequência de passos para andamento do projeto, bemcomo a importância dos requisitos. Em contraponto, suas limitações são as já explanadasanteriormente sobres métodos tradicionais: os clientes geralmente não conseguem definircompletamente todos os requisitos no início do projeto e o tempo elevado para entrega da


primeira versão do software funcional (BALAJI; MURUGAIYAN, 2012). Na Figura 4 éapresentado o fluxo de execução dos projetos de desenvolvimento de software utilizando omodelo waterfall.

Figura 4 – Modelo waterfall de desenvolvimento de software.

Fonte: http://users.csc.calpoly.edu/ jdalbey/

2.2.1 Guia PMBoK

O guia PMBoK, do PMI (Project Management Institute), classificado como umaabordagem tradicional, orienta sobre boas práticas de gerenciamento de projetos e podeser aplicado à maioria dos projetos. Estas práticas visam antever e mostrar como gerenciaras dez áreas de conhecimento, sendo importante destacar, que por se tratar de um guia, elesugere o que pode ser feito, mas não o que deve ser feito (GUIDE, 2017, grifo nosso).As áreas são relacionadas a escopo, cronograma, custos, qualidade, recursos, comunicações,aquisições, riscos, relacionamento com stakeholders e integração (MENEZES, 2018). Todasestas áreas de conhecimento são tratadas através de um conjunto de 49 processos, que sãoorganizados nos grupos de processos: Iniciação, Planejamento, Execução, Monitoração deControle e Encerramento.


2.2.1.1 Ciclo de vida e fases de um projeto

Ciclo de vida do projeto são as sequências de fases pelas quais ele passa, do inícioa conclusão. As fases são um conjunto de atividades do projeto relacionadas de maneiralógica que culminam na conclusão de uma ou mais entregas com prazos definidos (GUIDE,2017). Todos os projetos têm um inicio e um fim, independentemente do setor de atividadee complexidade do trabalho envolvido. O ciclo de vida oferece uma sistemática básica parao gerenciamento de projetos e facilita a comunicação com os stakeholders, fornecendo umvínculo direto entre o projeto e os objetivos estratégicos da organização (CRUZ, 2013). Ociclo de vida é composto pelo início do projeto, organização e preparação, execução dotrabalho e encerramento do projeto. A Figura 5 apresenta como o ciclo de vida do projetose relaciona com o nível de custo do projeto em relação ao tempo.

Figura 5 – Ciclo de vida dos projetos.

Fonte: Cruz (2013)

2.2.1.2 Grupos de processos

Segundo MENEZES (2018), a visão de processos, quando associada a um projeto,é compreendido como um elemento que se repete, pode ser padronizado e, eventualmente,automatizado. O Guide (2017) afirma que cada processo de gerenciamento de projetosproduz uma ou mais saídas a partir de uma ou mais entradas, usando técnicas e ferramentasde gerenciamento de projetos apropriadas. A saída pode ser uma entrega ou um resultado,o qual visa atender uma demanda. A seguir são apresentados os cinco grupos de processosdo guia PMBoK e na Figura 6 como eles se relacionam com o ciclo de vida do projeto e asdez áreas de conhecimento.


• Iniciação - Grupo de processos realizados na concepção do projeto ou em uma novafase, obtendo autorização para o seu início.

• Planejamento - Grupos de processos realizados para definição do escopo e objetivosdo projeto iniciado, assim como as atividades necessárias para entrega do projeto.

• Execução - Grupos de processos realizados para execução das atividades planejadase satisfazer os requisitos do projeto.

• Monitoramento e Controle - Grupos de processos realizados para acompanhar,analisar, mensurar e controlar o progresso e desempenho do projeto, assim comoidentificar eventuais necessidades de mudanças.

• Encerramento - Grupos de processos realizados para validar o encerramento doprojeto, fase ou contrato.

Figura 6 – Relacionamento entre os principais fundamentos do guia PMBoK.

Fonte: Guide (2017)

O TAP é o documento resultado de um dos processos que fazem parte do grupode processos de iniciação. Esse documento tem a finalidade de reconhecer formalmenteo início do projeto e pode identificar informações relevantes, dentre as quais destacam-se: identificar stakeholders e equipe envolvida, restrições, premissas, riscos preliminares,


fornecer justificativa e criar um vínculo direto entre o projeto e os objetivos estratégicosda organização. O documento pode ser realizado uma vez ou em pontos pré-definidos doprojeto. O TAP, apesar de tradicional, é um documento que foi incorporado pelos métodoságeis (ARANHA, 2016).

Outro documento importante e muito usado, é o termo de encerramento do projeto(TEP), o qual é resultado do processo de encerrar o projeto ou fase, seus principais objetivossão identificar se os critérios de sucesso do projeto foram satisfeitos, a formalização doaceite das entregas, desmobilizar a equipe de projeto e, principalmente, melhoria contínua,ao registrar as lições aprendidas para que sejam usadas nos projetos futuros da organização(GUIDE, 2017).

O conjunto de boas práticas do guia PMBoK se torna evidente quando a combinaçãodos processos, aplicados nas áreas de conhecimento, agregando valor para os projetos.Os processos são úteis para gerenciar cada uma das áreas de um projeto, em cada etapadistinta, formando um conjunto completo de gerenciamento eficiente e eficaz (CRUZ,2013).

2.3 Métodos ágeis

Buscando introduzir uma nova visão sobre como desenvolver software, a partirdos anos 90, surgiram os métodos ágeis. Uma das características que diferenciam osmétodos ágeis dos tradicionais são o enfoque maior nas pessoas e não em processo, e o seuconjunto de valores, princípios e práticas (PRIKLADNICKI R. WILLI, 2014). O conceitode agilidade está relacionado a capacidade de se adaptar às mudanças que ocorrem duranteo desenvolvimento, sendo elas técnicas, de recursos humanos ou de escopo (MENEZES,2018).

Apesar do surgimento dos primeiros métodos ágeis serem datados da década de90, por exemplo, RUP (Rational Unified Process) em 1994, Scrum em 1995, ExtremeProgramming (XP)2 em 1996, entre outros (MENEZES, 2018). O termo método ágilse tornou popular no ano de 2001, quando um grupo de dezessete especialistas emdesenvolvimento de software, que representavam os principais métodos ágeis já existentesna época, se reuniram em Utah, nos Estados Unidos, para criar a Aliança Ágil3 e oManifesto Ágil.

O Manifesto Ágil definiu quatro valores e doze princípios, de forma a guiar as

2 Processo de desenvolvimento de software organizado em torno de um conjunto de valores e práticas,assegurando que o cliente receba um alto retorno do investimento em software. Seus valores são feedback,comunicação, simplicidade e coragem (TELES, 2017).

3 Organização sem fins lucrativos comprometida em apoiar pessoas que exploram e aplicam valores,princípios e práticas ágeis para tornar as soluções de desenvolvimento de software mais eficazes,humanas e sustentáveis (ALLIANCE, 2015).

2.3. Métodos ágeis 33

equipes de desenvolvimento de software, independente da metodologia utilizada. Ainda quecada método tenha práticas específicas, para ser considerado ágil, é necessário compartilhardos mesmos valores e princípios do manifesto, sendo os valores apresentados na Tabela 2.

Tabela 2 – Valores do manifesto ágil.

Valores Mais queIndivíduos e interações Processos e ferramentas

Software em funcionamento Documentação abrangenteColaboração com o cliente Negociação de contratosResponder a mudanças Seguir um plano

Fonte: Beck et al. (2014)

Beck et al. (2014) afirma que mesmo havendo valor nos itens à direita, valoriza-semais os itens à esquerda. Esta frase é importante, pois existem especulações que os métodoságeis não possuem documentação ou contratos, o que não é verdade. Apenas os itens daesquerda são mais prioritários do que os da direita (PRIKLADNICKI R. WILLI, 2014).Os doze princípios de Beck et al. (2014) servem para complementar os valores, formandoos alicerces sobre os quais são construídos os métodos ágeis, sendo eles:

• Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua desoftware de valor;

• Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequama mudanças, para que o cliente possa tirar vantagens competitivas;

• Entregar software funcionando com frequência, na escala de semanas até meses, com prefe-rência aos períodos mais curtos;

• Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e diariamente,durante todo o curso do projeto;

• Construir projetos ao redor de indivíduos motivados, dando a eles o ambiente e suportenecessário, confiando que farão seu trabalho;

• O Método mais eficiente e eficaz de transmitir informações dentro de um time de desenvolvi-mento é através de uma conversa cara a cara;

• Software funcional é a medida primária de progresso;

• Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores eusuários devem ser capazes de manter, indefinidamente, passos constantes;

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

• Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito;

• As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis;

• Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam eotimizam seu comportamento de acordo.

Os métodos ágeis podem ser adotados com flexibilidade, adequando-se às necessida-des da empresa e do projeto. Relatórios produzidos pela empresa CollabNet VersionOne4,4 Empresa fornecedora de soluções de desenvolvimento e entrega de software sediada no sul de São

Francisco, Califórnia <https://www.collab.net/>.

https://www.collab.net/


no ano de 2016, mostram quais os métodos ágeis mais usados nos projetos de desenvolvi-mento de software. Pode-se observar, através da Figura 7, que o Scrum é o mais utilizado,seguido de outras três abordagens híbridas.

Figura 7 – Utilização dos métodos ágeis nos projetos de desenvolvimento de software.

Fonte: Versionone (2016)

2.3.1 Scrum

Scrum é um framework para desenvolver, entregar e sustentar produtos complexos(SCHWABER; SUTHERLAND, 2017). A origem do nome vem de uma jogada tradicionaldo Rugby, no qual durante a reposição da bola, o time trabalha em conjunto em prol deum objetivo comum. Através desta analogia de colaboração em equipe, foi dado o nome deScrum. O termo Scrum foi usado pela primeira vez nos anos 80, quando Hirotaka Takeuchie Nonaka Ikujiro, influenciados pelas melhores práticas dos princípios de desenvolvimentoLean, utilizado nas empresas da indústria Japonesa, como Toyota e Honda, desenvolveramuma estratégia flexível para o desenvolvimento de produtos (SUTHERLAND et al., 2011).O Scrum como existe hoje, e apresentado na Figura 8, foi desenvolvido por Ken Schwavere Jeff Sutherland, nos anos 90. Ele tem sido utilizado para projetos de desenvolvimentode software, hardware, sistemas embarcados, marketing e diversas outras áreas. Seufundamento é no empirismo, o qual afirma que o conhecimento vem da experiência e asdecisões feitas com base no que é conhecido (SCHWABER; SUTHERLAND, 2017). Ospilares fundamentais do Scrum são:

• Transparência - Os aspectos do processo devem ser visíveis para todos notime (SCHWABER; SUTHERLAND, 2017, grifo nosso) e todos devem compartilharde um entendimento comum.


• Inspeção - Os artefatos e objetivos devem ser frequentemente inspecionados, visandoidentificar os pontos de possíveis melhorias.

• Adaptação - Se a partir da inspeção é identificado que algo saiu do resultadoaceitável, o processo deve ser ajustado.

O Scrum é formado pelo Time Scrum e seus papéis associados, eventos, artefatos eregras. Cada componente serve para um propósito específico e é essencial para execuçãodo framework, conforme apresentado na Figura 8.

Figura 8 – Fluxo Scrum.

Fonte: Sutherland et al. (2011)

2.3.1.1 Papéis

O Time Scrum é formado por três papéis: Product Owner (PO), Time de Desen-volvimento (DevTeam) e Scrum Master (SM). O Time Scrum deve ser autogerenciável emultifuncional. Equipes autogerenciáveis têm autonomia para determinar como as ativida-des serão executadas, sem depender de gerência. Equipes multifuncionais têm todas ashabilidades necessárias para execução do projeto, sem precisar de outros colaboradores(SCHWABER; SUTHERLAND, 2017).

• Product Owner - É uma pessoa, responsável pelo valor do produto gerado peloDevTeam. Atua diretamente junto ao cliente. É o único com permissão para fazer agestão do Backlog do Produto (BP), priorizando os itens a serem desenvolvidos.


• Time de Desenvolvimento - Equipe de 3 a 9 pessoas, responsável por entregar osincrementos do produto no final de cada Sprint. São empoderados pela organizaçãopara organizar e gerenciar seu próprio trabalho.

• Scrum Master - É uma pessoa, responsável por garantir que o framework estásendo utilizado corretamente. Atua como líder-servidor do Time Scrum, apesar deestar no mesmo nível hierárquico dos demais membros. Auxilia o PO na gestãodo BP e facilita os eventos Scrum. Remove impedimentos e atua como coach doDevTeam. Geralmente, a pessoal que tem o papel de SM permanece com ele até ofinal daquele projeto (SCHWABER; SUTHERLAND, 2017).

2.3.1.2 Eventos

Os eventos são prescritos no Scrum para garantir regularidade e diminuir a necessi-dade de reuniões aleatórias. Todos os eventos possuem timebox definidos e, diferentementeda Sprint, que não pode ser encurtada, nem alongada, os demais eventos podem serencerrados assim que cumpridos os seus objetos, evitando desperdícios (SCHWABER;SUTHERLAND, 2017).

• Sprint - É um timebox de 1 mês, ou menos, no qual o DevTeam se compromete aentregar, no mínimo, um incremento do produto em funcionamento. Todos os demaiseventos ocorrem dentro do timebox da Sprint. Uma Sprint começa imediatamenteapós o término da anterior.

• Planejamento da Sprint - Reunião com timebox de 8 horas para Sprint de 1 mês.Para Sprint menor, o tempo é proporcionalmente menor. Reunião realizada no inícioda Sprint, tem a finalidade de planejar a Sprint. São definidos quais e como os itensdo BP serão entregues. Todo o Time Scrum deve estar presente.

• Reunião Diária - Reunião com timebox de 15 minutos. Geralmente realizada empé, em frente ao quadro de tarefas e sempre no mesmo local e horário, para diminuira complexidade. Cada membro do DevTeam informa o que fez no dia anterior, oque vai fazer no dia atual, e se tem algum impedimento para sua atividade. Todo oDevTeam deve estar presente.

• Revisão da Sprint - Reunião com timebox de 4 horas para Sprint de 1 mês. ParaSprint menor, o tempo é proporcionalmente menor. Reunião realizada no últimodia da Sprint, tem a finalidade de inspecionar o incremento do produto realizadona Sprint atual, assim como adaptar o BP, se necessário. Todo o Time Scrum deveestar presente e, eventualmente, stakeholders convidados pelo PO.

• Retrospectiva da Sprint - Reunião com timebox de 3 horas para Sprint de 1mês. Para Sprint menor, o tempo é proporcionalmente menor. Reunião realizada


logo após o término da Revisão da Sprint, tem o objetivo de inspecionar como foia última Sprint em relação a pessoas, relacionamentos, processos e ferramentas epropor adaptações para Sprint seguinte (SCHWABER; SUTHERLAND, 2017).

2.3.1.3 Artefatos

Segundo Schwaber e Sutherland (2017), os artefatos do Scrum representam otrabalho ou valor para prover transparência e oportunidade para inspeção e adaptação.Abaixo são apresentados os principais artefatos do Scrum:

• Backlog do Produto - É uma lista ordenada de todos os itens do produto quedevem ser desenvolvidos ao longo do projeto. Está em constante mudança. Podeconter itens funcionais e não funcionais, sendo que os itens mais acima na lista, sãoos de maior prioridade. Nasce junto com a visão do produto e enquanto o produtoexistir, o BP vai existir, nunca estando completo.

• Backlog da Sprint (BS) - Conjunto de itens selecionados do BP para seremrealizados durante a Sprint, somados as tarefas derivadas de cada item. Nascedurante a reunião de planejamento e tem a duração de uma Sprint.

• Incremento - Soma de todos os itens do BP concluídos durante a Sprint. Todoincremento deve estar no estado de "Pronto".

• Definição de "Pronto" - É o termo utilizado para identificar quando um trabalhoestá completo, ou seja, está desenvolvido, testado e homologado, pronto para sercolocado em produção. O seu significado tem que ser compartilhado e entendido portodo o Time Scrum (SCHWABER; SUTHERLAND, 2017).

2.3.1.4 Planning Poker

A complexidade dos itens do BP devem ser estimados pelo DevTeam, a qual érecomendada utilização de técnicas como o Planning Poker (PP) para realizar esta ação.A técnica é baseada no consenso para estimar, onde cada membro da equipe recebe umconjunto de cartas com possíveis valores de complexidade para atribuir a cada item.Analisado o item, os membros individualmente escolhem a carta que acreditam ter ovalor mais coerente para a atividade avaliada. Após todos do time terem definido as suasestimativas de complexidade, as suas cartas são mostradas para toda a equipe. Caso ocorradiscrepância sobre os valores escolhidos por cada membro, os envolvidos argumentam sobresua escolha. E assim, acontecem novas rodadas de estimativas até que tenha convergênciaentre os valores avaliados de todos os membros.

As cartas possuem uma sequência de valores que podem variar, mas uma comgrande aceitação por parte do times ágeis é a sequência de Fibonacci, a qual é uma


sequência de números naturais, onde os dois primeiros números são 0 e 1 e, a partir deles,cada termo subsequente corresponde a soma dos dois anteriores, por exemplo: 0, 1, 2, 3,5, 8, 13. Uma potencial razão para utilização dessa sequência é a inerente incerteza naestimativa de itens maiores, por isso, na maioria das vezes, os times optam por utilizar asequência até o número 13 (BERNARDO, 2014).

2.3.2 Kanban

Kanban é um método para definir, gerenciar e melhorar serviços que entregamum trabalho, podendo ser produtos físicos ou software (ANDERSON; CARMICHAEL,2016). A palavra Kanban deriva do japonês e significa "cartão visual", o termo vem sendoutilizado há décadas pelo sistema de produção Toyota, de modo a visualmente controlar eequilibrar a linha de produção (BOEG, 2011). O Método Kanban usado nos dias de hoje,principalmente para desenvolvimento de software, foi nomeado por David Anderson em2007, durante apresentações de abordagem de gerenciamento de projetos na Microsoft eCorbis (ANDERSON; CARMICHAEL, 2016).

Kanban é responsável por tornar o fluxo de trabalho visível, no qual os itens detrabalho se movem através de diferentes estágios, de modo a otimizar o desenvolvimentodo produto entregue aos clientes. Com o fluxo de trabalho visível é possível tomar decisõesembasadas e visualizar as consequências dessas decisões, além de identificar as oportunidadede melhoria, criando uma cultura Kaizen5, na qual a melhoria contínua é responsabilidadede todos (BOEG, 2011).

Sabendo que os indivíduos de uma organização são, geralmente, resistentes àmudanças, o princípio do Kanban de "começar com o que você faz agora", é uma ferramentautilizada como catalisadora em uma transformação ágil. A resistência é reduzida aorespeitar as práticas atuais, não impondo as modificações, mas concordando em perseguira melhoria contínua ao longo de todos os níveis da organização. A partir das atividadescorrentes, estabelece-se a base de desempenho e eficácia, a partir da qual as mudançasfuturas podem ser avaliadas (ANDERSON; CARMICHAEL, 2016).

2.3.2.1 Descrevendo o fluxo do sistema

Os processos podem ser definidos como uma série de etapas e suas políticasassociadas, como apresentado na Figura 9. O quadro retrata um fluxo, no qual o item detrabalho flui através dos estágios associados da esquerda para direita. Se não se tratar deuma equipe distribuída, o ideal é que o quadro de tarefas seja físico, visto que deixá-lofrente a frente com a equipe aumenta consideravelmente a transparência. A medida que

5 Melhoria contínua de um fluxo completo de valor ou de um processo individual, a fim de se criar maisvalor com menos desperdício (IMAI, 1994).


a maturidade da equipe evolui e o volume da dados cresce proporcionalmente, pode serinteressante ter uma cópia virtual do quadro (BOEG, 2011).

Figura 9 – Quadro Kanban.

Fonte: Anderson e Carmichael (2016)

Algumas condições devem existir para o fluxo ser considerado um sistema Kanban:

• Work in progress (WIP) - A quantidade de itens dentro do sistema, em execução,independente do momento, é considerado WIP. Deve ser limitado em cada estágiode atividade entre o comprometimento e o ponto de entrega, geralmente na partesuperior do quadro, de modo a ser selecionado através da experiência da equipe aolongo do desenvolvimento, sempre tendo em mente deixar o processo mais eficiente.

• Comprometimento - São os itens acordados entre cliente e empresa que devemser entregues. Antes do ponto de comprometimento pode existir uma área chamadade Pool of Ideas, onde ferramentas como brainstorming6 elencam os itens que podemser selecionados ou não para área de comprometimento.

• Ponto de entrega - É o local onde ficam armazenados os itens consideradoscompletos (ANDERSON; CARMICHAEL, 2016).

O design do quadro pode evoluir ao longo do tempo, de acordo com aumento damaturidade da organização. Raias podem ser criadas entre as colunas, de modo a distinguiros estados dos itens dentro das etapas, por exemplo podemos ter uma raia diferenciadapara os itens vinculados aos bugs7 do sistema. A inserção de políticas são boas práticas6 Técnica usada para levantar ideias de soluções de problemas ou para criar coisas novas (FARINAZZO,

2018).7 Termo usado quando é encontrado um erro em algum programa, ou seja, quando algum programa age

de maneira inesperada ou fora da normalidade esperada (ANDRADE, 2016).


para validar a transição dos itens de trabalho entre os estágios, a Figura 10 apresentaum quadro Kanban de uma organização de alta maturidade. Ao estabelecer os limites deWIP, é garantido que não se pode sobrecarregar o sistema com mais trabalho que a suacapacidade, sendo assim, é necessário que se finalize um trabalho existente antes de umnovo entrar em execução, isso torna um sistema em que os itens são puxados pela equipee não empurrados com base em previsões ou demandas (BOEG, 2011).

Figura 10 – Quadro Kanban de maior maturidade da equipe.

Fonte: Boeg (2011)

2.4 Métodos híbridos

O mercado possui empresas com diferentes características produtivas, logo nãoexiste uma abordagem de gerenciamento de projetos que seja perfeita para todos os seustipos de projetos. As abordagens de gerenciamento de projetos não são mutuamenteexclusivas ou se contrapõem, podendo ser combinadas para obter melhor eficiência. Nestesentido, surgiram os chamados métodos híbridos que, segundo MENEZES (2018), procuramselecionar as melhores práticas considerando restrições e características de determinadosambientes organizacionais e para determinados projetos.

Em uma pesquisa realizada no Massachusetts Institute of Technology (MIT), com856 profissionais que representavam 76 países e mais de 800 projetos de diferentes áreas deatuação, foi identificada a consistência no arranjo de práticas de abordagens ágeis com astradicionais. Muitos dos projetos de grande porte avaliados, por exemplo, utilizavam osmétodos tradicionais para gerenciar orçamentos e marcos, enquanto utilizavam os métodoságeis, como o Scrum, para desenvolvimentos internos (MENEZES, 2018). Conforme

2.4. Métodos híbridos 41

apresentado anteriormente na Figura 7, a mesclagem de diferentes práticas ágeis tambémjá vem sendo amplamente utilizadas.

Em Cruz (2013), o autor apresenta uma forma de integração entre o PMBoK eScrum. Na Figura 11 é mostrado um exemplo do ciclo de vida do projeto com base no seumodelo, onde é possível observar como as duas práticas podem ser usadas em conjunto.Alguns processos do guia podem ser usados antes, durante e depois do time iniciar aexecução do Scrum. Por exemplo, usando o TAP na iniciação e o TEP no fim do projeto.

Figura 11 – Ciclo de vida de projeto com Scrum e PMBoK.

Fonte: Cruz (2013)

Outro estudo, realizado por Conforto e Amaral (2016), afirma que nos últimosanos, devido um novo ambiente de inovação disruptiva, a forma do desenvolvimento deprodutos em diversos tipos de indústrias tem mudado, requerendo novas estratégias eferramentas para combinar simplicidade, velocidade e flexibilidade. Essa abordagem dedesenvolvimento de produtos tem explorado os métodos ágeis para lidar com a inovação edinamismo de certos tipos de projetos.

Em contraponto, em razão da complexidade do desenvolvimento ser proveniente dediversas fontes, como a incerteza na tecnologia, o número de componentes utilizados, entreoutros, essas indeterminadas características do projeto podem prejudicar a capacidade daequipe em trabalhar com os requisitos em evolução, sendo recomendado, nesses casos, umacoleta mais precisa dos requisitos nos estágios iniciais. A partir desta premissa, Conforto eAmaral (2016) apoia a utilização de métodos tradicionais nas fases de especificação dodesenvolvimento do produto e afirma que o dilema sobre qual método de gerenciamentode projeto é o melhor, pode ser resolvido através de um balanceamento do uso de ambos.Dado a natureza cada vez mais dinâmica dos projetos, é necessário a utilização de métricaspara auxiliar no acompanhamento e desenvolvimento do produto.


2.5 Métricas

Não existe uma métrica8 específica que vai indicar se o seu projeto está indo nocaminho que deveria. A melhora do desempenho do time vai acontecer conforme foremocorrendo os ajustes na sua operação em intervalos regulares. Coletar e analisar dados emforma de métricas é uma maneira de conhecer o comportamento da equipe e, assim, terinformações embasadas visando prover ações para sua melhoria.

As métricas ágeis aplicadas no desenvolvimento de software são usadas em ciclos,em paralelo com o desenvolvimento do produto, e podem ser divididas nas seguintes etapas:coletar os dados, analisar e transformar os dados em informação, aplicar melhorias noprocesso com base na informação obtida e monitorar os dados afetados após aplicação dasmelhorias (DAVIS, 2015). Este ciclo é mostrado na Figura 12.

Figura 12 – Ciclo PDCA de uma métrica ágil.

Fonte: Davis (2015)

Geralmente, os dados são coletados do software de rastreamento de projetos, porexemplo, JIRA Agile, Trello, Microsoft Project ou do software de controle de versões,como GitHub, GitLab, Bitbucket etc. Algumas equipes com alto nível de maturidadeainda podem se beneficiar de dados oriundos do sistema de integração contínua ou dosistema de monitoramento de aplicações. A integração contínua é uma prática em queos desenvolvedores, com frequência, juntam suas alterações de código em um repositóriocentral, o qual se torna um estágio de criação ou integração do processo de lançamento desoftware, além de originar um componente de automação. Ela também é uma ferramentapoderosa para que os testes automatizados verifiquem o código antes de enviar o incrementode software para o testador, evitando-se assim, reteste e desperdício de tempo.

Uma métrica muito utilizada por equipes que usam Kanban é o CumulativeFlow Diagram (CFD), a qual representa a quantidade de trabalho em um determinadoestado, mostrando chegadas, tempo na fila, quantidade na fila e partida (ANDERSON;

8 Termo ligado à metrificação, identificado como um conjunto de regras para a medição de resultados deesforços em números (DAVIS, 2015)

2.5. Métricas 43

CARMICHAEL, 2016). A seguir são apresentadas algumas das métricas ágeis maisaplicadas em projetos de desenvolvimento de software.

2.5.1 Velocidade

Velocidade é uma das métricas mais utilizadas por times ágeis que usam o Scrum.Basicamente, é a quantidade de trabalho realizado em relação a um determinado intervalode tempo, geralmente uma Sprint, que varia de uma a quatro semanas, dependendo daconfiguração adotada pela equipe. A unidade de trabalho pode ser pontos de complexidade9,número de tarefas ou qualquer outra característica que faça sentido para a equipe.

Os dados para cálculo da velocidade são obtidos do sistema de rastreamento doprojeto. Esta métrica fornece informações importantes para equipe, tendo como destaque,tornar visível, através do gráfico burndown, vide subseção 2.5.2, se o time está no ritmo idealpara a entrega do trabalho comprometido para o ciclo atual. A velocidade pode ser usadacomo referência para estimativa da seleção do trabalho para as próximas iterações, vistoque após alguns ciclos de estimativas o time vai identificar qual o seu ritmo de trabalho. Épossível constatar também se as estimativas estão ocorrendo adequadamente, pois caso otime altere bruscamente a sua velocidade durante Sprints em sequência, pode ser indíciode que os itens de trabalho estão sendo subestimados ou superestimados, necessitandoajustes.

Alguns fatores podem influenciar na velocidade da equipe, por exemplo, a mu-dança na sua formação, pois aumentar ou diminuir a quantidade dos seus membros,consequentemente se altera a relação de homem-hora disponível no projeto. Assim comonovos membros, possivelmente, terão menos conhecimento sobre o assunto, acarretandoem uma demora de algumas Sprints até que a velocidade volte ao patamar padrão daequipe anterior. Também deve se levar em consideração o surgimento de novas tecnologias,pois isso pode influenciar na velocidade, visto que os membros terão que aprender essatecnologia e desenvolver, simultaneamente (DAVIS, 2015).

2.5.2 Gráfico burndown

O gráfico burndown mostra a quantidade de trabalho feito na Sprint, assim como aquantidade de trabalho que ainda resta. Geralmente, é usado a velocidade como dadosde entrada, os quais são retirados do software de rastreamento de projetos. Essa métricafornece informação sobre a possibilidade do time completar o trabalho no tempo disponível,sendo uma forma de acompanhar sua produtividade durante o andamento da iteração(DAVIS, 2015).

9 Unidade subjetiva utilizada por times de desenvolvimento para estimar o esforço necessário paradesenvolver os itens do backlog (DUTRA, 2011)


Conforme apresentado na Figura 13, o eixo horizontal do gráfico é a linha do tempo,o qual compreende o período da Sprint corrente, no eixo vertical a unidade apresentadasão pontos de complexidade. A série em verde mostra a velocidade ideal do time, servindocomo sua linha de referência. O cálculo se da através da relação entre o somatório dospontos de complexidade e o intervalo de tempo em dias úteis, resultando no ritmo ideal detrabalho diário. A série em azul é a velocidade real do time, ou seja, aquilo que de fatoestá sendo executado no decorrer da Sprint.

Figura 13 – Gráfico burndown.

Fonte: Autoria própria

Usando a velocidade ideal como referência, é possível perceber facilmente que casoa série da velocidade real esteja acima da linha base azul, o time está atrasado e, casocontrário, o time estará adiantado. Esta ferramenta é um grande aliado na gestão docronograma da equipe. Este gráfico geralmente é atualizado diariamente e deve refletirtodos os itens concluídos pela equipe (DAVIS, 2015, grifo nosso).

2.5.3 Lead time

Segundo Anderson e Carmichael (2016), o tempo que um item permanece no fluxoentre a área de comprometimento e o ponto de entrega é chamado de lead time. É umamétrica muito utilizada por times que usam o Kanban, onde o foco no throughput dosistema é grande. Quanto menor o lead time do sistema, maior será o throughput, ou seja,mais rápido os itens serão entregues. Os dados para esta métrica são retirados do softwarede rastreamento de projetos. O lead time está altamente relacionado com a eficiência dofluxo. De forma genérica, podemos dizer que nem todo o tempo que um item de trabalhofica em progresso é gasto com adição de valor. Em geral, boa parte do tempo é, na verdade,

2.5. Métricas 45

gasto esperando em filas. Nesse sentido é importante identificar onde estão os gargalos dotime para atuar especificamente neste estágio e, assim, diminuir o lead time.

Para Davis (2015) alguns times usam velocidade e lead Time em conjunto, pois sãométricas que dizem coisas diferentes, enquanto a primeira mostra o quanto o time podefazer em relação aquilo que pensava que podia, o lead Time indica a média de tempo queos itens demoram para estarem prontos. A combinação do lead Time com outras métricasfornece um excelente indicador de quão eficiente o time está sendo durante aquela etapado projeto.

2.5.4 Taxa de reincidência

A taxa de reincidência é a quantidade de movimentos, pelos itens de trabalho,em sentido contrário ao fluxo de execução, ou seja, aqueles que tiveram algum tipode problema, em relação aqueles que seguiram o fluxo normal. Geralmente os retornosacontecem nos estágios de testes, também chamados de Quality Assurance (QA). Essamétrica é importante, pois permite perceber se os itens estão sendo desenvolvidos comqualidade. Os dados também são obtidos do software de rastreamento de projetos. Se ataxa de reincidência é alta ou ocorre mudanças abruptas entre as Sprints, é indício quealguns problemas podem estar ocorrendo, por exemplo, pode estar havendo problema decomunicação interna entre o time; a definição de pronto das tarefas podem não estar claropara todos; as tarefas podem estar sendo apressadas devido a curtos prazos ou estão sendoalterados os requisitos do projeto durante a fase de execução (DAVIS, 2015).

47

3 ESTUDOS DE CASO

Este capítulo apresenta estudos de caso realizados em organizações da área daTecnologia da Informação (ou que possuam setores na área tecnológica), visando identificaras abordagens de gerenciamento de projetos utilizadas no mercado atualmente. Na seção 3.1é apresentado como ocorreu o desenvolvimento do formulário e sua aplicabilidade. Emseguida são mostradas as três organizações selecionadas para documentação nesta pesquisa,iniciando pelo TRE-SC, passando pela Intelbras e finalizando com a Neoway. Todas estasempresas autorizaram a publicação dos resultados apresentados neste trabalho.

3.1 Formulário de pesquisa

No intuito de realizar um levantamento de informações, a respeito dos métodosde gerenciamento de projetos usados atualmente pelas empresas da região da GrandeFlorianópolis, foi criado um formulário através do Google Forms. Este formulário contém 24perguntas, que mesclam questões de múltipla escolha para questões específicas, por exemplo,a respeito de quais são as abordagens de gerenciamento de projetos utilizadas e, questõesabertas, tendo como exemplo, o questionamento sobre a avaliação geral dos resultadosobtidos após adoção dos métodos ágeis. O documento completo está disponibilizado noApêndice B deste trabalho.

O formulário foi divulgado através das redes sociais do autor, solicitando quepossíveis interessados respondessem a pesquisa, e também através do envio direto paraintegrantes de equipes de desenvolvimento de software de diferentes organizações. Ospotenciais alvos para responder o documento foram os responsáveis por aplicar as práticasde gerenciamento de projetos, como GP, SM, PO ou membros do DevTeam.

Entre os dez formulários respondidos por diferentes organizações, foram estrategica-mente selecionadas três, as quais serão apresentadas individualmente a seguir. Entre elas,foi escolhido um órgão público, o TRE-SC, com o objetivo de fazer uma analogia coerentecom a CTIC, onde será aplicado este trabalho, uma empresa tradicional de grande porte,a Intelbras, no intuito de aferir que empresas com décadas de existência também vemusando a abordagem e, por último, a Neoway, uma startup com crescimento exponencial,sendo o ambiente ainda mais propício para o gerenciamento ágil.

48 Capítulo 3. Estudos de caso

3.2 Tribunal Regional Eleitoral de Santa Catarina

O TRE-SC é um órgão público federal responsável por organizar e garantir alegitimidade do processo eleitoral brasileiro no âmbito do estado de Santa Catarina.O órgão, em conjunto com o Tribunal Superior Eleitoral (TSE), e demais regionaisdo Brasil, é considerado referência pela implementação de um dos sistemas de votaçãoeletrônico mais modernos e eficazes do mundo. Praticamente todos os softwares utilizados noprocesso eleitoral são desenvolvidos pelos próprios servidores do órgão. No TRE-SC, a áreaencarregada do desenvolvimento de software é a Coordenadoria de Soluções Corporativas(CSC), que possui um corpo técnico de 25 colaboradores, entre servidores do quadro,terceirizados e estagiários.

As informações sobre os métodos de gerenciamento usados para os projetos dedesenvolvimento de software do Tribunal foram obtidas, além do questionário de pesquisa,através de conversas in loco com a equipe, sendo a principal fonte de contato o Chefeda Seção de Governança e Planejamento de TI, profissional responsável por atuar comofacilitador dos times de desenvolvimento.

As equipes de desenvolvimento da CSC passaram a utilizar os métodos ágeis háaproximadamente 2 anos, visando a mudança de mindset dos membros do time, quetinham dificuldades para cumprir os prazos de entrega dos incrementos de software. Umdos projetos implementados com a abordagem ágil, de maior relevância e sucesso, foi oPortal do Eleitor1, sistema destinado a prover um canal de comunicação entre o TRE-SCe os cidadãos. Entre as funções do Portal do Eleitor estão as de registrar o interesse de sermesário voluntário e de enviar/confirmar o recebimento da carta de convocação do mesário.Somente nas Eleições de 2018, 33.938 mesários foram convocados através do sistema, oque representou 46,54% de todas as convocações do estado, o que denota grande aceitaçãopor parte dos seus usuários.

São utilizadas abordagens como Scrum, Kanban e o guia PMBoK para gerencia-mento dos seus projetos. O progresso do trabalho é monitorado através de um software derastreamento de projeto, o Trello, e por um quadro físico. Na Figura 14 é apresentadoo quadro no Trello após a finalização da 3a Sprint de um dos projetos implementadosusando ágil. É possível perceber, que as tarefas passam por diferentes estágios durante oseu ciclo de vida e que, nesta Sprint, todos os itens comprometidos foram finalizados.

As Sprints são geralmente de 3 semanas e uma das métricas obtidas do quadro évelocidade do time. O software de controle de versão usado é o Apache Subversion, maisconhecido como Apache Subversion (SVN). Os itens do BP são definidos em histórias deusuário2, sendo estimados em pontos de complexidade pela equipe do projeto.

1 Disponível em <https://www.tre-sc.jus.br/portal-eleitor-internet/loginExternoForm.faces>2 Descrição, em linguagem não formal, da funcionalidade que será valiosa para um usuário ou comprador

de um sistema ou software (COHN, 2004).

https://www.tre-sc.jus.br/portal-eleitor-internet/loginExternoForm.faces

3.3. Intelbras 49

Figura 14 – Quadro no Trello da equipe de desenvolvimento do TRE-SC.

Fonte: Tribunal Regional Eleitoral de Santa Catarina

O DevTeam é definido pelo Coordenador da CSC na abertura do projeto, bemcomo os papéis a serem desempenhados. Geralmente, o tamanho da equipe fica entre 6e 9 pessoas e existem papéis de Gerente de Projetos, Analista de Requisitos, Projetista,Desenvolvedor, Testador e Administrador de Infraestrutura de Sistemas (DevOps). Segundoo Chefe da Seção de Governança e Planejamento de TI, a avaliação dos resultados obtidosapós adoção das práticas ágeis foram excelentes tanto pela alta gestão de TI, quanto pelaequipe de projeto.

Conforme exposto, percebe-se que é adotada uma abordagem híbrida na organização,visto que há utilização de diferentes métodos de gerenciamento de projetos. Como resultado,podem-se destacar a satisfação da equipe, aumento da produtividade, redução do tempodas entregas ao cliente e, principalmente, a redução do esforço com gerenciamento dasmudanças nos projetos.

3.3 Intelbras

A Intelbras é uma empresa brasileira, multinacional, que atua nos mercados deSegurança, Telecomunicações e Redes. Com mais de 40 anos de história, atualmente contacom mais de 3 mil colaboradores, sendo aproximadamente 250 somente na área de Pesquisae Desenvolvimento (P&D). Todas as equipes de P&D possuem um GP responsável porfazer a gestão e acompanhamento dos projetos do seu departamento.

O formulário desta pesquisa foi respondido por dois GPs de diferentes áreas de P&D


da empresa, sendo um da Unidade de Segurança Eletrônica, no segmento de gerenciamentode imagens e o outro da Unidade de Redes, no segmento de redes com fio. Ambos osprofissionais vêm adotando as práticas ágeis nas suas equipes há aproximadamente 2 anos.Enquanto o GP 1 faz uso do Scrum e do Kanban, o GP 2 emprega Scrum, Kanban ePMBoK, o que caracteriza uma abordagem híbrida. Os ciclos de entregas são realizados acada duas e três semanas, respectivamente.

O JIRA agile é o software de rastreamento de projetos usado por ambos os GPs.Nenhum deles utilizam quadros físicos, pois a maioria das equipes de desenvolvimentopossuem colaboradores terceirizados atuando de forma remota. Nestes casos, é maiseficiente gerenciar os projetos somente com quadros compartilhados online, melhorandoassim a visibilidade para todos. Na Figura 15 é apresentado o quadro da Sprint 15 deum dos projetos da equipe do segmento de redes sem fio. Nele é possível perceber, alémda implementação de Scrum, o uso de divisões por estágios de desenvolvimento e WIP,característico de sistemas que usam o Método Kanban.

Figura 15 – Quadro no JIRA da equipe de desenvolvimento da Intelbras.

Fonte: Intelbras

O GP 1 obtém as métricas de Lead Time e quantidade de bugs do JIRA, já o GP2 utiliza gráficos Burndown e CFD. O GP 1 também retira métricas do repositório decontrole de versão de software, sendo elas: quantidade de linhas de código ou commits3

por membro da equipe por Sprint e quantidade de commits por ciclo de liberação doincremento do software para produção, também conhecido como release.

A política de formação das equipes para execução dos projetos são semelhantesem ambas as áreas. Na maioria das vezes, o GP executa o papel de SM, o colaborador3 Ação de submeter as últimas alterações do código fonte ao repositório através do software de controle

de versão (DAVIS, 2015).

3.4. Neoway 51

do setor de P&D com maior nível hierárquico e experiência é definido como PO, e dentrodo DevTeam um colaborador é indicado como QA, formando equipes em média de 6 a9 pessoas. Os itens do BP são criados através de histórias de usuários, sendo estimadosatravés de rodadas de PP pelo DevTeam, geralmente em pontos de complexidade ounos casos onde a demanda é direcionada para equipe de terceiros, em pontos de função.A Figura 15 também mostra que, em cada item, existe um número que indica que asestimativas são classificadas através da sequência de Fibonacci.

A conclusão dos dois GPs convergiu no sentido de que a empresa ainda precisaefetuar ajustes para ser mais ágil. Por se tratar de uma empresa de grande porte econservadora, a maior resistência para adoção do ágil é a mudança de mindset. Entretanto,após o início da utilização dos métodos híbridos, os segmentos já vêm apresentando umaevolução excelente. Os times estão conseguindo se organizar melhor e dar maior vazãopara as novas funcionalidades desenvolvidas, em especial as mais complexas.

3.4 Neoway

A Neoway é uma empresa de Big Data de Florianópolis, fundada em 2002 econsiderada a maior em inteligência de mercado da América Latina. Segundo o seuperfil nas redes sociais, a empresa conta com mais de 3.000 bancos de dados, tratadose atualizados diariamente. Entre os seus principais produtos está uma plataforma deassinatura, a qual os clientes conseguem obter informações valiosas a respeito do seuciclo de negócios, no sentido de vender mais e melhor ou contra riscos, fazendo análise depotenciais clientes e se mantendo em conformidade com leis e regulamentações. Com maisde 400 colaboradores e um produto inovador, a empresa vem em crescimento exponencial,sendo candidata a ser o próximo "unicórnio"brasileiro, ou seja, com valor de mercado maiorque um bilhão de dólares.

A pesquisa foi respondida por um desenvolvedor que atua em uma das equipesque tem a função de customizar o software da Neoway para cada cliente, desenvolvendonovas features de acordo com a demanda. A alta gestão da empresa dá liberdade paracada equipe utilizar as abordagens que julgarem mais eficientes. Nesta equipe vem sendoempregados Scrum e práticas do XP há aproximadamente 3 anos, onde o Customer Successfaz o papel de PO, definindo os itens do BP junto ao cliente, sendo também responsávelpor priorizar as atividades que serão executadas na Sprint de uma semana. O restante daequipe é fixa, com o SM sendo o líder e demais desenvolvedores, totalizando mais de novecolaboradores.

O software de rastreamento de projetos utilizado é o JIRA agile, não sendo usadoquadro físico, pois muitos colaboradores trabalham de forma remota. As métricas aplicadassão velocidade do time e a quantidade de horas consumidas por cliente. Para versionamento


do código é usado o Gitlab, que serve em conjunto com o Jenkins para fazer a IntegraçãoContínua. Os itens do Backlog são estimados pelo time em horas de trabalho e os aceitesdos itens feitos pelos próprios desenvolvedores checando o resultado na aplicação, ouatravés do Customer Success junto ao cliente.

Na avaliação do desenvolvedor, após adoção dos métodos ágeis, principalmentecom o Scrum, foi possível organizar melhor o BP e as entregas, deixando o processo maistransparente tanto para a equipe, quanto para o Customer Success representante do cliente.Percebe-se também que o nível de maturidade da equipe é alto face ao tempo de cadaSprint.

53

4 DESENVOLVIMENTO

Este capítulo descreve a implementação dos métodos de gerenciamento de pro-jetos usados na Coordenadoria de Tecnologia da Informação e Comunicação durante odesenvolvimento desta pesquisa. Inicialmente é apresentada a CTIC e informações sobrea estrutura tecnológica do IFSC-SJ. Em seguida é mostrado como ocorreu a seleção doprojeto tomado como foco de ação, a definição da equipe e a criação do BP. Posteriormente,são detalhados os métodos híbridos utilizados no gerenciamento do projeto, partindo-se doTAP, o detalhamento do desenvolvimento ao longo das Sprints e finalizando com o TEP.

4.1 Coordenadoria de Tecnologia da Informação e Comunicação

A CTIC é responsável por atender todas as demandas de serviços de tecnologia dainformação do IFSC-SJ, compreendendo um universo de aproximadamente 1.500 usuários,entre alunos, servidores e visitantes, com um parque de mais de 500 equipamentos deTI. Como a equipe está reduzida — atualmente conta com apenas quatro colaboradores— é necessário intercalar as demandas operacionais diárias de suporte aos usuários, comos projetos de melhoria da infraestrutura. Cada vez mais a organização caminha para atendência de mercado, que é a infraestrutura como código, aumentando-se assim a buscapor melhores práticas de desenvolvimento de software.

A escolha da CTIC na participação desta pesquisa surgiu a partir da sua demandaem adotar técnicas para gerenciamento dos seus projetos. Apesar de trabalharem porprojetos há algum tempo, muitas vezes eles acabavam não sendo efetivamente eficazes, pois,com frequência, ficavam parados em filas de espera aguardando priorização, resultado daalta quantidade de suporte consumir todo o tempo disponível da equipe. Em complemento,a CTIC também representava o case ideal para início de uma transformação ágil, vistoque já apresentava maturidade nas atividades desempenhadas, mas tinha bastante espaçopara evoluir quanto aos métodos de gerenciamento de projetos. Com o devido alinhamentode interesse e expectativa entre as partes, foi iniciada tal abordagem.

4.1.1 Escolha e descrição geral do projeto

Inicialmente, no mês de julho de 2018, em reunião de alinhamento com todos osintegrantes da CTIC, foi feito um nivelamento a respeito do conhecimento da equipe emrelação a projetos. Nela apresentou-se aos participantes definições do que é projeto, os mé-todos tradicionais e ágeis, bem como propostas de abordagens híbridas para gerenciamentode projetos. Nesta reunião, ainda identificou-se potenciais demandas da organização para

54 Capítulo 4. Desenvolvimento

aplicação dos métodos e, por fim, definido um projeto específico para foco de atuação.

Dentre os projetos disponíveis, foi escolhido pela equipe aMigração dos Módulosde Laboratório da Ferramenta Puppet1 para Ansible2, tal seleção motivou-se noalto grau de complexidade das atividades envolvidas e da necessidade da organização emrealizá-lo antes do final de 2018, o que estava de acordo com o prazo de término destapesquisa.

Atualmente o IFSC-SJ conta com nove laboratórios gerenciados pela ferramentaPuppet, sendo responsável por cerca de 100 módulos de configuração distintos. A equipe jáhavia executado um projeto menor anteriormente para migração de módulos administrativosdo Puppet para Ansible, os quais estavam em funcionamento e apresentavam consideráveisganhos de desempenho. Com o conhecimento adquirido, a proposta neste novo projetofoi migrar os módulos dos laboratórios a partir das boas práticas sugeridas da novaferramenta, deixando-os mais genéricos, estáveis e fáceis de aplicar manutenções. Com amigração, a organização procura obter incontáveis benefícios para a gestão dos laboratórios,principalmente no auxílio a futuros projetos de atualização dos sistemas operacionais ereformulação da estrutura de rede, as quais estão previstas para a próxima transição desemestre 2018-2/2019-1.

4.1.2 Definição dos papéis da equipe

Um dos principais frameworks utilizados no desenvolvimento do projeto foi oScrum, por este motivo a definição dos papéis da equipe ocorreram baseados no TimeScrum. O colaborador com o cargo de Coordenador da CTIC foi estabelecido como PO.Tal escolha teve fundamental importância, pois foi quem ficava responsável pela áreade negócio do projeto. O PO ainda teve a incumbência de atuar como ponto focal decontato do SM, sendo o principal aliado na mudança de mindset para filosofia Lean daorganização, e ainda fez parte do DevTeam, em decorrência da equipe reduzida no setor.O papel de SM foi desempenhado pelo autor deste trabalho. O DevTeam formou-se comtrês servidores da organização, incluindo-se o Coordenador que acumulava funções. Comesta configuração, constituiu-se um time multifuncional, ou seja, que compreende todasas competências necessárias para o bom desenvolvimento do projeto, sem depender decolaboradores terceirizados.

1 Software de código aberto para gerenciamento de configuração, utilizado para gerenciar estações físicase virtuais (WALBERG, 2008).

2 Software de código aberto que automatiza o provisionamento de software, o gerenciamento de configu-ração e a implantação de aplicativos (HOCHSTEIN; MOSER, 2017).

4.2. Implementação do projeto 55

4.1.3 Criação do Backlog do Produto

A primeira versão do Backlog do Produto surgiu em reunião entre o SM e o PO.Com o auxílio do SM, o PO definiu as atividades a serem desempenhadas, realizando suadocumentação na forma de itens. Durante a reunião, convergiu-se ao ponto comum de quea definição dos itens através de histórias de usuário não fazia sentido para o projeto doAnsible, pois a linguagem em nível de negócio não era aplicável naquele momento. Devidoo PO fazer parte do DevTeam, a linguagem técnica adotada na criação do BP não foi umproblema, visto que se tratava de um entendimento comum para todos os membros dotime.

Os módulos foram agrupados em sete categorias e priorizados, cada categoriarepresentada por um item do BP, conforme apresentado na Figura 16. Seguindo a ordemdo mais para o menos prioritário, os itens são: migrar módulos de programas em repositóriopadrão (MPRP), migrar módulos de programas em repositórios não oficiais (MPRNO),migrar módulos de programas de configuração normal (MPCN), migrar módulos deprogramas com file (compactados) 1 (MPFC1), migrar módulos de programas padrão doslaboratórios (MPPL), migrar módulos de programas com file (compactados) 2 (MPFC2)e migrar módulos de configuração virada semestre (MCVS).

A Figura 16 também reflete como ficou definido o fluxo de execução dos itens naprimeira versão do quadro Kanban físico, podendo ser explicado da seguinte forma: ositens a serem desenvolvidos na Sprint corrente são movimentados para a coluna BS, e odesdobramento das suas tarefas colocados na coluna to do. Os estágios in progress e intest são, de fato, onde as atividades estão sendo desenvolvidas e testadas, com restrição deque o mesmo item não poderia passar pelas duas etapas sendo executadas pelo mesmocolaborador. Depois de concluídas as tarefas, elas são movimentadas para o estágio dedone.

4.2 Implementação do projetoA seguir é apresentada uma sequência cronológica das Sprints realizadas durante

a implementação do projeto. O intuito será relatar as informações mais relevantes decada iteração, de modo a mostrar como ocorreu a evolução da organização no decorrer dotrabalho.

4.2.1 termo de abertura do projeto (TAP)

A reunião de kickoff 3 do projeto, realizada em 08 de agosto, teve como resultadoo TAP, processo recomendado pelo guia PMBoK, nele definiu-se formalmente o início3 Reunião de início do projeto, é o momento em que os participantes, validam os objetivos, recursos,

restrições, prazos, entregáveis e cronogramas referentes ao projeto em questão (GUIDE, 2017).


Figura 16 – Quadro físico com o Backlog do Produto.


da proposta, além de reunir informações importantes do projeto. Dentre as informações,são estabelecidos o objetivo principal, a situação atual, a justificativa, a equipe de desen-volvimento e suas funções, as partes interessadas, as restrições, as premissas, os riscos eorçamento do projeto. O documento original é apresentando no Apêndice A deste trabalho.

4.2.2 Sprint 1

No dia 12 de setembro, ocorreu a Reunião de Planejamento da Sprint 1 do projeto,com todo o Time Scrum presente, a primeira pauta foi a definição da quantidade de tempomínima que cada colaborador se dedicaria exclusivamente ao projeto diariamente. A partirdo consenso, foi escolhido um timebox de duas semanas para as Sprints, com quatro horaspara reunião corrente e definido a Reunião Diária para as 12h30min, pois foi o horário noqual todos os colaboradores estariam concomitantemente no local de trabalho.

Em seguida, o PO detalhou para o DevTeam cada item do BP, principalmenteaqueles mais prioritários e que tinham a probabilidade maior de serem selecionados para aprimeira iteração. Após o entendimento sobre os itens, o DevTeam identificou aquele demenor esforço para desenvolvimento e o estimou em um ponto de complexidade. Assim, apartir deste item, e usando relatividade, realizou-se a estimativa dos próximos itens do BPusando a sequência de Fibonacci. Nesta análise, o PO chegou a conclusão de que o itemMPRNO era muito complexo e poderia ser dividido em dois itens diferentes, fazendo adistinção entre módulos de programas para sistemas operacionais Linux e Windows. Logo,o DevTeam os estimou em dois e três pontos de complexidade, respectivamente.

Apesar desta rodada de estimativas não ser muito assertiva, pois era a primeira


vez que o DevTeam estava fazendo a atividade, o procedimento ocorreu sem problemas.Os três itens do topo do BP foram puxados para o BS. Este itens juntos somavam seispontos de complexidade, sendo o que o DevTeam entendia ser a quantidade de trabalhosuficiente para o primeiro ciclo de entregas, encerrando assim a primeira parte da reunião.

Na segunda parte da reunião, destinada a definição técnica de como o DevTeamfaria o desenvolvimento do trabalho, foram desdobradas cinco tarefas para cada item,totalizando 15 tarefas a serem executadas. A abordagem foi considerar que cada móduloa ser migrado seria uma tarefa atômica, visto que, teoricamente, cada desenvolvedorconseguiria executar em um dia de trabalho. As tarefas extraídas do mesmo item sãoconsideradas como de mesma complexidade, dado que já haviam sido categorizadas, apriori, pelo PO.

Para melhorar a visualização e identificação da conexão entre tarefas e item do BS,foram criadas raias no quadro físico. Na Figura 17 é apresentado como ele ficou organizadoao fim desta Reunião de Planejamento.

Figura 17 – Quadro físico ao fim da Reunião de Planejamento da Sprint 1.


Com o objetivo do SM acompanhar o trabalho do time constantemente, mesmonão estando no mesmo ambiente físico da equipe e visando facilitar a coleta de dados desteprojeto, criou-se um quadro virtual no Trello (TRELLO, 2018), o qual funcionava comoespelho do quadro físico. O time ficou responsável por fazer as movimentações dos post-itsno quadro físico e no Trello de forma sincronizada. O quadro virtual é apresentado naFigura 18, na qual é possível observar a utilização de labels para vincular as tarefas aositens.


Figura 18 – Quadro online da Sprint 1.


Baseado nas informações do Trello, o SM gerava as versões atualizadas do gráficoburndown diariamente (ao final do dia). Nos primeiros dias da Sprint 1, muitas tarefasforam iniciadas, porém não estavam sendo concluídas, o que acabou causando uma curvapraticamente flat no gráfico entre os dias 12 e 18 de setembro, conforme observado naFigura 19. Através destas informações, foi possível constatar o atraso do time com asentregas. Para mitigar o problema, o SM orientou o DevTeam para que começassem aterminar as tarefas em andamento, antes de iniciar as demais. A partir do dia seguinte, aquantidade de tarefas terminadas cresceu rapidamente e a velocidade do time se adequoua curva de velocidade ideal.

Em 25 de setembro, último dia da Sprint, foram realizadas as Reuniões de Revisãoe Retrospectiva, com time box de quatro horas para os dois eventos somados. Conformeapresentado na Figura 19, o time não concluiu 100% das tarefas. Apesar de ter seaproximado da estimativa inicial, uma das tarefas do item MPRNO Linux, a qual possuíatrês pontos de complexidade não estava completo e retornou para o BP. As demais tarefasforam validadas e movimentadas juntos com seus respectivos itens para done.

A velocidade final da equipe neste ciclo foi de 5,4 pontos de complexidade. A taxade reincidência foi medida através da quantidade de vezes que uma tarefa que estavanos estágios de done, in test ou in progress retornava para algum estágio anterior. NestaSprint a reincidência ocorreu apenas uma vez, quando uma tarefa in test voltou para inprogress, no total ocorreram 47 movimentações, culminando em uma taxa de reincidênciade 2,1%. Durante a revisão, o PO ainda identificou a necessidade de criar mais um item,


Figura 19 – Gráfico burndown da Sprint 1.


chamado de repositório com url verdadeiro (RUV), para o BP, pois se tratava de umafuncionalidade que facilitaria a migração dos módulos das próximas Sprints. Como setratava de uma nova priorização, tal atividade foi colocada no topo da lista.

Durante a reunião de retrospectiva desta Sprint, foi pontuada uma melhoria atravésda troca do nome do estágio de in test para code review, pois a pessoa que desenvolvia atarefa já realizava o teste de funcionamento em paralelo, assim o time adotou a política deque, necessariamente, outra pessoa da equipe faça o code review da tarefa, visando refatorare otimizar o código desenvolvido. O code review é uma das boas práticas estimuladas peloXP e foi adicionada à metodologia pela própria equipe, percebendo o seu grande impactona melhoria das etapas de (desenvolvimento/testes) durante a Sprint. Apesar de não serindicado que a mesma pessoa que desenvolveu o código faça os testes, neste projeto, por aequipe estar desenvolvendo arquivos de infraestrutura, onde uma tarefa era independenteda outra, na sua implementação o teste já era validado, por isso o time acreditava ser maisadequado trabalhar dessa forma.

O time percebeu também ser mais eficiente determinar a quantidade de horasmínima que cada colaborador atuava no projeto por Sprint, e não por dia. Desta formadiminuiria o tempo perdido com troca de contextos entre a mudança de foco nas atividades.Assim, nos dias dedicados ao projeto, era possível obter uma sequência maior de trabalho.Para monitorar a quantidade de horas exclusivamente no projeto, cada integrante doDevTeam passou a usar um cronômetro em sua mesa enquanto estavam trabalhando noprojeto.

Outra questão abordada, no intuito de se ter uma estimativa de tempo mais precisa,quando uma tarefa se encontrava no estágio de code review, se adotou a convenção de que


neste estágio a tarefa estava 80% pronta, pois segundo a equipe, grande parte do esforçode desenvolvimento já havia sido realizado. A nova abordagem melhorou a precisão dosgráficos burndown, pois os dados passaram a ser atualizados com maior frequência.

4.2.3 Sprint 2

A Sprint 2 começou no dia 26 de setembro com a reunião de planejamento daSprint. Nela, o DevTeam fez novas rodadas de PP para estimar os itens mais prioritáriosdo BP. Nesta ocasião, devido ao nível de maturidade ter crescido em consequência daexperiência adquirida na Sprint anterior, a decisão da complexidade de cada item foi maisdemorada. As discussões se tornaram mais técnicas e foram necessárias algumas rodadaspara que o time convergisse para uma estimativa comum.

Ao final, o DevTeam selecionou dois itens de cinco pontos de complexidade para oBS, se comprometendo a entregar dez pontos de complexidade, o que representava umaumento significativo em relação ao comprometimento da Sprint anterior de seis pontos. Oitem RUV, criado na última Reunião de Revisão, foi avaliado pelo DevTeam e percebeu-seque seriam necessárias a execução de duas tarefas para sua conclusão, enquanto o segundoitem foi desdobrado em sete tarefas, que representavam sete módulos distintos. Nestareunião criou-se outro artefato para auxiliar no controle dos módulos que ainda faltavamser migrados, o qual se configura de uma planilha compartilhada no Google Drive comtodo o Time Scrum, com o intuito de facilitar a edição compartilhada e se tornar ummecanismo de controle do BP.

Aproximadamente na metade do timebox da iteração, o SM percebeu a necessidadede realizar uma reunião de grooming4. Com a experiência da Sprint 1, o trabalho passou aser mais rápido e o time já havia finalizado um dos itens e estava na metade do segundo.Constatou-se que o time terminaria o trabalho com folga antes do fim da Sprint, e que umdos itens de cinco pontos havia sido superestimado. Sendo assim, ele foi rebaixado em doisníveis na escala de Fibonacci, ou seja, para dois pontos. Em contrapartida, mais um itemde cinco pontos foi puxado para o BS e quebrado em sete tarefas. Após as modificaçõesa Sprint ficou com um tamanho total de doze pontos de complexidade. É importantemencionar que a maioria dos times não costuma alterar a pontuação dos itens no meio daSprint, pois servem de lições para as próximas iterações.

O quadro atualizado após a reunião de grooming é mostrado na Figura 20. É possívelperceber que nesta versão foram utilizadas diferentes cores de post-its para melhorar avisualização, ou seja, as tarefas que faziam parte do mesmo item foram criadas com amesma cor, criando uma forma de label no quadro físico. No canto inferior direito do

4 Reunião com propósito de atualizar o BP, podendo ocorrer criações, alterações, novas estimativas oupriorização dos itens (SCHWABER; SUTHERLAND, 2017).


quadro foi colocada uma caixa para armazenamento dos itens e tarefas concluídas noencerramento da Sprints.

Figura 20 – Quadro físico da Sprint 2.


Na Reunião de Revisão todas as tarefas concluídas foram validadas com sucesso.O time atingiu uma velocidade de onze pontos de complexidade, praticamente o dobrodo último ciclo. As tarefas não terminadas voltaram para o BP, sendo todas do item decinco pontos que foi puxado na reunião de grooming, ou seja, de fato não houve atraso emrelação aos itens planejados inicialmente para a Sprint 2. A Figura 21 apresenta o gráficoburndown da Sprint 2, considerando o comprometimento de doze pontos de complexidadedesde o começo da iteração. É possível perceber que a velocidade real perseguiu a idealdurante todo o tempo, não chegando a ultrapassá-la em nenhum momento. Entretanto, seconsiderado o que havia sido estimado inicialmente, até a data do grooming, a velocidadereal seria maior neste período. Não ocorreu nenhum retrabalho durante esta Sprint, ficandoa taxa de reincidência em 0%.

Durante a Reunião de Retrospectiva foi consenso que um problema que estavaafetando o processo era a existência de um gargalo no estágio de code review. O problemadetectado foi que, novamente, o time estava frequentemente iniciando novas tarefas aoinvés de revisar as que já estavam em code review. Para resolver esta questão, foi inseridauma nova política de WIP, da forma que um membro do DevTeam só poderia iniciar umatarefa se não houvesse nenhuma outra em code review. Reforçando a conscientização detodos os membros do projeto em relação a política de code review (de que um membro doDevTeam não pode fazer a revisão de código da própria tarefa desenvolvida).

4.2.4 Sprint 3

Devido a participação da equipe em evento externo nos dias 10 e 11 de outubro,e o feriado do dia 12 de outubro a Sprint 3 iniciou somente no dia 15 de outubro. Na




Reunião de Planejamento, o item que não havia sido concluído na última iteração, juntocom suas três respectivas tarefas, foram inseridas nesta Sprint e estimado em um ponto decomplexidade. No BP ainda restavam três itens, sendo que dois deles, MPFC1 e MPFC2,naquele momento o PO julgou importante e coerente uni-los em um único. O DevTeamentão estimou este item em três pontos e o puxou para o BS. Por fim, o último item doBP foi estimado em oito pontos de complexidade e também adicionado. Com os três itenso tamanho total ficou em doze pontos de complexidade.

Na parte da reunião sobre a forma de execução do trabalho, não houve necessidadede discutir sobre o item de um ponto, pois já havia sido amplamente debatido na Sprintanterior. O item de três pontos teve divisão em dez tarefas, apesar de ser uma grandequantidade, a solução seguia o mesmo padrão para todas as tarefas, por isso foi consideradauma estimativa razoável pelo time. O último item debatido foi o de oito pontos, sendoquebrado em oito tarefas. De fato, era o item mais complexo realizado até então, poisalém de serem os módulos mais pesados, exigia um acompanhamento para validaçãomais próximo de uma das partes interessadas do projeto, os professores da Área deTelecomunicações. Com intuito de melhorar a visualização das datas das cerimônias, umcronograma com os marcos foi documentado e impresso na CTIC, o qual é apresentado naTabela 3 a seguir.

Tabela 3 – Cronograma da Sprint 3.

Sprint 3 - 15 a 26 de outubroEVENTOS DATA-HORA Timebox

Reunião de Planejamento 15/out 4 horasReunião Diaria 12h30min 15 min

Reunião de Revisão 26/out 2 horasReunião de Retrospectiva 26/out 2 horas


A primeira semana de trabalho ocorreu conforme planejamento, a velocidade dotime acompanhou a ideal durante todo o período. Em 20 de outubro já haviam sidoconcluídos mais de cinco pontos do ciclo. Entretanto, na segunda semana, o DevTeamparticipou de assembleias durante dois dias inteiros, e nos outros dias da semana tiveramque focar nas atividades de operação diária, que ficaram acumuladas devido os dois diasde indisponibilidade. O resultado é apresentado no gráfico burndown da Figura 22, o qualé perceptível que, possivelmente, se não tivessem ocorrido as atividades extraordinárias, aquantidade de tempo seria suficiente para conclusão do trabalho planejado.



No intuito de automatizar o processo de obtenção do lead time, foi adicionadouma extensão paga no Trello, chamada Screenful5 e, com ela, foi possível gerar o gráficoda Figura 23, o qual apresenta o comportamento desta métrica durante dez dias daSprint. O lead time foi calculado com base na soma do tempo que cada tarefa permaneceunos estágios de in progress e code review, diariamente, durante este período. É possívelvisualizar que, em consonância com a Figura 22, o lead time teve um aumento considerávelna segunda semana da Sprint, motivado pela situação exposta no parágrafo anterior. Outrainformação importante é que confirmou-se que o tempo gasto em revisão de código foiconsideravelmente maior do que em andamento, apesar de nesse estágio a tarefa já estaraproximadamente 80% concluída. A Figura 23 também mostra em destaque a média dolead time entre os dias 23 e 27 de outubro.

Os dois itens com menor complexidade estavam prontos ao final da Sprint e foramvalidados pelo PO na Reunião de Revisão. Entre as tarefas que estavam em done do item5 Esta ferramenta tem um período de teste por 21 dias, demais informações em <https://screenful.com/>

https://screenful.com/


Figura 23 – Lead time da Sprint 3.


de oito pontos, um deles não passou na validação e voltou para o BP, junto com as quatrotarefas que não haviam sido concluídas, enquanto que as demais tarefas concluídas foramvalidadas com sucesso. O PO dividiu este item em fase 1 e fase 2, sendo que a fase 2 ficariapara a Sprint 4. Nas 16 tarefas concluídas foram efetuadas 50 movimentações entre osestágios do quadro, sendo duas no fluxo contrário devido falta de aceitação nas etapas deteste ou validação na Reunião de Revisão. Portanto, a taxa de reincidência da iteraçãoficou em 4% nesta Sprint.

Durante a Reunião de Retrospectiva, um ponto levantado para melhoria do processofoi a adoção de uma nova política de programação em par, também adotada no XP. Istoporque ocorreram alguns casos em que um desenvolvedor perdia demasiado tempo namigração de um módulo por falta de conhecimento técnico, enquanto outro colaboradorpoderia auxiliar na solução em conjunto. Sendo assim, ficou definido que sempre que umatarefa demorasse mais de 1h30min para ser desenvolvida, seria feito a programação empar.

O SM também orientou o time que qualquer tipo de impedimento deveria serreportado nas Reuniões Diárias, para que os problemas como este fossem corrigidos deforma mais ágil. Outra melhoria foi na questão do planejamento melhor dos compromissosde participação de membros da equipe em relação à assembleias, treinamentos, férias, etc.,visando se comprometer com a quantidade do trabalho, já considerando com a diminuiçãoda produtividade devido a estes eventos, evitando-se assim o que ocorreu na segundasemana desta iteração (diminuição da produtividade devido participação em evento eatraso no início da Sprint).


4.2.5 Sprint 4

Na última Sprint restou apenas um item no BP, o qual havia ficado pendente dociclo anterior. Na Reunião de Planejamento o time usou como lógica a quantidade detrabalho que já havia sido concluído da atividade para estimar o item restante, sendoassim, cinco pontos de complexidade. O tamanho da Sprint permaneceu o padrão de duassemanas, com a quantidade de trabalho ficando folgada para esta iteração. A segundaparte da reunião fluiu sem problemas, visto que a equipe já havia debatido sobre o itemanteriormente e estava com excelente nível de maturidade em relação a este projetoespecífico.

Durante a execução das atividades, apesar de a quantidade de trabalho comprome-tida ser razoavelmente menor que nas iterações anteriores, possivelmente o prazo dilatadoestimulou um progresso menor no desenvolvimento. Através do gráfico da Figura 24 épossível perceber que o ritmo de trabalho acompanhou regularmente a velocidade ideal,apesar de o time já ter apresentado uma capacidade de produção maior. O time aproveitouo prazo para focar em outras atividades paralelas. Outro fator relevante foi que um dostrês colaboradores do DevTeam saiu de férias na segunda semana da Sprint, o que reduziua produtividade e, por ser uma iteração mais folgada, com apenas um item e cinco tarefas,não impactou negativamente na Sprint face o prazo dilatado.



Na Figura 25 é mostrado o gráfico do lead time durante toda a Sprint 4. Constata-seque os valores obtidos foram ainda maiores que na segunda semana da Sprint 3, o quetambém comprova a alta cadência adotada pela equipe no período.


Figura 25 – Lead time da Sprint 4.


No dia 09 de novembro, na Reunião de Revisão da Sprint 4, todas as tarefasrealizadas foram validadas com sucesso pelo PO, o qual já havia validado os requisitoscom as partes interessadas. Com isto, a migração de todos os módulos do projeto estavaconcluída. É possível o surgimento de mais algumas tarefas durante a configuração doslaboratórios na virada de semestre, pois apesar de todos estarem testados e validados,alguma atividade adicional poderá ser criada em relação ao ambiente, o qual não foipossível validar porque o semestre estava em curso, bem como não poderia ser feito semacarretar grande impacto negativo aos usuários do serviço.

4.2.6 Encerramento do projeto

Na última retrospectiva o time abordou as vantagens de ter adotado os métodoshíbridos no gerenciamento deste projeto, compilando as informações através de um do-cumento de encerramento, cujo template de referência foi obtido de Montes (2018) e éapresentado no Apêndice C. Este documento tem a finalidade de formalizar o encerramentodo projeto, apresentando o aceite da equipe em relação a escopo, prazo e qualidade. Foramdocumentados todas as lições aprendidas, visando compilar as principais experiências sobreo processo de gerenciamento do projeto. Nesta reunião ainda foram levantadas potenciaisaplicações para os próximos projetos da CTIC.

67

5 CONCLUSÕES

Este trabalho apresentou diferentes métodos de gerenciamento de projetos paradesenvolvimento de software, de modo a adaptar uma abordagem híbrida eficiente e eficazpara utilização na Coordenadoria de Tecnologia da Informação e Comunicação (CTIC)do IFSC-SJ. Como projeto piloto foi selecionada uma demanda mais urgente do setor e,consequentemente, da organização, a qual envolvia desenvolvimento de código e um prazode até 3 meses para sua conclusão. Inicialmente, um dos objetivos desse trabalho tambémseria a aplicação da metodologia na Empresa Júnior de Telecomunicações (TeleJr) doIFSC-SJ, porém a organização não tinha previsão de nenhum projeto de desenvolvimentode software para desenvolvimento que pudesse ser documentado no tempo disponível paraconclusão deste trabalho.

Através dos estudos de caso e pequisas bibliográficas realizadas, foi possível perceberque mesmo empresas privadas tradicionais e órgãos públicos de grande porte já adotampráticas híbridas no gerenciamento dos seus projetos de desenvolvimento de software, pois éuma área extremamente dinâmica, onde o escopo se torna pouco previsível face aos cenárioscom alto grau de incertezas e bastante susceptível à mudanças. As abordagens utilizadasvariam, entretanto uma combinação frequente encontrada nas organizações foi o uso doguia PMBoK, principalmente nas fases de iniciação e encerramento, e de práticas ágeiscomo Scrum e XP, associadas a ferramentas como o Kanban na fase de desenvolvimentosdos projetos. É importante salientar que todas as imagens dos projetos das organizações,as quais se encontram inseridas neste trabalho, foram fornecidas e aprovadas pelos gestorestécnicos das áreas envolvidas.

Durante a implementação do projeto na CTIC, foram utilizados dois processosdo guia PMBoK. O TAP, criado na fase de iniciação e o TEP, após a migração detodos os módulos. O principal intuito da criação destes documentos, além de fornecerinformações de alto nível para todas as pessoas que desejarem consultar, foi criar umabase de conhecimentos para os próximos projetos a serem executados. É importante frisar,que mesmo o manifesto ágil afirmando que software em funcionamento é mais valioso quedocumentação abrangente, o registro dos dois termos são exemplos de documentos que sãosimples e fácil de serem atualizados, agregando valor, e que podem ser aplicados na grandemaioria dos projetos, não servindo somente como mais uma ferramenta burocrática, massim com intuito organizacional.

Na execução do projeto, o Scrum foi o "coração", ditando o ritmo das entregas. OMétodo Kanban também foi um forte aliado durante o desenvolvimento, tornando o fluxodo sistema claro e transparente para a equipe, além de fornecer práticas que melhoraram a

68 Capítulo 5. Conclusões

agilidade, através de políticas de limitação do WIP. As adoções de políticas se mostraramaltamente recomendadas, visto que foram criadas pelos próprios membros do time aoobservarem situações que estavam prejudicavam o fluxo do sistema. Algumas práticas doXP surgiram nas Reuniões de Retrospectiva ao longo do projeto, como a revisão de códigoe programação em par, melhorando assim a qualidade do código desenvolvido. Através dainformação de leadtime das Sprints 3 e 4, constata-se que as tarefas demoravam um tempoconsideravelmente maior no estágio de code review do que em desenvolvimento, apesar deo time assumir a hipótese que ao chegar na revisão de código a atividade já estava 80%desenvolvida. Com isso é possível concluir que o estágio de code review foi um gargalo dosistema.

Um dos maiores problemas enfrentados no decorrer do projeto foram em relaçãoao tamanho reduzido da equipe, em conjunto com escalas de férias e licenças. Somenteapós um mês de criação do TAP foi possível reunir completamente a equipe do projetopara dar início a Sprint 1. Esse tipo de situação pode se tornar um empecilho paratornar organizações públicas mais ágeis. Tal cenário não ocorre em empresas privadas,pois os projetos são priorizados pela alta gestão e estão em sincronia com o planejamentoestratégico da organização. O fato do horário de trabalho não ser o mesmo entre osmembros da equipe acarretou em dificuldades para realizar as Reuniões Diárias todos osdias, apesar de terem sido realizadas na maioria dos dias no horário do almoço.

Outra questão que afetou a produtividade da equipe foi a necessidade de atuar emparalelo com as demandas de rotina de suporte, não podendo se dedicar integralmente aoprojeto. Geralmente, este problema também é minimizado em empresas privadas, ondeexistem equipes multidisciplinares trabalhando exclusivamente em projetos. Entretanto,apesar do tempo escasso, a equipe mostrou alto nível de maturidade e total comprometi-mento com as atividades. Foi possível observar o excelente clima organizacional e espíritode equipe dos colaboradores que procuram entregar a melhor experiência para os usuáriosda infraestrutura de TI do IFSC-SJ.

O projeto foi finalizado com êxito e alcançou os resultados pretendidos, podendo sercitados alguns parâmetros que indicam o seu sucesso: i) o encerramento foi antes do prazoestabelecido, em tempo para documentação deste trabalho e da transição do semestre2018-2/2019-1, o que era a necessidade da CTIC e do autor; ii) o escopo acordado foiintegralmente entregue, todos os módulos foram migrados, melhorados e testados; iii) eo resultado principal, agregou valor e conhecimento para a organização gerenciar maisadequadamente os seus projetos futuros.

Foi consenso entre a equipe as diversas vantagens obtidas após adoção dos métodoshíbridos, podendo-se destacar: a) uso do BP como forma de visualizar o todo do projetodesdobrado em pedaços menores, facilitando o foco na entrega de tarefas atômicas; b) otempo determinado e alocado para cada colaborador no projeto, minimizando o tempo

5.1. Trabalhos Futuros 69

perdido com interrupções; c) políticas de revisão de código para melhorar a QA. d)realização das estimativas dos itens em equipe, fornecendo uma previsibilidade maisprecisa do esforço necessário para execução de cada item; e) a mudança de mindset parafoco em entregas contínuas em curtos espaços de tempo.

A equipe já avalia o início de um novo projeto ainda este ano, utilizando a abordagemhíbrida para auxiliar no envolvendo de Analistas de outros Institutos Federais, de forma aintegrar especialistas em posições geográficas diferentes para atuação em uma demandaem comum de todos os Institutos, criando uma equipe de trabalho remoto. O autor destetrabalho ficou a disposição da CTIC para atuar como consultor e auxiliar na aplicação dametodologia.

5.1 Trabalhos Futuros

Devido a restrições de tempo, toda pesquisa precisa de um escopo limitado e,portanto, aspectos fora dos objetivos elencados serão propostos para serem abordados emtrabalhos futuros. Algumas sugestões de trabalhos futuros dentro da área de gerenciamentode projetos e desenvolvimento de software são:

• Implementar a abordagem híbrida de gerenciamento de projetos em uma equipe queesteja disponível para trabalhar em tempo integral no projeto, dando preferência porstartups que atuem exclusivamente com produtos de desenvolvimento de software;

• Dado a intenção da CTIC em realizar projetos envolvendo equipes de diferentesInstitutos Federais, implementar a abordagem híbrida para obter melhores resultadosatuando com equipes remota, além de não definir o PO como um membro doDevTeam, não dividindo seu foco em duas atividades distintas;

• Implementar a abordagem híbrida de gerenciamento de projetos na Empresa Júniorde Telecomunicações do IFSC-SJ;

• Melhorar as técnicas de QA, através de utilização de diferentes tipos de testes, entreeles, unitários, funcionais, automatizados e Test Driven Development (TDD), alémde ter um membro específico da equipe voltado para testes;

• Utilizar ferramentas de integração contínua, como o Jenkins, visando melhoriacontínua e agilidade no processo de colocar o incremento de software em produção,além de mitigar erros por longo tempo sem integração do código, evitando retrabalho.

• Utilizar simulações de Monte Carlo para criação de modelos estatísticos para melhorara previsibilidade do prazo de entrega dos incrementos de software;

70 Capítulo 5. Conclusões

• Obter informações do sistema de controle de versões para disponibilizar novas métricascomo, por exemplo, a quantidade de linhas de código alteradas e a quantidade decommits por Sprint por membro da equipe, correlacionando essas métricas com asdo software de rastreamento do projeto.

71

REFERÊNCIAS

ACATE. Acate. Agronegócio e tecnologia. Santa Catariana. Anuário, 2016. Citado napágina 22.

ALLIANCE, A. What is agile software development. web: http://www. agilealliance. org,2015. Citado na página 32.

ANDERSON, D. J.; CARMICHAEL, A. Essential Kanban Condensed. [S.l.]: Blue HolePress, 2016. Citado 4 vezes nas páginas 38, 39, 43 e 44.

ANDRADE, G. O que é um Bug. 2016. Disponível em: <https://www.infoescola.com/informatica/bug/>. Citado na página 39.

ARANHA, F. Conheça o Processo Criar a Visão do Projeto no Gerencia-mento Ágil de Projetos. 2016. Disponível em: <https://sitecampus.com.br/conheca-o-processo-criar-a-visao-do-projeto-no-gerenciamento-agil-de-projetos/>.Citado na página 32.

BALAJI, S.; MURUGAIYAN, M. S. Waterfall vs. v-model vs. agile: A comparative studyon sdlc. International Journal of Information Technology and Business Management, v. 2,n. 1, p. 26–30, 2012. Citado 2 vezes nas páginas 28 e 29.

BECK, K. et al. Disponível em:< http://www. manifestoagil. com. br/>. Acesso em,v. 30, 2014. Citado na página 33.

BENTLEY, C. Prince2: a practical handbook. [S.l.]: Routledge, 2012. Citado na página26.

BERNARDO, K. Planning poker: A técnica baseada no consenso. 2014. Disponível em:<https://www.culturaagil.com.br/planning-poker-tecnica-baseada-consenso/>. Citadona página 38.

BOEG, J. Priming Kanban: A 10 step guide to optimizing flow in your software deliverysystem. [S.l.]: Trifork, 2011. Citado 3 vezes nas páginas 38, 39 e 40.

CANDIDO, R. Escritório de gerenciamento de projetos (PMO) como estratégia decustomização de soluções na indústria eletroeletrônica. Tese (Doutorado) — Universidadede São Paulo, 2008. Citado 2 vezes nas páginas 26 e 27.

COHN, M. User stories applied: For agile software development. [S.l.]: Addison-WesleyProfessional, 2004. Citado na página 48.

CONFORTO, E. C.; AMARAL, D. C. Agile project management and stage-gate model—ahybrid framework for technology-based companies. Journal of Engineering and TechnologyManagement, Elsevier, v. 40, p. 1–14, 2016. Citado na página 41.

CRUZ, F. Scrum e PMBOK unidos no Gerenciamento de Projetos. [S.l.]: Brasport, 2013.Citado 3 vezes nas páginas 30, 32 e 41.

https://www.infoescola.com/informatica/bug/

https://www.infoescola.com/informatica/bug/

https://sitecampus.com.br/conheca-o-processo-criar-a-visao-do-projeto-no-gerenciamento-agil-de-projetos/

https://sitecampus.com.br/conheca-o-processo-criar-a-visao-do-projeto-no-gerenciamento-agil-de-projetos/

https://www.culturaagil.com.br/planning-poker-tecnica-baseada-consenso/

72 Referências

DAVIS, C. W. Agile Metrics in Action. [S.l.]: Manning Publications„ 2015. Citado 5vezes nas páginas 42, 43, 44, 45 e 50.

DUTRA, G. M. A gerência de projetos de software em duas perspectivas. 2011. Disponívelem: <http://bit.ly/gerProjetosSoftware>. Citado 2 vezes nas páginas 23 e 43.

EDER, S. et al. Diferenciando as abordagens tradicional e ágil de gerenciamento deprojetos. Production, SciELO Brasil, v. 25, n. 3, p. 482–497, 2015. Citado na página 28.

FARINAZZO, R. Brainstorming: o que é e como preparar uma reunião com resultadosreais. 2018. Disponível em: <https://resultadosdigitais.com.br/agencias/brainstorming/>.Citado na página 39.

GOUVEIA, R. O mindset dos líderes das empresas que evoluem como lean. 2017. Disponível em: <https://www.lean.org.br/artigos/540/o-mindset-dos-lideres-das-empresas-que-evoluem-com-o-lean.aspx>. Citado napágina 24.

GROUP, S. et al. Chaos report.(2002). West Yarmouth (MA): The Standish Group, 2008.Citado na página 22.

GUIDE, P. A guide to the project management body of knowledge. In: ProjectManagement Institute. [S.l.: s.n.], 2017. v. 6. Citado 6 vezes nas páginas 23, 29, 30, 31, 32e 55.

HOCHSTEIN, L.; MOSER, R. Ansible: Up and Running: Automating ConfigurationManagement and Deployment the Easy Way. [S.l.]: "O’Reilly Media, Inc.", 2017. Citadona página 54.

IMAI, M. Kaizen: a estratégia para o sucesso competitivo. [S.l.]: Imam, 1994. Citado napágina 38.

ISO, N. 10006, gestão da qualidade–diretrizes para a qualidade no gerenciamento deprojetos. Associação Brasileira de Normas Técnicas ABNT. Rio de Janeiro, 2000. Citadona página 25.

KERZNER, H. Strategic planning for project management using a project managementmaturity model. [S.l.]: John Wiley & Sons, 2002. Citado na página 25.

KOZAK-HOLLAND, M. The history of project management. [S.l.]: Multi-MediaPublications, 2011. Citado na página 25.

MENEZES, L. C. d. M. Gestão de projetos. [S.l.]: Atlas, 2018. Citado 6 vezes nas páginas27, 28, 29, 30, 32 e 40.

MONTES, E. Escritório de Projetos. 2018. Disponível em: <https://escritoriodeprojetos.com.br/>. Citado na página 66.

NPWIT. Comparando Agile X Waterfall. 2017. Disponível em: <https://www.npwit.com.br/2017/05/19/desenvolvimento-comparando-agile-x-waterfall/>. Citado na página 21.

PMBOK, G. Um guia do conhecimento em gerenciamento de projetos. Quarta Edição,v. 123, 2013. Citado 2 vezes nas páginas 21 e 25.

http://bit.ly/gerProjetosSoftware

https://resultadosdigitais.com.br/agencias/brainstorming/

https://www.lean.org.br/artigos/540/o-mindset-dos-lideres-das-empresas-que-evoluem-com-o-lean.aspx

https://www.lean.org.br/artigos/540/o-mindset-dos-lideres-das-empresas-que-evoluem-com-o-lean.aspx

https://escritoriodeprojetos.com.br/

https://escritoriodeprojetos.com.br/

https://www.npwit.com.br/2017/05/19/desenvolvimento-comparando-agile-x-waterfall/

https://www.npwit.com.br/2017/05/19/desenvolvimento-comparando-agile-x-waterfall/

Referências 73

PRESSMAN, R. S. Engenharia de software. [S.l.]: Makron books São Paulo, 1995. v. 6.Citado na página 21.

PRIKLADNICKI R. WILLI, F. M. R. Métodos Ágeis Para Desenvolvimento de Software.[S.l.]: Bookman, 2014. Citado 4 vezes nas páginas 21, 22, 32 e 33.

RIES, E. Lean Startup: Schnell, risikolos und erfolgreich Unternehmen gründen. [S.l.]:Redline Wirtschaft, 2014. Citado na página 22.

ROBIOLO, G.; GRANE, D. Do agile methods increase productivity and quality?American Journal of Software Engineering and Applications, v. 3, n. 1, p. 1–11, 2014.Citado na página 21.

ROYCE, W. W. Managing the development of large software systems: concepts andtechniques. In: IEEE COMPUTER SOCIETY PRESS. Proceedings of the 9th internationalconference on Software Engineering. [S.l.], 1987. p. 328–338. Citado na página 21.

SCHWABER, K.; SUTHERLAND, J. The scrum guide. Scrum Alliance, 2017. Citado 6vezes nas páginas 23, 34, 35, 36, 37 e 60.

SHARMA, M.; KOTWAL, I. A concept note on impact of agile software projectmanagement methods in midsized it product development companies. We’Ken-International Journal of Basic and Applied Sciences, v. 1, n. 3, p. 110–116, 2016. Citado2 vezes nas páginas 21 e 28.

SUTHERLAND, J. et al. The scrum papers: Nuts, bolts, and origins of an agile process.2011. Citado 2 vezes nas páginas 34 e 35.

TELES, V. M. Extreme Programming: Aprenda como encantar seus usuários desenvolvendosoftware com agilidade e alta qualidade. [S.l.]: Novatec Editora, 2017. Citado na página32.

TRELLO. Trello lets you work more collaboratively and get more done. 2018. Disponívelem: <https://trello.com/>. Citado na página 57.

VALLE, A. B. do. Fundamentos do gerenciamento de projetos. [S.l.]: Editora FGV, 2015.Citado 2 vezes nas páginas 25 e 26.

VERSIONONE. ANNUAL STATE OF AGILE REPORT. 2016. Disponível em:<http://info.versionone.com/state-of-agile-report-thank-you.html>. Citado na página34.

WALBERG, S. Automate system administration tasks with puppet. Linux Journal,Belltown Media, v. 2008, n. 176, p. 5, 2008. Citado na página 54.

https://trello.com/

http://info.versionone.com/state-of-agile-report-thank-you.html

Termo de Abertura do Projeto

Migração dos módulos de laboratório da ferramenta Puppet para Ansible

Controle de Versões

Versão Data Autor Notas da Revisão

1.1 08/10/2018 Natan Martins Jory Alterado Partes Interessadas/Riscos

1 Objetivos do projeto Migrar os módulos da ferramenta de gerenciamento de configuração Puppet para Ansible e otimizá-los com as boas práticas sugeridas da nova ferramenta, deixando-os mais genéricos, estáveis e mais fáceis de aplicar manutenções.

2 Situação atual e justificativa Atualmente o parque tecnológico do IFSC-SJ conta com 9 laboratórios gerenciados pelo Puppet, com cerca de 100 módulos de configuração distintos. O projeto de migração da ferramenta de gerenciamento para o Ansible iniciou primeiramente com a migração dos módulos administrativos. Estes já estão validados e em funcionamento. Agora com a experiência adquirida pretendemos fazer as migrações dos módulos dos laboratórios com melhor qualidade e agilidade.

3 Descrição geral Esse projeto vai auxiliar nos futuros projetos de atualização dos sistemas operacionais e reformulação da estrutura de rede que estão previstas para a virada de semestre 2018-2 para 2019-1. Com a nova ferramenta teremos incontáveis benefícios para a gestão dos laboratórios, principalmente reescrevendo os módulos para que fiquem mais genéricos, estáveis e fáceis de aplicar manutenções.

4 Equipe do projeto - Gabriel de Souza – Product Owner e Time de Desenvolvimento - Humberto José de Sousa - Time de Desenvolvimento - Natan Martins Jory - Scrum Master - Ricardo Martins - Time de Desenvolvimento

5 Partes interessadas do projeto

Instituição Participante Função

IFSC - SJ Professores de Tele Definir módulos a serem migrados

75

APÊNDICE A – TERMO DE ABERTURA

Termo de Abertura do Projeto


IFSC - SJ Equipe do Projeto Implementação do Projeto

IFSC - SJ Clayrton Monteiro Henrique Orientar TCC

IFSC - SJ Ederson Torresini Banca TCC

IFSC - SJ Pedro Paulo Corrêa de Souza Banca TCC

USJ Fernanda Rocha Banca TCC

6 Restrições - Alocação de tempo exclusivo da equipe para execução do projeto.

7 Premissas - Cada membro da equipe disponibilizar 6 horas por sprint para trabalhar exclusivamente no projeto. - Disponibilidade dos professores para ajudarem na definição do escopo das funcionalidades dos módulos a serem migrados.

8 Riscos - Não migração de todos os módulos até o final do ano. - Membros da equipe de férias/licença. - Equipe não conseguir alocar tempo para execução do projeto.

9 Orçamento do Projeto - Não será necessária aquisição de nenhum tipo de licença e equipamentos.

76 APÊNDICE A. Termo de Abertura

�� !"#$%!& �� &�'!&() �*(!(�(#+&$&(!�,(�&"*$�"�,-(./ �) �0!(1($2() �)��3 ,'$#�/ �)��3#!� �) �($#, �4(-(,�5(!-&,��6 !78�9!()#(,) ��"��,9�,2(!&(�)��0�$�' "#,&'(.:��*�$ �;,�-&-#- �<�)�!($�)��=(,-(�3(-(!&,(�>3("*#��=/ �6 �?@A�B�*��C#&�(�?�� 1!��5?- ) ��DE1!&) ��*(!(�F�!�,'&("�,- �)��G! H�- ��)��I��,J $J&"�,- �)��= �-K(!�A�L�C#��-& ,%!& �$�J(��"�- !, �)��MN�"&,#- ��*(!(��!�*!��,'2&) A

L�' ,-(- �) ��,-!�J&�-() 8�(*��(!�)�� 1!&9(-O!& 8�,/ ��!%�) '#"�,-() �, �033A�B�&)�,-&�&'(./ �)(��"*!��(8��,-!�-(,- 8�* )�!%��!�'&-()(8�"�)&(,-��*!?J&(�(#- !&P(./ �) ��#��9��- !��A�

L�!��#" �) �033��-%�)&�* ,EJ�$�, �$&,Q�(1(&+ R

2--*�RSS1&-A$7ST4#!M67

MA�U� �� V

TA�W��

XA�Y Z��

[A�\�]̂ �� Z ��_ ̀a�� bZ��Z�� c

defghijklhijmhineko

�5�, ��)��M�(,

�M�(�X�(, �

�X�(�p�(, �

�5(&��)��p�(, �

pA�Uq��̂��]̂ ��̂��_ ��Z�� bZ��r

�

�

�

�

�

77

APÊNDICE B – FORMULÁRIO

��

�� !!�"#

�$%&'(

�)*+,*+

�-./0)

�123&4(4�-&05&*((6+5�78-9

�:4*3'&4�;&6<4+�;4<4=0>(4+3�7:;;9

�?3@4&A�

B��C�� CD��E��FG�� CH��F��

I�J��KL�"�KL��KM��#

�N�O4(*+*

�P�O4(*+*O

�Q�O4(*+*O

�R�O4(*+*O

S��T��E��H�FU��D��VF�� CD��D��D��F�W��

�

�

�

�

�

X�� F�� H��Y��

�� !!�"#

�Z6&*

�[&4==0

�12%4=

�.6%&0O0\3�-&0]4%3

�̂4&O60+?+4

�?3@4&A�

N_��̀a��E�� b��D��

I�J��KL�"�KL��KM��#

�$6(

�cd0

78 APÊNDICE B. Formulário

��

�� !!�"� "� ##!$%

�&'()*+,-,'�,)�.+/'

�0'-,�.+/'

�12-3.+,-,'�,'�4256

�789:+*)6�;283,)<3�'�;2832=

�>2/2(-.+?'�@()<�A+-58-/�B>@AC

�D.E'8F�

�G��H�� H��I��

�� !!�"� "� ##!$%

�7+.E24

�7+.(-4

�J&K

�;+.42*L'.

�D.E'8F�

�M�� H�� H��I��

�� !!�"� "� ##!$%

�12-3.+,-,'�,'�(+3E-6�,'�*N,+5)�-(.'8-,-6�=)8�6=8+3.

�12-3.+,-,'�,'�(+3E-6�,'�*N,+5)O*)//+.6�=)8�/'/48)�,-�'P2+='

�12-+6�-6�=-8.'6�,)�*N,+5)�P2'�/-+6�6):8'/�-(.'8-QR'6

�12-3.+,-,'�,'�*)//+.6�=)8�8'('-6'

�S-T-�,'�=2((�8'P2'6.6�-*'+.-6

�D.E'8F�

�U��V�� W��

�

�

�

�

�

�X��H��Y��

�� !!�"� "� ##!$%

�Z'3)8�P2'�M�='66)-6

�M�-�X�='66)-6

�[�-�\�='66)-6

�Z-+)8�P2'�\�='66)-6

79

��

�� !"

�#$%&�'()&*%$

�+,$)$�-%�#$)

�.(/%&0�

�1��2�� 3��

4�5��67�!�67��68��"

�'*9

�:;)

�<��

�� !"

�=)>()$�-%�?)9@A%B*-,-%

�=)>()$�-%�CD>E;)

�.(/%&0�

�F��GH��3IJ� ��H��3�I�� I��

�

�

�

�

�

KL��MN ��3�3��GH�� O�P��HI��QGPR��SH 3��

4�5��67�!�67��68��"

�'*9

�:;)

K��II�� 3I��

�

�

�

�

�

KK��GH��II��T��I�U��V�H��H� � W��

�� !"

�X%>Y*>$

�ZD-$)>

�.(/%&0�

80 APÊNDICE B. Formulário

��

�� !��"

�

�

�

�

�

#��$ ��%��& ��'�� !��(

�

�

�

�

�

)�� *��+

,-.-/�0-�.1/2�3��

81

83

APÊNDICE C – TERMO DEENCERRAMENTO

Termo de Encerramento do Projeto


1 Objetivos Este documento tem a finalidade formalizar o encerramento do projeto de migração dos módulos de laboratório da ferramenta Puppet para Ansible, apresentando o aceite da equipe em relação a escopo, prazo e qualidade. Além de apresentar as lições aprendidas, visando compilar as principais informações relatadas e adotadas sobre o processo de gerenciamento do projeto durante as Reuniões de Retrospectiva.

2 Planejado x Realizado A análise de escopo entre planejado e realizado praticamente se sobrepõem. Além da própria migração dos módulos, em todos eles ocorreram melhorias, através de atualizações de versões de softwares e adotadas boas práticas de automação. Alguns módulos foram descontinuados, pois durante o desenvolvimento foi avaliado que não seriam mais utilizados. Outro ponto relevante é a possibilidade de surgimento de alguma issue durante a configuração dos laboratórios na virada de semestre, pois será quando de fato os módulos serão utilizados.

2.1 Os objetivos foram atingidos? Sim, todos os módulos previstos foram migrados.

2.2 Projeto foi entregue dentro do prazo? Sim. O prazo limite era na segunda quinzena do mês de novembro, entretanto, foi concluído no dia 09/11.

3 O Projeto Os métodos de gerenciamento de projeto adotados, de modo geral, tiveram excelente aceitação por parte da organização, a qual pretende continuar adotando as abordagens nos próximos projetos realizados. A seguir são elencados alguns pontos fortes e fracos considerados pela equipe ao longo do desenvolvimento do trabalho.

3.1 Pontos fortes

Agilidade através de entregas regulares em curtos espaço de tempo;

Através da estimativa dos itens foi possível efetuar um planejamento mais assertivo;

Nas reuniões de planejamento a análise crítica do time fornecia pontos de vista diferentes para solução da tarefa;

Alocação de tempo determinado para cada colaborador atuar no desenvolvimento do projeto;

Mudança de mindset da equipe para uma performance mais ágil;

Melhora na qualidade do código desenvolvido através de técnica do code review;

Melhora na visualização do escopo do projeto ao desdobrá-lo em tarefas atômicas.

Termo de Encerramento do Projeto


3.2 Pontos fracos

O horário de trabalho não concomitante da equipe em alguns dias impossibilitava as Reuniões Diárias, fazendo com que eventuais impedimentos demorassem mais para serem resolvidos;

Alguns dias sem trabalhar no projeto em alguns casos diminuiu a eficiência, pois perdiam algum tempo para retornar ao contexto de dias atrás. Entretanto, dados as atuais circunstâncias da equipe, foi a melhor configuração encontrada.

4 Recomendações a serem adotadas para os próximos projetos

Viabilizar intervalos maiores de tempo com expediente concomitante dos colaboradores, no intuito de melhorar a comunicação e agilizar a retirada de impedimentos gerados;

Programar períodos de férias dos colaboradores em sintonia com a execução de projetos.

Através do desdobramento da questão anterior, aumentar o tempo de programação em par para otimizar o código gerado e diminuir o tempo perdido com dificuldades técnicas.

84 APÊNDICE C. Termo de Encerramento

INSTITUTOFEDERALDESANTACATARINA · 2019. 3. 8. · Buscando introduzir uma nova visão sobre como...

Documents

Transcript of INSTITUTOFEDERALDESANTACATARINA · 2019. 3. 8. · Buscando introduzir uma nova visão sobre como...