O processo de Desenvolvimento

O processo de desenvolvimento utilizado pela companhia ´e baseado no framework Scrum (se¸c˜ao 3.3), por´em com algumas altera¸c˜oes que ser˜ao detalhadas nas se¸c˜oes a seguir.

O setor analisado ´e estruturado em nove equipes. Cada equipe ´e respons´avel por um conjunto de produtos ou tecnologias espec´ıficas. As equipes s˜ao constitu´ıdas de quatro a oito profissionais. Ao contr´ario do recomendado pelo Scrum, os times de desenvolvimento possuem t´ıtulos n˜ao definidos pelo framework. Portanto cada equipe possui, em todos os casos, ao menos um profissional com cada um dos seguintes t´ıtulos: Desenvolvedor, Analista de neg´ocio, Testador e L´ıder t´ecnico.

O papel de Scrum Master ´e atribu´ıdo de forma adicional a um dos membros da equipe, n˜ao sendo desempenhado de forma dedicada. As equipes contam tamb´em com um diretor

de produto, que atua como Product Owner e ´e respons´avel por priorizar e analisar as demandas implementadas pelas equipes.

5.1.1.1 Pr´e-desenvolvimento

As equipes mantˆem um ´unico Backlog, onde s˜ao alocados itens de diferentes produtos. Os itens dispostos podem ser referentes a corre¸c˜ao de bugs, aprimoramento de produtos ou implementa¸c˜ao de novas funcionalidades. Tais itens s˜ao adicionados nos backlogs das equipes atrav´es de duas principais maneiras:

Desenvolvimento de novo produto ou funcionalidade: Neste caso, o processo se inicia atrav´es da identifica¸c˜ao de uma oportunidade de neg´ocio ou de uma requisi¸c˜ao de cliente. As demandas s˜ao analisadas por gerentes de contas da companhia em rela¸c˜ao a sua viabilidade e caso se mostrem vi´aveis, s˜ao encaminhadas aos diretores dos produtos afetados. Os diretores de produto, juntamente com os analistas de neg´ocio da equipe, detalham os requisitos identificados de forma a estrutura-los em itens de backlog de pro- duto. Ap´os esta etapa, os diretores de produto priorizam e alocam os itens no backlog da equipe.

Corre¸c˜ao de defeitos: O processo se inicia atrav´es da identifica¸c˜ao interna ou externa de defeitos em produtos da companhia. Os defeitos s˜ao analisados pela equipe de suporte, e caso confirmados, s˜ao encaminhados aos diretores dos produtos afetados, que priorizam e alocam novos itens referentes ao defeito no Backlog da equipe.

5.1.1.2 Desenvolvimento

Na companhia analisada as atualiza¸c˜oes de produto (releases) s˜ao lan¸cadas em ciclos pr´e- fixados de duas semanas. Portanto, todas as equipes do setor realizam Sprints com esta dura¸c˜ao. Desta forma, a cada duas semanas uma reuni˜ao de planejamento da Sprint ´e realizada visando selecionar os itens que ser˜ao implementados na Sprint em quest˜ao. Ap´os o in´ıcio da itera¸c˜ao, reuni˜oes di´arias s˜ao realizadas para distribui¸c˜ao e verifica¸c˜ao do andamento de atividades. Ap´os o t´ermino do per´ıodo estabelecido, a Sprint ´e finalizada com a realiza¸c˜ao de uma reuni˜ao de Revis˜ao da Sprint, onde o diretor de produto verifica os itens implementados, realizando cr´ıticas e sugerindo melhorias que podem ser adicionadas como itens no Backlog. Ap´os esta reuni˜ao a equipe realiza a Retrospectiva da Sprint, onde s˜ao identificados pontos de melhorias no processo de trabalho da mesma. Este processo se repete indefinidamente, enquanto existirem itens nos backlogs das equipes.

Durante a Sprint a equipe realiza tamb´em algumas reuni˜oes adicionais n˜ao descritas pelo framework Scrum. Estas reuni˜oes envolvem a distribui¸c˜ao de trabalho e a comunica¸c˜ao com outras equipes.

