UNIVERSIDADE FEDERAL FLUMINENSEINSTITUTO DE COMPUTACcedilAtildeO

BACHARELADO EM SISTEMAS DE INFORMACcedilAtildeO

FABRICIO BARROSO DA SILVA

ANAacuteLISE DA APLICACcedilAtildeO DA CULTURA DEVOPS NAS ORGANIZACcedilOtildeES

Niteroacutei2018

FABRICIO BARROSO DA SILVA

ANAacuteLISE DA APLICACcedilAtildeO DA CULTURA DEVOPS NAS ORGANIZACcedilOtildeES

Trabalho de conclusatildeo de cursoapresentado ao curso de Bacharelado emSistemas de Informaccedilatildeo como requisitoparcial para conclusatildeo do curso

OrientadorProf Dr Flaacutevio Luiz Seixas

CoorientadorProf Dr Marcelo Fornazin

Niteroacutei2018

Aos meus pais Luciane e Huedson por sempre me apoiarem em qualquer decisatildeo tomada

AGRADECIMENTOS

Agrave minha famiacutelia por todo o apoio durante este periacuteodo de estudos e estaacutegios Sem a base que

me proporcionaram jamais estaria escrevendo estas linhas com tanto afinco

Ao professor Flaacutevio pelo acircnimo constante em nossas reuniotildees sempre me ajudando a pensar

fora da caixa e dar a volta por cima

Ao professor Marcelo pela contribuiccedilatildeo acadecircmica e pela motivaccedilatildeo de escrever uma

monografia sobre um tema tatildeo interessante

Agrave Vitoacuteria de Maria minha amada companheira de todas as horas que sempre buscou me

auxiliar em diversos assuntos que ela nunca nem ouviu falar que sempre conseguiu me

reerguer em momentos onde a caminhada estava difiacutecil que sempre fez questatildeo de me

mostrar o outro lado das histoacuterias e me ajudou a entender coisas que sem o seu jeito

carinhoso eu jamais conseguiria entender

Ao Caio meu amigo de anos e mais anos que decidiu entrar nessa empreitada chamada

universidade junto comigo

Agrave Yuki minha grande amiga e parceira de jogatina que sempre me apoiou em momentos

bons e ruins mesmo estando longe

Aos meus amigos Daniel Alce e Lucas e agraves minhas amigas Vic e Lets pelos grandes

momentos marcantes e pelos que ainda viratildeo ao longo desses incriacuteveis anos de amizade

Aos meus amigos Diogo Viana Lima Samuel Gabriel Tuime Shinato Morico e Lontra os

ldquoPreulasrdquo pelos longos debates travados no grupo e pelas jogatinas madrugada afora

Agrave minha grandissiacutessima amiga Anita pelos momentos mais inusitados que duas pessoas

podem presenciar na praccedila da Cantareira nas quintas-feiras

Agrave Dani pela contribuiccedilatildeo inigualaacutevel neste uacuteltimo ano com as disciplinas e pela parceria

firmada nos grupos que fizemos parte

Chegou a hora de ser maior que as muralhasLucas Silveira

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

FABRICIO BARROSO DA SILVA

ANAacuteLISE DA APLICACcedilAtildeO DA CULTURA DEVOPS NAS ORGANIZACcedilOtildeES

Trabalho de conclusatildeo de cursoapresentado ao curso de Bacharelado emSistemas de Informaccedilatildeo como requisitoparcial para conclusatildeo do curso

OrientadorProf Dr Flaacutevio Luiz Seixas

CoorientadorProf Dr Marcelo Fornazin

Niteroacutei2018

Aos meus pais Luciane e Huedson por sempre me apoiarem em qualquer decisatildeo tomada

AGRADECIMENTOS

Agrave minha famiacutelia por todo o apoio durante este periacuteodo de estudos e estaacutegios Sem a base que

me proporcionaram jamais estaria escrevendo estas linhas com tanto afinco

Ao professor Flaacutevio pelo acircnimo constante em nossas reuniotildees sempre me ajudando a pensar

fora da caixa e dar a volta por cima

Ao professor Marcelo pela contribuiccedilatildeo acadecircmica e pela motivaccedilatildeo de escrever uma

monografia sobre um tema tatildeo interessante

Agrave Vitoacuteria de Maria minha amada companheira de todas as horas que sempre buscou me

auxiliar em diversos assuntos que ela nunca nem ouviu falar que sempre conseguiu me

reerguer em momentos onde a caminhada estava difiacutecil que sempre fez questatildeo de me

mostrar o outro lado das histoacuterias e me ajudou a entender coisas que sem o seu jeito

carinhoso eu jamais conseguiria entender

Ao Caio meu amigo de anos e mais anos que decidiu entrar nessa empreitada chamada

universidade junto comigo

Agrave Yuki minha grande amiga e parceira de jogatina que sempre me apoiou em momentos

bons e ruins mesmo estando longe

Aos meus amigos Daniel Alce e Lucas e agraves minhas amigas Vic e Lets pelos grandes

momentos marcantes e pelos que ainda viratildeo ao longo desses incriacuteveis anos de amizade

Aos meus amigos Diogo Viana Lima Samuel Gabriel Tuime Shinato Morico e Lontra os

ldquoPreulasrdquo pelos longos debates travados no grupo e pelas jogatinas madrugada afora

Agrave minha grandissiacutessima amiga Anita pelos momentos mais inusitados que duas pessoas

podem presenciar na praccedila da Cantareira nas quintas-feiras

Agrave Dani pela contribuiccedilatildeo inigualaacutevel neste uacuteltimo ano com as disciplinas e pela parceria

firmada nos grupos que fizemos parte

Chegou a hora de ser maior que as muralhasLucas Silveira

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

Aos meus pais Luciane e Huedson por sempre me apoiarem em qualquer decisatildeo tomada

AGRADECIMENTOS

Agrave minha famiacutelia por todo o apoio durante este periacuteodo de estudos e estaacutegios Sem a base que

me proporcionaram jamais estaria escrevendo estas linhas com tanto afinco

Ao professor Flaacutevio pelo acircnimo constante em nossas reuniotildees sempre me ajudando a pensar

fora da caixa e dar a volta por cima

Ao professor Marcelo pela contribuiccedilatildeo acadecircmica e pela motivaccedilatildeo de escrever uma

monografia sobre um tema tatildeo interessante

Agrave Vitoacuteria de Maria minha amada companheira de todas as horas que sempre buscou me

auxiliar em diversos assuntos que ela nunca nem ouviu falar que sempre conseguiu me

reerguer em momentos onde a caminhada estava difiacutecil que sempre fez questatildeo de me

mostrar o outro lado das histoacuterias e me ajudou a entender coisas que sem o seu jeito

carinhoso eu jamais conseguiria entender

Ao Caio meu amigo de anos e mais anos que decidiu entrar nessa empreitada chamada

universidade junto comigo

Agrave Yuki minha grande amiga e parceira de jogatina que sempre me apoiou em momentos

bons e ruins mesmo estando longe

Aos meus amigos Daniel Alce e Lucas e agraves minhas amigas Vic e Lets pelos grandes

momentos marcantes e pelos que ainda viratildeo ao longo desses incriacuteveis anos de amizade

Aos meus amigos Diogo Viana Lima Samuel Gabriel Tuime Shinato Morico e Lontra os

ldquoPreulasrdquo pelos longos debates travados no grupo e pelas jogatinas madrugada afora

Agrave minha grandissiacutessima amiga Anita pelos momentos mais inusitados que duas pessoas

podem presenciar na praccedila da Cantareira nas quintas-feiras

Agrave Dani pela contribuiccedilatildeo inigualaacutevel neste uacuteltimo ano com as disciplinas e pela parceria

firmada nos grupos que fizemos parte

Chegou a hora de ser maior que as muralhasLucas Silveira

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

AGRADECIMENTOS

Agrave minha famiacutelia por todo o apoio durante este periacuteodo de estudos e estaacutegios Sem a base que

me proporcionaram jamais estaria escrevendo estas linhas com tanto afinco

Ao professor Flaacutevio pelo acircnimo constante em nossas reuniotildees sempre me ajudando a pensar

fora da caixa e dar a volta por cima

Ao professor Marcelo pela contribuiccedilatildeo acadecircmica e pela motivaccedilatildeo de escrever uma

monografia sobre um tema tatildeo interessante

Agrave Vitoacuteria de Maria minha amada companheira de todas as horas que sempre buscou me

auxiliar em diversos assuntos que ela nunca nem ouviu falar que sempre conseguiu me

reerguer em momentos onde a caminhada estava difiacutecil que sempre fez questatildeo de me

mostrar o outro lado das histoacuterias e me ajudou a entender coisas que sem o seu jeito

carinhoso eu jamais conseguiria entender

Ao Caio meu amigo de anos e mais anos que decidiu entrar nessa empreitada chamada

universidade junto comigo

Agrave Yuki minha grande amiga e parceira de jogatina que sempre me apoiou em momentos

bons e ruins mesmo estando longe

Aos meus amigos Daniel Alce e Lucas e agraves minhas amigas Vic e Lets pelos grandes

momentos marcantes e pelos que ainda viratildeo ao longo desses incriacuteveis anos de amizade

Aos meus amigos Diogo Viana Lima Samuel Gabriel Tuime Shinato Morico e Lontra os

ldquoPreulasrdquo pelos longos debates travados no grupo e pelas jogatinas madrugada afora

Agrave minha grandissiacutessima amiga Anita pelos momentos mais inusitados que duas pessoas

podem presenciar na praccedila da Cantareira nas quintas-feiras

Agrave Dani pela contribuiccedilatildeo inigualaacutevel neste uacuteltimo ano com as disciplinas e pela parceria

firmada nos grupos que fizemos parte

Chegou a hora de ser maior que as muralhasLucas Silveira

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

Agrave Dani pela contribuiccedilatildeo inigualaacutevel neste uacuteltimo ano com as disciplinas e pela parceria

firmada nos grupos que fizemos parte

Chegou a hora de ser maior que as muralhasLucas Silveira

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

Chegou a hora de ser maior que as muralhasLucas Silveira

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

RESUMO

Este trabalho tem como finalidade apresentar uma anaacutelise sobre a aplicaccedilatildeo da culturaDevOps nas organizaccedilotildees A notoacuteria visibilidade das chamadas metodologias aacutegeis no Brasilcom seus resultados surpreendentes em melhoria contiacutenua da qualidade e satisfaccedilatildeo do clienteno exterior fez com que organizaccedilotildees adotassem somente os pontos que lhe interessaramdesses meacutetodos como o Scrum o XP FDD entre outros Poreacutem a adoccedilatildeo descuidada podedesencadear nos efeitos da Espiral Descendente A cultura DevOps atraveacutes de um Pipeline deImplementaccedilatildeo oferece os conceitos apropriados como a Integraccedilatildeo e Entrega Contiacutenuaspara evitar os efeitos desastrosos da Espiral Para verificar esta situaccedilatildeo foi elaborada umapesquisa atraveacutes de um questionaacuterio composto de questotildees referentes tanto aos meacutetodos aacutegeisquanto aos meacutetodos tradicionais como o Modelo Cascata para analisar como estatildeo sendoaplicados os conceitos na visatildeo do colaborador participante da pesquisa As anaacutelisesrealizadas a partir dos resultados da pesquisa sugeriram que os colaboradores natildeo estatildeofamiliarizados com os conceitos e as teorias das abordagens adotadas pela empresa em quetrabalham e aleacutem disso natildeo as aplicam de forma adequada no seu dia-a-dia Acredita-se queesta situaccedilatildeo se deve a forte dificuldade dos desenvolvedores em aplicar os processos ealgoritmos descritos em diagramas e fluxos que representam a documentaccedilatildeo dos sistemas eprogramas desenvolvidos

Palavras-chave Aacutegil Meacutetodo Anaacutelise DevOps

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

ABSTRACT

This work aims to present an analysis about the application of DevOps culture inorganizations The notorious visibility of agile methodologies in Brazil with its surprisingresults in continuous quality improvement and customer satisfaction in other countries hasled organizations to adopt only concerning points in these methods such as Scrum XP FDDamong others However careless adoption can trigger the effects of the Downward SpiralThe DevOps culture through a Deployment Pipeline provides the appropriate concepts suchas Continuous Integration and Continuous Delivery to avoid the disastrous effects of theSpiral In order to verify this situation a research was elaborated through a questionnairecomposed of questions referring to agile methods as well as traditional methods such as theWaterfall Model to analyze how the concepts are being applied regarding the participantsperspective The analyzes based on the research results suggested that employees are notfamiliar with the concepts and theories of the approaches adopted by the company in whichthey work and moreover do not apply them adequately in their daily lives It is believed thatthis situation is due to the strong difficulty of the developers to apply the processes andalgorithms described in diagrams and flows that represent the documentation of the systemsand programs developed

Keywords DevOps Analysis Agile

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

LISTA DE ILUSTRACcedilOtildeES

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto 16Figura 2 ndash Ciclo de Vida de um projeto 31Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida do projeto dentro dos cinco

estaacutegios 32Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce em 1970 35Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin 40

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

LISTA DE TABELAS

Tabela 1 ndash Tabela comparativa dos meacutetodos aacutegil e tradicional 36Tabela 2 ndash Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos 50Tabela 3 ndash Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores 53

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

LISTA DE ABREVIATURAS E SIGLAS

CIO Chief Information OfficerFBI Federal Bureau of InvestigationFDD Feature Driven DevelopmentPMI Project Management InstitutePMBOKreg Project Management Book Of KnowledgePDCA Plan Do Check ActTI Tecnologia da InformaccedilatildeoXP Extreme Programming

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

SUMAacuteRIO

1 INTRODUCcedilAtildeO 1511 O caso Sentinelhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1712 A Espiral Descendentehelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 1813 Objetivohelliphelliphelliphelliphelliphelliphelliphellip 1914 Organizaccedilatildeo deste trabalho 202 REFERENCIAL TEOacuteRICOhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2121 DevOpshelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 22211 A Trecircs Maneirashelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2322 Manifesto Aacutegilhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2523 Scrumhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 2724 PMBOKreghelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 28241 Ciclo de vida do projetohelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 29242 PDCA 31243 As aacutereas de conhecimento da gerecircncia de projetoshelliphelliphelliphelliphelliphelliphelliphelliphellip 3225 O Modelo Cascatahelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 343 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA 3631 Sob o aspecto da Engenharia de Software 3932 Sob o aspecto da Gestatildeo de Projetos 4233 Pontos negativos dos modelos 454 METODOLOGIAhelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 485 RESULTADOS OBTIDOShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 5451 Identificaccedilatildeo do participante 5452 Caracteriacutesticas das abordagens 5553 Valores da organizaccedilatildeo 5954 Visatildeo do participante 616 CONSIDERACcedilOtildeES FINAIShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 64

REFEREcircNCIAS BIBLIOGRAacuteFICAShelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphelliphellip 65

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

15

1 INTRODUCcedilAtildeO

Com o objetivo de superar a concorrecircncia fomentando a necessidade empresarial de

gerar lucro as organizaccedilotildees tecircm utilizado artefatos tecnoloacutegicos que visam modernizar o seu

modelo de negoacutecios Em trabalhos publicados pela comunidade cientiacutefica e acadecircmica satildeo

descritas diversas estrateacutegias competitivas para manutenccedilatildeo da organizaccedilatildeo em uma posiccedilatildeo

de vantagem diante dos competidores

Um dos especialistas mais conhecidos nesse quesito eacute Michael E Porter autor do

livro ldquoVantagem Competitivardquo de 1985 Para ele a ferramenta baacutesica para entender o papel

da tecnologia na vantagem competitiva eacute a Cadeia de Valor que consiste em um conjunto de

atividades estrateacutegicas relevantes para uma a gestatildeo empresarial

A tecnologia estaacute incorporada em todas as atividades da Cadeia de Valor e qualquer

mudanccedila pode impactar qualquer uma dessas atividades afetando a competitividade

Poreacutem mudanccedila tecnoloacutegica natildeo eacute importante por si soacute Tudo depende de como essa

mudanccedila se adapta na Cadeia de Valor como ela beneficia a posiccedilatildeo competitiva da

companhia e como favorece a atratividade comercial

Trazendo para um contexto histoacuterico a partir da segunda metade da deacutecada de 90

Drucker (1997) afirma que ldquoAs organizaccedilotildees se encontram frente ao desafio de buscar

alcanccedilar resultados eficientes e eficazes face agraves novas exigecircncias do mercado global que tecircm

sido impostas pelas mudanccedilas sociais poliacuteticas econocircmicas e tecnoloacutegicasrdquo Mudanccedilas essas

causadas pela terceira revoluccedilatildeo industrial e intensificadas pelas inovaccedilotildees tecnoloacutegicas

Seguindo essa linha de raciociacutenio duas abordagens predominam hoje no que tange aos

meacutetodos de desenvolvimento e gestatildeo de projetos das empresas de tecnologia a adaptativa e a

preditiva A abordagem preditiva sendo representada pelo Modelo Cascata ou tradicional eacute

