Desperd´ıcios do Desenvolvimento de Software

Assim como na manufatura, no desenvolvimento de software Lean desperd´ıcio ´e definido como qualquer atividade que n˜ao seja conducente a cria¸c˜ao de valor ao cliente (MIDDLE-

TON; JOYCE, 2012). O desenvolvimento de software Lean tem como foco eliminar itens e processos desnecess´arios, sem que as medidas tomadas causem novos desperd´ıcios como defeitos e reaprendizagem.

A elimina¸c˜ao de desperd´ıcios depende da compreens˜ao dos diferentes tipos de desperd´ıcios que podem ocorrer no desenvolvimento de software. Mary e Tom Poppendieck adaptaram os 7 desperd´ıcios da manufatura (Muda) para a engenharia de software (POPPENDIECK; POPPENDIECK, 2003). Tais desperd´ıcios s˜ao ilustrados na Figura 5 e discutidos nas se¸c˜oes a seguir.

Figura 5: Mapeamento dos desperd´ıcios da manufatura ao desenvolvimento de software. Fonte: Adaptado de Poppendieck e Poppendieck (2003)

3.2.2.1 Defeitos

Defeitos requerem retrabalho e podem ser custosos. O desenvolvimento de software Lean enfatiza a preven¸c˜ao de defeitos com atividade cont´ınua, realizada sempre que poss´ıvel, en- quanto abordagens tradicionais de desenvolvimento de software tendem a dedicar tempos e recursos para a detec¸c˜ao de defeitos. Estat´ısticas demonstram que no desenvolvimento de software legado, em m´edia 40 a 50% do tempo de desenvolvimento ´e consumido na

detec¸c˜ao e elimina¸c˜ao de defeitos (POPPENDIECK; CUSUMANO et al., 2012). O dano cau- sado por um simples defeito pode ser mensurado como produto do impacto causado pelo defeito e o tempo que este permaneceu no produto sem ser percebido. Isto significa que um defeito cr´ıtico que ´e detectado nas etapas iniciais do desenvolvimento pode n˜ao ser uma grande amea¸ca ou fonte de desperd´ıcio. Todavia, um pequeno defeito n˜ao detectado no sistema durante um longo per´ıodo de tempo pode trazer grandes preju´ızos ao produto e ao cliente, causando manuten¸c˜oes futuras.

3.2.2.2 Funcionalidades Extra

