Conforme relatado na literatura e verificado atrav´es do estudo de caso e da survey realiza- dos na presente pesquisa, o Scrum pode de fato contribuir para elimina¸c˜ao de desperd´ıcios em processos de desenvolvimento de softwares.
A estrutura iterativa e incremental estabelecida pelo m´etodo, onde busca-se realizar pe- quenas parcelas utiliz´aveis do software, mostrou ter impacto positivo em grande parte dos desperd´ıcios do desenvolvimento de software. Al´em disso a transparˆencia e a constante inspe¸c˜ao e adapta¸c˜ao promovida pelo framework atrav´es dos seus eventos e artefatos pro- move oportunidades para que desperd´ıcios sejam identificados e eliminados durante todo o desenvolvimento.
Conforme relatado por (BARTON, 2009) e verificado no estudo, o Scrum implementa um
sistema de fluxo semelhante a produ¸c˜ao puxada promovido pelo Lean. Desta forma, atrav´es dos eventos Scrum, as equipes possuem controle sobre sua carga de trabalho na itera¸c˜ao, podendo desta forma prevenir problemas como desbalanceamento (Mura) e sobrecargas (Muri ).
Verificou-se tamb´em que os eventos e artefatos definidos pelo framework s˜ao considerados como elementos que contribuem para gera¸c˜ao de valor e suficientes para realizar o trabalho de desenvolvimento, auxiliando a evitar reuni˜oes ou documenta¸c˜oes adicionais que impac- tem negativamente o valor na perspectiva do cliente, evitando desta forma desperd´ıcios relacionados ao Extra Processamento.
Como forma de responder a quest˜ao de pesquisa QP3 (Como se d´a na pr´atica a rela¸c˜ao entre Scrum e os desperd´ıcios do desenvolvimento de software?), com base nos resultados obtidos na presente pesquisa, a tabela 4 descreve as rela¸c˜oes identificadas entre as pr´aticas Scrum e os desperd´ıcios do desenvolvimento de software, ilustrando os desperd´ıcios que podem ser eliminados atrav´es de cada pr´atica Scrum.
Pr´atica Scrum Desperd´ıcios que identifica ou elimina. Retrospectiva da Sprint: Desbalanceamento (Mura), Sobrecarga (Muri ),
Desperd´ıcios (Muda) em geral.
Sprint: Desbalanceamento (Mura), Sobrecarga (Muri ),
Atrasos, Trabalho parcialmente completo, Funci- onalidades Extra
Times pequenos e multifuncionais: Desbalanceamento (Mura), Handoffs e Atrasos
Planejamento da Sprint: Desbalanceamento (Mura), Sobrecarga (Muri ), Mudan¸ca de Contexto, Atrasos, Handoffs, De- feitos, Funcionalidades Extra, Trabalho parcial- mente completo
Reuni˜ao di´aria: Desbalanceamento (Mura), Sobrecarga (Muri ) e todos os tipos de Muda (Handoffs, Atrasos, Ex- tra Processamento, Defeitos, Funcionalidades Ex- tra, Trabalho Parcialmente Completo, Mudan¸ca de Contexto)
Refinamento de Backlog: Desbalanceamento (Mura), Sobrecarga (Muri ), Handoffs, Atrasos, Defeitos, Funcionalidades Ex- tra.
Revis˜ao da Sprint: Trabalho parcialmente completo e Funcionalida- des extra.
Defini¸c˜ao de Pronto: Defeitos
Tabela 4: Scrum x Desperd´ıcios do desenvolvimento de softwares
Conforme verificado em estudos como (GIROT, 2013) e (VERSION ONE, 2011), diversas
companhias adotam o Scrum de forma parcial, aplicando somente algumas das pr´aticas e orienta¸c˜oes definidas pelo m´etodo. Com base nos resultados obtidos na presente pesquisa,
verifica-se, por´em, que ado¸c˜ao parcial ou inadequada do framework pode, em diversos casos, favorecer a ocorrˆencia dos desperd´ıcios do desenvolvimento de software.
De acordo com Schwaber (2004), ao contr´ario de processos definidos como a abordagem em cascata onde busca-se controlar antecipadamente aspectos relacionados aos entreg´aveis, o Scrum ´e um processo emp´ırico que assume a complexidade do desenvolvimento de soft- ware e se utiliza da constante inspe¸c˜ao e adapta¸c˜ao para produzir os melhores resultados poss´ıveis. Todavia, verificou-se que em diversos casos, companhias tratam o Scrum como um processo definido, estabelecendo previamente escopos e prazos fixos para a constru¸c˜ao dos incrementos.
Desta forma, ao contr´ario do que ´e explicitamente recomendado pelo framework, verificou- se que em alguns casos, companhias tratam os eventos do framework como reuni˜oes for- mais de status ou de acompanhamento de projetos. Constatou-se que este fator pode even- tualmente causar desperd´ıcios como Sobrecarga (Muri ) e tamb´em afetar a transparˆencia promovida pelo Scrum, na medida em que membros acabam por ocultar eventuais pro- blemas relacionados aos incrementos ou ao processo na tentativa de apresentar o trabalho no qual havia se comprometido a realizar.
Tamb´em foi observado que por diversas vezes, equipes se comprometem a realizar uma carga de trabalho que excede a sua capacidade na itera¸c˜ao com o objetivo de atender prazos estabelecidos externamente. Esta situa¸c˜ao faz com que membros se sintam pressi- onados a realizar todo o trabalho planejado para a Sprint, causando desperd´ıcios relacio- nados a Sobrecarga (Muri ) e Desbalanceamento (Muri ). Conforme visto na survey, esta situa¸c˜ao pode tamb´em ocasionar o comprometimento da qualidade dos itens desenvolvi- dos, causando desperd´ıcios adicionais, como defeitos.
Observa-se, por´em, que os objetivos da Sprint devem ser definidos pelo time de desen- volvimento com base em sua capacidade e com base nos crit´erios definidos na defini¸c˜ao de pronto. Conforme discutido, a sobrecarga causada por este fator pode se dar devido a press˜oes externas ou pela inexperiˆencia das equipes na utiliza¸c˜ao do framework.
De acordo com diversos estudos como (SCHWABER; SUTHERLAND, 2013), (SUTHERLAND; SCHWABER, 2007) e (SCHWABER, 2004) equipes Scrum s˜ao por defini¸c˜ao multifuncio- nais e auto-organiz´aveis. Entretanto, conforme descrito no estudo de caso (cap´ıtulo 5) e verificado na survey, diversas companhias possuem equipes Scrum constitu´ıdas de especi- alistas que atuam somente em suas ´areas. Conforme analisado, a especializa¸c˜ao extrema em equipes Scrum pode causar desperd´ıcios como Handoffs, atrasos, desbalanceamento e sobrecargas no processo, na medida em que impacta a colabora¸c˜ao e gera esperas ociosas.
Durante o estudo, verificou-se tamb´em que os planos das Sprints tendem a ser interrompi- dos frequentemente por trabalho n˜ao planejado. Este fator pode comprometer o objetivo da sprint e causar problemas como Sobrecarga (Muri ), e trabalho realizado parcialmente, al´em de causar mudan¸cas de contexto prejudiciais ao processo.
Foi observado tamb´em que defeitos n˜ao urgentes e d´ebitos t´ecnicos s˜ao frequentemente adiados em algumas das equipes Scrum analisadas. Apesar de n˜ao terem sido identificados meios diretos de avaliar o impacto deste fator em rela¸c˜ao a qualidade dos produtos no cen´ario analisado, estudos como (POPPENDIECK; POPPENDIECK, 2006) apontam que o tratamento de defeitos deve ser realizado de maneira cont´ınua no processo, de forma que o seus impactos podem ser agravados com o tempo, causando desperd´ıcios adicionais como reaprendizado.
Por ´ultimo, observou-se que a defini¸c˜ao de pronto n˜ao ´e utilizada frequentemente na pr´atica. Diversos times reportaram n˜ao utilizar tal elemento para avaliar a completude dos itens implementados, conforme indicado pelo framework. Verifica-se que a n˜ao uti- liza¸c˜ao deste elemento pode impactar em desperd´ıcios como defeitos e trabalho realizado parcialmente. Observa-se, entretanto, que este elemento n˜ao ´e descrito detalhadamente na literatura Scrum, podendo desta forma causar diferentes interpreta¸c˜oes e torn´a-lo talvez subjetivo.