amplamente utilizada ateacute hoje e foi derivada de modelos de atividade de engenharia (Royce

1970) com o fim de estabelecer ordem no desenvolvimento de grandes produtos de software

atraveacutes da sua orientaccedilatildeo agrave documentaccedilatildeo e sequenciamento de etapas do desenvolvimento

Segundo Sommerville (2011) a engenharia de software presente no Modelo Cascata

consiste em 5 etapas bem definidas a anaacutelise e levantamento de requisitos o design do

software a implementaccedilatildeo e teste do software integraccedilatildeo e teste do sistema e a melhoria

contiacutenua do produto Esse processo natildeo eacute um simples modelo linear cada etapa fornece

informaccedilotildees a serem utilizadas pelas etapas subsequentes e produz uma documentaccedilatildeo a

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

16

respeito do que foi elaborado Dessa forma os gerentes podem monitorar o progresso e

acompanhar de acordo com o que foi descrito no plano de desenvolvimento

O Modelo Cascata a princiacutepio deve ser usado quando os requisitos satildeo bem

conhecidos e possuem poucas chances de sofrerem mudanccedilas radicais durante o

desenvolvimento do sistema pois o maior problema deste modelo eacute a inflexibilidade

promovida pelas etapas do desenvolvimento fazendo com que compromissos sejam feitos

muito cedo no projeto

Em 2016 a Standish Group uma empresa internacional independente de consultoria

em pesquisa de TI fundada em 1985 conhecida por seus relatoacuterios sobre projetos de

implementaccedilatildeo de sistemas de informaccedilatildeo nos setores puacuteblico e privado divulgou um

relatoacuterio contendo informaccedilotildees sobre o nuacutemero de projetos fracassados alterados e

finalizados no decorrer de 2011 ateacute 2015 conhecido como Chaos Report (Figura 1) No

relatoacuterio consta que entre os dez mil projetos estudados o nuacutemero daqueles que

independente de tamanho fracassaram ou sofreram alteraccedilotildees eacute maior entre aqueles que

adotaram um desenvolvimento em Cascata enquanto os nuacutemeros de sucesso satildeo maiores

entre os projetos que envolvem a Metodologia Aacutegil

Figura 1 ndash Resoluccedilatildeo Aacutegil versus Cascata por tamanho do projeto Fonte Standish Group 2016

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

17

11 O caso Sentinel

Sutherland (2016) conta que o FBI poliacutecia federal norte-americana teve seacuterios

contratempos com relaccedilatildeo ao sistema de informaccedilatildeo da instituiccedilatildeo Ateacute 2010 a agecircncia ainda

preenchia a maioria dos seus relatoacuterios no papel e utilizava um sistema que era executado em

computadores gigantescos que em algum periacuteodo da deacutecada de 1980 eram o que existia de

mais moderno Poreacutem o sistema era inconveniente e lento demais para uma eacutepoca de ataques

terroristas - ningueacutem o usava - e portanto a informaccedilatildeo natildeo era compartilhada Por conta

disso natildeo foi possiacutevel prever os ataques do 11 de setembro na eacutepoca em 2001

Apoacutes os ataques o escritoacuterio federal anunciou uma modernizaccedilatildeo do sistema orccedilado

em 170 milhotildees de doacutelares Trecircs anos depois em 2004 o projeto foi cancelado por natildeo estar

funcionando Em 2005 a agecircncia novamente anunciou um novo programa o Sentinel com

orccedilamento de 451 milhotildees de doacutelares e funcionamento previsto para 2009 sendo

desenvolvido por uma terceirizada com a promessa de que dessa vez o projeto sairia do

papel planejando tudo o que precisava ser feito e como precisava ser feito Utilizando

diagramas e graacuteficos o fluxo de desenvolvimento mostrava cada uma das fases do projeto

como uma cascata Em 2010 apenas metade do programa estava implantado tendo sido gasto

405 milhotildees de doacutelares Ou seja o projeto jaacute estava um ano atrasado na metade do caminho e

com estimativa de mais seis ou oito anos aleacutem de um investimento adicional de 350 milhotildees

de doacutelares para conclusatildeo

Na situaccedilatildeo criacutetica em que se encontrava o CIO (Diretor-Executivo de Informaccedilatildeo)

do FBI tomou a decisatildeo de desenvolver o restante do projeto internamente cortando o

nuacutemero de desenvolvedores e assim conseguiram entregar a parte mais desafiadora do

projeto em menos de um quinto do tempo com menos de um deacutecimo da quantia orccedilada Tais

decisotildees configuraram a utilizaccedilatildeo do Scrum por parte do FBI trouxeram o projeto para

desenvolvimento interno reduziram o nuacutemero de pessoas envolvidas e procuraram agregar

mais valor ao produto dando menos atenccedilatildeo agrave documentaccedilatildeo e aos prazos

O Scrum eacute uma abordagem adaptativa representada pela Metodologia Aacutegil de

desenvolvimento de software que traz um conceito mais leve de orientaccedilatildeo agrave pessoas e

mudanccedilas Aleacutem de quebrar essa forte necessidade de documentaccedilatildeo o Modelo Aacutegil conta

com equipes reduzidas para realizar trabalhos onde os requisitos natildeo satildeo bem definidos e o

grau de complexidade eacute elevado pois as mudanccedilas satildeo inevitaacuteveis durante o processo de

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

18

desenvolvimento Nesse contexto Sommerville (2011) diz que ateacute o momento da entrega o

software estaraacute desatualizado caso haja a adoccedilatildeo do Modelo Cascata

Poreacutem a simples adoccedilatildeo de Metodologias Aacutegeis por si soacute natildeo eacute o suficiente para o

sucesso de um projeto Eacute necessaacuterio entender que os meacutetodos aacutegeis natildeo solucionam todos os

problemas de desenvolvimento de software Por se tratar de uma quebra de paradigma elas

requerem disciplina conhecimento taacutecito e equipes auto gerenciaacuteveis Foi nesse cenaacuterio que

surgiu a cultura DevOps dada como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil

12 A Espiral Descendente

DevOps representa um novo modelo para o desenvolvimento de aplicaccedilotildees que

necessita da profunda colaboraccedilatildeo entre os desenvolvedores de software e teacutecnicos

responsaacuteveis pela infraestrutura de TI na empresa Essa colaboraccedilatildeo eacute indicativa de uma

cultura focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

entrega do software de forma que a construccedilatildeo o teste e a entrega do software ocorra de

forma raacutepida frequente e confiaacutevel

No entanto existe um conflito crocircnico central inerente agrave quase toda empresa de

tecnologia entre as equipes de desenvolvimento e de infraestrutura que causa a chamada

Espiral Descendente resultando em menos tempo para comercializar novos produtos e

recursos em qualidade reduzida e interrupccedilotildees constantes sempre acumulando mais tarefas

pendentes de resoluccedilatildeo

Um dos motivos que causa esse conflito eacute a definiccedilatildeo concorrente dos objetivos dos

times de desenvolvimento e de infraestrutura enquanto o time de desenvolvimento tem de

responder agraves mudanccedilas no mercado o time de infraestrutura tem de fornecer para seus

consumidores serviccedilos de TI que sejam estaacuteveis confiaacuteveis e seguros Configurados dessa

forma os times tecircm objetivos e incentivos opostos (KIM HUMBLE DEBOIS 2016)

A Espiral Descendente eacute um processo definido em trecircs estaacutegios

1) O primeiro estaacutegio comeccedila na aacuterea de operaccedilotildees onde o objetivo eacute manter

aplicaccedilotildees e infraestrutura operando em perfeito estado para que a organizaccedilatildeo possa entregar

valor ao cliente A maioria dos problemas que surgem diariamente estaacute relacionada agrave

aplicaccedilotildees e infraestrutura complexas demais pouco documentadas e incrivelmente fraacutegeis

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

19

Atraveacutes de workarounds ou seja accedilotildees miacutenimas que solucionam problemas pontuais a

diacutevida teacutecnica comeccedila com promessas de que os ajustes adequados seratildeo realizados quando

houver tempo Aos poucos as consequecircncias desses atos vecircm agrave tona e o problema acumula

Aleacutem disso os sistemas mais propensos a falhas satildeo tambeacutem os mais importantes para as

mudanccedilas urgentes Quando essas mudanccedilas falham elas comprometem a disponibilidade dos

serviccedilos as metas de receita e a seguranccedila de dados de clientes entre outros problemas

criacuteticos

2) O segundo estaacutegio comeccedila quando algueacutem tem que compensar pela quebra da

promessa descrita no primeiro ato ndash pode ser por exemplo um(a) gerente prometendo uma

funcionalidade ousada para deslumbrar os clientes ou um(a) executivo(a) querendo traccedilar uma

meta de receita maior ainda - entatildeo sem ter ideia do que a tecnologia pode fazer ou quais

fatores levaram agrave quebra do compromisso anterior ele(a) estimula a organizaccedilatildeo a cumprir

essa nova promessa Como resultado os desenvolvedores ficam encarregados de mais um

projeto urgente que inevitavelmente requer novas soluccedilotildees teacutecnicas para cumprir com as

metas e os prazos estabelecidos sendo obrigados a trabalhar de forma apressada para entregar

no prazo estabelecido resultando no acuacutemulo da diacutevida teacutecnica causada novamente pela

promessa de que os ajustes adequados seratildeo realizados quando houver tempo

3) Nesse estaacutegio tudo vai ficando um pouco mais difiacutecil todo mundo vai ficar

mais ocupado o trabalho leva mais tempo para ser concluiacutedo a comunicaccedilatildeo fica lenta e a

fila de trabalho cresce O trabalho fica mais apertado pequenas accedilotildees causam problemas

maiores e as pessoas ficam com medo e menos tolerantes em causar mudanccedilas Equipes

devem esperar mais pelos seus trabalhos que dependem de outras aacutereas e setores e a qualidade

vai piorando Eventualmente a organizaccedilatildeo vai perdendo seu valor no mercado (KIM

HUMBLE DEBOIS 2016)

Portanto os casos de sucesso advindos da adoccedilatildeo de Meacutetodos Aacutegeis possuem nuacutemeros

animadores Sua adoccedilatildeo vem se mostrando uma crescente e acaba levantando a questatildeo as

empresas que se colocam como praticantes dos Meacutetodos Aacutegeis estatildeo de fato se utilizando de

suas prerrogativas Nesse cenaacuterio de busca constante da vantagem competitiva e de evitar os

efeitos da Espiral Descendente que estaacute inserida a cultura DevOps eacute preciso ter cautela ao

aplicar as praacuteticas aacutegeis de imediato para natildeo acumular diacutevida teacutecnica

13 Objetivo

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

20

Diversas empresas de grande porte muitas delas com estrutura altamente

hierarquizada inflexiacutevel e monoliacutetica motivadas pelos grandes nuacutemeros de sucesso das

metodologias aacutegeis (MANN MAURER 2005) querem utilizar somente aquilo que as lhes

conveacutem das boas praacuteticas de desenvolvimento aacutegil de software e aplicaacute-las em algum(ns)

determinado(s) contexto(s)

Como veremos no decorrer deste trabalho a adoccedilatildeo da metodologia aacutegil requer

mudanccedilas radicais na estrutura organizacional e na forma como a organizaccedilatildeo e

consequentemente as pessoas pensam Obstaacuteculos como a diacutevida teacutecnica podem se

transformar em uma ldquobola de neverdquo O esforccedilo em detectar precocemente um problema pode

ser em vatildeo caso o mesmo seja tratado de forma incorreta da mesma forma que natildeo adianta

saber tratar o problema se natildeo o detectar a tempo Com a adoccedilatildeo de DevOps problemas como

esse satildeo solucionados ldquode dentro para forardquo pois o foco eacute na forma como o indiviacuteduo pensa

sobre o projeto Por ser uma abordagem empiacuterica ela abre matildeo da burocracia presente nos

meacutetodos tradicionais e concentra seus esforccedilos na interaccedilatildeo e colaboraccedilatildeo entre os membros

da equipe geralmente enxutas

Eacute gerado um sentimento de pertencimento que faz com que os membros se sintam

dono do produto e se preocupem com cada detalhe defeituoso no sistema e nos processos que

entregam valor ao cliente

Desta forma o objetivo deste trabalho eacute analisar se as empresas que se declaram

usuaacuterias de metodologias aacutegeis estatildeo aplicando a cultura DevOps de forma adequada e

promovendo a quebra do paradigma nas empresas concentrando seus esforccedilos para eliminar

os impactos da Espiral Descendente e consequentemente da diacutevida teacutecnica

Portanto eacute necessaacuterio verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos de software e como

ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a cultura

organizacional presente

14 Organizaccedilatildeo deste trabalho

No decorrer deste trabalho a organizaccedilatildeo dos capiacutetulos se daraacute da seguinte forma

seratildeo apresentados no capiacutetulo 2 a seguir os fundamentos que cerceiam as praacuteticas de

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

21

desenvolvimento de software O capiacutetulo 3 traz uma comparaccedilatildeo entre as duas abordagens

No capiacutetulo 4 seraacute descrito o meacutetodo de pesquisa aplicado para a coleta de informaccedilotildees e no

capiacutetulo 5 a apuraccedilatildeo dos resultados obtidos Por fim no capiacutetulo 6 estaratildeo dispostas as

consideraccedilotildees finais com relaccedilatildeo a este trabalho e a conclusatildeo

2 REFERENCIAL TEOacuteRICO

Neste capiacutetulo seratildeo apresentados os toacutepicos contendo os conceitos que serviratildeo de

embasamento para a validaccedilatildeo do tema proposto neste trabalho Eacute necessaacuterio entender

detalhes das teorias e dos conceitos por traacutes de ambas as abordagens discutidas nas seccedilotildees

anteriores para conseguir detectar a sua presenccedila nas organizaccedilotildees

Dessa forma este capiacutetulo seraacute dividido em seis seccedilotildees sendo da seccedilatildeo 21 ateacute a seccedilatildeo

23 a apresentaccedilatildeo das teorias e dos conceitos que cerceiam a abordagem adaptativa

representada pela metodologia aacutegil de desenvolvimento A seccedilatildeo 21 apresenta a cultura

DevOps e os seus trecircs princiacutepios ou maneiras que descrevem a transformaccedilatildeo na forma de

pensar dos indiviacuteduos Sua adoccedilatildeo adequada depende dessa transformaccedilatildeo A seccedilatildeo 22

contempla os doze princiacutepios do manifesto sobre o desenvolvimento aacutegil de software e as suas

prioridades A seccedilatildeo 23 traz a metodologia Scrum como um exemplo de gestatildeo de projetos

baseada no modelo aacutegil de desenvolvimento A adoccedilatildeo de uma metodologia aacutegil eacute

considerada um preacute-requisito para que uma organizaccedilatildeo consiga apropriadamente adotar a

cultura DevOps apresentada na seccedilatildeo seguinte A seccedilatildeo 24 apresenta o guia de

gerenciamento de projetos que trata de ambas as abordagens em suas paacuteginas Ele detalha as

boas praacuteticas e padrotildees que satildeo amplamente utilizados pelos gerentes de projeto e satildeo

reconhecidos mundialmente A seccedilatildeo 25 finaliza o capiacutetulo apresentando as caracteriacutesticas

da abordagem preditiva do modelo de desenvolvimento em cascata da engenharia de

software de Pressman

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

22

21 DevOps

O DevOps pode ser dado como o uacuteltimo estaacutegio que acompanha a ideia do

desenvolvimento aacutegil Com suas raiacutezes na metodologia japonesa Lean ele representa um

modelo para o desenvolvimento de aplicaccedilotildees que necessita da profunda colaboraccedilatildeo entre os

desenvolvedores de software e operaccedilotildees de TI Essa colaboraccedilatildeo eacute indicativa de uma cultura

focada em definir o software com as operaccedilotildees em mente e automatizar o processo de

implantaccedilatildeo de forma que a construccedilatildeo o teste e a entrega ocorra de forma raacutepida frequente

e confiaacutevel

Este processo eacute o Pipeline de Implantaccedilatildeo que consiste em colocar a automaccedilatildeo no

passo a passo da implantaccedilatildeo garantindo que os testes forneccedilam feedback imediato e

apropriado ao desenvolvedor e a todos na cadeia de valor sobre o status das mudanccedilas no

momento do deploy

A ideia do Pipeline eacute fazer com que o fluxo da cadeia de valor ldquoda esquerda para a

direitardquo acelere mas com qualidade atraveacutes de condiccedilotildees miacutenimas para testagem de forma

que minimize a probabilidade de erro em produccedilatildeo e o tempo de lead ou seja periacuteodo de

tempo entre o momento em que um requisito eacute solicitado e ele eacute entregue em produccedilatildeo O

Pipeline eacute formado por trecircs estaacutegios Integraccedilatildeo Contiacutenua Entrega Contiacutenua e o uacuteltimo

estaacutegio da Implantaccedilatildeo Contiacutenua

Atraveacutes da Integraccedilatildeo Contiacutenua os desenvolvedores integram seu coacutedigo no miacutenimo

uma vez no dia fazem a construccedilatildeo (build) automaacutetica com testes para detectar erros e

fornecem feedback imediato e permitem um software coeso de forma mais raacutepida reduzindo