5.2

Resultados

A partir da an´alise dedutiva realizada, foram obtidos os seguintes resultados em rela¸c˜ao aos desperd´ıcios do desenvolvimento de software na companhia. Na tentativa de estruturar a an´alise de forma objetiva, os itens a seguir buscam abordar trˆes principais t´opicos sobre cada tipo de desperd´ıcio:

1. O desperd´ıcio ocorre na companhia?

2. De que maneira se apresenta?

3. Rela¸c˜oes com o Scrum

5.2.1

Desbalanceamento (Mura )

1. O desperd´ıcio ocorre na companhia?

Frequentemente.

2. De que maneira se apresenta?

Devido a especializa¸c˜oes no time de desenvolvimento, a carga de trabalho dos mem- bros durante uma itera¸c˜ao ´e por vezes irregular. Este problema se apresentou de forma semelhante em diversas equipes e foi a principal forma de Mura identificada no estudo de caso.

“No in´ıcio das Sprints os testadores basicamente n˜ao possuem trabalho. Todavia, na medida que nos aproximamos do final da sprint, eventual- mente h´a uma sobrecarga e press˜ao para que eles finalizem o trabalho, pois temos o objetivo de ter todos os itens desenvolvidos e testados ao final da itera¸c˜ao.” (Entr. 3, tradu¸c˜ao do pesquisador)

Durante as entrevistas, verificou-se que os profissionais associam este tipo de pro- blema a fatores como: forma na qual dividem o trabalho, colabora¸c˜ao entre os diferentes pap´eis durante as itera¸c˜oes, quantidade de testadores na equipe e ultima- mente a forma como a metodologia Scrum foi implementada na companhia.

De maneira geral, verifica-se que este problema poderia ser minimizado atrav´es de uma maior colabora¸c˜ao dentre os profissionais. A aproxima¸c˜ao entre testadores, analistas de neg´ocio e desenvolvedores nas etapas iniciais da itera¸c˜ao tem auxiliado equipes a evitarem problemas desta natureza.

3. Rela¸c˜oes com o Scrum:

