OBSTÁCULOS NA IMPLANTAÇÃO DO SCRUM EM FÁBRICAS DE SOFTWARE

1. RESUMO

O presente trabalho de conclusão de curso propõe o estudo do tema das metodologias ágeis, em particular o Scrum e as possíveis dificuldades de sua adoção plena em empresas de desenvolvimento de software para terceiros. O objetivo é levantar informações, apresentá-las com foco nas dificuldades e não nas virtudes e refletir sobre as mesmas, através da metodologia da revisão bibliográfica. Conclui-se provisoriamente que todo o contexto do projeto deve estar preparado para a adoção da metodologia, desde os colaboradores, até os clientes em geral e que essa mudança cultural ainda está longe de ser tranquila em um ambiente tão complexo como o de desenvolvimento de software.

Palavras-chave: Scrum, Agilidade, Comunicação.

2. INTRODUÇÃO

O tema do emprego de metodologias ágeis no processo de desenvolvimento de sistemas é recorrente e abundante em discussões em todos os meios de comunicação que abordam o assunto, e motivador de diversas pesquisas e estudos.

Dentre elas, uma das mais destacadas é o Scrum. Seus principais benefícios saltam aos olhos de responsáveis por projetos em todas as empresas. Mas estão eles dispostos a enfrentar os seus ônus em busca dos bônus proporcionados? Há dificuldades reais na adoção e implantação do Scrum? Estão eles cientes e até mesmo preparados suficientemente para esses obstáculos?

A profusão de informações acerca do Scrum cita com baixa frequência ou sem grandes detalhes, os desafios aos quais as empresas estarão sujeitas afim de conseguir extrair a máxima agilidade de seus colaboradores e aferir aos seus projetos o status de ágeis.

O estudo definido neste trabalho de conclusão de curso, apresenta como objetivo evidenciar o contraste entre algumas das proposições do framework Scrum e a realidade das empresas de desenvolvimento de software para terceiros, comumente chamadas como “fábricas de software”. Quando identificados, destacar a importância de estarmos prontos para esses problemas e reforçar a importância do foco na eliminação de quaisquer impeditivos que possam acabar por diluir os resultados advindos da implantação do framework Scrum em sua plenitude.

Devido ao escopo reduzido de tempo para a realização do referido trabalho e toda dificuldade e necessidade de recursos disposta para a elaboração de uma pesquisa de campo, a metodologia escolhida fora a de artigo científico de revisão bibliográfica.

O pesquisador e autor deste trabalho também pretende incluir relatos de sua experiencia pessoal no campo profissional que compreende o estudo, baseado em seus conhecimentos acadêmicos e empíricos acumulados ao longo de quase dez anos de trabalho junto à projetos de desenvolvimento de software nos mais diversos contextos, sempre pautando-se pela ética e pela discrição na disseminação de informações quase sempre confidenciais acerca dos projetos nos quais esteve envolvido e ressaltando que eventuais opiniões pessoais não refletem dados cientificamente apurados e por conseguinte não devem ser levados como tal, mas sim, são trazidos na expectativa de exemplificar experiencias reais e enriquecer o debate.

3. DESENVOLVIMENTO

3.1. O que são, de onde surgiram e o que propõe as metodologias ágeis como o Scrum

Para identificarmos e discorrermos sobre as dificuldades, faz-se necessário apresentarmos, ao menos de forma rápida e sucinta, o que é o Scrum e principalmente o que são as metodologias ágeis de software. Além, é claro, de citarmos também os resultados propostos que as tornam atrativas.

A metodologia ágil apresenta diversas vertentes ou frameworks, como são comumente chamados, devido ao fato de normalmente constituírem um conjunto conciso de técnicas que devem ser aplicadas o mais conjuntamente possível.

Dentre elas há várias opções, como por exemplo o exTreme Programming (XP), Crystal, Adaptive Software Development, DSDM, Feature-Driven Development e por fim: o Lean.

Para fins deste trabalho, não serão abordadas em detalhes quaisquer definições acerca de outras metodologias ágeis, como as citadas acima, ficando o escopo, na medida do possível, restrito apenas ao framework Scrum e as propriedades gerais das metodologias ágeis na qual ele se encaixa.

É interessante também abordar, embora superficialmente, um contexto temporal e histórico, visando ilustrar rapidamente as questões que levaram à elaboração dessa metodologia.

Dentre as vertentes citadas, o Lean é, além de parte importante da história das metodologias ágeis, também precursor de muitas ideias por ele difundidas.