os erros de integraccedilatildeo Atraveacutes da Entrega Contiacutenua surge a necessidade de adaptar a

definiccedilatildeo de ldquoprontordquo O software precisa estar funcional e testado em um ambiente de similar

ao de produccedilatildeo com controle de versatildeo criaccedilatildeo de ambiente sob demanda - infraestrutura

como coacutedigo - e pipeline automatizado Ou seja garante-se que o coacutedigo e a infraestrutura

estejam prontos para implantar com seguranccedila por meio de deploys automatizados nos

ambientes que antecedem a produccedilatildeo para inspeccedilatildeo final e novos testes bastando apertar

apenas um botatildeo para pocircr em produccedilatildeo (deploy manual) E atraveacutes da Implantaccedilatildeo Contiacutenua

os dois processos anteriores se datildeo de forma completamente autocircnoma e automaacutetica

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

23

aumentando a responsabilidade do desenvolvedor na hora de dar o commit sabendo que seu

coacutedigo iraacute direto para produccedilatildeo caso passe em todos os conjuntos de testes

Em diversos textos e artigos acadecircmicos o termo DevOps eacute referido de diversas

formas entre elas ldquoabordagemrdquo ldquometodologiardquo ldquoframeworkrdquo ldquojornadardquo o que natildeo quer

dizer que estejam erradas pois eacute um pouco de cada DevOps eacute uma quebra de paradigma um

olhar sob um aspecto diferente daquilo que eacute tradicionalmente proposto e que haacute uma forte

resistecircncia quanto agraves suas praacuteticas Por conta disso ela pode ser considerada uma cultura Por

definiccedilatildeo cultura eacute um ldquoconjunto de padrotildees de comportamento crenccedilas conhecimentos

costumes e etc que distinguem um grupo socialrdquo Portanto podemos dizer que a cultura

DevOps requer que seus praticantes possuam um conjunto de comportamentos

conhecimentos e principalmente costumes voltados agraves suas Trecircs Maneiras Fluxo Feedback

e Experimentaccedilatildeo e Aprendizado Contiacutenuo Elas satildeo os princiacutepios da cultura DevOps (KIM

HUMBLE DEBOIS 2016)

211 As Trecircs Maneiras

A primeira maneira Fluxo consiste em suavizar e otimizar o fluxo de trabalho para

entrega raacutepida de valor ao cliente Os componentes chave satildeo tornar o trabalho visiacutevel

atraveacutes de quadros que representam o progresso das aacutereas de trabalho como o Kanban por

exemplo limitar a quantidade de WIPs (do inglecircs ldquoTrabalho em andamentordquo - Work In

Progress) por conta do problema de multitarefa produzir em pequenos lotes de trabalho

diminuir o nuacutemero de transferecircncia de trabalho identificar e avaliar continuamente as

restriccedilotildees e eliminar as dificuldades no trabalho diaacuterio

O segundo princiacutepio Feedback consiste em receber criacuteticas de forma raacutepida objetiva

e confiaacutevel acerca do produtoserviccedilo desenvolvido para a resoluccedilatildeo de algum problema ou

identificaccedilatildeo de alguma falha criacutetica Isso previne que determinados problemas ocorram

novamente aumentando a qualidade e seguranccedila do sistema de trabalho Aleacutem disso esse

princiacutepio preza pelo aprendizado com os erros quando ocorrem atraveacutes do Enxame ou

seja um grupo dos colaboradores que para suas tarefas em prol da resoluccedilatildeo de determinado

problema Dessa forma os colaboradores aprendem coletivamente sobre o sistema evitando

que o problema se espalhe e cobre mais tempo e esforccedilo para resolvecirc-lo Caso contraacuterio iraacute

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

24

permitir que a diacutevida teacutecnica cresccedila ou seja o acuacutemulo de ajustes prometidos de serem

realizados

O terceiro princiacutepio se chama Aprendizagem e Experimentaccedilatildeo Continuada Ao

cometer um erro o colaborador natildeo eacute culpado pelo erro Em vez disso investiga-se o motivo

do erro a fim de aprender com o mesmo Quando o colaborador natildeo leva a culpa ele perde o

medo de puniccedilotildees e ao perder o medo ele eacute honesto e honestidade gera prevenccedilatildeo e aumenta

a confianccedila exigecircncia do DevOps Segundo cita Neto (NETO 2000 apud HANDY 1997) ldquoo

poder nas novas organizaccedilotildees proveacutem das relaccedilotildees e natildeo das estruturas A confianccedila sendo o principal meio de

controle torna as pessoas mais eficazes criativas e capazes de atuar em um ambiente dinacircmico Esta colocaccedilatildeo

corrobora com a visatildeo de que a funccedilatildeo da estrutura natildeo estaacute somente na designaccedilatildeo do poder mas sim nas

relaccedilotildees que a mesma implicardquo Ao colocar o aprendizado organizacional no lugar da culpa as

organizaccedilotildees se tornam mais autodiagnosticas e auto aperfeiccediloadas haacutebeis em detectar

problemas e resolvecirc-los Isso ajuda os clientes garante a qualidade cria vantagem

competitiva e uma forccedila de trabalho motivada Aleacutem disso promove-se a experimentaccedilatildeo

continuada para aprimorar a resiliecircncia pois dessa forma a organizaccedilatildeo vive num estado de

tensatildeo e mudanccedila Esse processo de aplicar estresse para aumentar a resiliecircncia recebeu o

nome de Antifragilidade

As Trecircs Maneiras norteiam os comportamentos e o modo de pensar dos indiviacuteduos

Tais princiacutepios encontram obstaacuteculos quando aplicados em organizaccedilotildees de grande porte

devido agrave forte hierarquizaccedilatildeo da estrutura organizacional onde eacute extremamente difiacutecil

garantir o fluxo raacutepido frequente e confiaacutevel entre todas as aacutereas da empresa Por exemplo o

setor de TI de uma grande empresa de telecomunicaccedilotildees possui as equipes de

desenvolvimento e infraestrutura Eacute solicitado ao time de infraestrutura um novo ambiente de

testes para um projeto novo O time de infraestrutura precisa avaliar o pedido verificar se eacute

possiacutevel aproveitar recursos internos ou se eacute necessaacuterio adquirir novos recursos e solicitar a

providecircncia dos itens agrave aacuterea de patrimocircnio e aquisiccedilotildees Este processo burocraacutetico toma muito

tempo dos indiviacuteduos e da proacutepria empresa Atividades que tentam garantir mudanccedilas raacutepidas

em ambientes monoliacuteticos e intolerantes agrave alteraccedilotildees tendem ser prejudiciais para a empresa

A estrutura organizacional mais adequada para se aplicar as Trecircs Maneiras eacute a

horizontal Nela natildeo haacute hierarquizaccedilatildeo na delegaccedilatildeo de tarefas fazendo com que a

burocracia nas solicitaccedilotildees intersetoriais seja quase totalmente eliminada Todos satildeo

responsaacuteveis pela realizaccedilatildeo das atividades necessaacuterias para alcanccedilar os objetivos do projeto

O ambiente colaborativo e comunicativo estabelece viacutenculos de confianccedila entre os

colaboradores essenciais para a cultura DevOps Por conta da agilidade pequenas empresas

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

25

comeccedilam configuradas de forma horizontal facilitando a gestatildeo dos processos e tornando a

execuccedilatildeo das atividades mais fluida Atraveacutes de infraestrutura sob coacutedigo os servidores e

bases de dados satildeo configurados em maacutequinas na nuvem eliminando o custo de manutenccedilatildeo

de cariacutessimas salas contendo armaacuterios de servidores switches e outros hardwares

Configurada desta forma a estrutura horizontal possui caracteriacutesticas que facilitam a

aplicaccedilatildeo do Pipeline de Implantaccedilatildeo

22 Manifesto Aacutegil

Em 2001 nos EUA um grupo de pessoas se reuniu para debater sobre uma alternativa

para os processos orientados ao desenvolvimento pesado de software com forte

documentaccedilatildeo Dessa reuniatildeo foi elaborado o Manifesto Aacutegil

O Manifesto Aacutegil eacute uma declaraccedilatildeo no escopo de desenvolvimento de software que

rege sob 12 princiacutepios e promove formas mais aacutegeis consideradas leves de se desenvolver

softwares focando mais em indiviacuteduos e interaccedilotildees e menos em documentaccedilatildeo e processos

Isso natildeo significa que estes sejam ignorados apenas recebem uma prioridade menor durante a

elaboraccedilatildeo da soluccedilatildeo Os 12 princiacutepios do manifesto satildeo (SUTHERLAND FOWLER

BEEDLE et al 2001)

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

26

1) ldquoNossa maior prioridade eacute satisfazer o cliente atraveacutes da entrega contiacutenua e adiantada

de software com valor agregadordquo

2) ldquoMudanccedilas nos requisitos satildeo bem-vindas mesmo tardiamente no desenvolvimento

Processos aacutegeis tiram vantagem das mudanccedilas visando vantagemrdquo

3) ldquoEntregar frequentemente software funcionando de poucas semanas a poucos meses

com preferecircncia agrave menor escala de tempordquo

4) ldquoPessoas de negoacutecio e desenvolvedores devem trabalhar diariamente em conjunto por

todo o projetordquo

5) ldquoConstrua projetos em torno de indiviacuteduos motivados Decirc a eles o ambiente e o

suporte necessaacuterio e confie neles para fazer o trabalhordquo

6) ldquoO meacutetodo mais eficiente e eficaz de transmitir informaccedilotildees para e entre uma equipe

de desenvolvimento eacute atraveacutes de conversa face a facerdquo

7) ldquoSoftware funcionando eacute a medida primaacuteria de progressordquo

8) ldquoOs processos aacutegeis promovem desenvolvimento sustentaacutevel Os patrocinadores

desenvolvedores e usuaacuterios devem ser capazes de manter um ritmordquo

9) ldquoContiacutenua atenccedilatildeo agrave excelecircncia teacutecnica e bom design aumenta a agilidaderdquo

10) ldquoSimplicidade a arte de maximizar a quantidade de trabalho natildeo realizado eacute

essencialrdquo

11) ldquoAs melhores arquiteturas requisitos e designs emergem de equipes auto

organizaacuteveisrdquo

12) ldquoEm intervalos regulares a equipe reflete sobre como se tornar mais eficaz e entatildeo

refina e ajusta seu comportamento de acordordquo

Os meacutetodos tradicionais tambeacutem considerados meacutetodos pesados de desenvolvimento

concentram seus esforccedilos na prescriccedilatildeo antes da accedilatildeo dos processos Por outro lado os

meacutetodos aacutegeis tecircm o foco na entrega perioacutedica do produto e nas interaccedilotildees entre os

indiviacuteduos A fase inicial de planejamento eacute minimizada para que seja possiacutevel o foco na

entrega do produto ao fim de cada ciclo ao inveacutes de planejar e prever atraveacutes de documentos

extremamente detalhados todo o andamento do projeto como um todo (CARVALHO

MELLO 2012)

Existem diversos meacutetodos aacutegeis aleacutem do Scrum citado anteriormente a Programaccedilatildeo

extrema (XP) o Feature Driven Development (FDD) Dynamic Systems Development

Method Adaptive Software Development Crystal Pragmatic Programming e o Test Driven

Development (TDD)

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

27

23 Scrum

O meacutetodo Scrum criado por Jeff Sutherland em 1993 em conjunto com Mike Beedle

e Ken Schwaber segue os princiacutepios do Manifesto Aacutegil Segundo Schwaber e Beedle (2002)

ele tem como objetivo definir um processo de desenvolvimento de projetos focado nas

pessoas da equipe O nome Scrum eacute proveniente do Ruacutegbi que eacute a reuniatildeo raacutepida dos

jogadores quando se inicia um lance Nele todos os membros se ajudam e cada um exerce

uma funccedilatildeo especiacutefica na elaboraccedilatildeo do software

O Scrum possui praacuteticas e artefatos chave para o sucesso do desenvolvimento aacutegil O

ponto inicial eacute o Product Backlog a praacutetica responsaacutevel pelo armazenamento e gerenciamento

dos requisitos coletados conforme aponta Schwaber e Beedle (2002) Atraveacutes de reuniotildees

com os Stakeholders satildeo levantadas funcionalidades provenientes das necessidades do

negoacutecio apresentadas para entatildeo formalizar uma lista dessas funcionalidades ordenadas por

prioridades que se tecircm o intuito de se desenvolver

Em seguida haacute a praacutetica das StandUp Meetings reuniotildees diaacuterias de no maacuteximo

quinze minutos em que os membros geralmente se levantam e respondem trecircs questotildees

(RISING JANOFF 2000) 1) O que foi feito ontem 2) O que seraacute feito hoje e 3) Haacute algum

obstaacuteculo agrave realizaccedilatildeo das atividades Dessa forma cada integrante fica ciente das metas

individuais de seus colegas de trabalho aleacutem de conhecerem os riscos e poderem cobrar os

compromissos assumidos de cada um

O Sprint eacute a praacutetica principal do Scrum Eacute nesse momento que os itens definidos no

Product Backlog satildeo desenvolvidos Conforme Abrahamsson et al (2002) ele normalmente

dura de uma a quatro semanas mas natildeo haacute uma regra para isto as equipes que decidem a

duraccedilatildeo a ser adotada para o projeto

O Sprint Backlog eacute um subconjunto do Product Catalog Em vez de serem discutidos

detalhes do produto satildeo discutidos detalhes das atividades a serem desenvolvidas no sprint

Apoacutes o sprint satildeo realizadas as Sprint Review Meetings reuniotildees que discutem as liccedilotildees do

sprint o que foi acerto e o que foi erro

No comeccedilo do projeto eacute definido o Product Backlog as ferramentas que seratildeo

utilizadas e os integrantes satildeo selecionados Um deles eacute eleito o Scrum Master A funccedilatildeo do

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

28

Scrum Master eacute auxiliar na soluccedilatildeo dos obstaacuteculos enfrentados pelos desenvolvedores para

que os mesmos soacute se concentrem em questotildees teacutecnicas

Um dos membros deveraacute ser o Product Owner Ele representa o cliente (interno ou

externo) e precisa estar muito bem familiarizado com as regras de negoacutecios do cliente de

forma que ele possa tirar qualquer duacutevida que o time possa ter em relaccedilatildeo agraves funcionalidades

do produto Ao final de cada Sprint uma versatildeo do produto geralmente um protoacutetipo eacute

apresentada ao cliente para receber o feedback Os defeitos satildeo acrescentados ao Product

Backlog

24 PMBOKreg

Em termos de cronologia as metodologias aacutegeis soacute comeccedilaram a ter notoacuteria

visibilidade no Brasil na uacuteltima deacutecada (CARVALHO MELLO 2012) Anterior a isso as

organizaccedilotildees baseavam o gerenciamento dos seus projetos no extenso guia produzido pelo

PMI o PMBOKreg - Guia do Conhecimento em Gerenciamento de Projetos que consiste

como o nome jaacute diz em um conjunto de boas praacuteticas de gerenciamento de projetos sejam

eles de software ou natildeo

Ateacute o ano de 2008 natildeo havia qualquer menccedilatildeo no livro sobre boas praacuteticas que

considerasse o uso de metodologias aacutegeis Na quinta ediccedilatildeo de 2013 apesar de natildeo

especificar qualquer metodologia a obra separa uma subseccedilatildeo para descrever praacuteticas que

remetem agraves praacuteticas aacutegeis do Scrum sendo atribuiacutedas o nome de meacutetodos adaptativos

caracterizados pelas iteraccedilotildees raacutepidas e incrementais Isso indica que aleacutem de bem aceito

entre os projetos de desenvolvimento aacutegil o Scrum estaacute sendo amplamente utilizado Mesmo

assim o PMBOKreg ainda eacute considerado um grande repositoacuterio de informaccedilatildeo para o

desenvolvimento de projetos no Modelo Cascata

Esta seccedilatildeo apresenta os dois conceitos principais descritos no PMBOKreg sempre

contendo uma comparaccedilatildeo com o Scrum que satildeo o ciclo de vida do projeto consistindo em

detalhar brevemente os cinco estaacutegios que todo projeto comumente atinge durante a sua

execuccedilatildeo e o ciclo PDCA de melhoria contiacutenua e as dez aacutereas de conhecimento descrevendo

os grupos responsaacuteveis pelos processos de gerenciamento e controle de aspectos fundamentais

para que um projeto seja concluiacutedo com sucesso No capiacutetulo 3 eacute apresentada uma

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

29

comparaccedilatildeo entre os conceitos do modelo tradicional e os conceitos do modelo aacutegil sob os

aspectos do gerenciamento de projetos e da engenharia de software

241 Ciclo de vida do projeto

O PMBOKreg propotildee a divisatildeo do ciclo de vida de um projeto em cinco estaacutegios

chamados grupos de processos Iniciaccedilatildeo Planejamento Execuccedilatildeo Monitoramento e

Controle e Encerramento conforme ilustra a Figura 2 Cada estaacutegio conta com uma seacuterie de

processos que satildeo comumente executados em seus momentos especiacuteficos Eacute importante notar

