Desperd´ıcio (Muda ) 1 Defeitos

1. O desperd´ıcio ocorre na companhia?

Frequentemente.

2. De que maneira se apresenta?

Este tipo de desperd´ıcio parece ser o mais recorrente na companhia. Grande parte dos produtos s˜ao mantidos h´a mais de 10 anos. Portanto h´a uma grande base de c´odigo legado, que ´e constantemente alterada, gerando novos defeitos frequen- temente. Esta situa¸c˜ao vai ao encontro do estudo Poppendieck, Cusumano et al. (2012), que afirma que no desenvolvimento de software legados, em m´edia 40 a 50% do tempo ´e consumido na detec¸c˜ao e elimina¸c˜ao de defeitos. Observa-se que defeitos n˜ao identificados nos produtos durante um longo per´ıodo, parecem de fato trazer grandes preju´ızos a companhia.

Verificou-se que h´a um distanciamento entre o desenvolvimento e o cliente final. As equipes n˜ao possuem contato direto com os clientes dos elementos que implementam. A comunica¸c˜ao ´e realizada atrav´es dos gerentes de conta da companhia e alguns outros canais indiretos, possibilitando desta forma que informa¸c˜oes sejam perdidas no caminho, resultando por diversas vezes em requisitos mal interpretas e defeitos no produto.

“Eu vejo este desperd´ıcio (Defeitos) ocorrendo frequentemente na compa- nhia. Acredito que na maioria das vezes isto ´e causado pela falta de comu- nica¸c˜ao entre o cliente e o time de desenvolvimento. Existe uma grande distˆancia entre n´os, com esta distˆancia ´e prov´avel que interpretemos coisas de maneira inadequada, ou que mudan¸cas ocorram no caminho.” (Entr. 5, tradu¸c˜ao do pesquisador)

3. Rela¸c˜oes com o Scrum

Em geral, o Scrum parece n˜ao ter grande impacto neste tipo de desperd´ıcio. Apesar de os times manterem uma defini¸c˜ao de pronto que estabelece verifica¸c˜oes de qua- lidade nos itens implementados, como realiza¸c˜ao de testes automatizados e testes unit´arios, por diversas vezes as verifica¸c˜oes tornam-se n˜ao aplic´aveis devido a prazos ou devido ao fato de o c´odigo ser legado. Os participantes relatam que a realiza¸c˜ao dos itens previstos da defini¸c˜ao de pronto geraria um esfor¸co desproporcional ao escopo do item de backlog.

Foi observado tamb´em que uma quantidade significativa de defeitos ´e preterida con- tinuamente, alguns defeitos est˜ao presentes no backlog da equipe h´a mais de um ano. Esta situa¸c˜ao pode causar outros tipos de desperd´ıcios, como reaprendizado e transferˆencias de conhecimento adicionais. Portanto, eliminando as demais vari´aveis como prioridades de neg´ocio e decis˜oes estrat´egicas, a utiliza¸c˜ao de um backlog pri- orizado parece ter um impacto negativo na corre¸c˜ao de bugs presentes nos sistemas da companhia.

Todavia, conforme descrito na caracteriza¸c˜ao do ambiente, as equipes mant´em um ´

unico backlog para todos os produtos em que atua. Esta abordagem ´e divergente ao defendido pela metodologia Scrum, onde ´e prevista a manuten¸c˜ao de um backlog dedicado a cada Produto.

5.2.3.2 Funcionalidades Extra

1. O desperd´ıcio ocorre na companhia?

Ocasionalmente

2. De que maneira se apresenta?

N˜ao foi identificada a ocorrˆencia deste desperd´ıcio com frequˆencia na organiza¸c˜ao. Todavia, verifica-se que a identifica¸c˜ao e elimina¸c˜ao deste desperd´ıcio ´e dificultada

pelo distanceamento existente dentre o time de desenvolvimento e o cliente final, conforme descrito no item anterior.