"Após a Segunda Guerra Mundial, a Toyota criou o processo de produção Lean Manufacturing (manufatura enxuta) ou TPS (Toyota Production System). Anos depois, esses mesmos conceitos de produção enxuta foram revisitados para maior agilidade do desenvolvimento de sistemas". (FOGGETTI, 2015, p. 3)

A produtividade nas empresas orientais no pós-guerra era notória e influenciava muitos estudiosos da área, além de haver vários casos vivenciados pelo mundo, onde os controles antigos eram apontados como falhos, culminando na criação do manifesto ágil. Trata-se de uma declaração de valores e princípios, criada em fevereiro de 2001, a partir da reunião de dezessete profissionais que já praticavam métodos ágeis em suas carreiras em diversas empresas.

O Scrum foi desenvolvido por Ken Schwaber e Jeff Sutherland (FOGGETTI, 015, p.13). Eles fizeram parte desse grupo de profissionais reunidos na concepção do manifesto e Jeff Sutherland é autor de uma das mais famosas obras sobre Scrum e que é utilizada como referência importante deste trabalho.

Entre estes valores que foram almejados, temos alguns que podem ser considerados mais básicos e que permeiam todos os demais. São eles: indivíduos e interações acima de processos e ferramentas, software em funcionamento mais que documentação abrangente e colaboração com o cliente sobre negociação de contratos.

A partir da reflexão sobre estes valores, já é possível imaginar algumas das dificuldades impostas por se utilizar exclusivamente e em sua totalidade, o framework Scrum para desenvolvimento de software para terceiros e é sobre elas que pretendo concentrar a pesquisa e fazer as reflexões que julgo interessantes.

3.2. As propostas colocadas em prática

A velocidade e a agilidade conseguida com a priorização de indivíduos sobre processos e com software funcionando sobre documentação abrangente, é bastante clara. Contudo ela acaba por ser igualmente uma grande fonte de conflitos nas relações cliente versus fornecedor, devido à baixa incidência de rastreabilidade das decisões tomadas em conjunto e acaba até mesmo por facilitar comportamentos antiéticos em busca de vantagens comerciais.

Além disso, a complexidade dos produtos comumente desenvolvidos apresenta um grande desafio na troca de informações enxutas, abrindo espaço para grandes discussões e falhas de entendimento.

E é nesse contexto que esse valor parece exigir um pouco mais de definição e refinamento envolvendo as partes. Reforçando a importância de se procurar um nível mínimo de documentação e não o desleixo ou mesmo a extinção da prática de registro de decisões e pontos chaves do funcionamento do produto a ser desenvolvido.

"Valores são abstratos demais para guiar comportamentos. Documentos longos têm a intenção de comunicar, assim como diálogos. Qual é o mais efetivo? A resposta depende em parte do contexto e, em parte, de princípios intelectuais. Neste caso, o princípio do humanismo sugere que diálogos atendem à necessidade humana de conexão, portanto, é a forma de comunicação preferível, sem levarmos em conta outros fatores." (TELLES, 2006).

Comunicações pessoais levam a acordos tácitos, mas que podem não ser traduzidos em artefatos de aceitação ou mesmo não serem suficientemente difundidas, levando a problemas futuros.

Pressões podem ser sentidas para a elevação da carga de documentação ou mesmo pela criação de documentações técnicas, não previstas pelo Scrum. Além disso há de se evitar a duplicidade de informações entre os diversos documentos e que se tomar cuidado em não tornar a documentação tida como objetiva em insuficiente.

Para falarmos de forma prática nessas responsabilidades, devemos chegar aos papéis propostos pelo Scrum e, me adiantando às suas definições, cito aqui dois deles que teriam relações mais próximas com essas questões. São eles o Scrum Master e o Product Owner.

O Scrum Master é, segundo Foggetti (2015), similar ao papel de um gerente projetos, sendo responsável por garantir que os princípios e cerimonias do Scrum sejam aplicadas. Já o Product Owner agiria mais como um ponto focal das decisões e até mesmo do conhecimento completo do produto em si.

Os próprios papéis do Scrum podem levantar discussões pela dificuldade em se atrelar esses papéis aos atuais organogramas das empresas. Muitas delas hoje em dia já inclusive contratam pessoas baseadas nessas nomenclaturas e responsabilidades, mas será possível atribuir o papel de dono do produto a uma pessoa que não seja premiada conforme esses interesses? Ou que não tenha a disponibilidade exigida para a tarefa?