que esses estaacutegios natildeo seguem uma ordem fixa e que seus processos natildeo necessitam ser

exclusivamente executados em seus respectivos estaacutegios Por exemplo no estaacutegio de

Execuccedilatildeo um processo de Planejamento precisa ser executado Isso natildeo torna o processo de

Planejamento pertencente ao estaacutegio de Execuccedilatildeo e nem retorna o projeto do estaacutegio de

Execuccedilatildeo ao estaacutegio de Planejamento No Scrum o ciclo de vida contempla trecircs estaacutegios

iterativos Planejamento Desenvolvimento e Encerramento Todo Sprint contempla esses trecircs

estaacutegios

O estaacutegio de Iniciaccedilatildeo consiste na solicitaccedilatildeo de aprovaccedilatildeo de um termo de abertura

Neste documento satildeo definidos o escopo do projeto o orccedilamento os stakeholders e o gerente

do projeto O projeto soacute eacute autorizado quando o termo de abertura eacute aprovado O objetivo

principal deste estaacutegio eacute alinhar com os stakeholders o que se espera da realizaccedilatildeo do projeto

e ajudar a estabelecer a visatildeo do produto e do que precisa ser alcanccedilado No Scrum

O estaacutegio de Planejamento consiste em forte documentaccedilatildeo dos requisitos podendo

ser revistos eou alterados periodicamente durante todo o ciclo de vida do projeto Eacute traccedilada a

estrateacutegia para o curso de accedilatildeo a ser seguido no desenvolvimento assim como o caminho para

a conclusatildeo do projeto com sucesso A documentaccedilatildeo aqui elaborada contempla as dez aacutereas

de conhecimento do projeto (detalhadas no proacuteximo toacutepico) e deve ser determinado o prazo

final para refinamento dos documentos pois o processo de coleta de informaccedilotildees relacionadas

aos requisitos e feedbacks natildeo pode durar indefinidamente Quaisquer mudanccedilas na

documentaccedilatildeo proporcionam maior precisatildeo com respeito ao cronograma custos e

requisitos de recursos para cumprir o escopo definido para o projeto

O estaacutegio de Execuccedilatildeo eacute quando ocorre o maior esforccedilo por parte da equipe do

projeto Aleacutem de como o nome jaacute diz executar o plano de accedilatildeo definido no estaacutegio anterior

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

30

este estaacutegio tem como finalidade coordenar pessoas e recursos a expectativa dos stakeholders

quanto ao andamento do projeto e gerir a equipe do projeto para que a execuccedilatildeo esteja em

conformidade com o planejamento elaborado Durante a execuccedilatildeo os resultados obtidos

podem divergir daqueles previstos anteriormente Por conta disso este tambeacutem eacute o estaacutegio

onde as mudanccedilas ocorrem e requer que atualizaccedilotildees sejam feitas nas linhas de base Isso

pode incluir mudanccedilas no cronograma no orccedilamento no desempenho e no plano de riscos

caso venha agrave tona algum imprevisto Com toda essa possiacutevel mudanccedila eacute possiacutevel que grande

parte do orccedilamento seja gasta neste estaacutegio pois requer atualizaccedilotildees em documentos e

anaacutelises detalhadas que mediante aprovaccedilatildeo demandam tempo e gastos adicionais

O estaacutegio de Monitoramento e Controle consiste em acompanhar analisar e organizar

o progresso e o desempenho do projeto Por meio de mediccedilatildeo de resultados eacute possiacutevel analisar

o desempenho do projeto de tempos em tempos e identificar quaisquer variaccedilotildees com o que

foi anteriormente planejado Este monitoramento contiacutenuo garante agrave equipe uma visatildeo geral

do que estaacute bom e do que estaacute ruim Por conta disso eacute possiacutevel controlar o esforccedilo do projeto

direcionando a atenccedilatildeo para uma aacuterea ou setor mais vulneraacutevel Neste estaacutegio dependendo do

resultado de alguma mediccedilatildeo desfavoraacutevel seraacute necessaacuteria a implementaccedilatildeo de accedilotildees

corretivas para que a equipe cumpra com o planejado nos documentos de especificaccedilatildeo sendo

possiacutevel que haja mudanccedilas referentes ao cronograma e orccedilamento do projeto que necessitam

de atualizaccedilatildeo

O estaacutegio de Encerramento consiste no acerto de contas entre a equipe do projeto com

os stakeholders Tem como objetivo a conclusatildeo da fase em caso de um projeto com

muacuteltiplas fases ou a conclusatildeo formal do projeto em caso de um projeto de fase uacutenica ou na

fase final verificando se todas as atividades relacionadas ao projeto foram finalizadas e

concluindo as obrigaccedilotildees contratuais para que se possa encerrar apropriadamente e

formalmente o projeto Haacute tambeacutem o caso de encerramento prematuro ou seja projeto

cancelado abortado ou em situaccedilatildeo criacutetica Em ambos os casos neste estaacutegio eacute possiacutevel a

realizaccedilatildeo de atividades como revisatildeo poacutes-projeto post-mortem ou seja documentar as

liccedilotildees aprendidas para serem utilizadas nos novos projetos arquivar a documentaccedilatildeo para

registro histoacuterico desmobilizaccedilatildeo da equipe do projeto etc (PMI 2013)

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

31

Figura 2 Ciclo de Vida de um projeto Fonte PMI 2013

O Scrum natildeo conta exatamente com esses cinco estaacutegios supracitados mas conta com

trecircs estaacutegios iterativos que satildeo similares quanto agraves atividades realizadas Satildeo eles

Planejamento Desenvolvimento e Encerramento Cada Sprint contempla as trecircs etapas

O estaacutegio de Planejamento do Scrum conteacutem as atividades de levantar os requisitos

para gerar os Product Backlog e definir os Sprint Backlogs Aleacutem disso este estaacutegio conta

com as reuniotildees diaacuterias os StandUp Meetings que consiste das revisotildees do que foi feito no

dia anterior os obstaacuteculos a enfrentar e o que deve ser feito a partir daquele momento

No estaacutegio de Desenvolvimento os desenvolvedores implementam o coacutedigo dos

toacutepicos especificados no Sprint Backlog em ordem de prioridade Qualquer obstaacuteculo eacute dever

do Scrum Master auxiliar os membros da equipe de modo que esse obstaacuteculo natildeo interfira no

processo de desenvolvimento A cada toacutepico implementado eacute necessaacuterio informar a sua

conclusatildeo no quadro de tarefas da equipe Scrum

No estaacutegio de Encerramento a equipe documenta no Product Backlog as

implementaccedilotildees concluiacutedas as mudanccedilas aplicadas a dificuldade sofrida e os defeitos

apresentados Eacute neste estaacutegio que ocorre a entrega do produto parcial ou final em caso de

conclusatildeo do projeto

242 PDCA

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

32

Tanto Sutherland (SUTHERLAND 2012) quanto o PMBOKreg (PMI 2013) citam a

utilizaccedilatildeo do ciclo PDCA (do inglecircs Plan Do Check Act) um modelo de melhoria contiacutenua

do produto aplicado no gerenciamento de projetos criado por Shewart (1980) e aperfeiccediloado

por Deming (1986) que se adequa aos processos definidos em ambas as abordagens

Tradicional e Aacutegil A Figura 3 ilustra a relaccedilatildeo do ciclo PDCA no ciclo de vida de projeto

Ele consiste em quatro fases

Planejar estabelecer os objetivos e os processos necessaacuterios para alcanccedilar metas no

projeto

DesenvolverExecutarDirigir treinar os operadores quanto a execuccedilatildeo dos processos

anteriormente definidos para entatildeo executaacute-los Sendo necessaacuteria a telemetria para

anaacutelise no proacuteximo passo ou seja coletar informaccedilotildees dos resultados da execuccedilatildeo

para analisaacute-los posteriormente

ConferirChecarVerificar estudar os resultados e comparaacute-los com os dados

esperados Verificar quaisquer variaccedilotildees e planejar cursos de accedilatildeo para o tratamento

de erros ou melhoria do processo

AlavancarAjustarAtuarAgir tomar as medidas preventivas corretivas ou de

melhoria que foram planejadas na etapa anterior para os efeitos da melhoria contiacutenua

Figura 3 ndash Relaccedilatildeo do ciclo PDCA no ciclo de vida de um projeto dentro dos cinco estaacutegios FontePMI 2013

243 As aacutereas de conhecimento da gerecircncia de projetos

O PMBOKreg dispotildee de dez aacutereas de conhecimento que satildeo normalmente utilizadas na

maior parte dos projetos na maioria das vezes Satildeo elas integraccedilatildeo custo escopo

cronograma qualidade recursos aquisiccedilotildees comunicaccedilatildeo riscos e stakeholders As aacutereas se

integram com os cinco estaacutegios do ciclo de vida do projeto e a aacuterea de integraccedilatildeo eacute a

responsaacutevel por integrar e orquestrar todas as outras aacutereas

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

33

As mais importantes para o projeto cumprir o seu objetivo satildeo custo escopo

cronograma e qualidade Poreacutem eacute preciso notar que a priorizaccedilatildeo de uma aacuterea iraacute resultar na

carecircncia de outra ou seja priorizar a reduccedilatildeo do custo iraacute comprometer a qualidade por

exemplo

A aacuterea de custo contempla processos que asseguram que todo o desenvolvimento do

projeto termine dentro do orccedilamento previsto no estaacutegio de planejamento atraveacutes de

estimativas e medidas no controle de atividades que afetam o custo do projeto

A aacuterea de escopo descreve os processos que asseguram que soacute e somente soacute os

requisitos levantados no estaacutegio de planejamento sejam desenvolvidos Quaisquer alteraccedilotildees

devem refletir nas aacutereas impactadas pela mudanccedila

A aacuterea de cronograma eacute responsaacutevel por determinar que o projeto termine no prazo

estipulado anteriormente no estaacutegio de planejamento Esta aacuterea apresenta a maior

complexidade dentre as dez pois o tempo gasto jamais seraacute recuperado Ela apresenta

processos de planejamento e replanejamento contiacutenuos aleacutem de resoluccedilatildeo de conflitos Eacute de

vital importacircncia o gerenciamento adequado para o sucesso do projeto

A aacuterea de qualidade possui processos que seguem as poliacuteticas de garantia da

qualidade de controle da qualidade e de melhoria contiacutenua do produto garantindo que o

projeto satisfaccedila agraves necessidades para as quais foi empreendido de modo que os requisitos

levantados sejam atendidos no seu desenvolvimento

As aacutereas de recursos e aquisiccedilotildees servem para fornecer os materiais necessaacuterios para

produzir o(s) produto(s) do projeto elas lidam com o gerenciamento do esforccedilo humano e da

aquisiccedilatildeo de bens materiais eou imateriais para o desenvolvimento do produto Comunicaccedilatildeo

e riscos precisam estar em constante observaccedilatildeo para rastrear possiacuteveis problemas e mantecirc-los

sob controle

A aacuterea de comunicaccedilatildeo consiste em elaborar um plano para a difusatildeo de informaccedilatildeo

para os stakeholders ou seja informar o progresso as mudanccedilas realizadas e os resultados

obtidos das atividades do projeto

Um plano tambeacutem eacute elaborado para a aacuterea de riscos que consiste em identificar as

incertezas e as ameaccedilas que podem servir de obstaacuteculo para o andamento do projeto O

documento resultante desse plano conta com planos de contenccedilatildeo e contingecircncia contendo o

curso de accedilatildeo para prevenir e remediar respectivamente os riscos

A aacuterea dos stakeholders consiste na identificaccedilatildeo de todas as partes que podem

impactar ou serem impactadas pelo projeto aleacutem de analisar as expectativas quanto o projeto

e elaborar estrateacutegias para mantecirc-las motivadas e engajadas nas decisotildees e na sua execuccedilatildeo

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

34

Esta aacuterea concentra seus esforccedilos na comunicaccedilatildeo contiacutenua com as partes interessadas para

levar em consideraccedilatildeo as suas necessidades e o que elas esperam solucionando conflitos e

incentivando o comprometimento delas com as atividades do projeto A satisfaccedilatildeo das partes

interessadas deve ser gerenciada como um objetivo essencial do projeto (PMI 2013)

25 Modelo Cascata

Originalmente criado por Winston W Royce em 1970 o modelo cascata sugere uma

abordagem sequencial e sistemaacutetica de desenvolvimento de software que se inicia na etapa de

requisitos do sistema e avanccedila pelas etapas de anaacutelise design codificaccedilatildeo testes e suporte

conforme ilustra a Figura 4

Adotado pela engenharia de software (PRESSMAN 2001) as etapas iniciais de

anaacutelise e design do modelo cascata contam com a documentaccedilatildeo das suas atividades como a

elaboraccedilatildeo de graacuteficos fluxos e diagramas para o entendimento da ideia proposta Essa

documentaccedilatildeo serve de guia nas etapas seguintes para a equipe de desenvolvedores

Se os processos da etapa de design foram executados de maneira apropriadamente

detalhista a etapa de codificaccedilatildeo ocorreraacute mecanicamente Esta eacute a etapa em que o design eacute

traduzido para uma forma que a maacutequina consiga entender

Assim que o coacutedigo foi gerado os testes estatildeo prontos para serem aplicados Os

processos de testagem focam em analisar os quesitos internos como verificar a loacutegica de

programaccedilatildeo e externos do software como garantir que as entradas fornecidas geraram

saiacutedas em conformidade com os requisitos esperados

O suporte comeccedila quando o software for entregue ao consumidor Inevitavelmente ele

iraacute solicitar mudanccedilas por conta de erros eou bugs encontrados e isso ocorre porque o

software precisa ser adaptado para acomodar as mudanccedilas do mercado ou simplesmente

porque o cliente quer um aprimoramento funcional ou uma melhoria na performance Esta

etapa repete todas as etapas anteriores sendo aplicadas no software em modificaccedilatildeo em vez

de produzir um novo programa

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

35

Figura 4 ndash Representaccedilatildeo graacutefica do modelo cascata proposto por Royce Fonte ROYCE 1970

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

36

3 COMPARACcedilAtildeO AacuteGIL VERSUS CASCATA

Soares (SOARES 2004) diz que o que diferencia as metodologias tradicionais das

metodologias aacutegeis eacute o enfoque o os valores A ideia das metodologias aacutegeis eacute o enfoque nas

pessoas enquanto a ideia das metodologias tradicionais eacute processos e algoritmos Nesta

seccedilatildeo seraacute feita uma comparaccedilatildeo entre as metodologias tradicional e aacutegil sob dois aspectos o

da Engenharia de Software relacionado agraves praacuteticas de desenvolvimento de software

comparando toacutepicos como Utilizaccedilatildeo Planejamento Testes e Desenvolvimento do Coacutedigo e

o da Gestatildeo de Projetos considerando toacutepicos como as dez aacutereas de conhecimento descritas

no PMBOKreg Ao final seratildeo apresentados os pontos negativos de ambas as abordagens

Essa comparaccedilatildeo tem como objetivo notar as diferenccedilas e as similaridades das duas

abordagens perceber os benefiacutecios e os malefiacutecios teacutecnicos e humanos que cada uma pode

oferecer e observar como se daacute a praacutetica de cada abordagem para fundamentar a metodologia

de pesquisa aplicada que seraacute descrita no capiacutetulo seguinte A Tabela 1 apresenta de forma

resumida os conceitos descritos neste capiacutetuloTabela 1 Tabela comparativa dos meacutetodos aacutegil e tradicional Adaptado de KARDEC 2012 SOARES 2004

DimensatildeoMeacutetodo

Aacutegil Tradicional

Utilizaccedilatildeo

Adaptativo Responde agraves mudanccedilasde forma raacutepida se adaptando a

novos fatores decorrentes dodesenvolvimento do projeto Sua

utilizaccedilatildeo eacute recomendada emsituaccedilotildees onde os requisitos do

software satildeo dinacircmicos e possuemalto grau de incerteza

Preditiva Sua utilizaccedilatildeo eacuterecomendada em situaccedilotildees onde os

requisitos satildeo estaacuteticos eprevisiacuteveis que possuam grandenecessidade de documentaccedilatildeoformal dos algoritmos e uma

estrutura riacutegida dedesenvolvimento seguindo fases

preacute-estabelecidas de acordo com asboas praacuteticas da literatura

Planejamento

O planejamento eacute definido acurtiacutessimo prazo Eacute mais

interessante desenvolver osrequisitos atuais do que os futurosmesmo que tenham que ser feitasmudanccedilas para a integraccedilatildeo dosproacuteximos requisitos O cliente

sempre presente conseguevisualizar melhor o software a cada

iteraccedilatildeo bem-sucedida

O planejamento eacute a longo prazoProjetos no modelo tradcional tecircm

prazos maiores devido ao niacutevelelevado de burocratizaccedilatildeo das

comunicaccedilotildees da formalizaccedilatildeo dasdocumentaccedilotildees e a grande riquezade detalhes contidas nelas Planeja-se muito para evitar futuros erros ebugs no software pois quanto maiscedo detectar um problema mais

barato eacute

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

37

Testes