Em rela¸c˜ao ao c´odigo, por se tratar de uma su´ıte de produtos padronizados, ven- didos a diferentes clientes, grande parte das funcionalidades requeridas por clientes espec´ıficos s˜ao arquitetadas da forma mais abrangente poss´ıvel. Apesar de poder antecipar requerimentos de outros poss´ıveis clientes, esta abordagem por vezes re- sulta em uma complexidade incompat´ıvel com a demanda do cliente inicial, gerando tamb´em funcionalidades e ´areas de c´odigo que s˜ao raramente utilizadas. Todavia, a maioria dos participantes questionados em rela¸c˜ao a este fator indica que a compa- nhia tem se beneficiado desta estrat´egia.

3. Rela¸c˜oes com o Scrum

O Scrum parece ter impacto positivo em rela¸c˜ao a este desperd´ıcio. Os participan- tes indicam que a manuten¸c˜ao do backlog priorizado, aliado a curtas itera¸c˜oes e limita¸c˜oes de escopo parecem prover uma estrutura que contribui para que apenas as funcionalidades que gerem maior valor para o cliente sejam implementadas.

5.2.3.3 Mudan¸ca de Contexto

1. O desperd´ıcio ocorre na companhia?

Frequentemente.

2. De que maneira se apresenta?

Mudan¸cas de contexto parecem ocorrer de forma frequente nas equipes analisadas. N˜ao existe uma equipe dedicada a manuten¸c˜ao na companhia. Portanto, as equipes s˜ao respons´aveis pela manuten¸c˜ao dos produtos que desenvolvem, isto implica em uma frequente ocorrˆencia de interrup¸c˜oes no trabalho da equipe. Por diversas vezes durante uma itera¸c˜ao, os membros das equipes alternam entre a implementa¸c˜ao de novas funcionalidades e solicita¸c˜oes de suporte. Al´em disso, em uma mesma Sprint, itens de diferentes produtos e diferentes tipos s˜ao implementados, ocasionando uma constante alternˆancia de contexto por parte dos membros.

Uma outra vertente deste tipo de desperd´ıcio no ambiente analisado ´e atua¸c˜ao dos membros da equipe em diversas tarefas em paralelo. Na tentativa de evitar a espera ociosa por parte dos testadores, desenvolvedores geralmente trabalham em mais de uma tarefa simultaneamente, resultando em uma constante troca de contexto.

3. Rela¸c˜oes com o Scrum

Frequentemente, ao contr´ario do que ´e definido pelo Scrum, o plano da sprint n˜ao ´

e respeitado, causando desta forma mudan¸cas de contexto, no sentido em que a equipe se prepara previamente para implementar um conjunto de funcionalidades e acaba tendo que mudar o curso durante a execu¸c˜ao da Sprint.

Al´em disso, o Scrum define a cria¸c˜ao e manuten¸c˜ao de um Backlog com itens relaci- onados a um produto espec´ıfico. Portanto, intui-se que a equipe deveria direcionar seus esfor¸cos apenas a um produto durante uma itera¸c˜ao. Todavia, conforme dis- cutido anteriormente, a empresa utiliza um ´unico Backlog para a equipe, com itens de diversos produtos, por vezes n˜ao diretamente relacionados, causando com que as equipes atuem em diversos produtos em uma mesma itera¸c˜ao.

Em rela¸c˜ao a desenvolvedores trabalhando em m´ultiplas tarefas simultaneamente, o Scrum n˜ao define diretamente nenhuma regra ou recomenda¸c˜ao em rela¸c˜ao a aloca¸c˜ao de tarefas, por´em a reuni˜ao di´aria sugerida pela metodologia deve ser utili- zada para que os membros se auto organizem e definam a melhor forma de trabalho para que alcancem o objetivo da Sprint. Entretanto, no caso do ambiente analisado, a reuni˜ao parece n˜ao ter impacto significativo na identifica¸c˜ao e elimina¸c˜ao deste tipo de desperd´ıcio.

5.2.3.4 Atrasos

1. O desperd´ıcio ocorre na companhia?

Frequentemente.

2. De que maneira se apresenta?