Verificou-se que a forma de trabalho proposta pelo Scrum e adotada pela companhia, onde novos itens s˜ao iniciados e conclu´ıdos durante a itera¸c˜ao, tem causado dificul- dades na distribui¸c˜ao do trabalho dentre os membros das equipes durante alguns per´ıodos da Sprint. Esta situa¸c˜ao ocorre principalmente devido `as especializa¸c˜oes no time de desenvolvimento, que por diversas vezes resultam em membros ociosos, principalmente nos per´ıodos iniciais da itera¸c˜ao, onde ainda n˜ao existem elementos test´aveis. Esta situa¸c˜ao tem gerado consequentes atrasos e sobrecargas nas equipes.

Todavia, percebeu-se que o Scrum tem auxiliado a identificar e eliminar outros tipos de irregularidades no processo. As reuni˜oes di´arias e de retrospectiva da sprint tˆem sido utilizadas para discutir pontos relacionados a colabora¸c˜ao e a divis˜ao de trabalho dentre os membros durante a itera¸c˜ao, al´em do fluxo de trabalho da equipe como um todo.

“Acredito que o Scrum seja uma boa solu¸c˜ao para este problema (Mura), se implementado da maneira correta. Por´em, este ´e um processo de apren- dizado, eu acredito que se aprendermos a colaborar como um time, evi- tar´ıamos este tipo de situa¸c˜ao.” (Entr. 4, tradu¸c˜ao do pesquisador)

Entretanto, o gerente de desenvolvimento (Entr.1) e o gerente de setor (Entr. 2) relataram durante as entrevistas que este tipo de desperd´ıcio passou a ser percebido com mais frequˆencia ap´os a ado¸c˜ao do Scrum. Estes alegam que no modelo adotado anteriormente, semelhante ao modelo em cascata, este tipo de problema se apresen- tava de maneira mais rara, uma vez que testadores e desenvolvedores constitu´ıam equipes distintas e trabalhavam de forma cont´ınua em diferentes funcionalidades.

Existem tamb´em profissionais na companhia que acreditam que o Scrum n˜ao possua rela¸c˜oes diretas com este tipo de problema, indicando que o framework n˜ao imp˜oe qualquer regra direta que favore¸ca ou impe¸ca a ocorrˆencia deste desperd´ıcio. Um dos entrevistados descreve “Eu acredito que todo processo de desenvolvimento pos- sua foco prim´ario no desenvolvedor, problemas deste tipo (desn´ıveis entre teste e desenvolvimento) n˜ao s˜ao causados exatamente pelo Scrum”

4. Observa¸c˜oes

Parte dos problemas identificados parecem estar relacionados aos diferentes pap´eis que constituem a equipe de desenvolvimento. Cabe ressaltar que conforme apresen- tado na se¸c˜ao 3.3, o Scrum, em sua defini¸c˜ao, n˜ao permite pap´eis ou t´ıtulos diferentes dos estabelecidos pelo framework, alegando que a presen¸ca de t´ıtulos (extrema es- pecializa¸c˜ao) no time de desenvolvimento pode dificultar a colabora¸c˜ao dentre os membros da equipe (SCHWABER; SUTHERLAND, 2013). Esta alega¸c˜ao parece se afirmar no cen´ario analisado.

5.2.2

Sobrecarga (Muri )

1. O desperd´ıcio ocorre na companhia?

Ocasionalmente.

2. De que maneira se apresenta?

Este tipo de desperd´ıcio se apresenta principalmente nos per´ıodos finais da Sprint, onde os membros do time do desenvolvimento buscam completar os itens que pla- nejaram e se comprometeram a realizar durante a itera¸c˜ao. Em algumas equipes este desperd´ıcio se apresenta tamb´em quando existem prazos (deadlines) urgentes determinados para o desenvolvimento de funcionalidades ou corre¸c˜ao de defeitos pri- orit´arios. Quando definidos, estes prazos n˜ao parecem levar em conta a capacidade das equipes nas itera¸c˜oes, causando sobrecarga (Muri ) nas equipes e prejudicando fatores relacionados a qualidade dos itens desenvolvidos.

““Quando temos um press˜ao em rela¸c˜ao ao tempo, n´os frequentemente temos que ignorar alguns procedimentos de qualidade, na tentativa de respeitar os prazos de- finidos.” (Entr. 9, tradu¸c˜ao do pesquisador)”

Verificou-se tamb´em que colaboradores com extenso conhecimento dos produtos da companhia, como l´ıderes de equipe, possuem geralmente uma elevada carga de trabalho, pois est˜ao constantemente auxiliando outros times e indiv´ıduos menos experientes na companhia de forma concorrente `as tarefas de suas equipes.

3. Rela¸c˜oes com o Scrum:

No aspecto geral, verifica-se que o Scrum tem auxiliado a evitar este tipo de pro- blema. A possibilidade de planejar o trabalho a ser realizado em cada itera¸c˜ao

permite que os time estabele¸cam um ritmo sustent´avel, definindo a carga de tra- balho adequada. Al´em disso, foi observado que na maioria das vezes, o Scrum centraliza as requisi¸c˜oes de trabalho, protegendo a equipe de interrup¸c˜oes causadas por requisi¸c˜oes externas.

Entretanto, conforme citado, percebe-se que frequentemente fatores de qualidade s˜ao comprometidos na tentativa de entregar os itens planejados para a Sprint, situa¸c˜ao que pode acarretar em outros tipos de desperd´ıcios, como defeitos e retrabalho.

Todavia, verificou-se que as reuni˜oes de Retrospectiva e de Planejamento da Sprint tˆem auxiliado as equipes a identificar e eliminar este tipo de desperd´ıcio, tornando vis´ıveis problemas e ajustando a carga de trabalho em rela¸c˜ao a capacidade das equipes.

5.2.3

Desperd´ıcio (Muda )