Os testes devem ser aplicadoscontinuamente em todas a iteraccedilotildeesdo processo de desenvolvimento A

cada nova alteraccedilatildeo deve serimediatamente aplicado um teste

para verificar e validar a suafuncionalidade

Os testes satildeo aplicados assim que ocoacutedigo fonte eacute gerado Apoacutes a

codificaccedilatildeo satildeo executados casosde teste a fim de homologar aspartes interna (loacutegica) e externa

(requisitos) do software

Desenvolvimento

Encoraja a programaccedilatildeo em pares(Pair Programming) como parte da

ideia de comunicaccedilatildeo direta ecolaborativa pois ela eleva os

niacuteveis da produtividade do processode desenvolvimento evitando quemembros faccedilam horas extras que eacute

nocivo agrave sauacutede da equipe

Segundo Pressman (2001) aconstruccedilatildeo de um softwarecomputacional requer uma

abordagem disciplinada O softwareem construccedilatildeo passa pelas fases delevantamento de requisitos design

implementaccedilatildeo e testes

A refatoraccedilatildeo eacute aplicada sempreque visualizada uma oportunidadede simplificar o coacutedigo sem queocorra o risco de alterar alguma

funcionalidade do software

A engenharia de requisitos visagerenciar o que foi pedido pelocliente e o que seraacute entregue na

forma de produto tangiacutevelAmodelagem do sistema a partir de

diagramas orienta o desenvolvedora entender as partes elucidadas do

levantamento de requisitos eprepara o software em construccedilatildeo

para a sua anaacutelise

O desenvolvimento aacutegil promove aideia da propriedade coletiva o

coacutedigo do projeto pertence a todosos membros da equipe Ou seja

todos podem tomar decisotildeesconstrutivas para com o coacutedigo

desde que agreguem valor aosoftware inteiro e executem os

testes necessaacuterios Como todos satildeodonos caso aconteccedila de algum

membro deixar a equipe eacute possiacuteveldar prosseguimento ao

desenvolvimento sem grandesdificuldades pois todos conhecemtodas as partes do software mesmo

que por alto

O engenheiro de software realiza aanaacutelise de requisitos visando revisar

a clareza a completude e aconsistecircncia do software Aleacutem

disso essa anaacutelise tem comoproduto a especificaccedilatildeo dosoftwareApoacutes a anaacutelise e

especificaccedilatildeo o desenvolvedordeve seguir princiacutepios e conceitosque o guiaratildeo na realizaccedilatildeo de trecircs

atividades teacutecnicas designcodificaccedilatildeo e teste A tarefa do

design de software possui 4estaacutegios dados arquitetura

interface do usuaacuterio e componentesAs 3 primeiras satildeo a fundaccedilatildeo para

o desenvolvedor construir ummodelo de design procedural

(coacutedigo-fonte)

Integraccedilatildeo

O plano de projeto eacute representadopelo Product Backlog e pelo Sprint

Backlog (nas iteraccedilotildees) que satildeoatualizados constantemente durante

o projetoO gerente de projeto eacuterepresentado pelo Scrum Masterque tem a funccedilatildeo de facilitador do

projeto minimizando que possiacuteveisimpendimentos venham a ocorrer

O plano de projeto eacute realizado deforma bastante formal e detalhadano iniacutecio do projetoO gerente de

projeto eacute o responsaacutevel pelo projetoe possui controle total do mesmo

CronogramaCurto prazo - projetos aacutegeis levam

de semanas ateacute um mecircsCronogramaorientado ao produto produzido ao

final de cada iteraccedilatildeo

Meacutedio a longo prazo - grandesprojetos no meacutetodo tradicional

costumam levar de meses ateacute umanoCronograma orientado ao

projeto definido na fase inicial doplanejamento

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

38

Custo

Alteraccedilotildees no custo do projeto satildeofacilmente realizadas em qualquerfase de desenvolvimento pois satildeo

implantadas na iteraccedilatildeo maisapropriada com consentimento docliente para natildeo sofrer variaccedilotildeesmuito grandes no valor final do

mesmo

Alteraccedilotildees no custo do projeto tecircmum impacto criacutetico no seu ciclo dedesenvolvimentoFoco no controle

monitoramento e documentaccedilatildeo dasmudanccedilas para que natildeo afete ocusto planejado inicialmente no

projeto

Escopo

Definido a cada Sprint comenormes chances de alteraccedilatildeo derequisitos O cliente a qualquermomento enquanto contratante

pode solicitar algumafuncionalidade ou recurso novo noprojetoImplementaccedilotildees iterativasem pequena escala A cada entrega

sai alguma tela recurso oufuncionalidade nova Ao fim tem-

se a aplicaccedilatildeo por completa

Definido com alto grau dedetalhamento na fase inicial de

planejamento Cada processo deveser documentado e toda informaccedilatildeo

levantada serve de base naespecificaccedilatildeo dos requisitos e na

gestatildeo de mudanccedilas durante oandamento do projeto

Qualidade

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo aacutegil eacute gerida durante todo o

ciclo de vida do projeto a cadaiteraccedilatildeo desenvolvida sendo

realizado testes desde o iniacutecio dodesenvolvimentoO cliente participa

ativamente do processo deverificaccedilatildeo da qualidade Caso natildeoaceite a entrega realizada ele pode

recusaacute-la

Haacute a preocupaccedilatildeo de garantir asatisfaccedilatildeo do clienteA qualidade nomodelo tradicional eacute gerida durante

os procesos de verificaccedilatildeo evalidaccedilatildeo atraveacutes de planos de

testes montados a partir daespecificaccedilatildeo dos requisitosEsses

processos tem como foco omonitoramento e controle da

qualidade dos resultados do projetoou seja assegurar que os resultadosestejam de acordo com os padrotildees

de qualidade desejados pelo cliente(1)

Recursos

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoA confianccedila e acolaboraccedilatildeo dos integrantes daequipe eacute um fator essencial no

projeto A tomada de decisotildees emconjunto exige profissionaishabilidosos com alto grau de

conhecimento taacutecito poreacutem natildeonecessariamente precisam estar nomesmo niacutevel Todos da equipe tecircm

a liberdade de fazer de tudo umpouco e a equipe eacute selecionada de

acordo com as habilidades que cadaum desempenha visando atender

aos requisitos do Product Backlog

Haacute premiaccedilotildees e comemoraccedilotildeespela realizaccedilatildeo de um projeto bem

sucedidoFunccedilotildees e cargos bemdefinidos com processos

especiacuteficos visando a organizaccedilatildeo eo gerenciamento da equipe

identificando e documentando asfunccedilotildees responsabilidades e asrelaccedilotildees hieraacuterquicas entre seus

integrantes melhorando a interaccedilatildeoe o desempenho dos membros da

equipe

Comunicaccedilotildees

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante odecorrer do projeto Constantefeedback durante o processo de

construccedilatildeo do projetoComunicaccedilatildeo colaborativa e direta

entre os envolvidos atraveacutes dasreuniotildees diaacuterias e em todo o

processo de desenvolvimento doprojeto Proporciona uma maior

Haacute a preocupaccedilatildeo em divulgar edocumentar assuntos que satildeo deextrema importacircncia durante o

decorrer do projeto A comunicaccedilatildeodireta se daacute de forma objetiva e

clara considerando as expectativasdo emissorreceptor e os niacuteveis de

hierarquia (relevacircncia dainformaccedilatildeo)Documentaccedilatildeo formal e

detalhada de todos os fatos(marcos) ocorridos a fim de evitar

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

39

aproximaccedilatildeo entre as partesenvolvidas ao preccedilo da exigecircncia deque as mesmas tenham maturidade

suficiente para que natildeo hajaconflitos

conflitos entre as partes envolvidasno projetoComunicaccedilatildeo informalpode ajudar ou prejudicar a equipe

e os participantes do projeto

Riscos

A identificaccedilatildeo anaacutelisemonitoramento e respostas aoseventos de riscos satildeo realizados

continuamente durante as reuniotildeesde planejamento de cada iteraccedilatildeo

Eacute feito um plano formal para ogerenciamento de riscos garantindo

a identificaccedilatildeo avaliaccedilatildeoquantificaccedilatildeo planejamento de

respostas monitoramento e controledos processos durante o ciclo de

vida do projeto a fim de minimizaras chances de falha causadas por

eventos natildeo planejados

Aquisiccedilotildees

Dificuldade muito grande em seestabelecer negociaccedilotildees atraveacutes de

contratos devido ao fato daocorrecircncia constante de alteraccedilotildees

no escopo original do projeto Nestecontexto natildeo ha preocupaccedilatildeo em

definir detalhadamente o processode aquisiccedilatildeo de mercadorias

Processo bem definido e detalhadoatraveacutes de um contrato ondetambeacutem pode-se controlar eacompanhar as atividades do

projeto e do fornecedor garantindoque ambas as partes cumpram com

o combinado estabelecido pelocontrato

Stakeholders

Os stakeholders participamativamente no desenvolvimento do

projeto Eles podem solicitaralteraccedilotildees no escopo a qualquer

momento Satildeo representados peloProduct Owner no Scrum

Eacute gerida a expectativa dosenvolvidos pelo projeto quanto agraves

funcionalidades o prazo e oorccedilamento Motiva-se a equipe para

que ela continue entregando oproduto

31 Sob o aspecto da Engenharia de Software

Quanto a sua utilizaccedilatildeo para esclarecer este ponto eacute necessaacuterio falar sobre o

framework Cynefin (Figura 5) um modelo criado por Dave Snowden em 2007 muito

utilizado para auxiliar grupos a tomarem ciecircncia do domiacutenio em que se encontram para entatildeo

decidirem quais teacutecnicas e metodologias seratildeo adotadas As atividades realizadas no

framework natildeo seratildeo descritas neste trabalho mas eacute importante contemplar os quatro cenaacuterios

e suas respectivas atividades descritas no modelo e ilustradas na Figura 5 que satildeo 1)

Cenaacuterio Simples onde os liacutederes ldquosentem categorizam e depois respondemrdquo 2) Cenaacuterio

Complicado onde os liacutederes ldquosentem analisam e depois respondemrdquo 3) Cenaacuterio Complexo

onde os liacutederes ldquosondam sentem e depois respondemrdquo e o 4) Cenaacuterio Caoacutetico onde os

liacutederes ldquoagem sentem e depois respondemrdquo

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

40

Nesse contexto Joseph Pelrine em 2011 aplicou o framework em um estudo com

pessoas envolvidas em desenvolvimento aacutegil de software e chegou agrave conclusatildeo de que os

meacutetodos aacutegeis se encaixam nos cenaacuterios Complicado e Complexo

A abordagem aacutegil eacute considerada uma abordagem adaptativa Isto significa que o foco eacute

na resposta raacutepida agraves mudanccedilas se adaptando a novos fatores decorrentes do desenvolvimento

do projeto Eacute recomendada em situaccedilotildees onde os requisitos satildeo dinacircmicos e possuem alto grau

de incerteza

Em relaccedilatildeo agrave abordagem tradicional pode-se dizer que ela eacute considerada preditiva

Isto significa que a sua utilizaccedilatildeo eacute recomendada em situaccedilotildees onde os requisitos satildeo estaacuteticos

e previsiacuteveis que possuam grande necessidade de documentaccedilatildeo formal dos algoritmos e dos

processos e uma estrutura riacutegida de desenvolvimento seguindo fases preacute-estabelecidas de

acordo com as boas praacuteticas da literatura como o PMBOKreg Ou seja a abordagem

tradicional se encontra em cenaacuterios considerados Simples segundo o framework Cynefin

Ou seja em situaccedilotildees onde os requisitos satildeo conhecidos e bem definidos a abordagem

tradicional consegue cumprir com suas premissas mas tambeacutem natildeo significa que a

abordagem aacutegil natildeo consiga pois ela possui ferramentas mais efetivas para projetos mais

complexos enquanto que a abordagem tradicional oferece ferramentas mais conhecidas e

seguras para a conclusatildeo bem-sucedida de projetos conhecidos como um sistema bancaacuterio

Figura 5 ndash Cenaacuterios de projetos de acordo com o framework Cynefin Fonte Pelrine 2011

Quanto ao planejamento na abordagem aacutegil o planejamento eacute feito a curtiacutessimo

prazo Eacute mais interessante desenvolver os requisitos atuais mesmo que tenham que ser feitas

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

41

mudanccedilas para a integraccedilatildeo dos proacuteximos requisitos O cliente sempre presente consegue

visualizar melhor o software a cada iteraccedilatildeo bem-sucedida Jaacute na abordagem tradicional o

planejamento eacute feito a longo prazo

Projetos no modelo tradicional tecircm prazos maiores devido ao niacutevel elevado de

burocratizaccedilatildeo das comunicaccedilotildees da formalizaccedilatildeo das documentaccedilotildees e a grande riqueza de

detalhes contidas nelas Planeja-se muito para evitar erros e bugs no software pois quanto

mais cedo detectar um problema mais barato eacute Mudanccedilas feitas apoacutes a etapa de

planejamento chegam a custar de sessenta a cem vezes mais caro (SOARES 2004)

Quanto aos testes na abordagem aacutegil os testes devem ser aplicados continuamente em

todas as iteraccedilotildees do processo de desenvolvimento A cada nova alteraccedilatildeo deve ser

imediatamente aplicado um teste para validar a sua funcionalidade

Enquanto na abordagem tradicional os testes satildeo aplicados assim que o coacutedigo fonte eacute

gerado Apoacutes a codificaccedilatildeo satildeo executados casos de teste a fim de homologar as partes

interna (loacutegica) e externa (requisitos) do software

Quanto ao desenvolvimento a abordagem aacutegil encoraja a adoccedilatildeo da programaccedilatildeo em

pares (Pair Programming) ou seja a implementaccedilatildeo eacute feita em dupla ndash dois desenvolvedores

trabalham em um uacutenico computador Enquanto um implementa o outro observa

continuamente o trabalho que estaacute sendo feito procurando identificar erros sintaacuteticos e

semacircnticos e pensando estrategicamente em como melhorar o coacutedigo que estaacute sendo

implementado Esta teacutecnica tem como grande vantagem o aprendizado contiacutenuo intensificado

pela parceria Aleacutem disso a programaccedilatildeo em pares faz parte da ideia de comunicaccedilatildeo direta e

colaborativa pois ela eleva os niacuteveis de produtividade do processo de desenvolvimento

evitando que membros faccedilam horas extras que eacute nocivo agrave sauacutede da equipe Durante a

codificaccedilatildeo a refatoraccedilatildeo eacute aplicada sempre que visualizada uma oportunidade de simplificar

o coacutedigo sem que ocorra o risco de alterar alguma funcionalidade do software Por fim o

desenvolvimento aacutegil promove a ideia da propriedade coletiva o coacutedigo do projeto pertence a

todos os membros da equipe Ou seja todos podem tomar decisotildees construtivas para com o

coacutedigo desde que agreguem valor ao software inteiro e executem os conjuntos de testes

necessaacuterios Como todos satildeo donos caso aconteccedila de algum membro deixar a equipe eacute

possiacutevel dar prosseguimento ao desenvolvimento sem grandes dificuldades pois todos

conhecem todas as partes do software mesmo que por alto

Na abordagem tradicional a construccedilatildeo de um software segundo Pressman

(PRESSMAN 2001) requer uma abordagem mais disciplinada O software em construccedilatildeo

passa pelas fases de levantamento de requisitos design implementaccedilatildeo e testes A fase de

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

42

suporte soacute vem agrave tona a partir do software pronto e entregue A engenharia de requisitos visa

gerenciar o que foi pedido pelo cliente e o que seraacute entregue na forma de produto tangiacutevel A

modelagem do sistema a partir de diagramas orienta o desenvolvedor a entender as partes

elucidadas do levantamento dos requisitos e prepara o software em construccedilatildeo para a sua

anaacutelise O engenheiro de software entatildeo analisa os requisitos visando revisar a clareza a

completude e a consistecircncia do programa Aleacutem disso essa anaacutelise tem como produto a sua

especificaccedilatildeo Apoacutes a anaacutelise e especificaccedilatildeo o desenvolvedor deve seguir princiacutepios e

conceitos que o guiaratildeo na realizaccedilatildeo de trecircs atividades teacutecnicas design codificaccedilatildeo e teste

A tarefa do design de software possui quatro estaacutegios dados arquitetura interface do usuaacuterio

e componentes As trecircs primeiras satildeo a fundaccedilatildeo para o desenvolvedor construir um ldquomodelo

de design proceduralrdquo ou seja o proacuteprio coacutedigo-fonte

Como dito no iniacutecio deste capiacutetulo o desenvolvimento aacutegil possui um foco nas

pessoas ndash programaccedilatildeo em pares - enquanto o desenvolvimento tradicional em cascata possui

um foco nos processos ndash seguir os estaacutegios de anaacutelise especificaccedilatildeo design e testes ndash e na

documentaccedilatildeo ndash especificar muito nas etapas de planejamento para natildeo arcar com alteraccedilotildees

custosas depois

32 Sob o aspecto da Gestatildeo de Projetos

