UNIVERSIDADE FEDERAL FLUMINENSE BACHARELADO EM … · 2020-05-25 · ANÁLISE DA APLICAÇÃO DA...
Transcript of UNIVERSIDADE FEDERAL FLUMINENSE BACHARELADO EM … · 2020-05-25 · ANÁLISE DA APLICAÇÃO DA...
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
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
- 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
-
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
- 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
-
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
- 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
-