Outo ponto que a literatura pouco aborda de forma direta é a solução de conflitos quando a entrega é considerada não satisfatória, principalmente por expectativas distorcidas e por não entendimento da referida documentação. A busca por pontos-chave em discussões já realizadas começa, num processo de “caça às bruxas”, causada por crises de confiança e de conhecimento. O cliente precisa estar familiarizado com o formato de entrega por sprints e confortável com a descrição do que realmente contratou.

São nesses momentos de conflito que usualmente a adoção do Scrum costuma ser freada, a burocracia aumenta e a agilidade evapora. Nos momentos de indefinição, as pessoas tendem a se voltar para a busca de documentos e artefatos que corroborem o que estão argumentando e, dependendo da proporção do problema, isso pode levar a produção de mais documentos no futuro. Principalmente quando, mesmo com a adoção desses, a informação produzida acabou por não ser clara a todas as partes envolvidas na discussão.

“Todo mundo já ouviu que preencher o formulário corretamente é mais importante que realizar o trabalho, ou que é preciso fazer uma reunião para se preparar para outra preparatória. É uma loucura. Ainda assim, continuamos fazendo a mesma coisa. Ainda que estejamos diante do mais completo fracasso.” (SUTHERLAND, 204, p. 386)

O atraso causado pela burocracia e a segurança que ela provê à algumas partes envolvidas no projeto é fácil de se notar em várias histórias e é um dos focos do problema aos quais a agilidade se dispôs a enfrentar e Sutherland conta várias delas para demonstrar a diferença entra as antigas abordagens em cascata ou “portões”.

Ele usa esse termo para ilustrar a existência de pontos de controle em meio as fases do projeto onde, uma vez o obstáculo sendo transposto, as responsabilidades vão se perdendo e a importância da missão vai migrando para os entregáveis produzidos em forma de documentação, em substituição ao produto em si.

“Em seguida, há um ‘portão’, em que um gerente ou um grupo de gerentes precisa dar o aval para que o projeto vá em frente. Depois disso, há uma fase de escopo, na qual todo o ‘pessoal das exigências’ resolve o que o produto fará. Em seguida há outro portão, e outra série de reuniões, e aí esses documentos monstruosos são entregues à fase seguinte[...] Os integrantes dessa equipe nunca viram o produto antes, mas eles o testam, aprovam e empurram para outro portão” (SUTHERLAND, 204, p. 858)

Em momentos de crises e conflitos as pessoas tendem a procurar novamente pelo porto seguro representado pela ideia dos portões, mesmo que, pela “tentativa” de adoção do Scrum, esses portões tenham parecidos até aqui, bem tênues e tranquilos ou até mesmo turvos. O que facilitava a agilidade no início do projeto pode ser tornar um complicador no futuro, caso os desentendimentos não consigam ser sanados.

“Então falei que no fim do mês entregaria um software que funcionasse, em vez de um diagrama de Gantt não cumprido. Ele mesmo poderia testá-lo para verificar se estávamos no caminho certo. Precisávamos tentar essa abordagem se quiséssemos cumprir o prazo”. (SUTHERLAND, 204, p. 554)

O interessante neste outro relato de Sutherland, em contraponto ao anterior, é que alguém, em algum momento, nesse caso personificado provavelmente pelo CEO que fazia o papel do cliente do seu plano de ação, precisou arriscar o resultado esperado em nome da confiança que depositava no modus operandi proposto por ele.

E essa confiança, no contexto atual de desenvolvimento de software para terceiros, é baseada em contratos que muitas vezes não propiciam esse tipo de comportamento e segurança.

Sendo o contrato um dos tipos mais importantes de documentação, acabamos por esbarrar no terceiro valor apresentado, que define que colaboração com o cliente deve estar acima de negociação de contratos.

"Quando um contrato de um projeto com duração de vários anos é elaborado, com todos os requisitos enunciados naqueles lindos gráficos, é tentador dizer: 'Bem, isso é tudo.'Então, o fornecedor diz: 'Concordo em fazer isso e apenas isso. Se você quiser qualquer mudança, vai ter um custo'" (SUTHERLAND, 204, p. 2952)

Foi a partir da observação acima que o Scrum, na figura de Jeff Sutherland, propôs também novos modelos de contrato, não ficando restrito apenas a metodologias práticas de gestão de equipes, mas sim, olhando para o processo como um todo, desde a sua concepção, entrega e sustentação, passando até mesmo pelas relações comerciais e a necessidade de atenção às mesmas.