Apresenta-se principalmente na forma de espera ociosa por parte de testadores no in´ıcio da itera¸c˜ao, conforme discutido no item Mura do presente estudo de caso. Ocorre tamb´em na configura¸c˜ao de ambientes para replica¸c˜ao de defeitos e quando as equipes precisam lidar com fatores externos.

3. Rela¸c˜oes com o Scrum

Conforme discutido na se¸c˜ao Mura, a presen¸ca de pap´eis ou t´ıtulos espec´ıficos no time de desenvolvimento pode estar favorecendo a ocorrˆencia de atrasos no processo, de forma que em diversos momentos da itera¸c˜ao, membros precisam aguardar para iniciar suas tarefas.

Outro tipo de espera ociosa ´e referente a presen¸ca de membros n˜ao engajados nas reuni˜oes propostas pelo framework. Verifica-se que, por diversas vezes, este des- perd´ıcio ´e agravado pelo limitado n´ıvel de colabora¸c˜ao nas equipes e pela obriga- toriedade de participa¸c˜ao de todos os membros em reuni˜oes espec´ıficas. Devido a maneira em que as equipes distribuem o seu trabalho, durante as reuni˜oes grande parte dos itens s˜ao discutidos apenas por um pequeno subgrupo. Esta situa¸c˜ao gera esperas ociosas e parece contribuir para o desengajamento dos demais membros.

5.2.3.5 Trabalho Parcialmente Completo

1. O desperd´ıcio ocorre na companhia?

Raramente

2. De que maneira se apresenta?

Este tipo de desperd´ıcio parece ser relativamente raro na companhia. Todavia, existem ocorrˆencias na forma de documenta¸c˜oes incompletas, funcionalidades n˜ao sincronizadas e testes automatizados incompletos. Foram identificadas tamb´em si- tua¸c˜oes onde a conclus˜ao dos itens de backlog ´e impedida ou dificultada por inter- rup¸c˜oes no trabalho planejado para a itera¸c˜ao. Devido a outros prazos e prioridades, os elementos parcialmente completos por vezes tˆem sua conclus˜ao postergada por longos per´ıodos, causando outros tipos de desperd´ıcios como Handoffs e reaprendi- zado.

3. Rela¸c˜oes com o Scrum

Os participantes indicaram que as reuni˜oes de refinamento de backlog e as curtas itera¸c˜oes auxiliam na preven¸c˜ao deste tipo de problema. De maneira geral, foi poss´ıvel perceber um impacto positivo do Scrum em rela¸c˜ao a este desperd´ıcio.

5.2.3.6 Transferˆencia de Conhecimento (Handoff )

1. O desperd´ıcio ocorre na companhia?

Ocasionalmente

2. De que maneira se apresenta?

Apresenta-se na forma de pequenos handoffs, ou transferˆencias de tarefas por parte dos membros durante a itera¸c˜ao. Os participantes relatam que transferˆencias de co-