De acordo com Hibbs, Jewett e Sullivan (2009), o princ´ıpio de Pareto (80-20) aplicado ao desenvolvimento de software sugere que 80% das necessidades dos clientes s˜ao atendi- das por 20% das funcionalidades do produto. As demais funcionalidades s˜ao raramente, ou nunca utilizadas. Funcionalidades extras se configuram no maior tipo de desperd´ıcio do desenvolvimento de software, de maneira que consome deliberadamente recursos do projeto. Durante o ciclo de vida do software, cada linha de c´odigo escrita deve ser inte- grada, testada e mantida por diversas vezes. As funcionalidades ou peda¸cos de c´odigos que n˜ao podem ser relacionadas `as necessidades ou requisitos reais se tornar˜ao poss´ıveis pontos de falha. Desta forma, recomenda-se que c´odigos ou funcionalidades que n˜ao s˜ao necess´arios imediatamente n˜ao sejam constru´ıdos ou inclu´ıdos na solu¸c˜ao (POPPENDIECK; POPPENDIECK, 2003).

3.2.2.3 Mudan¸ca de Contexto (Task Switching )

Ao contr´ario do que diversas organiza¸c˜oes acreditam, de acordo com Poppendieck e Pop- pendieck (2003), envolver o mesmo recurso em m´ultiplos projetos ao mesmo tempo pode se tornar uma fonte de desperd´ıcio, de forma que esta medida afeta negativamente o fluxo e a produtividade dos profissionais. Toda vez que desenvolvedores de software alteram o foco entre diferentes tarefas ou projetos, uma consider´avel quantidade de tempo ´e ne- cess´aria para que se compreenda os pr´e-requisitos das tarefas e para que um ritmo est´avel seja alcan¸cado. Desta forma, enquanto alternam entre diferentes tarefas, os desenvolve- dores de software devem reaprender diversas vezes para que retomem o mesmo n´ıvel de produ¸c˜ao que possu´ıam quando atuando na mesma tarefa (HIBBS; JEWETT; SULLIVAN, 2009).

3.2.2.4 Atrasos

Relacionados a esperas ociosas no processo, atrasos no desenvolvimento de software s˜ao detectados frequentemente em situa¸c˜oes onde pessoas est˜ao aguardando a ocorrˆencia de alguma a¸c˜ao, como por exemplo, aguardando a inicia¸c˜ao do projeto, aguardando a cria¸c˜ao e revis˜ao de documentos, aguardando decis˜oes pendentes, aguardando pela configura¸c˜ao de ambientes etc. Na perspectiva do cliente, estes atrasos no ciclo de desenvolvimento prejudicam o tempo de resposta para as suas necessidades, que podem inclusive se alterar rapidamente, impedindo que stakeholders obtenham o valor do produto no tempo esperado (POPPENDIECK; POPPENDIECK, 2003).

3.2.2.5 Trabalho Parcialmente Completo

O trabalho parcialmente completo ´e um trabalho que foi iniciado, mas n˜ao foi finalizado. Este tipo de desperd´ıcio diz respeito a items como, requisitos n˜ao aprovados, requeri- mentos n˜ao implementados, c´odigo n˜ao testado, defeitos identificados e n˜ao corrigidos e funcionalidades n˜ao entregues. Existe o risco que o trabalho realizado parcialmente se torne obsoleto no ciclo de desenvolvimento. Assim como o desperd´ıcio relacionado a es- toque na manufatura (se¸c˜ao 3.1.1.3), trabalho realizado parcialmente no desenvolvimento de software pode ser visto como capital j´a aplicado, mas que n˜ao gera qualquer lucro para o produtor ou para o cliente (POPPENDIECK; POPPENDIECK, 2003).

3.2.2.6 Transferˆencia de Conhecimento (Handoff )

Abordagens tradicionais de desenvolvimento requerem a movimenta¸c˜ao de diversos ar- tefatos, incluindo documenta¸c˜ao de requisitos, de design ou de testes, de um grupo de profissionais para outro. Esta transferˆencia de conhecimento ou de tarefas, definidos como Handoffs, pode gerar desperd´ıcios na medida que tais documentos s˜ao por vezes incapazes de refletir o que os especialistas que os criaram (programadores, arquitetos ou testadores) aprenderam ou descobriram durante o seu trabalho. Isto pode resultar em perda de uma grande quantidade de conhecimento t´acito, que permanece com o criador e n˜ao ´e trans- mitido para os passos seguintes do processo. Hibbs, Jewett e Sullivan (2009) descrevem que a perda de conhecimento ´e agravada a cada handoff realizado.

3.2.2.7 Extra Processamento

Este desperd´ıcio diz respeito a etapas do processo que poderiam ser eliminadas para que o fluxo de produ¸c˜ao seja otimizado. Como exemplo, a burocracia ou documenta¸c˜ao des- necess´aria consome recursos, reduz os tempos de resposta, omite problemas de qualidade e se torna obsoleta. Em alguns cen´arios de desenvolvimento de software, onde requisitos mudam frequentemente, existe a necessidade de se alinhar o produto com as expectativas do cliente regularmente.(POPPENDIECK; POPPENDIECK, 2003)

O termo extra processamento foi convertido posteriormente para reaprendizado em (POP- PENDIECK; POPPENDIECK, 2006). Todavia, o sentido permanece semelhante, uma vez que o reaprendizado pode ser visto com um processo ou atividade desnecess´aria, que poderia ser evitada para eliminar desperd´ıcios no processo.

3.2.2.8 Desbalanceamento (Mura ) e Sobrecarga (Muri )

N˜ao foram identificadas na literatura adapta¸c˜oes diretas de Muri e Mura ao desenvol- vimento de software. Todavia, problemas de fluxo n˜ao s˜ao exclusivos da manufatura (GEORGAKOPOULOS; HORNICK; SHETH, 1995). Problemas como sobrecarga e varia¸c˜oes podem ocorrer em diversos tipos de processo. Portanto, presume-se que tais desperd´ıcios podem se apresentar tamb´em em processos de desenvolvimento de software.

3.3

Scrum

Inicialmente formalizado como um processo de desenvolvimento de software (SCHWABER, 1997) e posteriormente definido como um framework para desenvolvimento e sustenta¸c˜ao de produtos complexos (SCHWABER; SUTHERLAND, 2013), o Scrum ´e um conjunto de pr´aticas e regras que aplica uma abordagem iterativa e incremental para execu¸c˜ao de projetos ou constru¸c˜ao de produtos. De acordo com Schwaber (2004), o Scrum implementa os requisitos de transparˆencia, inspe¸c˜ao e adapta¸c˜ao inerentes ao controle de processos emp´ıricos.

No ˆambito do desenvolvimento de softwares, o Scrum ´e considerado como um m´etodo ´agil com foco no gerenciamento de projetos (SCHWABER, 2004), sendo um dos percussores e influenciadores do manifesto ´agil (FOWLER; HIGHSMITH, 2001). O movimento ´agil articula uma s´erie de valores e princ´ıpios a respeito de como desenvolver softwares com qualidade e de forma eficiente, com alta responsividade `a mudan¸cas de neg´ocio. Estudos como

(VERSION ONE, 2011), (SCHWABER; LEGANZA; D’SILVA, 2007) apontam o Scrum como o processo de desenvolvimento ´agil mais popular no mercado.

3.3.1

Origem

O Scrum foi originalmente formalizado como um processo de desenvolvimento de softwa- res por Ken Schwaber and Jeff Shutterland nos anos 1990 (SCHWABER, 1997). De acordo com Larman e Basili (2003), o m´etodo foi inspirado na abordagem interativa e incre- mental utilizada na constru¸c˜ao de produtos complexos na ind´ustria japonesa em empre- sas como Honda, Canon e Fujitsu. Shutterland e Schwaber (SUTHERLAND; SCHWABER, 2007) definem Scrum como uma abordagem enxuta para o desenvolvimento de softwares influenciada pelas melhores pr´aticas da ind´ustria japonesa, particularmente por princ´ıpios Lean.

O termo Scrum ´e origin´ario do estudo publicado por Takeuchi e Nonaka em 1986 (TAKEU- CHI; NONAKA, 1986), que indica que times pequenos e multifuncionais tem historicamente produzido resultados superiores no desenvolvimento de produtos complexos. Os autores comparam tais times a forma¸c˜oes Scrum, do Rugby. No Rugby, cada time atua como uma unidade integrada onde cada membro contribui com um papel no time, buscando um objetivo em comum. Esta ´e a forma que times Scrum atuam no desenvolvimento de software (SCHWABER, 2004).