Apesar destes sintomas poderem estar relacionados a outras causas, a divis\u00e3o do squad pode ajudar a resolver ou at\u00e9 solucionar estes problemas. Lembrando tamb\u00e9m que o seu time pode sim ser dividido mesmo tendo uma quantidade pequena de pessoas e talvez n\u00e3o precise ser divido mesmo tendo uma quantidade grande de pessoas. Pense nisso!<\/p>\n
Ainda sobre as dores, um parentese sobre a visibilidade das m\u00e9tricas<\/h3>\n
Se o seu time utiliza de m\u00e9tricas para melhoria de processos, remo\u00e7\u00e3o de gargalos e previsibilidade, a visibilididade das m\u00e9tricas pode estar comprometida devido a grande diversidade de caracter\u00edsticas dentro do seu time. Pode ser que haja diferen\u00e7a em parte do time quanto aos processos, a velocidade, natureza das demandas, tipo de produto ou usu\u00e1rio, e outros, que quando as m\u00e9tricas est\u00e3o juntas, as melhorias que o processo precisa podem n\u00e3o estar vis\u00edveis para serem implementadas. Vou utilizar aqui uma experi\u00eancia que tive em um projeto:<\/p>\n
Neste projeto, havia uma plataforma de mobile e outra web para o mesmo tipo de usu\u00e1rio e uma Squad \u00fanica atendia ambas plataformas. Durante o dia a dia de trabalho sent\u00edamos algumas dores, por\u00e9m elas n\u00e3o estavam sendo refletidas nas m\u00e9tricas. Ap\u00f3s algumas discuss\u00f5es sobre os problemas que v\u00ednhamos enfrentando no time, entre eles: reuni\u00f5es longas; atrasos em uma das frentes; discuss\u00f5es onde todos estavam presentes, por\u00e9m poucos participavam. Percebemos que o time precisava ser quebrado e depois dessa decis\u00e3o as m\u00e9tricas come\u00e7aram a fazer sentido.<\/p>\n
Com a quebra, percebemos que a frente de mobile e a frente de plataforma web possu\u00edam caracter\u00edsticas diferentes de desenvolvimento, apesar de seguirem as mesmas etapas no processo. Isso ficou claro quando fomos consultar o grafico de CFD\u00a0<\/a>ap\u00f3s a divis\u00e3o e verificamos que havia um grande tempo em espera dos cards que estavam na etapa “pronto para produ\u00e7\u00e3o”. Tal caracter\u00edstica se dava pelo fato da hist\u00f3ria ter que esperar ser homologada antes de ser enviada para a loja ou aguardar um conjunto de funcionaldades chaves ser implementada para, ent\u00e3o, fazermos a release da vers\u00e3o, fato que n\u00e3o ocorria na outra frente. Outro ponto que conseguimos acompanhar com o CFD separado foi o fato de uma frente estar com poucas demandas no backlog e correndo o risco de n\u00e3o ter demandas para trabalhar nos pr\u00f3ximos dias. Tudo isso ficava dilu\u00eddo na visualiza\u00e7\u00e3o das m\u00e9tricas quando os dados de ambos os times estavam juntos.<\/p>\n Outro ponto foi em rela\u00e7\u00e3o ao throughput<\/a>\u00a0do time, que enquanto uma frente tinha um throughput semanal mais alto, o outro tinha um throughput muito mais baixo devido a uma s\u00e9rie de fatores, como quantidade de desenvolvedores na plataforma, estrutra do software para novas funcionaldades, complexidade das demandas, entre outros. Isso impactava na previsibilidade do produto quanto consult\u00e1vamos o burnup<\/a>, por exemplo, pois em uma frente est\u00e1vamos sendo muito pessimista e na outra muito otimista com a jun\u00e7\u00e3o dos dados de ambas as frentes.<\/p>\n Decidido que a divis\u00e3o \u00e9 o caminho, tenha em mente que seu problema n\u00e3o vai se resolver de forma r\u00e1pida e em uma \u00fanica altera\u00e7\u00e3o no time. Vai ser preciso realizar alguns ajustes durante o processo de mundan\u00e7a e o envolvimento do time \u00e9 crucial. Tente fazer pequenas melhorias progressivamente em dire\u00e7\u00e3o ao que querem alcan\u00e7ar e evitem grandes altera\u00e7\u00f5es, utilizando o conceito da curva J ou The J Curve of Change<\/em><\/a>.<\/p>\n Uma das formas de conseguir dar mais agilidade para sua equipe \u00e9 manter a multiciplinaridade dos membros desta equipe. Se voc\u00ea pensou em dividir o squad por tipo de software, como backend, frontend e mobile, talvez esse n\u00e3o seja o melhor caminho se h\u00e1 depend\u00eancias destas partes para gerar valor para o usu\u00e1rio.<\/p>\n Ao dividir o time por tipo de disciplina, voc\u00ea correr\u00e1 o risco de uma parte do produto ou servi\u00e7o que o time est\u00e1 desenvolvendo fique pronta e a outra parte complementar desta demore muito tempo ainda para ser finalizada. Isto \u00e9 comum de se perceber em times de desenvolvimento de software quando, por exemplo, a tela de uma funcionalidade foi desenvolvida, por\u00e9m a parte de backend anida n\u00e3o e, sem ambas o partes, o valor da funcionalidade n\u00e3o \u00e9 entregue na m\u00e3o do usu\u00e1rio. Com isso, atrasamos o feedback sobre a funcionalidade, aumentando o risco de integra\u00e7\u00f5es entre as partes entre outros problemas. Se voc\u00ea quer entender melhor sobre as consequ\u00eancias que este atraso pode trazer, recomendo este blogpost sobre Cost of Delay<\/a>\u00a0e um e-book localizado neste blogpost<\/a>\u00a0de um dos nossos consultores \u00e1gil.<\/p>\n Em resumo, somente a partir desta quebra \u00e9 que de fato conseguimos vizualizar os problemas sentidos pela equipe. Dessa forma podemos evindenciar estes problemas, propor solu\u00e7\u00f5es para eles e verificar o resultados destas solu\u00e7\u00f5es com m\u00e9tricas.<\/p>\n \u00c9 l\u00f3gico que cada caso \u00e9 um caso, mas uma forma que eu vejo que tem dado certo \u00e9 a divis\u00e3o dos squads por tipos de servi\u00e7os e\/ou usu\u00e1rios. Isso significa que em um time que cont\u00e9m membros com especializa\u00e7\u00f5es em disciplinas diferentes (como backend, frontend e mobile, por exemplo), dever\u00edamos dividir de uma forma que o time consiga desenvolver funcionalidades completas e evitar a divis\u00e3o por disciplina.<\/p>\n O seu time pode, por exemplo, ser divido por tipos de usu\u00e1rios onde cada time conteria as habilidades necess\u00e1rias para entregar valor de forma completa para o usu\u00e1rio ap\u00f3s a divis\u00e3o.<\/p>\n Das vantagens desta divis\u00e3o, temos algumas que se destacam, como a rapidez da entrega de funcionalidades, a melhoria na comunica\u00e7\u00e3o dentro do squad, reuni\u00f5es mais produtivas e em menor tempo de dura\u00e7\u00e3o, melhor visibilidade do backlog para cada squad\/frente, redu\u00e7\u00e3o do Lead Time<\/a>\u00a0e do Time to Market<\/em>.<\/p>\n A equipe onde essa divis\u00e3o foi aplicada tamb\u00e9m se sentiu motivada, pois antes havia a sensa\u00e7\u00e3o de “entregamos algo, mas e da\u00ed?” que vinha do fato de ter dois tipos de objetivos diferentes mascarados em um \u00fanico objetivo dentro do mesmo time e quando uma parte atingia o “objetivo” o restante do time se sentia “atrasado”, o que causava uma insatisfa\u00e7\u00e3o de todo o time e sendo um t\u00f3pico de discuss\u00e3o nas retrospectivas. Com a separa\u00e7\u00e3o, cada time se sentiu mais realizado sabendo que cada time tinha seu pr\u00f3prio tempo para atingir seus objetivos.<\/p>\n H\u00e1 tamb\u00e9m algumas desvantagens, como um maior esfor\u00e7o para sincronizar o trabalho entre os squads e gerenciar o backlog, a estrutura do software pode n\u00e3o sustentar este tipo de divis\u00e3o e tornar o processo lento e burocr\u00e1tico e recursos compartilhados, como QA, precisam de uma maior orienta\u00e7\u00e3o sobre as prioridades dos squads.<\/p>\n Em resumo, acredito que dependendo do momento da sua equipe e do seu produto, vale a pena sim realizar esta divis\u00e3o.<\/p>\n E voc\u00ea? J\u00e1 teve dificuldades em dividir o seu time? J\u00e1 realizou alguma divis\u00e3o de squad? Deixe seus coment\u00e1rios abaixo sobre sua experi\u00eancia com divis\u00e3o de times!<\/p>\n Muitas equipes t\u00eam vivenciado algumas dores comuns que d\u00e3o sinais de que o time\/squad est\u00e1 muito grande e precisa ser dividido. Como tamb\u00e9m j\u00e1 passei por este problema antes, resolvi escrever este blogpost sobre divis\u00e3o de squads para compartilhar a minha experi\u00eancia. Com base nas experi\u00eancias que tive, vou mostrar abaixo algumas dicas do por … \u00bb<\/a><\/p>\n","protected":false},"author":73,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[3],"tags":[123],"aioseo_notices":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8045"}],"collection":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/users\/73"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=8045"}],"version-history":[{"count":14,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8045\/revisions"}],"predecessor-version":[{"id":8071,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8045\/revisions\/8071"}],"wp:attachment":[{"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=8045"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=8045"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=8045"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Se preparando para a mudan\u00e7a<\/h2>\n
Uma forma de dividir: divis\u00e3o por frentes.<\/h2>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/11\/imagem3-300x189.png\")
<\/p>\nUma sugest\u00e3o de divis\u00e3o<\/h3>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/11\/imagem1-300x181.png\")
<\/p>\nOs trade-offs dessa divis\u00e3o<\/h3>\n
![\"\"](\"http:\/\/blog.plataformatec.com.br\/wp-content\/uploads\/2018\/11\/Call-to-Action-Ebook-\u00c1gil-4-300x97.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"