nhecimento s˜ao frequentes na fase de pr´e-desenvolvimento, devido ao distanciamento dos clientes. Al´em disso, identificou-se que a alta complexidade dos produtos da companhia pode favorecer a ocorrˆencia deste tipo de problema. Novamente relativo `

a especializa¸c˜ao nas equipes, os membros por vezes trabalham em silos, causando pequenos handoffs durante toda a Sprint para que o trabalho seja sincronizado.

3. Rela¸c˜oes com o Scrum

Os participantes indicaram que as reuni˜oes di´arias, reuni˜oes de retrospectiva da sprint e reuni˜oes de refinamento do backlog podem auxiliar a eliminar este tipo de desperd´ıcio.

5.2.3.7 Extra Processamento

1. O desperd´ıcio ocorre na companhia?

Raramente

2. De que maneira se apresenta?

N˜ao foram identificados casos significativos de extra processamento na companhia. Os participantes acreditam que o processo da companhia ´e enxuto o bastante, sendo pouco prescritivo e possuindo poucas burocracias ou passos adicionais que n˜ao geram valor ao cliente. Por outro lado, verificou-se uma alta incidˆencia de membros n˜ao engajados nas reuni˜oes realizadas. Este problema parece ser minimizado em reuni˜oes onde a presen¸ca dos membros se d´a de maneira opcional.

3. Rela¸c˜oes com o Scrum

Durante as entrevistas, a maioria dos participantes indicou que o framework Scrum fornece as reuni˜oes necess´arias para execu¸c˜ao do trabalho, minimizando desta forma a necessidade de reuni˜oes adicionais. Todavia, alguns membros parecem n˜ao estar totalmente engajados nas reuni˜oes realizadas.

Percebeu-se que na maioria das equipes, raramente os membros do time atuam em um mesmo item do backlog simultaneamente. Esta pode ser uma das raz˜oes pela qual membros perdem o interesse nas reuni˜oes realizadas, afinal quando itens s˜ao alocados a indiv´ıduos, discuss˜oes coletivas podem n˜ao fazer sentido. Apesar de n˜ao descrever explicitamente que membros devem atuar nos mesmos itens de backlog, o cen´ario apresentado na companhia est´a de certa forma em contradi¸c˜ao com as

orienta¸c˜oes gerais do Scrum que indicam que o time deve atuar como uma unidade integra na implementa¸c˜ao dos produtos.

6

Survey

Este cap´ıtulo busca apresentar os resultados obtidos atrav´es da survey realizada. Al´em de apresentar dados sobre os participantes, este cap´ıtulo descreve os resultados das quest˜oes dispostas no question´ario, relacionando-os aos diferentes tipos de desperd´ıcio do desen- volvimento de software.

6.1

Participantes

A pesquisa obteve 67 respostas de profissionais que atuam com o framework Scrum na ind´ustria de desenvolvimento de softwares neozelandesa. Os participantes foram solicita- dos a indicar de forma opcional a empresa em que atuam. Apesar de grande parte ter omitido esta informa¸c˜ao, foram identificadas respostas de 11 companhias diferentes.

Dos participantes, 13.4% tem atuado com Scrum em per´ıodo inferior a um ano. 40.3% atuam com o Scrum de 1 a 2 anos. 6% atuam com Scrum de 4 a 6 anos e finalmente 10.4% dos participantes atuam com o framework mais de 6 anos.

A m´edia estimada de experiˆencia atuando com Scrum ´e de 2,7 anos, sendo um pouco superior a m´edia dos entrevistados (2,08) durante a realiza¸c˜ao do estudo de caso. A figura 7 descreve a experiˆencia dos participantes.

Figura 7: Experiˆencia dos respondentes com o framework Scrum

Conforme demonstrado na figura 8, 58.2% dos participantes atuam com o desenvolvi- mento de novos produtos, enquanto que 41.8% possuem um maior envolvimento com a manuten¸c˜ao de softwares existentes.

Figura 8: Tipo de desenvolvimento no qual os respondentes atuam

Os resultados demonstram tamb´em que 91.9% dos participantes possuem t´ıtulos ou papeis espec´ıficos em seus times. Este dado deve ser levado em considera¸c˜ao ao analisar os resultados, pois como visto na se¸c˜ao 3.3, o Scrum n˜ao permite pap´eis ou t´ıtulos espec´ıficos no time de desenvolvimento. No estudo de caso este fator mostrou-se como uma das causas de desperd´ıcios na companhia analisada. A figura 9, ilustra os resultados obtidos.

Figura 9: Presen¸ca de t´ıtulos nos times de desenvolvimento

Conforme ilustrado na figura 10, a maioria dos participantes s˜ao Desenvolvedores (38,8%), seguidos por Testadores (19,4%), Outros (11.9%), Analistas de neg´ocio (10,4%), Coach (7,5%), Membro multifuncional (7.5%) e Scrum Masters (4.5%).

Figura 10: Designa¸c˜ao principal dos participantes

6.2

Desbalanceamento (Mura )

No estudo de caso (capitulo 5), foi verificado que devido a novos itens serem iniciados a cada itera¸c˜ao, alguns membros das equipes, como testadores, apresentavam-se ociosos nos per´ıodos iniciais da sprint. Desta forma, na tentativa de verificar se esta situa¸c˜ao se

apresentava em outros cen´arios, a seguinte afirma¸c˜ao foi inclu´ıda no question´ario:

• Devido a novos itens serem iniciados a cada itera¸c˜ao, existem momentos na sprint nos quais membros possuem uma carga de trabalho reduzida ou nula.

A maioria dos participantes indicou concordˆancia com a afirma¸c˜ao (75,7%). O alto valor da mediana (4), aliado ao baixo valor de amplitude interquartil (0,5) calculados para as respostas indicam que os participantes possuem um elevado n´ıvel de concordˆancia com a afirma¸c˜ao, demonstrando tamb´em consenso em rela¸c˜ao ao item.

Os resultados detalhados s˜ao ilustrado na figura 11.

Figura 11: Desbalanceamento (Mura) no per´ıodo inicial das itera¸c˜oes

Na outra quest˜ao da pesquisa relacionada a Mura, os participantes foram solicitados a indicar o grau de concordˆancia em rela¸c˜ao a eficiˆencia das pr´aticas Scrum em remover este tipo de desperd´ıcio do processo. Desta forma, a seguinte afirmativa foi adicionada a pesquisa:

• A pr´atica Scrum a seguir ajuda o meu time a manter constantes cargas de trabalho no projeto, evitando desequil´ıbrios ou desn´ıveis no processo.

As alternativas nas quais os participantes deveriam indicar o seu grau de concordˆancia foram: Planejamento da Sprint, Reuni˜ao Di´aria, Refinamento de Backlog, Revis˜ao da Sprint, Pequenos Times Multifuncionais, Itera¸c˜oes Curtas, Defini¸c˜ao de Pronto.

A Reuni˜ao de planejamento da Sprint obteve o melhor desempenho em rela¸c˜ao a este tipo de desperd´ıcio, possuindo um alto n´ıvel de concordˆancia e um consenso significa- tivo (med =4; aiq=0). Os participantes indicam tamb´em que o Refinamento do Backlog (med =4; aiq=1), Pequenos Times Multifuncionais (med =4; aiq=1), Curtas Itera¸c˜oes

(med =4; aiq=1) e Reuni˜ao Di´aria (med =4; aiq=2) auxiliam os seus times na elimina¸c˜ao de Mura.

Conforme os dados obtidos, a Revis˜ao da Sprint (med =3; aiq=2) e a Defini¸c˜ao de Pronto (med =3; aiq=2) parecem n˜ao ter impacto significativo na elimina¸c˜ao deste desperd´ıcio. A mediana e a amplitude interquartil calculados para cada evento s˜ao ilustradas na figura 12.

Figura 12: Pr´aticas Scrum x Mura

6.3

Sobrecarga (Muri )

No estudo de caso realizado diversas equipes mostravam-se sobrecarregadas ou pressiona- das no final da itera¸c˜ao na tentativa de entregar todo trabalho planejado para a sprint. Portanto, como forma de verificar se esta situa¸c˜ao se apresentava em outros cen´arios, a seguinte afirma¸c˜ao foi inclu´ıda no question´ario:

• O time fica sobrecarregado no final da itera¸c˜ao, antes da revis˜ao da sprint, na tentativa de entregar todo o trabalho que seu comprometeu a realizar.

Uma consider´avel parte dos participantes (47.8%) indicou que esta situa¸c˜ao ocorre com frequˆencia, enquanto que 16.4% demonstraram opini˜ao contr´aria. 35,8% dos participantes

relataram que o problema ocorre algumas vezes. Desta forma, verificou-se que apesar de grande parte da amostra indicar que o problema ocorre com frequˆencia, as opini˜oes est˜ao um pouco divididas em rela¸c˜ao a este item (med =3; aiq=1).

Figura 13: Muri (sobrecarga) no final das itera¸c˜oes

Uma outra vertente do Muri, identificado no estudo de caso, foi o comprometimento de fatores de qualidade na tentativa de completar o trabalho no per´ıodo de tempo estabele- cido. Desta forma, novamente na tentativa de verificar se este problema ocorre em outros cen´arios, a seguinte afirma¸c˜ao foi disposta no question´ario:

• O time sacrifica qualidade na tentativa de entregar todo o trabalho que se compro- meteu a realizar na sprint.

Apesar de uma consider´avel parcela dos participantes indicarem que este problema ocorre com frequˆencia (29,9%), a maioria dos participantes indica que esta situa¸c˜ao ocorre ra- ramente (40,3%). Por outro lado, 29.9% dos participantes indicaram que esta situa¸c˜ao ocorre algumas vezes. Desta forma, n˜ao houve um consenso em rela¸c˜ao a afirma¸c˜ao, as opini˜oes mostraram-se consideravelmente divididas (med =3; aiq=2).

Figura 14: Frequˆencia na qual o time sacrifica aspectos de qualidade para finalizar os itens da sprint.

No estudo de caso, foram identificados raros casos nos quais profissionais se sentiam pressionados ou sobrecarregados devido a realiza¸c˜ao da reuni˜ao di´aria. Na tentativa de verificar se esta situa¸c˜ao ocorre em outros cen´arios, a seguinte afirma¸c˜ao foi inclu´ıda na survey.

• Os times se sentem pressionados ou sobrecarregados devido a reuni˜ao di´aria.

A maioria dos participantes (70.2%) expressaram que a situa¸c˜ao ocorre raramente, 20.9% indicaram que o problema ocorre algumas vezes, enquanto que apenas 9% indicam que a situa¸c˜ao ocorre frequentemente. O valor da mediana (2) aliado ao baixo valor de amplitude interquartil (1.5) indicam que esta situa¸c˜ao ocorre raramente na opini˜ao dos participantes.

Figura 15: Frequˆencia na qual os times se sente pressionados ou sobrecarregados devido a reuni˜ao di´aria.

No ´ultimo item referente ao Muri na pesquisa, os participantes foram solicitados a indicar o grau de concordˆancia em rela¸c˜ao a eficiˆencia das pr´aticas Scrum em eliminar este tipo de desperd´ıcio. Desta forma, a seguinte afirmativa foi adicionada a pesquisa:

• A seguinte pr´atica Scrum tem auxiliado o meu time a evitar cargas de trabalho pesadas ou insustent´aveis.

Novamente, as alternativas nas quais os participantes deveriam indicar o seu grau de con- cordˆancia foram: Planejamento da Sprint, Reuni˜ao Di´aria, Refinamento de Backlog, Re- vis˜ao da Sprint, Pequenos Times Multifuncionais, Itera¸c˜oes Curtas, Defini¸c˜ao de Pronto.

Conforme esperado, devido a se tratar do fluxo de trabalho das equipes, os resultados refe- rentes a esta afirmativa foram bastante semelhantes aos obtidos em rela¸c˜ao ao desperd´ıcio Mura. A Reuni˜ao de planejamento da Sprint tamb´em obteve o melhor desempenho em rela¸c˜ao a este tipo de desperd´ıcio, possuindo um alto n´ıvel de concordˆancia e um con- senso significativo (med =4; aiq=0). Os participantes indicam tamb´em que o Refinamento do Backlog (med =4; aiq=1), Pequenos Times Multifuncionais (med =4; aiq=1), Curtas Itera¸c˜oes (med =4; aiq=1) e Reuni˜ao Di´aria (med =4; aiq=1,5) auxiliam os seus times na elimina¸c˜ao de Muri.

A Revis˜ao da Sprint (med =3; aiq=2) e a Defini¸c˜ao de Pronto (med =3; aiq=2) novamente parecem n˜ao ter impacto significativo na elimina¸c˜ao deste desperd´ıcio. Os resultados s˜ao ilustrados na figura 16.

Figura 16: Pr´aticas Scrum x (Muri )