"Foi por isso que pensei na ideia de 'alterações gratuitas'. Em um contrato de preço fixo padrão, diga que as alterações são de graça. Liste todas as funcionalidades que espera.[...] acho que isso equivale a cem pontos, o mecanismo de carregamento, digamos de são cinquenta pontos. [...] e por aí vai, até o fim da lista. [...] Então, a cada sprint, o cliente, que nesse cenário é obrigado por contrato a trabalhar em estreita colaboração com o Product Owner, pode mudar as prioridades. Todos os itens do backlog podem ser reordenados. E novos recursos? Sem problema: basta abdicar de outras funcionalidades com o mesmo tamanho." (SUTHERLAND, 204, p. 2952)

É possível intuir que, os processos internos da equipe de desenvolvimento devem estar alinhados com o processo comercial e jurídico da companhia, na formulação dos modelos de negócio e contratos, para que possíveis discrepâncias não sejam fonte de conflitos que tirem o foco e até mesmo venham a distorcer o produto final.

Verifica-se que, em se tratando de documentações, sejam elas comerciais ou técnicas, o Scrum propõe uma atenção mais humanista e enxuta aos detalhes e para isso, é importante também que seus clientes tenham certa experiencia na gestão desses contratos, bem como dos requisitos em si.

Nem sempre o ambiente de desenvolvimento de software, compreendido pelo cliente e seu fornecedor, apresentam um grau semelhante de maturidade, que lhes permita versar sobre essas questões com facilidade, o que se configura em uma grande barreira no emprego dessas técnicas.

Mas como promover a evolução do seu cliente? Essa é uma questão de difícil argumentação e reposta, porém, o correto emprego do Scrum propõe soluções.

A partir da sua máxima de promover a interação, naturalmente ocorrerá uma adequação e evolução nos processos e na comunicação, bem como no já esperado andamento do projeto em si.

"No Scrum, ao fim de cada ciclo você tem algo de valor que pode ver, tocar e mostrar aos clientes. Você tem a oportunidade de perguntar para eles: 'É isso que você quer? Isso resolve pelo menos uma parte do seu problema? Estamos indo na direção certa?' Se a resposta for não, mude o seu plano." (SUTHERLAND, 204, p. 2952)

Nesse contexto, a frequente apresentação de resultados, em formato de software utilizável, acaba por suplantar a necessidade do registro de toda e qualquer decisão e principalmente de enormes materiais descrevendo o produto, mas repare como a participação do cliente é muito mais regular do que em gestões tradicionais, o que levanta a necessidade que ele esteja não só ciente, mas igualmente bem preparado.

É importante ressaltar também, que nesse ponto se fará necessário gerenciar muito bem a expectativa do cliente no contato com um produto ainda em fase inicial, que careça de diversos ajustes e que apresente problemas que deviam ser esperados à esta altura, gerando frustrações e preocupações descabidas.

Para promover a interação e torná-la a mais produtiva possível, oferecendo software e não documentação a cada rodada, é necessário que toda a equipe esteja muito atenta a divisão dos sprints.

“Certa vez uma gerente de produtos que participava de um workshop meu, disse: “Esse lance de Sprints até que é legal, mas algumas entregas que são feitas simplesmente não me importam muito e acabam não resolvendo meu problema”. Respondi sobre a palavra-chave do que a Sprint deve produzir: VALOR. Não adianta pegar um projeto e fracionar em 10 Sprints, sendo que a maior parte delas não agrega valor ao produto e apenas nas últimas é possível ter feedback do cliente final. Muitos agilistas principiantes acabam “fatiando” o produto em diversas entregas, mas erram no valor agregado nestas entregas.” (MASSARI)

Cada sprint é uma oportunidade de iteração que deve ser levada muito a sério. Por outro lado, será possível ter tanto valor para entregar em intervalos tão regulares? Esse é realmente um grande desafio, já que no começo de projetos, principalmente os grandes, é realmente complicado encontrar entregáveis de valor ao cliente, que já possibilitem a solução de alguns problemas, enquanto normalmente, o que ainda se está criando é a base arquitetural que permitirá ao software cumprir o seu papel.

Sendo assim, algumas tarefas muito importantes e de longa duração, acabam por não conseguir cumprir esse papel de gerarem valor palpável e visível aos clientes. Além é claro, da já citada necessidade da gestão da percepção do cliente frente a um produto inacabado.

Outro fato bem comum é o sucesso de alguns projetos com Scrum levarem gestores a identificar de forma errada os pontos que o levaram a esse sucesso, como por exemplo, querer impor o mesmo tempo de sprint a todos os projetos e equipes ou mesmo se apoiar em observações erronias, como diminuir os sprints ao máximo tentando aumentar a produtividade. O que surgiu como uma fonte de agilidade e flexibilidade pode padecer do próprio sucesso, se convertendo em novos processos pétreos e imutáveis que atrapalham futuras atividades.

