{"id":7003,"date":"2017-12-08T12:32:41","date_gmt":"2017-12-08T14:32:41","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=7003"},"modified":"2017-12-08T14:02:49","modified_gmt":"2017-12-08T16:02:49","slug":"estoques-no-desenvolvimento-de-software","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2017\/12\/estoques-no-desenvolvimento-de-software\/","title":{"rendered":"Estoques no desenvolvimento de software"},"content":{"rendered":"<p>Sempre ouvi e li que os grandes vil\u00f5es da produtividade de um sistema s\u00e3o os <em>delays<\/em> ocasionados pelo tempo de espera em filas. Tenho certeza que voc\u00ea tamb\u00e9m j\u00e1 ouviu ou leu algo sobre isso. Da mesma forma, os estoques representam uma das maiores causas de desperd\u00edcio, especialmente para a manufatura.<\/p>\n<p>Mas, pensando em desenvolvimento de software, ser\u00e1 que as filas e estoques de demandas (qualquer item de trabalho de uma equipe de software, como hist\u00f3rias de usu\u00e1rios, bugs, etc&#8230;) se comportam da mesma maneira e trazem as mesmas consequ\u00eancias em todos os est\u00e1gios do fluxo de desenvolvimento? Ser\u00e3o essas consequ\u00eancias sempre negativas?<\/p>\n<p>Para respondermos essas quest\u00f5es, consideremos uma equipe que trabalha com o <em>workflow<\/em> composto pelas seguintes etapas:<\/p>\n<ul>\n<li><strong>Backlog<\/strong>: Itens j\u00e1 escritos pelo PO (<em>Product Owner<\/em>) e que ainda precisam ser refinados com a equipe;<\/li>\n<li><strong>Ready to Dev<\/strong>: Itens que j\u00e1 foram refinados com a equipe e est\u00e3o aguardando o in\u00edcio do desenvolvimento;<\/li>\n<li><strong>In Development<\/strong>: Itens em desenvolvimento;<\/li>\n<li><strong>Ready to Test<\/strong>: Itens desenvolvidos e aguardando testes;<\/li>\n<li><strong>Testing<\/strong>: Itens sendo testados pelo time de QA (<em>Quality Assurance<\/em>);<\/li>\n<li><strong>Ready to Deploy<\/strong>: Itens j\u00e1 aprovados por QA e aguardando o deploy em produ\u00e7\u00e3o;<\/li>\n<li><strong>In Production<\/strong>: Itens em produ\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>Da lista acima, conseguimos identificar algumas etapas de filas, onde seria poss\u00edvel acumular estoques de demandas aguardando as pr\u00f3ximas etapas. S\u00e3o elas: <em>Backlog<\/em>, <em>Ready to Dev<\/em>, <em>Ready to Test<\/em> e <em>Ready to Deploy<\/em>.<\/p>\n<p>Como ser\u00e1 que os estoques se comportam em cada uma dessas etapas?<\/p>\n<h3>Estoque em <em>Backlog<\/em>?<\/h3>\n<p><em>Cen\u00e1rio: como j\u00e1 tinha uma ideia do que seria trabalhado pelos pr\u00f3ximos meses, o PO da equipe decidiu escrever uma grande quantidade de hist\u00f3rias de usu\u00e1rio.<\/em><\/p>\n<p>Para este cen\u00e1rio, h\u00e1 um risco consider\u00e1vel de desperd\u00edcio do esfor\u00e7o do PO e at\u00e9 das hist\u00f3rias de usu\u00e1rio escritas, uma vez que que podem ocorrer mudan\u00e7as na estrat\u00e9gia do produto. Por exemplo, um concorrente lan\u00e7ou uma nova feature que n\u00e3o estava mapeada e decidiu-se implement\u00e1-la tamb\u00e9m. Novas hist\u00f3rias precisar\u00e3o ser escritas e outras possivelmente ser\u00e3o fechadas como obsoletas.<\/p>\n<h3>Estoque em <em>Ready to Dev<\/em>?<\/h3>\n<p><em>Cen\u00e1rio: o PO da equipe sair\u00e1 de f\u00e9rias nos pr\u00f3ximos dias e n\u00e3o haver\u00e1 um substituto. Nos \u00faltimos dias de trabalho antes do descanso, o PO e a equipe se esfor\u00e7aram para refinar uma grande quantidade de hist\u00f3rias de usu\u00e1rio para que a equipe trabalhasse durante o per\u00edodo.<\/em><\/p>\n<p>Neste caso, h\u00e1 um risco maior de que os acordos entre PO e equipe, discutidos durante os refinamentos, sejam esquecidos com o passar do tempo (\u00e9 sempre melhor que esses acordos estejam frescos na cabe\u00e7a da equipe).<\/p>\n<p>Por\u00e9m, trata-se de uma op\u00e7\u00e3o bastante interessante para que a equipe n\u00e3o sofra de <em>starvation<\/em> durante a aus\u00eancia do PO. Al\u00e9m de ser uma op\u00e7\u00e3o melhor do que deixar as hist\u00f3rias de usu\u00e1rios na etapa anterior (<em>Backlog<\/em>), o que poderia elevar o risco de desalinhamento entre o que era planejeado e o que ser\u00e1 desenvolvido.<\/p>\n<p>No geral, \u00e9 importante ter bem claro quem pode tomar as decis\u00f5es do produto em caso de aus\u00eancia do PO, pois, mesmo com a ado\u00e7\u00e3o dessa estrat\u00e9gia de estoque, d\u00favidas e incertezas certamente surgir\u00e3o na sequ\u00eancia do processo. Em muitos casos, essa responsabilidade acaba ficando com algu\u00e9m da equipe de design, um facilitador do processo ou mesmo com a pr\u00f3pria equipe de desenvolvimento, que pode tomar as decis\u00f5es em conjunto.<\/p>\n<h3>Estoque em <em>Ready to Test<\/em>?<\/h3>\n<p><em>Cen\u00e1rio: o respons\u00e1vel pelo QA da equipe ficar\u00e1 ausente por algumas semanas para realiza\u00e7\u00e3o de uma cirurgia. A equipe optou por continuar o desenvolvimento das hist\u00f3rias de usu\u00e1rio e deix\u00e1-las acumulando em &#8216;Ready to Test&#8217; at\u00e9 o retorno do QA.<\/em><\/p>\n<p>Para esta abordagem, como as funcionalidades n\u00e3o ser\u00e3o testadas at\u00e9 o retorno do respons\u00e1vel pelo QA, o ciclo de feedback ser\u00e1 mais longo. Isso trar\u00e1 desvantagens como:<\/p>\n<ol>\n<li><strong>Aumento no WIP (trabalho em progresso)<\/strong>: das filas que discutimos at\u00e9 aqui, esta \u00e9 a primeira em que h\u00e1 c\u00f3digo em progresso sendo estocado (nas anteriores, j\u00e1 havia esfor\u00e7o de an\u00e1lise e design). Com isso, a quantidade de WIP no sistema tende a aumentar, e o Wesley Zapellini j\u00e1 nos explicou em seu e-book <a href=\"http:\/\/pages.plataformatec.com.br\/5-estrategias-para-otimizar-fluxo-de-desenvolvimento-de-software\">&#8220;5 Estrat\u00e9gias para otimizar o fluxo de desenvolvimento de software&#8221;<\/a> os principais efeitos colaterais de ter o WIP alto.<\/li>\n<li><strong>Redu\u00e7\u00e3o da visibilidade do processo<\/strong>: com mais tarefas no board da equipe, tende a ficar mais complicado ter visibilidade do que est\u00e1 realmente em andamento.<\/li>\n<li><strong>Redu\u00e7\u00e3o da previsibilidade do processo<\/strong>: com a pausa do processo de testes, todas as tarefas que estiverem ou chegarem na fila de <em>Ready to Test<\/em> durante o per\u00edodo de aus\u00eancia do respons\u00e1vel de QA ficar\u00e3o por l\u00e1 at\u00e9 o retorno dele, \u00e9 claro. O <em>lead time<\/em> do processo (tempo entre o in\u00edcio do trabalho da equipe na demanda e o t\u00e9rmino dela) ser\u00e1, portanto, impactado.<\/li>\n<li><strong>Aumento no n\u00famero de bugs e n\u00e3o conformidades<\/strong>: como j\u00e1 mencionado no e-book <a href=\"http:\/\/pages.plataformatec.com.br\/5-estrategias-para-otimizar-fluxo-de-desenvolvimento-de-software\">&#8220;5 Estrat\u00e9gias para otimizar o fluxo de desenvolvimento de software&#8221;<\/a>, o aumento do WIP tende a impactar diretamente na qualidade do software. Neste cen\u00e1rio, h\u00e1 ainda um ponto adicional: a falta de feedback quanto \u00e0 conformidade das hist\u00f3rias desenvolvidas faz com que hist\u00f3rias sejam iniciadas com uma base j\u00e1 fora de conformidade, o que tende a sobrepor os problemas.<\/li>\n<\/ol>\n<p>As imagens a seguir apresentam a distribui\u00e7\u00e3o do <em>lead time<\/em> das demandas da equipe imediatamente antes e ap\u00f3s as f\u00e9rias do profissional de QA (para entender melhor os gr\u00e1ficos, recomendo o blogpost do Raphael Albino <a href=\"http:\/\/blog.plataformatec.com.br\/2017\/08\/metricas-ageis-o-que-lead-time-fala-sobre-seu-projeto\/\">&#8220;M\u00e9tricas \u00c1geis: o que Lead Time fala sobre seu projeto&#8221;<\/a>). Na primeira delas, antes do in\u00edcio das f\u00e9rias do profissional, \u00e9 poss\u00edvel ver que h\u00e1 pouca variabilidade no <em>lead time<\/em> das entregas e pouco WIP.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-7004\" src=\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-before.png\" alt=\"Antes das f\u00e9rias\" width=\"1919\" height=\"907\" srcset=\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-before.png 1919w, http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-before-300x142.png 300w, http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-before-768x363.png 768w, http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-before-1024x484.png 1024w\" sizes=\"(max-width: 1919px) 100vw, 1919px\" \/><\/p>\n<p>J\u00e1 ap\u00f3s as f\u00e9rias, \u00e9 poss\u00edvel perceber uma tend\u00eancia de aumento no <em>lead time<\/em> (m\u00e9dia projetada j\u00e1 bastante acima do percentil 95%), o que deve contribuir para uma redu\u00e7\u00e3o na previsibilidade das entregas. Al\u00e9m disso, \u00e9 poss\u00edvel ver que a quantidade de trabalho em progresso tamb\u00e9m teve um aumento consider\u00e1vel:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-7006\" src=\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-after.png\" alt=\"Ap\u00f3s as f\u00e9rias\" width=\"1919\" height=\"907\" srcset=\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-after.png 1919w, http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-after-300x142.png 300w, http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-after-768x363.png 768w, http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2017\/12\/ready-to-qa-after-1024x484.png 1024w\" sizes=\"(max-width: 1919px) 100vw, 1919px\" \/><\/p>\n<p>J\u00e1 vimos os poss\u00edveis impactos dessa estrat\u00e9gia, mas o que podemos fazer em uma situa\u00e7\u00e3o como esta? Supondo que n\u00e3o haja outro profissional de QA dispon\u00edvel para a equipe, algu\u00e9m do time pode assumir essa atividade ou, o que temos feito com sucesso em alguns contextos, a equipe como um todo pode se dividir para realizar os testes: sempre que algu\u00e9m mover uma demanda para QA, antes de iniciar uma nova, pode verificar se h\u00e1 alguma pendente de testes e j\u00e1 pux\u00e1-la. A \u00fanica sugest\u00e3o \u00e9 para que uma demanda n\u00e3o seja testada pela mesma pessoa que a desenvolveu.<\/p>\n<h3>Estoque em <em>Ready to Deploy<\/em>?<\/h3>\n<p><em>Cen\u00e1rio: por op\u00e7\u00e3o do PO, decidiu-se que todas as hist\u00f3rias mapeadas inicialmente precisariam estar prontas para que as novas features fossem para produ\u00e7\u00e3o.<\/em><\/p>\n<p>Neste caso, o maior impacto do ponto de vista do processo \u00e9 que ser\u00e1 preciso garantir que essas hist\u00f3rias praticamente prontas n\u00e3o criem um empecilho para que outras linhas de desenvolvimento integrem c\u00f3digo em produ\u00e7\u00e3o. De maneira geral, a sugest\u00e3o \u00e9 integrar c\u00f3digo pronto em produ\u00e7\u00e3o sempre que poss\u00edvel (h\u00e1 t\u00e9cnicas para se fazer isso sem necessariamente liberar as funcionalidades para os usu\u00e1rios, como a t\u00e9cnica de <em>Feature Toggle<\/em>). Al\u00e9m de desbloquear futuros deploys que precisem &#8220;passar na frente&#8221; (como <em>bug fixes<\/em>, por exemplo), essa estrat\u00e9gia ainda permitir\u00e1 que os deploys sejam mais tranquilos e sem grandes riscos.<\/p>\n<p>Do ponto de vista de produto, e considerando o Cost of Delay conforme nos apresentou o Lucas Colucci em seu blog post <a href=\"http:\/\/blog.plataformatec.com.br\/2017\/06\/quanto-a-empresa-perde-financeiramente-quando-o-projeto-atrasa\/\">&#8220;Quanto a empresa perde financeiramente quando o projeto atrasa?&#8221;<\/a> sobre o assunto, \u00e9 sempre interessante disponibilizar as novas features para o cliente, mesmo que todas as features planejadas no escopo de um projeto n\u00e3o tenham sido finalizadas.<\/p>\n<p>Um outro cen\u00e1rio muito comum, especialmente em equipes maiores, \u00e9 o da exist\u00eancia de janelas e filas para deploy. Geralmente, essa estrat\u00e9gia \u00e9 adotada quando:<br \/>\n1. o ferramental de deploy\/rollback exige tempo e trabalho manual (frequentemente, com recursos compartilhados por v\u00e1rias equipes),<br \/>\n2. quando h\u00e1 falta de confian\u00e7a quanto \u00e0 qualidade do que est\u00e1 sendo colocado no ar (algu\u00e9m se perguntaria: <em>ser\u00e1 que o c\u00f3digo est\u00e1 adicionando bugs?<\/em>)<br \/>\n3. ou quando h\u00e1 muitas equipes trabalhando em um mesmo produto.<\/p>\n<p>Essa burocracia para o deploy (hor\u00e1rios pr\u00e9-definidos, dias da semana permitidos, comit\u00eas para decidir o que vai e o que n\u00e3o vai pro ar&#8230;) contribuir\u00e1 para atrasar a entrada das novas funcionalidades em produ\u00e7\u00e3o. Para reverter esse cen\u00e1rio, o ideal \u00e9 investir em cobertura de testes e em automa\u00e7\u00f5es em geral (tanto da execu\u00e7\u00e3o dos testes, quanto de deploy\/rollback), o que far\u00e1 com que o processo de colocar c\u00f3digo novo no ar se torne mais simples e <em>indolor<\/em>, tanto para quem faz o deploy quanto para quem usa o produto.<\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>Em geral, as filas e estoques no desenvolvimento de software, especialmente em contextos \u00e1geis, trazem como consequ\u00eancia aumento no risco de desperd\u00edcio de esfor\u00e7o e de oportunidades de neg\u00f3cio representadas pelas demandas em estoque, principalmente as que j\u00e1 est\u00e3o mais pr\u00f3ximas de serem finalizadas e que poderiam gerar receitas para a empresa ou melhorias para os usu\u00e1rios.<\/p>\n<p>Por\u00e9m, como vimos acima, h\u00e1 tamb\u00e9m outras consequ\u00eancias que variam conforme o est\u00e1gio do fluxo de desenvolvimento em que a demanda est\u00e1, podendo impactar na qualidade do c\u00f3digo e aumentar o n\u00famero de bugs, ou at\u00e9 evitar uma poss\u00edvel situa\u00e7\u00e3o de <em>starvation<\/em> da equipe.<\/p>\n<p>E voc\u00ea? Quais situa\u00e7\u00f5es j\u00e1 enfrentou com estoques e filas em suas equipes? Deixe seus relatos e coment\u00e1rios abaixo!<\/p>\n<div style=\"border: 1px solid #009eaa; border-radius: 6px; margin: 32px 0; padding: 22px 24px; font-family: sans-serif;\">\nE-book gratuito:<br \/>\n<span style=\"font-size: 1.4em; line-height: 1.3em;\">5 Estrat\u00e9gias para otimizar o fluxo de desenvolvimento de software<\/span><br \/>\n<a style=\"background: #009eaa; border: none; border-radius: 3px; color: #fff; display: inline-block; font-size: 12px; line-height: 1.5; margin-top: 18px; padding: 8px 16px; text-align: center; text-decoration: none; font-weight: bold; letter-spacing: 0.05em;\" href=\"http:\/\/pages.plataformatec.com.br\/5-estrategias-para-otimizar-fluxo-de-desenvolvimento-de-software?utm_source=our-blog&amp;utm_medium=referral&amp;utm_campaign=ebook-5-estratgias-para-fluxo&amp;utm_content=cta-blog-post-bottom\" target=\"_blank\" rel=\"noopener\">BAIXAR E-BOOK<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Sempre ouvi e li que os grandes vil\u00f5es da produtividade de um sistema s\u00e3o os delays ocasionados pelo tempo de espera em filas. Tenho certeza que voc\u00ea tamb\u00e9m j\u00e1 ouviu ou leu algo sobre isso. Da mesma forma, os estoques representam uma das maiores causas de desperd\u00edcio, especialmente para a manufatura. Mas, pensando em desenvolvimento &#8230; <a class=\"read-more-link\" href=\"http:\/\/blog.plataformatec.com.br\/2017\/12\/estoques-no-desenvolvimento-de-software\/\">\u00bb<\/a><\/p>\n","protected":false},"author":62,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[123,254,257,261,264,258],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7003"}],"collection":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/62"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=7003"}],"version-history":[{"count":9,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7003\/revisions"}],"predecessor-version":[{"id":7016,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/7003\/revisions\/7016"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=7003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=7003"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=7003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}