Nesta seccedilatildeo seraacute apresentada uma comparaccedilatildeo entre o meacutetodo aacutegil Scrum e as boas

praacuteticas de gerenciamento de projetos descritas no PMBOKreg Eacute interessante notar que o

Scrum possui pontos de semelhanccedila com os processos apresentados nas dez aacutereas de

conhecimento (Capiacutetulo 2 seccedilatildeo 24) presentes na maioria dos projetos

A aacuterea de integraccedilatildeo traz como referecircncia os objetivos o planejamento e a

coordenaccedilatildeo das atividades do projeto No Scrum o plano de projeto eacute representado pelo

Product Backlog e pelos Sprint Backlogs que satildeo atualizados constantemente durante o

projeto O gerente do projeto eacute representado pelo Scrum Master quem tem a funccedilatildeo de

facilitador do projeto minimizando que possiacuteveis impedimentos venham a ocorrer NO

PMBOKreg o plano de projeto eacute realizado de forma bastante formal e detalhada no iniacutecio do

projeto O gerente do projeto eacute o responsaacutevel pelo projeto e possui controle sobre o

andamento do mesmo

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

43

Com relaccedilatildeo agrave aacuterea de custo no Scrum as alteraccedilotildees no orccedilamento satildeo facilmente

realizadas em qualquer fase de desenvolvimento pois satildeo implantadas na iteraccedilatildeo mais

apropriada com consentimento do cliente para natildeo sofrer variaccedilotildees muito grandes no valor

final do mesmo Jaacute no PMBOKreg as alteraccedilotildees no custo do projeto tecircm um impacto criacutetico no

seu ciclo de desenvolvimento Satildeo concentrados os esforccedilos no controle monitoramento e

documentaccedilatildeo das mudanccedilas para que natildeo afete o custo planejado inicialmente no projeto

Os processos na aacuterea de escopo do Scrum definem os toacutepicos a serem priorizados no

Sprint corrente Com enormes chances de alteraccedilatildeo dos requisitos o cliente pode solicitar

alguma funcionalidade nova ou recurso novo no projeto a qualquer momento enquanto

contratante Satildeo implementaccedilotildees iterativas em pequenos lotes onde cada entrega sai alguma

tela recurso ou funcionalidade nova Ao fim tem-se a aplicaccedilatildeo por completa O PMBOKreg

descreve que o escopo eacute definido com alto grau de detalhamento no estaacutegio inicial de

Planejamento Cada processo deve ser documentado e toda informaccedilatildeo levantada serve de

base na especificaccedilatildeo dos requisitos e na gestatildeo de mudanccedilas no andamento do projeto

A aacuterea de cronograma no Scrum se preocupa em definir o cronograma do projeto

orientado ao produto produzido ao final de cada iteraccedilatildeo considerando a entrega de valor

agregado ao cliente e por isso levam geralmente de duas a quatro semanas No PMBOKreg eacute

descrito que o cronograma deve ser orientado ao projeto Estipulado no estaacutegio inicial de

Planejamento os projetos da abordagem tradicional geralmente de grandes proporccedilotildees

costumam levar de meses ateacute anos de desenvolvimento e todas as atividades devem considerar

o prazo do projeto

Tanto na abordagem aacutegil do Scrum quanto na abordagem tradicional das boas praacuteticas

descritas no PMBOKreg haacute a preocupaccedilatildeo de garantir a satisfaccedilatildeo do cliente A aacuterea de

qualidade de ambas as abordagens eacute gerida durante o ciclo de vida do projeto sempre

realizando os conjuntos de testes para garantir que o produto seja entregue de acordo com o

que foi especificado no levantamento de requisitos A diferenccedila eacute que na abordagem aacutegil o

cliente participa ativamente da elaboraccedilatildeo do produto enquanto na abordagem tradicional o

cliente soacute visualiza o software no momento da entrega

A aacuterea de recursos refere-se ao capital humano os esforccedilos que a equipe aplica no

desenvolvimento e gerenciamento do projeto Em ambas as abordagens satildeo encorajadas as

premiaccedilotildees e comemoraccedilotildees no advento de um projeto bem-sucedido Na abordagem aacutegil do

Scrum a confianccedila e a colaboraccedilatildeo dos integrantes da equipe eacute um fator essencial no projeto

A tomada de decisotildees em conjunto exige profissionais habilidosos com alto grau de

conhecimento taacutecito poreacutem natildeo necessariamente precisam estar no mesmo niacutevel Todos da

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

44

equipe tecircm a liberdade de fazer de tudo um pouco e a equipe eacute selecionada de acordo com as

habilidades que cada um desempenha visando atender aos requisitos do Product Backlog Jaacute

nas boas praacuteticas descritas no PMBOKreg as funccedilotildees e cargos satildeo definidos atraveacutes de

processos especiacuteficos visando a organizaccedilatildeo e o gerenciamento da equipe identificando e

documentando as funccedilotildees responsabilidades e as relaccedilotildees hieraacuterquicas entre seus integrantes

melhorando a interaccedilatildeo e o desempenho dos membros da equipe

A aacuterea de aquisiccedilotildees apresenta uma diferenccedila marcante entre as abordagens aqui

estudadas No Scrum haacute uma dificuldade muito grande em se estabelecer negociaccedilotildees atraveacutes

de contratos devido ao fato da ocorrecircncia constante de alteraccedilotildees no escopo original do

projeto Neste contexto natildeo haacute a preocupaccedilatildeo em definir detalhadamente o processo de

aquisiccedilatildeo de mercadorias Por outro lado o processo de aquisiccedilatildeo de bens materiais e

imateriais eacute bem definido e detalhado como descrito no PMBOKreg atraveacutes de um contrato

firmado entre as partes onde tambeacutem pode-se controlar e acompanhar as atividades do

projeto e do fornecedor garantindo que ambas as partes cumpram com o combinado

estabelecido pelo contrato

Haacute uma similaridade presente em ambas as abordagens no que tange a aacuterea de

comunicaccedilotildees que eacute a preocupaccedilatildeo em divulgar e documentar assuntos que satildeo de extrema

importacircncia durante o decorrer do projeto Eacute importante notar que a abordagem aacutegil natildeo

elimina a necessidade de documentar as informaccedilotildees decorrentes do projeto ela apenas natildeo a

prioriza No Scrum haacute um constante feedback durante o processo de construccedilatildeo do produto

aleacutem de comunicaccedilatildeo colaborativa e direta entre os envolvidos atraveacutes de reuniotildees diaacuterias e

em todo o processo de desenvolvimento do projeto Isso proporciona uma maior aproximaccedilatildeo

entre as partes envolvidas ao preccedilo da exigecircncia de que as mesmas tenham maturidade

suficiente para que natildeo haja conflitos Caso contraacuterio o Scrum Master precisaraacute intervir Na

visatildeo do PMBOKreg a comunicaccedilatildeo direta se daacute de forma clara e objetiva considerando as

expectativas do emissorreceptor e os niacuteveis de hierarquia ou seja a relevacircncia da informaccedilatildeo

para determinado cargo Eacute exigida a documentaccedilatildeo formal e detalhada de todos os fatos e

marcos ocorridos a fim de evitar conflitos entre as partes envolvidas no projeto Aleacutem disso a

utilizaccedilatildeo da comunicaccedilatildeo informal pode ajudar ou prejudicar a equipe e os participantes do

projeto dependendo de como se daacute o tratamento entre os superiores e seus subordinados

Como a abordagem aacutegil eacute adaptativa ou seja lida com requisitos complexos onde o

cliente natildeo sabe bem o que estaacute pedindo e a equipe precisa dar respostas raacutepidas agraves mudanccedilas

natildeo existe um plano detalhado de gerenciamento de riscos poreacutem na praacutetica as duas

abordagens satildeo similares neste contexto Na aacuterea de riscos as atividades de identificaccedilatildeo

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

45

anaacutelise monitoramento e respostas aos eventos de risco satildeo realizadas continuamente

durantes as reuniotildees de planejamento de cada iteraccedilatildeo Uma reavaliaccedilatildeo eacute realizada durante

as reuniotildees diaacuterias para analisar e revisar os riscos para que sejam tomadas medidas para

erradicaacute-los nas proacuteximas iteraccedilotildees Nas praacuteticas do PMBOKreg a aacuterea de riscos contempla a

elaboraccedilatildeo de um plano formal para o gerenciamento de riscos garantindo a identificaccedilatildeo

avaliaccedilatildeo quantificaccedilatildeo planejamento de respostas monitoramento e controle dos processos

durante o ciclo de vida do projeto a fim de minimizar as chances de falha causadas por

eventos natildeo planejados

Para finalizar a aacuterea de stakeholders possuem algumas diferenccedilas De um modo geral

as partes interessadas representam indiviacuteduos grupos ou organizaccedilotildees que afetaratildeo ou seratildeo

afetados direta ou indiretamente no desenvolvimento do produto ou pelo produto em si Na

abordagem aacutegil essas partes contemplam a equipe e o cliente que solicitou o produto Na

abordagem tradicional comumente outras organizaccedilotildees ou grupos estatildeo indiretamente

envolvidos na concepccedilatildeo do produto Isso quer dizer que soacutecios e parceiros comerciais estatildeo

contemplados no conceito de stakeholder O PMBOKreg considera mais como partes

interessadas os envolvidos na concepccedilatildeo do produto apesar do cliente tambeacutem ser

considerada uma parte interessada segundo o seu conceito Esta aacuterea eacute responsaacutevel pelo

gerenciamento das expectativas das partes interessadas no que tange o andamento e a

capacidade funcional do produto Eacute responsaacutevel tambeacutem por manter a equipe uma das partes

interessadas motivada a continuar desenvolvendo Essas funccedilotildees se mostram muito mais

fluidas na abordagem aacutegil onde as equipes satildeo auto gerenciaacuteveis ou seja a proacutepria equipe

deve se manter motivada e operante e o Product Owner que eacute o representante do cliente

participa ativamente na elaboraccedilatildeo do produto atraveacutes de feedback e esclarecimentos a cada

entrega

33 Pontos negativos dos modelos

Segundo Pressman (PRESSMAN 2001) o modelo tradicional linear e sequencial eacute o

paradigma mais antigo e o mais utilizado para a Engenharia de Software No entanto criacuteticas

ao modelo causou seus apoiadores a questionar sua eficaacutecia Dentre os problemas que satildeo

encontrados quando o modelo eacute aplicado satildeo eles 1) Projetos reais raramente seguem o fluxo

sequencial que o modelo propotildee pois apesar do modelo acomodar iteraccedilatildeo ele o faz

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

46

indiretamente Como resultado as mudanccedilas causam confusatildeo agrave medida que a equipe avanccedila

2) Eacute geralmente complicado para o consumidor explicitar todos os requisitos O modelo

requer que seja feito este levantamento e demonstra dificuldade em acomodar a incerteza

natural que existe no iniacutecio de muitos projetos 3) O consumidor precisa ter paciecircncia Uma

versatildeo funcional do(s) programa(s) natildeo estaraacute disponiacutevel ateacute as fases finais do ciclo de vida

do projeto Um erro de grandes proporccedilotildees caso natildeo detectado durante as revisotildees do

programa pode ter consequecircncias desastrosas Pressman cita Bradac (1994) e diz que em uma

de suas anaacutelises foi descoberto que a natureza linear do ciclo de vida claacutessico leva a ldquoestados

de bloqueiordquo onde alguns membros da equipe devem aguardar as tarefas dependentes de seus

colegas E de fato o tempo gasto em espera pode exceder o tempo gasto sendo produtivo

Esse estado de bloqueio tende a ser mais predominante no iniacutecio e no final do processo

sequencial Apesar destes problemas serem reais ele continua dizendo no entanto que o

paradigma de ciclo de vida linear tem um lugar definitivo e importante na Engenharia de

Software pois ela provecirc um template no qual os meacutetodos de anaacutelise design codificaccedilatildeo

testagem e suporte podem ser aplicados A abordagem claacutessica permanece como um modelo

procedural amplamente utilizado pela Engenharia de Software e embora ela tenha as suas

fraquezas ela eacute significantemente melhor que uma abordagem aleatoacuteria para desenvolver

softwares

Cockburn e Highsmith (COCKBURN HIGHSMITH 2001) dizem que os meacutetodos

aacutegeis satildeo mais difiacuteceis de se aplicar com equipes grandes Ainda completam dizendo que o

desenvolvimento aacutegil natildeo eacute para todos A imposiccedilatildeo de princiacutepios aacutegeis em organizaccedilotildees

centradas no processo natildeo colaborativas e otimizadoras provavelmente falharaacute A imposiccedilatildeo

de um processo de mutaccedilatildeo de ideias em equipes de projeto tranquumlilas pode natildeo ser sensata A

tentativa de obter colaboraccedilatildeo de usuaacuterios proacutexima com organizaccedilotildees que tecircm pouco tempo

para gastar com os desenvolvedores natildeo funcionaraacute Ou seja como a abordagem aacutegil requer

uma horizontalidade organizacional minimizando os impactos da hierarquia vertical

organizaccedilotildees que possuem tais processos tradicionais enraizados natildeo conseguiratildeo adotar suas

praacuteticas A empresa nasce aacutegil ou ela transforma radicalmente a forma de pensar dos seus

gestores e dos seus colaboradores para a produccedilatildeo de algo em comum O Scrum por exemplo

possui ideias simples poreacutem dominar a metodologia se prova um desafio quando algueacutem se

dispotildee a aprender A comunicaccedilatildeo eacute intensa e a colaboraccedilatildeo eacute imperativa indiviacuteduos

introvertidos encontraratildeo seacuterias dificuldades em achar uma posiccedilatildeo em uma equipe aacutegil

Demanda-se tambeacutem alto niacutevel de conhecimento teacutecnico e taacutecito da equipe de forma que

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

47

todos saibam de tudo um pouco mas natildeo necessariamente precisando dominar o que se faz

Tornar a equipe auto gerenciaacutevel eacute um processo de meacutedio a longo prazo Caso natildeo haja

experiecircncia na equipe capacitaacute-los se prova como um desafio tal qual o domiacutenio da

metodologia

Como visto neste capiacutetulo eacute importante ressaltar que apesar dos pontos negativos

no que tange aos problemas inerentes da gerecircncia de projetos e da engenharia de software a

metodologia aacutegil se torna protagonista ao trazer soluccedilotildees e produzir inovaccedilotildees que mudam o

modo que as pessoas trabalham e transformam a sociedade Sua origem no sistema Toyota de

produccedilatildeo em 1986 utilizando o Scrum na implementaccedilatildeo dos carros em suas faacutebricas trouxe

um novo olhar sobre o modo de trabalhar ser eficiente e eficaz

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

48

4 METODOLOGIA

Neste capiacutetulo seraacute apresentada a metodologia de pesquisa adotada para a validaccedilatildeo

do tema proposto Foi utilizada a metodologia de pesquisa atraveacutes de questionaacuterio para coletar

os dados relacionados agraves praacuteticas do participante na elaboraccedilatildeo de um software Segundo

Kitchenham (KITCHENHAM PFLEEGER 2001) uma pesquisa atraveacutes de questionaacuterio eacute

um sistema abrangente para coletar informaccedilotildees com o intuito de descrever comparar ou

explicar conhecimentos atitudes e comportamentos Portanto este meacutetodo se apresenta como

adequado para avaliar atraveacutes de conhecimentos atitudes e comportamentos se a cultura

DevOps estaacute sendo bem aplicada no contexto das metodologias aacutegeis

O questionaacuterio foi separado em quatro seccedilotildees 1) identificaccedilatildeo do cargo e da

organizaccedilatildeo do participante 2) afirmaccedilotildees que contemplam atitudes caracteriacutesticas de uma

das abordagens de desenvolvimento de software ndash tradicional ou aacutegil 3) afirmaccedilotildees que tecircm o

intuito de perceber a visatildeo do(a) participante sobre ele(a) mesmo dentro da organizaccedilatildeo e 4)

perguntas abertas para avaliar o conhecimento do participante quanto agrave estrutura

organizacional Tais seccedilotildees estatildeo de acordo com o objetivo proposto neste trabalho descrito

no capiacutetulo 2 verificar como o indiviacuteduo atuante no desenvolvimento profissional de

software ou natildeo realiza as suas atividades de planejamento de projetos e desenvolvimento de

software e como ele enxerga a sua participaccedilatildeo na organizaccedilatildeo assim como eacute observada a

cultura organizacional presente

O questionaacuterio conteacutem vinte e seis questotildees sendo quatro da primeira seccedilatildeo de

caraacuteter identificador e dezenove questotildees de caraacuteter afirmativo das seccedilotildees 2 e 3 em escala de

Likert ou seja uma escala de 1 a 5 onde 1 representa ldquoDiscordo Totalmenterdquo e 5 representa

ldquoConcordo Totalmenterdquo Todas estas questotildees satildeo obrigatoacuterias diferente das uacuteltimas trecircs

perguntas da seccedilatildeo 4 que satildeo abertas e destinadas agrave opiniatildeo e a visatildeo do participante sendo

elas natildeo-obrigatoacuterias

As questotildees da seccedilatildeo 1 tecircm o intuito de revelar dados sobre os tipos de cargo os(as)

