{"id":8891,"date":"2019-04-01T16:05:08","date_gmt":"2019-04-01T19:05:08","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=8891"},"modified":"2019-04-03T13:30:02","modified_gmt":"2019-04-03T16:30:02","slug":"como-estruturar-os-processos-e-as-praticas-de-times-ageis","status":"publish","type":"post","link":"http:\/\/blog.plataformatec.com.br\/2019\/04\/como-estruturar-os-processos-e-as-praticas-de-times-ageis\/","title":{"rendered":"Como Estruturar os Processos e as Pr\u00e1ticas de Times \u00c1geis?"},"content":{"rendered":"
Nesses anos em que tenho trabalhado com m\u00e9todos e pr\u00e1ticas \u00e1geis, tenho observado diversas composi\u00e7\u00f5es e formatos de times (comumente chamados de squads, talvez por influ\u00eancia do modelo Spotify). De forma geral, muitos aspectos e caracter\u00edsticas dessas equipes se repetem, tais como:<\/p>\n
Enfim, esses s\u00e3o apenas alguns exemplos comuns. E, fazendo uma an\u00e1lise bem enxuta, isso tudo parece muito bom! H\u00e1 muitos conceitos \u00e1geis por tr\u00e1s dessas caracter\u00edsticas, como, por exemplo, a auto-organiza\u00e7\u00e3o de times, a melhoria cont\u00ednua, o alinhamento estrat\u00e9gico, entre outros.<\/p>\n
Pensando nisso, resolvi compartilhar com voc\u00eas um exemplo gen\u00e9rico, e relativamente simples, para estruturar processos e pr\u00e1ticas em times \u00e1geis. Um time considerado \u00e1gil provavelmente ter\u00e1 uma estrutura semelhante a essa:<\/p>\n
\nA composi\u00e7\u00e3o de um time \u00e1gil deve, na minha opini\u00e3o, contemplar as seguintes esferas:<\/p>\n
Mas n\u00e3o se apegue aos exemplos espec\u00edficos do desenho, mas sim ao conceito atrelado a eles. Vou explicar rapidamente, com um pouco mais detalhes, cada peda\u00e7o deste exemplo. Vamos l\u00e1!<\/p>\n
Tanto os OKRs (Objetivos e Resultados-Chave, do ingl\u00eas Objectives and Key Results) quanto o User Story Mapping (Mapeamento de Hist\u00f3rias de Usu\u00e1rio) s\u00e3o muito utilizados por times \u00e1geis. Mas, a ideia aqui n\u00e3o \u00e9 necessariamente utilizar ambos, mas sim compreender que, de alguma maneira, sua empresa tem que possuir a capacidade de criar objetivos para o neg\u00f3cio e decompor eles em partes menores (entreg\u00e1veis)<\/strong>.<\/p>\n Ou seja, baseado no Planejamento Estrat\u00e9gico da organiza\u00e7\u00e3o, por exemplo, criar um processo de decomposi\u00e7\u00e3o at\u00e9 que o time desenvolvedor do projeto consiga atrelar o que est\u00e3o entregando com o que a empresa espera de resultados de neg\u00f3cios. Em outras palavras, o time estar\u00e1 trabalhando na esfera da efic\u00e1cia (fazendo as coisas certas). Dessa maneira, haver\u00e1 alinhamento e a empresa conseguir\u00e1 conceder autonomia para os times, sem o risco de as entregas n\u00e3o responderem \u00e0s necessidades do neg\u00f3cio. Para entender melhor o conceito de alinhamento e autonomia, sugiro a leitura do blogpost O desafio de analisar a maturidade \u00e1gil de uma empresa<\/a>, escrito por Raphael Albino.<\/p>\n Para conhecer mais sobre OKRs<\/strong>, framework criado pelo ex-CEO da Intel, Andrew Grove, sugiro a leitura do blogpost Dilemas de PO: como definir OKRs em equipes \u00e1geis<\/a>, escrito novamente por Raphael Albino. E, se voc\u00ea deseja entender mais sobre Mapeamento de Hist\u00f3rias de Usu\u00e1rio<\/strong>, t\u00e9cnica criada por Jeff Patton, recomendo a leitura do blogpost Vamos falar sobre Story Mapping<\/a>, escrito por Felipe Gimenes.<\/p>\n \u00c9 extremamente prov\u00e1vel que voc\u00ea j\u00e1 conhe\u00e7a o m\u00e9todo Kanban<\/strong> e o framework Scrum<\/strong>. Caso contr\u00e1rio, sugiro a leitura do e-book gratuito Kanban em 10 Passos<\/a>, escrito por Jesper Boeg, como tamb\u00e9m do Guia do Scrum<\/a>, mantido por seus criadores Ken Schwaber e Jeff Sutherland.<\/p>\n Voc\u00ea pode, sem d\u00favidas nenhuma, utilizar as pr\u00e1ticas mencionadas acima de forma integral. Por\u00e9m, assim como no t\u00f3pico anterior, a ideia n\u00e3o \u00e9 dizer que, necessariamente, voc\u00ea precisa utilizar ambas as pr\u00e1ticas, total ou parcialmente, para formar um time \u00e1gil. O objetivo aqui \u00e9: estruture uma forma de gerenciar seu fluxo de desenvolvimento e tenha um mecanismo de melhoria cont\u00ednua<\/strong>. Para isso, eu costumo utilizar o m\u00e9todo Kanban, movendo as hist\u00f3rias de usu\u00e1rio de etapa em etapa, bem como as reuni\u00f5es di\u00e1rias para alinhamento cont\u00ednuo\/constante e retrospectivas para melhoria cont\u00ednua. E, se necess\u00e1rio, algum processo de valida\u00e7\u00e3o interna de entregas (comum quando temos muitas integra\u00e7\u00f5es no sistema ou homologa\u00e7\u00f5es de parceiros externos, por exemplo).<\/p>\n Mas, independentemente do m\u00e9todo, framework, modelo ou metodologia utilizada, \u00e9 sempre oportuno lembrar que voc\u00ea precisa procurar qual \u00e9 o melhor conjunto de pr\u00e1ticas que se adequa ao contexto do time<\/strong>. Como opini\u00e3o, o m\u00e9todo Kanban e o framework Scrum, bem como uma forma h\u00edbrida de ambos, sempre s\u00e3o boas op\u00e7\u00f5es para considerar nessa an\u00e1lise e respectiva escolha.<\/p>\n Gosto muito dessa famosa frase de William Deming (1900-1993): “N\u00e3o se gerencia o que n\u00e3o se mede”. E, principalmente se voc\u00ea estiver escolhido o m\u00e9todo Kanban para gerenciar seu fluxo de trabalho, \u00e9 extremamente recomend\u00e1vel que voc\u00ea limite seu trabalho em progresso, o famoso WIP (Work in Progress). Este, ali\u00e1s, \u00e9 um dos princ\u00edpios do Kanban. Para entender mais sobre o aperfei\u00e7oamento do seu fluxo de desenvolvimento, recomendo a leitura do blogpost 5 Estrat\u00e9gias para otimizar o fluxo de desenvolvimento de software<\/a>, escrito por Wesley Zapellini.<\/p>\n Ao limitar o WIP, voc\u00ea conseguir\u00e1 trabalhar com outras m\u00e9tricas. Neste caso, consigo destacar o Lead time e o Throughput. Entender a rela\u00e7\u00e3o da m\u00e9dia dessas tr\u00eas vari\u00e1veis \u00e9 muito importante, pois, ao limitar o trabalho em progresso (WIP), voc\u00ea potencialmente conseguir\u00e1 entregar mais r\u00e1pido (em outras palavras, diminuir\u00e1 seu Lead time). A compreens\u00e3o da rela\u00e7\u00e3o dessas vari\u00e1veis surgiu em um estudo do in\u00edcio da d\u00e9cada de 60, quando o professor John Little e Stephen Graves publicaram um artigo pelo Massachusetts Institute of Technology (MIT) chamado Little’s Law<\/a>, ou Lei de Little. N\u00f3s, da Plataformatec, falamos um pouco disso na parte 1<\/a> do epis\u00f3dio “A rela\u00e7\u00e3o entre Lead time, WIP e Throughput”, do Cont\u00c1gil Podcast<\/a>.<\/p>\n Entretanto, seguindo o mesmo racioc\u00ednio dos casos anteriores, trabalhar com WIP, Lead time e Throughput \u00e9 apenas uma – \u00f3tima – op\u00e7\u00e3o. O recado aqui \u00e9: tenha um sistema de medi\u00e7\u00e3o que consiga produzir e coletar dados confi\u00e1veis, com o objetivo de compreender e melhorar continuamente seu formato de trabalho<\/strong>, e, por consequ\u00eancia, melhorar seus resultados de forma cont\u00ednua.<\/p>\n Para finalizar, recomendo a leitura do blogpost 12 Erros comuns no uso de M\u00e9tricas de Processo<\/a>, escrito por Lucas Colucci. Neste texto h\u00e1 dicas que ir\u00e3o lhe ajudar a evitar erros que podem prejudicar a an\u00e1lise de seus dados.<\/p>\n Entregar valor. Essa talvez seja a parte mais dif\u00edcil de rodar<\/em> na pr\u00e1tica. Como garantir, por exemplo, que as entregas dos times est\u00e3o efetivamente entregando valor para seus clientes? E o que \u00e9 exatamente valor?<\/p>\n Se voc\u00ea procurar pelo significado desta palavra, provavelmente encontrar\u00e1 v\u00e1rias defini\u00e7\u00f5es. Eu, particularmente, gostei muito de uma das defini\u00e7\u00f5es apresentadas pelo Dicio<\/a> (Dicion\u00e1rio Online de Portugu\u00eas): “Qualidade que faz com que algo se torne importante para algu\u00e9m.”<\/p>\n Portanto, antes de entregar \u00e9 preciso compreender o que \u00e9 o valor para esse algu\u00e9m (no caso, seu cliente). Tente responder essas perguntas:<\/p>\n Se voc\u00ea consegue responder essas perguntas, provavelmente entendeu o que \u00e9 valor para seu cliente. \u00c0 partir disso, tudo fica mais f\u00e1cil: garanta que as features (entregas) de seu time est\u00e3o alinhadas com as respostas dessas perguntas<\/strong>. E, se voc\u00ea montou corretamente a primeira parte do exemplo de estrutura de um time \u00e1gil, a de criar objetivos para o neg\u00f3cio e decompor eles em partes menores (entreg\u00e1veis), voc\u00ea provavelmente conseguir\u00e1 isso. Claro que h\u00e1 uma premissa aqui: seus objetivos de neg\u00f3cio est\u00e3o atrelados com o que o mercado (seu cliente) est\u00e1 demandando de produtos e\/ou servi\u00e7os.<\/p>\n Como dica complementar, recomendo a leitura do livro Sprint. O M\u00e9todo Usado no Google Para Testar e Aplicar Novas Ideias em Apenas Cinco Dias<\/a>, escrito por Jake Knapp, John Zeratsky e Braden Kowitz. Eu tive a oportunidade de participar de um processo de concep\u00e7\u00e3o de produto baseado neste modelo do livro e, sem d\u00favida nenhuma, foi uma \u00f3tima experi\u00eancia. Se voc\u00ea conseguir compreender seu cliente, \u00e9 muito prov\u00e1vel que ir\u00e1 entender o que \u00e9 valor para ele e, dessa forma, entregar features compat\u00edveis com esta situa\u00e7\u00e3o.<\/p>\n Por fim, a \u00faltima parte da composi\u00e7\u00e3o de um time \u00e1gil \u00e9, na minha opini\u00e3o, a capacidade de conseguir coletar feedbacks qualitativos e quantitativos do ambiente externo, neste caso, seus clientes<\/strong>. Voc\u00ea n\u00e3o precisa apenas de um mecanismo interno de melhoria continua do seu processo de desenvolvimento, mas tamb\u00e9m de um externo.<\/p>\n O feedback qualitativo pode ser obtido atrav\u00e9s de formul\u00e1rios, pesquisas de opini\u00e3o, entrevistas com seus clientes, enfim, de diversas maneiras. O importante n\u00e3o \u00e9 s\u00f3 obter, mas agir com base nestes feedbacks. Essa talvez seja a parte mais importante: se voc\u00ea ouvir o cliente e n\u00e3o fizer nada a respeito, voc\u00ea poder\u00e1 errar em dobro: eventualmente entregar\u00e1 features equivocadas e n\u00e3o agir\u00e1 perante os feedbacks colhidos.<\/p>\n Mas como medir se suas a\u00e7\u00f5es est\u00e3o efetivamente surtindo efeito ao longo do tempo? Uma forma de fazer isso \u00e9 transformar os feedbacks em dados tang\u00edveis (n\u00fameros). \u00c9 muito complicado observar feedbacks qualitativos de, por exemplo, 1 ano atr\u00e1s e verificar se os atuais est\u00e3o melhores do que os antigos. Al\u00e9m de complexo e trabalhoso, a interpreta\u00e7\u00e3o do avaliador tamb\u00e9m pode afetar o resultado, podendo se transformar em algo subjetivo. Logo, tenha tamb\u00e9m um mecanismo de medi\u00e7\u00e3o num\u00e9rica.<\/p>\n Uma forma interessante de obter feedbacks via dados \u00e9 utilizando o Net Promoter Score<\/a> (NPS), metodologia criada por Fred Heichheld. Nela, seu cliente responde, de 0 a 10, a possibilidade dele recomendar seu produto e\/ou servi\u00e7o para outra pessoa. Ao longo do tempo, voc\u00ea poder\u00e1, por exemplo, comparar os valores obtidos h\u00e1 1 ano com os valores que est\u00e3o sendo obtidos atualmente.<\/p>\n Se voc\u00ea trabalha com aplicativos, os valores de avalia\u00e7\u00e3o mostrados na pr\u00f3pria p\u00e1gina de download (geralmente de 1 a 5) tamb\u00e9m s\u00e3o interessantes de registrar (mensalmente, bimestralmente, enfim, em uma periodicidade que seja relevante para seu neg\u00f3cio). E, ao longo do tempo, voc\u00ea poder\u00e1 comparar se as avalia\u00e7\u00f5es est\u00e3o melhorando ou piorando. Com isso, \u00e9 prov\u00e1vel que voc\u00ea consiga verificar se suas entregas est\u00e3o efetivamente respondendo ao valor esperado por seus clientes.<\/p>\n Se voc\u00ea est\u00e1 gerenciando seu fluxo de desenvolvimento com a limita\u00e7\u00e3o do trabalho em progresso, voc\u00ea potencialmente entregar\u00e1 em um tempo menor e, por consequ\u00eancia, obter\u00e1 feedbacks dos clientes mais rapidamente que, por sua vez, realimentar\u00e3o seus objetivos. Se voc\u00ea conseguiu entrar neste ciclo, parab\u00e9ns, seu time provavelmente est\u00e1 sendo \u00e1gil!<\/strong><\/p>\n Resumindo todo o racioc\u00ednio deste blogpost, para conseguirmos estruturar um time \u00e1gil, precisaremos, na minha opini\u00e3o, das seguintes caracter\u00edsticas:<\/p>\n Feedbacks sobre o texto? Por favor, fique \u00e0 vontade para comentar. Vamos trocar experi\u00eancias!<\/p>\n","protected":false},"excerpt":{"rendered":" Nesses anos em que tenho trabalhado com m\u00e9todos e pr\u00e1ticas \u00e1geis, tenho observado diversas composi\u00e7\u00f5es e formatos de times (comumente chamados de squads, talvez por influ\u00eancia do modelo Spotify). De forma geral, muitos aspectos e caracter\u00edsticas dessas equipes se repetem, tais como: A utiliza\u00e7\u00e3o de m\u00e9tricas ou indicadores; Algum formato ou t\u00e9cnica de decomposi\u00e7\u00e3o de … \u00bb<\/a><\/p>\n","protected":false},"author":61,"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":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8891"}],"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\/61"}],"replies":[{"embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/comments?post=8891"}],"version-history":[{"count":8,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8891\/revisions"}],"predecessor-version":[{"id":8904,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/posts\/8891\/revisions\/8904"}],"wp:attachment":[{"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/media?parent=8891"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/categories?post=8891"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog.plataformatec.com.br\/wp-json\/wp\/v2\/tags?post=8891"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Utiliza\u00e7\u00e3o de Kanban e eventos do Scrum<\/h3>\n
M\u00e9tricas (WIP, Lead time e Throughput)<\/h3>\n
Features e entrega de valor<\/h3>\n
\n
Feedbacks estruturados<\/h3>\n
Resumindo<\/h2>\n
\n