Foi possível notar até aqui que, para cada prática fomentada pelo Scrum há diversos entraves e paradigmas a serem quebrados. Há sim muitas dificuldades e de difícil solução. Ele não representa um porto seguro onde podemos nos ancorar para encontrar respostas para todos os nossos problemas.

O próprio fato de pregar a confiança nas pessoas e suas capacidades até mesmo com auto-gestão, já é um problema em si e exige muito cuidado.

Muito mais dilemas e dificuldades poderiam ser detectados e elencados ao longo de um trabalho que dispusesse de mais tempo e recursos, como por exemplo, um estudo que incluísse pesquisas de campo, entrevistas e outras ferramentas que possibilitassem geração de estatísticas e melhores contrapontos.

Contudo, acredito que esta singela dissertação tocou em pontos interessantes e procurou desmistificar as belas frases de efeito que tornam as metodologias ágeis as meninas dos olhos de gerentes de projetos e stakeholders ávidos para sempre obterem o melhor de suas equipes e pouco refletindo sobre o seu próprio papel e a confiança que eles hão de investir no processo.

Seja qual for o processo de gestão de desenvolvimento de software, haverão desafios e como na tecnologia empregada na codificação em si, o segredo está em identificar com cuidado o melhor uso para cada técnica e não procurar aplicar as mesmas soluções a todos os problemas.

4. CONSIDERAÇÕES FINAIS

Com o aprofundamento do meu conhecimento, baseado nas leituras e pesquisa que fiz visando este trabalho, a minha admiração pela iniciativa do movimento ágil e principalmente o apreço pelo Scrum em si só fez aumentar. Mas ainda mais claro se tornou para mim o quanto devemos estar prontos a prever dificuldades ocultas e a refletir sempre que nos deparamos com novos mantras da indústria, ainda mais quanto mais exaustivamente isso ocorrer.

Em minha própria experiência pessoal e profissional ainda estamos presos aos métodos ultrapassados de gerenciamento, quando não temos um cenário ainda pior, onde, devido ao sucesso e fama dos métodos ágeis, o mercado cobra seus benefícios, sem abrir mão dos antigos e rígidos controles.

As empresas representadas pelas figuras dos seus gestores se mostram ainda muito inseguras de evoluir certos paradigmas para finalmente poderem adotar o Scrum em sua plenitude e poder colher de forma completa seus benefícios, mas a única maneira de vencermos essas barreiras é através da difusão desses valores e principalmente na comparação de seus resultados frente dados históricos e por muitas vezes questionáveis, conseguidos baseados em velhas práticas.

Concluo dizendo esta pesquisa não conseguiu sequer passar da superfície na proposta de identificação de problemas e obstáculos na adoção do Scrum. Entretanto foi possível deparar-se com a escassez de materiais e literatura a respeito, confirmando e justificando ainda mais a importância de sua proposta.

5. REFERÊNCIAS

FOGGETTI, C. (Org.). Gestão ágil de projetos. São Paulo: Pearson Education, 2015. (Coleção Bibliografia Universitária Pearson). (Biblioteca Virtual Pearson).

SOUZA, Diogo Rodrigues de; Implantação da metodologia ágil Scrum em um ambiente de desenvolvimento. UNIVERSIDADE FEDERAL DE SANTA CATARINA CAMPUS ARARANGUÁ. Araranguá, dezembro de 2014. Disponível em: <https://repositorio.ufsc.br/xmlui/bitstream/handle/123456789/130043/TCC%20Final.pdf?sequence=1&isAllowed=y>. Acesso em 10/03/2018 as 10:34

SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. Editora Leya. 2014.

MASSARI, Vitor. Scrum: 10 situações de quando ele poderá (e certamente irá) fracassar. Disponível em: <https://www.profissionaisti.com.br/2013/09/scrum-10-situacoes-de-quando-ele-podera-e-certamente-ira-fracassar/>. Acesso em 10/03/2018 as 12:15.

Modelo de Gestão de Projetos para Empresas de Desenvolvimento de Software. Disponível em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1583>. Acesso em 10/03/2018 as 12:15.

TELLES, Vinicius Manhães. Princípios do XP. Disponível em: <http://www.desenvolvimentoagil.com.br/xp/principios/>. Acesso em Acesso em 21/04/2018 as 12:38. Publicado em 02/10/2006.

BRASILEIRO, Roberto. Manifesto Ágil, o que é e qual a sua história. Disponível em: <http://www.metodoagil.com/manifesto-agil/>. Acesso em 21/04/2018 as 12:44.