participantes tecircm na organizaccedilatildeo em que trabalham e categorizaacute-lo(a) de acordo com o

tamanho da empresa em nuacutemeros de funcionaacuterios Desta forma o(a) participante representa a

empresa na participaccedilatildeo do questionaacuterio de acordo com a sua visatildeo

As questotildees da seccedilatildeo 2 correspondem agrave alguma caracteriacutestica de uma das abordagens

envolvidas A maioria das questotildees tem um par antagocircnico ou seja algumas afirmaccedilotildees que

representem uma caracteriacutestica da abordagem tradicional teratildeo uma afirmaccedilatildeo ndash em alguns

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

49

casos duas ndash que represente uma caracteriacutestica da abordagem aacutegil Na maioria dessas

afirmaccedilotildees a concordacircncia de uma questatildeo teraacute de ser corroborada pela discordacircncia de seu

par antagocircnico caso contraacuterio o(a) participante entraraacute em contradiccedilatildeo que eacute o objeto de

estudo neste trabalho Entrando em contradiccedilatildeo poderaacute seraacute configurada uma aplicaccedilatildeo

inadequada da metodologia em questatildeo A tabela 1 detalha quais satildeo as questotildees e quais satildeo

seus pares antagocircnicos

Na seccedilatildeo 3 do questionaacuterio os resultados das afirmaccedilotildees tecircm como objetivo serem

usadas em conjunto com a identificaccedilatildeo da organizaccedilatildeo do(a) participante Por exemplo uma

organizaccedilatildeo praticante dos meacutetodos aacutegeis comumente inclui seus colaboradores na difusatildeo de

informaccedilotildees referentes agrave tomada de decisatildeo da organizaccedilatildeo Dependendo das respostas do(a)

participante confirmam-se as teorias e os conceitos acerca das metodologias aqui estudadas

A Tabela 2 traz os valores por traacutes de cada uma dessas afirmaccedilotildees e o que se busca entender

pela sua resposta

A seccedilatildeo 4 foi reservada para o(a) participante se sentir agrave vontade para escrever sobre a

sua visatildeo da cultura organizacional e de si mesmo na organizaccedilatildeo A decisatildeo de deixar esta

seccedilatildeo com perguntas abertas com risco de natildeo serem respondidas partiu da ideia de que o(a)

participante poderia natildeo saber dizer como se daacute essa configuraccedilatildeo ou com receio de informar

como se daacute a cultura da organizaccedilatildeo por considerar uma informaccedilatildeo sensiacutevel sem garantia de

que a informaccedilatildeo natildeo seraacute divulgada

O questionaacuterio foi divulgado atraveacutes de mensagens diretas para indiviacuteduos que

trabalham ou jaacute trabalharam em atividades que demandassem conhecimento em TI Com este

perfil em mente o autor convidou em suas redes sociais indiviacuteduos com quem possui ou jaacute

possuiu relaccedilotildees profissionais acadecircmicas ou amizade e incentivou a divulgaccedilatildeo do

questionaacuterio para quem conhecesse outros indiviacuteduos com o mesmo perfil Durante dezoito

dias foram coletadas vinte e cinco respostas e foi esperado que o participante respondesse de

forma coerente as perguntas de acordo com o meacutetodo adotado na empresa onde trabalha

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

50

Tabela 2 Afirmaccedilotildees da seccedilatildeo 2 do questionaacuterio e seus pares antagocircnicos

Questatildeo Aacutegil Questatildeo Tradicional Relaccedilatildeo entre osPares Antagocircnicos

O cliente deve sempre dar

feedback sobre as entregas

parciais do software

Os documentos de especificaccedilatildeo

devem conter grande riqueza de

informaccedilotildees Detalha-se muito no

iniacutecio a fim de prever possiacuteveis

bugs no software pois quanto

mais cedo detectar um problema

mais barato eacute

O processo de

documentaccedilatildeo

descrito na questatildeo

tradicional acima eacute

lento e burocraacutetico

O participante que

concorda com esta

frase natildeo deve

concordar com os

seus pares

antagocircnicos Caso

contraacuterio configura-

se a contradiccedilatildeo

Para o desenvolvimento eacute mais

importante garantir uma

funcionalidade o quanto antes

mesmo sabendo que esta

funcionalidade vai mudar

eventualmente

Para cada nova funcionalidade

eacute necessaacuterio a aplicaccedilatildeo

imediata de um teste para

verifica-la e validaacute-la

Os testes satildeo aplicados na fase

final do ciclo de vida de

desenvolvimento

Receber feedback

imeadiato eacute uma

caracteriacutestica

essencial nos

meacutetodos aacutegeis

Aplicar teste

somente no final do

ciclo de vida do

produto aumenta as

chances de serem

encontrados

problemas de

grandes proporccedilotildees

que pode afetar a

disponibilidade do

serviccedilo em

produccedilatildeo

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

51

A primeira entrega de um

produto leva pelo menos um

mecircs

O cronograma eacute orientado ao

prazo do projeto e natildeo ao valor

agregado ao cliente

A entrega raacutepida eacute

uma caracteriacutestica

aacutegil que natildeo pode ser

associada agrave um

modelo de

cronograma

orientado ao prazo

do projeto A

agilidade no

desevolvimento se

daacute pelo fato do

projeto ser orientado

ao valor agregado

entregue ao cliente

devido aos pequenos

lotes de trabalho

As alteraccedilotildees no custo de um

projeto satildeo facilmente

adaptadas em qualquer fase de

desenvolvimento

Eacute fundamental o foco no

controle monitoramento e

documentaccedilatildeo das mudanccedilas para

que natildeo afete o custo planeado

inicialmente no projeto

Nos meacutetodos

tradicionais existem

uma grande

dificuldade em

realizar alteraccedilotildees no

custo de um projeto

por conta da forte

documentaccedilatildeo que eacute

necessaacuteria no

momento das

mudanccedilas Na

abordagem aacutegil

essas alteraccedilotildees

dizem respeito

apenas ao Sprint

corrente sendo

portanto mais faacuteceis

de serem realizadas

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

52

Natildeo haacute problemas caso haja

modificaccedilotildees no escopo do

produto pois elas satildeo

inevitaacuteveis e vatildeo acontecer

Devo trabalhar de forma

adaptativa para garantir uma

boa resposta agraves mudanccedilas

Releases soacute devem ser entregues

a partir do final do projeto inicial

para evitar retrabalhos durante o

desenvolvimento

Trabalhar de forma

adaptativa significa

trabalhar

respondendo agraves

mudanccedilas

inevitaacuteveis Portanto

documentar

processos e gerir

mudanccedilas eacute uma

preocupaccedilatildeo

secundaacuteria na

abordagem aacutegil

visto que o

retrabalho eacute uma

constante e tem a

funccedilatildeo de aprimorar

a qualidade do

produto atraveacutes do

feedback

Cada processo deve ser bem

documentado para que as

informaccedilotildees levantadas sirvam de

base na especificaccedilatildeo dos

requisitos e na gestatildeo de

mudanccedilas durante o andamento

do projeto

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

53

Tabela 3 - Afirmaccedilotildees da seccedilatildeo 3 e seus respectivos valores

Afirmaccedilatildeo Valor

Onde eu trabalho me sinto confortaacutevel em

aplicar minhas soluccedilotildees nos problemas

Autonomia

Onde eu trabalho me sinto livre para

questionar e propor ideias

Liberdade

Onde eu trabalho consigo pocircr agrave prova a

minha capacidade

Lideranccedila

Onde eu trabalho meus colegas datildeo valor ao

meu trabalho

Confianccedila

Onde eu trabalho eu e meus colegas

seguimos de forma rigorosa os processos

Disciplina

Onde eu trabalho sou visto(a) como

referecircncia no que faccedilo

Reconhecimento

Onde eu trabalho sou informado(a) das

tomadas de decisatildeo da companhia

Transparecircncia

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

54

5 RESULTADOS OBTIDOS

Os resultados desta pesquisa seratildeo apresentados neste capiacutetulo da seguinte forma a

seccedilatildeo 61 e suas seccedilotildees subsequentes ateacute a seccedilatildeo 64 contempla os resultados obtidos

referentes agraves questotildees da seccedilatildeo 1 ateacute a seccedilatildeo 4 do questionaacuterio

Na escala de Likert foram utilizados os valores de 1 a 5 onde 1 significa ldquoDiscordo

Totalmenterdquo e 5 significa ldquoConcordo Totalmenterdquo Para fins quantitativos os valores 1 e 2

iratildeo representar a discordacircncia do participante quanto agrave afirmaccedilatildeo ou seja o candidato que

respondeu 1 ou 2 na escala discordou da questatildeo da mesma forma que os valores 4 e 5

representaratildeo a concordacircncia da questatildeo O valor 3 receberaacute um valor de neutralidade onde o

participante natildeo concorda e nem discorda do que foi questionado

No total foram analisadas as respostas de 25 participantes que atenderam ao

questionaacuterio

51 Identificaccedilatildeo do participante

1) Com relaccedilatildeo agrave faixa etaacuteria dos participantes

13 (52) tecircm entre 18 e 25 anos

5 (20) tecircm entre 26 e 35 anos

5 (20) tecircm entre 36 e 45 anos e

2 (8) tecircm mais que 45 anos

2) Com relaccedilatildeo ao cargo dos participantes

7 (28) satildeo analistas

6 (24) satildeo estagiaacuterios

4 (16) satildeo teacutecnicos

3 (12) satildeo especialistas

2 (8) satildeo consultores

2 (8) satildeo diretores e

1 (4) eacute autocircnomo

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

55

3) Com relaccedilatildeo ao perfil profissional dos participantes

16 (64) possuem perfil teacutecnico

6 (24) possuem perfil operacional

2 (8) possuem perfil executivo e

1 (4) possui perfil administrativo

4) Com relaccedilatildeo ao tamanho da empresa que os participantes trabalham

19 (76) trabalham em empresa de grande porte com mais de 99 colaboradores

3 (12) trabalham em empresa de meacutedio porte entre 50 e 99 colaboradores

2 (8) trabalham em microempresastartup com ateacute 9 colaboradores e

1 (4) trabalha em empresa de pequeno porte entre 10 e 49 colaboradores

Com esses dados pode-se concluir que o perfil dos participantes corresponde ao

jovem adulto que trabalha como analista ou estagiaacuterio em setores que demandam atividades

teacutecnicas em empresas de grande porte

52 Caracteriacutesticas das abordagens

Nesta seccedilatildeo seratildeo apresentados os resultados obtidos das perguntas da seccedilatildeo 2

relacionando-as com seus respectivos pares antagocircnicos Foram realizadas tambeacutem algumas

relaccedilotildees que mostraram ser apropriadas apesar de natildeo serem pares antagocircnicos

1) Analisando a questatildeo ldquoNatildeo haacute problemas caso haja modificaccedilotildees no escopo

(funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo acontecer Devo trabalhar de

forma adaptativa para garantir uma boa resposta agraves mudanccedilasrdquo que contempla uma das

questotildees aacutegeis da tabela 1 as repostas foram as seguintes

18 (72) concordaram

4 (16) discordaram e

3 (12) foram neutros

Em seguida foi analisada a questatildeo ldquoReleases soacute devem ser entregues a partir do final

do projeto inicial para evitar retrabalhos durante o desenvolvimentordquo que pertence agraves

questotildees tradicionais da tabela 1 Dos 18 que concordaram com a questatildeo anterior as

respostas foram as seguintes

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

56

9 (50) concordaram

5 (28) discordaram e

4 (22) foram neutros

Comparando as respostas em conjunto pode-se chegar agrave conclusatildeo de que os

participantes que afirmam trabalhar de forma adaptativa em um cenaacuterio onde haacute mudanccedilas no

escopo do produto entram em contradiccedilatildeo quando afirmam que as releases soacute devem ser

entregues a partir do final do projeto para evitar retrabalho Esta contradiccedilatildeo se configura no

momento em que trabalhar de forma adaptativa significa saber lidar com o retrabalho que as

mudanccedilas constantes demandam pois o princiacutepio da abordagem aacutegil adaptativa em um

ambiente dinacircmico eacute divulgar releases sempre em pequenos lotes mesmo que isso signifique

alterar o trabalho jaacute realizado

2) Foi feita a anaacutelise das respostas da questatildeo ldquoO cliente deve sempre dar feedback

sobre as entregas parciais do softwarerdquo ndash da abordagem aacutegil Os resultados foram

21 (84) concordaram

3 (12) discordaram e

1 (4) foi neutro

Os 21 participantes que concordaram com a questatildeo anterior responderam agrave questatildeo

ldquoO cronograma eacute orientado ao prazo do projeto e natildeo ao valor agregado ao clienterdquo ndash da

abordagem tradicional ndash da seguinte forma

8 (38) concordaram

7 (33) foram neutros e

6 (29) discordaram

Analisando as questotildees em conjunto chega-se agrave conclusatildeo que os participantes

concordam que o cliente deve participar do desenvolvimento atraveacutes do feedback Poreacutem os

resultados da segunda questatildeo mostram que nem sempre isso eacute possiacutevel O fato de o

cronograma ser orientado ao prazo do projeto eacute uma caracteriacutestica da abordagem tradicional e

o fato do cronograma ser orientado ao valor agregado ao cliente eacute uma caracteriacutestica da

abordagem aacutegil Portanto conclui-se nessa contradiccedilatildeo que as equipes consideram

importante a presenccedila do cliente mas natildeo conseguem na maioria dos casos consideraacute-lo

como motivaccedilatildeo para a conclusatildeo do objetivo visto que para eles cumprir o prazo eacute mais

importante que entregar valor ao cliente

3) A anaacutelise a seguir foi realizada entre duas questotildees que natildeo satildeo pares antagocircnicos

mas demonstrou relevacircncia quanto ao tema A questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

57

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo que apresentou 18 respostas em concordacircncia em conjunto com a questatildeo ldquoA

primeira entrega de um produto leva pelo menos 1 mecircsrdquo ambas da abordagem aacutegil presente

na tabela 1 apresentaram os seguintes resultados

11 (61) discordaram

5 (28) foram neutros e

2 (11) concordaram

A partir da anaacutelise destes dados percebe-se uma contradiccedilatildeo quando os participantes

afirmam concordar que trabalham de forma adaptativa sugerindo que eles adotam esta

caracteriacutestica da abordagem aacutegil que entrega o software entre 2 e 4 semanas mas respondem

que a entrega do produto natildeo leva pelo menos 1 mecircs

4) A proacutexima questatildeo analisada considerada aacutegil eacute a seguinte ldquoPara o

desenvolvimento eacute mais importante garantir uma funcionalidade o quanto antes mesmo

sabendo que esta funcionalidade vai mudar eventualmenterdquo Entre os participantes os

resultados foram

11 (44) discordaram

10 (40) concordaram e

4 (16) foram neutros

Por apresentar uma divisatildeo de fatos quanto ao tema nesta anaacutelise foram considerados

dois conjuntos o conjunto dos participantes que concordaram com a primeira questatildeo e os

que discordaram da primeira questatildeo Para ambos os conjuntos foi levantada a seguinte

questatildeo ndash tradicional ndash em conjunto com a primeira ldquoCada processo deve ser bem

documentado para que as informaccedilotildees levantadas sirvam de base na especificaccedilatildeo dos

requisitos e na gestatildeo de mudanccedilas durante o andamento do projetordquo

Dentre os 11 que discordaram os resultados foram

8 (73) concordaram

2 (18) foram neutros e

1 (9) discordou

Dentre os 10 que concordaram os resultados foram

7 (70) concordaram

2 (20) foram neutros

1 (10) discordou

Desta anaacutelise foram concluiacutedos dois vereditos para o conjunto dos participantes que

discordaram foi percebida uma confirmaccedilatildeo dos conceitos e teorias que cerceiam o tema da

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

58

abordagem tradicional pois projetos preocupados em gerar a documentaccedilatildeo dos processos

possuem a necessidade de manter o controle das alteraccedilotildees portanto precisam realizar as

atividades de desenvolvimento de modo que haja o miacutenimo de alteraccedilotildees no futuro

Jaacute para o conjunto dos participantes que concordaram com a primeira questatildeo foi

percebida uma contradiccedilatildeo em relaccedilatildeo aos conceitos e teorias que cerceiam o tema de

abordagem aacutegil pois o processo de alteraccedilotildees no escopo ndash o plano de gestatildeo de mudanccedilas ndash eacute

bastante burocraacutetico e demorado que necessita de eventual documentaccedilatildeo dessas variaccedilotildees

Pelo conceito da abordagem aacutegil essa eacute uma prioridade secundaacuteria

5) A questatildeo a seguir corresponde aos conceitos da abordagem tradicional ldquoEacute

fundamental o foco no controle monitoramento e documentaccedilatildeo das mudanccedilas para que natildeo

afete o custo planejado inicialmente no projetordquo Os resultados obtidos foram

19 (76) concordaram

3 (12) discordaram e

3 (12) foram neutros

Em conjunto com a questatildeo ldquoAs alteraccedilotildees no custo de um projeto satildeo facilmente

adaptadas em qualquer fase de desenvolvimentordquo da abordagem aacutegil apresentou os seguintes

resultados dentre os 19 que concordaram

14 (74) discordaram

4 (21) concordaram e

1 (5) foi neutro

Desses 14 que discordaram foi interessante analisar que 10 (72) trabalham em

empresas de grande porte o que corrobora para a confirmaccedilatildeo dos conceitos e das teorias

acerca da abordagem tradicional pois empresas tradicionais de grande porte comumente se

preocupam em controlar monitorar e documentar as mudanccedilas numa tentativa de prevecirc-las

Quaisquer alteraccedilotildees satildeo malvistas do ponto de vista gerencial Os 4 que concordaram

entraram em contradiccedilatildeo

6) A questatildeo a seguir corresponde aos conceitos da abordagem aacutegil ldquoPara cada nova

funcionalidade eacute necessaacuterio a aplicaccedilatildeo imediata de um teste para verificaacute-la e validaacute-lardquo

Os resultados obtidos foram

23 (92) concordaram

1 (4) discordou e

1 (4) foi neutro

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

59

Em conjunto com a questatildeo ldquoOs testes satildeo aplicados na fase final do ciclo de vida de

desenvolvimentordquo da abordagem tradicional apresentou os seguintes resultados dentre os 23

que concordaram

13 (57) discordaram

6 (26) foram neutros e

4 (17) concordaram

Nessa anaacutelise configurou-se a confirmaccedilatildeo quanto aos conceitos da abordagem aacutegil

onde os conjuntos de testes devem ser aplicados apoacutes a implementaccedilatildeo para obter feedback

imediato e assim ter a oportunidade de corrigir o coacutedigo o quanto antes gerando qualidade e

garantindo a satisfaccedilatildeo do consumidor

53 Valores da organizaccedilatildeo

Esta seccedilatildeo apresentaraacute as questotildees referentes aos valores trabalhados na organizaccedilatildeo e

que satildeo percebidos pelos participantes Na primeira coluna da tabela 2 estatildeo descritas as

afirmaccedilotildees seguidas do valor que cada uma representa para o participante Por exemplo a

afirmaccedilatildeo ldquoOnde eu trabalho sou informado(a) das tomadas de decisatildeo da companhiardquo

representa o niacutevel de transparecircncia aplicada pela organizaccedilatildeo de modo que o(a)

colaborador(a) participante desta pesquisa conseguiu perceber A seguir os resultados

1) Autonomia

17 (68) disseram que tecircm

4 (16) disseram que natildeo tecircm e

4 (16) ficaram neutros

2) Liberdade

19 (76) disseram que tecircm

3 (12) disseram que natildeo tecircm e

3 (12) ficaram neutros

3) Lideranccedila

20 (80) disseram que possuem

4 (16) disseram que natildeo possuem e

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

60

1 (4) ficou neutro

4) Confianccedila

21 (84) disseram que possuem

2 (8) disseram que natildeo possuem e

2 (8) ficaram neutros

5) Disciplina

10 (40) disseram que seguem processos disciplinadamente

8 (32) disseram que natildeo seguem processos de forma disciplinada e

7 (28) ficaram neutros

6) Reconhecimento

12 (48) ficaram neutros

10 (40) disseram que satildeo reconhecidos pelo que fazem e

3 (12) disseram que natildeo recebem reconhecimento por aquilo que fazem

7) Transparecircncia

16 (64) disseram que satildeo comunicados das decisotildees da empresa

6 (24) disseram que satildeo alienados agraves decisotildees empresariais e

3 (12) ficaram neutros

Eacute interessante notar que nestas anaacutelises todos os valores especificados na tabela 2 se

encontram em abundacircncia entre os participantes com exceccedilatildeo de disciplina e

reconhecimento que satildeo valores em equiliacutebrio dentre os participantes

Estas questotildees tambeacutem puderam ser utilizadas em conjunto com as questotildees das

seccedilotildees 2 e 4 do questionaacuterio Como exemplo disso foi feita a seguinte anaacutelise da questatildeo

ldquoOnde eu trabalho eu e meus colegas seguimos de forma rigorosa os processosrdquo Os

resultados foram

10 (40) concordaram

8 (32) discordaram e

7 (28) foram neutros

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

61

Dentre os 8 que discordaram foi levantada a questatildeo ldquoComo vocecirc visualiza a

estrutura organizacional da sua empresardquo ndash da seccedilatildeo 4 do questionaacuterio ndash com os

seguintes resultados

4 (50) disseram ser vertical

2 (25) disseram ser horizontal e

2 (25) natildeo souberam responder

Aleacutem disso foram analisadas as respostas desses mesmos 8 participantes que

discordaram da afirmaccedilatildeo inicial com relaccedilatildeo agrave questatildeo ldquoNatildeo haacute problemas caso haja

modificaccedilotildees no escopo (funcionalidades) do produto pois elas satildeo inevitaacuteveis e vatildeo

acontecer Devo trabalhar de forma adaptativa para garantir uma boa resposta agraves

mudanccedilasrdquo ndash da seccedilatildeo 2 do questionaacuterio ndash e foram obtidos os resultados

7 (88) concordaram e

1 (12) discordou

Com as trecircs anaacutelises em conjunto pode-se chegar agrave seguinte conclusatildeo Dentre os

32 dos participantes que natildeo segue os processos de forma rigorosa 25 trabalha em

empresa com estrutura horizontal Ou seja o foco nas organizaccedilotildees horizontais deixa de ser o

processo e passa a ser as pessoas Aleacutem disso desses mesmos 32 88 trabalham de forma

adaptativa reforccedilando o conceito da abordagem aacutegil do trabalho em ambientes em constante

mudanccedila

Portanto estes valores se mostram relevantes tambeacutem quando usados em conjunto

com outras questotildees relacionadas agraves abordagens tradicional e aacutegil Eacute possiacutevel dessa maneira

identificar tendecircncias entre grupos de participantes que justifiquem determinados

comportamentos como visto no exemplo anterior

54 Visatildeo do participante

Esta seccedilatildeo encerra o capiacutetulo apresentando os resultados obtidos das uacuteltimas trecircs

perguntas abertas presentes na seccedilatildeo 4 do questionaacuterio Os resultados satildeo

Dentre os 25 participantes do questionaacuterio

8 (32) participantes natildeo responderam as trecircs perguntas abertas da seccedilatildeo 4

9 (36) participantes responderam pelo menos uma das trecircs perguntas abertas da

seccedilatildeo 4

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

62

11 (44) participantes responderam pelo menos duas das trecircs perguntas abertas da

seccedilatildeo 4 e

13 (52) participantes responderam as trecircs perguntas abertas da seccedilatildeo 4

As perguntas da seccedilatildeo 4 revelam a visatildeo do participante em relaccedilatildeo a estrutura

organizacional da empresa e como as aacutereas interagem entre si Aleacutem disso eacute analisado se o

participante deteacutem de algum entendimento relacionado ao tema do DevOps e das abordagens

tradicional e aacutegil de gerenciamento de projetos apresentadas neste trabalho

Com relaccedilatildeo a visatildeo da estrutura organizacional por parte do participante foram

coletadas as seguintes informaccedilotildees

11 (44) natildeo responderam

8 (32) disseram que a estrutura eacute vertical e hieraacuterquica

4 (16) responderam de forma ambiacutegua portanto a estrutura natildeo pocircde ser definida e

2 (8) declararam trabalhar em uma estrutura horizontal e colaborativa

Com relaccedilatildeo a visatildeo por parte do participante da interaccedilatildeo entre as aacutereas da empresa

foram coletados resultados referentes ao tipo de abordagem ndash tradicional ou aacutegil ndash que se

aproxima agrave realidade na organizaccedilatildeo A seguir

9 (36) natildeo responderam

6 (24) disseram interagir como em uma abordagem tradicional

6 (24) disseram interagir como em uma abordagem aacutegil e

4 (16) responderam de forma ambiacutegua portanto a interaccedilatildeo natildeo pocircde ser definida

Com relaccedilatildeo ao entendimento do participante sobre o tema apresentado neste trabalho

foram consideradas respostas que demonstravam conhecimento e entendimento

conhecimento mas pouco entendimento apenas conhecimento e desconhecimento Os

resultados foram

10 (42) natildeo responderam podendo significar possiacutevel desconhecimento do tema

8 (33) demonstraram conhecer mas entendem pouco sobre o tema

4 (17) demonstraram conhecer e entender o tema

1 (4) disse que jaacute leu ou ouviu algo a respeito e

1 (4) disse que nunca ouviu falar sobre o tema

Portanto os resultados obtidos e apresentados neste capiacutetulo puderam reforccedilar alguns

conceitos relacionados agrave abordagem tradicional como maior controle e monitoramento dos

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

63

processos e seus resultados como forma de previsatildeo para tomada de decisatildeo e os

relacionados agrave abordagem aacutegil como testagem imediata apoacutes a codificaccedilatildeo para receber

feedback e gerar qualidade ambas no que tange as aacutereas de conhecimento Tambeacutem puderam

ser apontadas algumas contradiccedilotildees presentes em atividades como garantir um requisito do

escopo o quanto antes ao mesmo tempo em que haacute a preocupaccedilatildeo em elaborar um plano de

gestatildeo de mudanccedilas considerado secundaacuterio em abordagens aacutegeis por envolver

documentaccedilatildeo Tais contradiccedilotildees podem indicar em contraste com a primeira observaccedilatildeo

feita neste paraacutegrafo uma falta de conhecimento dos conceitos acerca das metodologias

adotadas nas empresas em que trabalham visto que a maioria dos participantes natildeo respondeu

agrave pergunta final do questionaacuterio sobre o entendimento dele sobre o guia de boas praacuteticas de

gerenciamento de projetos e DevOps Aleacutem disso outra grande parte revelou natildeo ter

conhecimento aprofundado acerca dos temas apesar de deter noccedilatildeo do que se trata A maioria

dos participantes informou ter a visatildeo de trabalhar em uma estrutura organizacional vertical e

hieraacuterquica com interaccedilotildees caracteriacutesticas da abordagem tradicional entre os setores da

empresa Por conta disso pocircde ser feita uma observaccedilatildeo com relaccedilatildeo agrave maioria dos

participantes natildeo ter concordado com a frase ldquoOnde eu trabalho sou visto(a) como referecircncia

no que faccedilordquo possivelmente significando uma falta de reconhecimento do trabalho realizado

por eles o que eacute muito comum entre os colaboradores de uma empresa verticalmente

hieraacuterquica Eacute possiacutevel que isto se decirc ao fato de grande parte dos participantes possuir cargo

de estagiaacuterio onde trabalham e portanto natildeo possuem poder de decisatildeo nos planos

estrateacutegicos da empresa No proacuteximo e uacuteltimo capiacutetulo seratildeo apresentadas as consideraccedilotildees

finais e o que se pode concluir a partir da anaacutelise realizada neste trabalho aleacutem da sugestatildeo de

um trabalho futuro

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

64

6 CONSIDERACcedilOtildeES FINAIS

Como pode ser visto neste trabalho a cultura DevOps exige mudanccedilas radicais na

estrutura organizacional das empresas Por ser uma quebra de paradigma ela muda o foco de

processos e algoritmos para pessoas e colaboraccedilatildeo com o intuito de garantir a satisfaccedilatildeo dos

clientes e entregar qualidade atraveacutes da agilidade proporcionada pelo Pipeline de

Implantaccedilatildeo na entrega de seus serviccedilos e softwares produzidos sempre evitando os efeitos

da Espiral Descendente

O questionaacuterio conseguiu mostrar que as empresas participantes representadas pelos

seus colaboradores que atenderam ao questionaacuterio natildeo estatildeo aplicando de maneira adequada

a maioria dos conceitos da abordagem adotada na organizaccedilatildeo devido ao alto nuacutemero de

anaacutelises com resultados contraditoacuterios

Dada a importacircncia do assunto na sociedade pela capacidade de afetar o jeito que as

pessoas trabalham e na maneira de como as empresas se relacionam com os seus

consumidores torna-se necessaacuteria a divulgaccedilatildeo de materiais de treinamento e capacitaccedilatildeo de

pessoal para que desenvolvedores analistas e profissionais de tecnologia em qualquer

posiccedilatildeo profissional natildeo se tornem alienados no seu proacuteprio ambiente de trabalho

Nesse sentido quanto mais pessoas souberem dos benefiacutecios trazidos pela

metodologia aacutegil maior o senso criacutetico com relaccedilatildeo agraves atividades realizadas em determinados

contextos mais conhecimento sobre que tipo de estrutura organizacional elas se identificam

em trabalhar e consequentemente maior a satisfaccedilatildeo pessoal e profissional com o trabalho

realizado com um potencial para motivar outras pessoas a quererem saber mais sobre a

abordagem adotada em sua empresa

Como trabalho futuro sugere-se uma abordagem mais proacutexima agraves organizaccedilotildees

acompanhando o comportamento de seus colaboradores e a realizaccedilatildeo das atividades para

compreender melhor seus processos de desenvolvimento de software Aleacutem disso uma

entrevista com os gerentes responsaacuteveis pelas equipes de desenvolvimento poderia auxiliar na

elaboraccedilatildeo de um perfil teacutecnico do grupo de forma que seja possiacutevel comparar de forma mais

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

65

precisa os resultados da pesquisa com a teoria acerca da abordagem aacutegil de desenvolvimento

de software Pode-se tambeacutem incentivar o aprimoramento do questionaacuterio produzido neste

trabalho para a elaboraccedilatildeo de pesquisas para a geraccedilatildeo de estatiacutesticas correlaccedilotildees

clusterizaccedilotildees ou testes de hipoacutetese

REFEREcircNCIAS BIBLIOGRAacuteFICAS

ABRAHAMSSON P et al Agile software development methods ndash review andanalysis Espoo VTT Publications 2002

CARVALHO B V MELLO C H P Aplicaccedilatildeo do meacutetodo aacutegil scrum nodesenvolvimento de produtos de software em uma pequena empresa de basetecnoloacutegica Gest Prod Satildeo Carlos v 19 n 3 p 557-573 2012 Disponiacutevel em

lthttpwwwscielobrpdfgpv19n309pdfgt Acesso em jun 2018

COCKBURN A HIGHSMITH J Agile Software Development The PeopleFactor IEEE Computer v34 n11 nov 2001 p 131-33

DA SILVA D B DA SILVA R M GOMES M L B O Reflexo da TerceiraRevoluccedilatildeo Industrial na Sociedade 2002

KARDEC M S Estudo de compatibilidade entre PMBOKreg e Scrum Revista

Tecnologias em Projeccedilatildeo v 3 n 1 p 1-7 2012 Disponiacutevel em

lthttprevistafaculdadeprojecaoedubrindexphpProjecao4articleview290182gt

Acesso em set 2018

KIM G HUMBLE J DEBOIS P et al The DevOps Handbook How to CreateWorld-Class Agility Reliability and Security in Technology Organizations 2016

MANN C MAURER F A Case study on the impact of Scrum on overtime andcustomer satisfaction In AGILE DEVELOPMENT CONFERENCE 2005

Proceedings IEEE Computer Society 2005 p 70-79

MORAES E A P Guia PMBOKreg Para Gerenciamento de Projetos UFF 2012

NETO M S FILHO E E Estrutura Organizacional e Equipes de TrabalhoEstudo da mudanccedila organizacional em quatro grandes empresas industriais

2000

66

PELRINE J On Understanding Software AgilitymdashA Social Complexity Point OfView ECO Issue Vol 13 Nos 1-2 2011 pp 26-37 2011

PMI Um Guia do Conhecimento em Gerenciamento de Projetos GuiaPMBOKreg Quinta Ediccedilatildeo ndash EUA Project Management Institute 2013

PORTER M Competitive Advantage Creating and Sustaining SuperiorPerformance 1985

PRESSMAN R S Software Engineering A Practitioners Approach FifthEdition 2001

RISING L JANOFF N S The Scrum software development process for smallteams IEEE Software v 17 n 4 p 26-32 2000 Disponiacutevel em

lthttpdxdoiorg10110952854065gt Acesso em dez 2018

ROYCE WW Managing the development of large software systems conceptsand techniques Proc IEEE Westcon Los Angeles CA 1970

SCHWABER K BEEDLE M Agile software development with SCRUM

Prentice Hall 2002

SNOWDEN D J BOONE M E A Leaders Framework for DecisionMaking Harvard Business Review 69ndash76 2007

SOARES M S Comparaccedilatildeo entre Metodologias Aacutegeis e Tradicionais para oDesenvolvimento de Software 2004 Disponiacutevel em

ltwwwdccuflabrinfocompindexphpINFOCOMParticleview6853gt Acesso em

set 2018

STANDISH GROUP CHAOS report 2016

SUTHERLAND J Scrum A Arte de Fazer o Dobro do Trabalho na Metade doTempo 2012

SUTHERLAND J FOWLER M BEEDLE M et al Manifesto para odesenvolvimento aacutegil de software 2001 Disponiacutevel

emlthttpagilemanifestoorgisoptbrmanifestohtmlgt Acesso em dez 2018