{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Como iniciar uma transforma\u00e7\u00e3o DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se voc\u00ea n\u00e3o entende o que \u00e9 DevOps, aqui est\u00e1 um breve resumo. DevOps \u00e9 um conjunto de pr\u00e1ticas que reduzem os medos dos engenheiros<\/strong> e diminuem a quantidade de falhas na produ\u00e7\u00e3o de software. Geralmente, tamb\u00e9m reduzem o tempo de lan\u00e7amento ao mercado<\/strong> \u2014 o per\u00edodo desde a ideia at\u00e9 a entrega do produto final aos clientes, permitindo realizar rapidamente experimentos de neg\u00f3cios<\/strong>.<\/p>\n

Como iniciar a transforma\u00e7\u00e3o DevOps? De forma resumida: escolhemos o servi\u00e7o com o qual come\u00e7aremos o processo, identificamos as pessoas envolvidas com o servi\u00e7o, constru\u00edmos um Value Stream Map, criamos uma equipe tempor\u00e1ria que se dedicar\u00e1 \u00e0 transforma\u00e7\u00e3o inicialmente e definimos uma tarefa para ela. Repetimos o ciclo quantas vezes forem necess\u00e1rias.<\/p>\n

\"Como<\/p>\n

Um plano detalhado de transforma\u00e7\u00e3o DevOps com exemplos e instru\u00e7\u00f5es est\u00e1 dispon\u00edvel abaixo \u2014 na transcri\u00e7\u00e3o do<\/a><\/noindex> Andrey Alexandrov<\/b> \u2014 de um engenheiro da empresa Express42, que consulta sobre o crescimento do DevOps, acelerando esse processo, pois j\u00e1 construiu um mapa de armadilhas. Se voc\u00ea acha que a transforma\u00e7\u00e3o n\u00e3o \u00e9 necess\u00e1ria ou que a sua especificidade torna as pr\u00e1ticas DevOps inadequadas, use o relat\u00f3rio como um guia para identificar e remover limita\u00e7\u00f5es.
\n<\/a><\/noindex>
\nSe voc\u00ea est\u00e1 preocupado com a quest\u00e3o da transforma\u00e7\u00e3o DevOps, ent\u00e3o sua empresa \u00e9 grande e \u00e9 preciso escalar esse processo aos poucos por toda a estrutura. Enquanto houver necessidade de transformar a equipe ou eliminar alguma limita\u00e7\u00e3o, o algoritmo abaixo pode ser repetido.<\/p>\n

Escolha do servi\u00e7o<\/h2>\n

\nO plano est\u00e1 tra\u00e7ado, vamos come\u00e7ar pelo primeiro passo \u2014 a escolha do servi\u00e7o. O primeiro crit\u00e9rio \u00e9 a vida \u00fatil<\/strong>: h\u00e1 servi\u00e7os antigos \u2014 legacy, e novos. Podemos come\u00e7ar tanto com os antigos quanto com os novos.<\/p>\n

Escolher um servi\u00e7o jovem faz sentido<\/strong>. Ele \u00e9 novo, n\u00e3o h\u00e1 ainda um processo estabelecido de trabalho na equipe respons\u00e1vel. N\u00e3o h\u00e1 uma montanha de d\u00edvida t\u00e9cnica em torno dele, n\u00e3o \u00e9 necess\u00e1rio estar sempre consertando. Podemos fazer com ele o que quisermos.<\/p>\n

No caso de um servi\u00e7o antigo, h\u00e1 problemas relacionados ao fato de que mudar sempre \u00e9 dif\u00edcil<\/strong>. J\u00e1 existem certas limita\u00e7\u00f5es s\u00e9rias, mas talvez sejam administradas por pessoas que j\u00e1 est\u00e3o prontas para tudo mudar \u2014 elas est\u00e3o cansadas e querem fazer algo diferente porque est\u00e3o enfrentando dificuldades.<\/p>\n

Trabalhar com um servi\u00e7o antigo cria um forte precedente<\/strong> na sua empresa \u2014 \u00e9 poss\u00edvel mudar algo. Se voc\u00ea mudou um servi\u00e7o novo, ele vai para produ\u00e7\u00e3o 100 vezes por hora, e tudo est\u00e1 bem, ent\u00e3o as pessoas na sua empresa podem dizer:<\/p>\n

\u2014 Este \u00e9 um novo servi\u00e7o! Era tudo simples, tente fazer algo com a nossa sucata.<\/em><\/p>\n

Um servi\u00e7o legado faz sentido para transforma\u00e7\u00e3o quando voc\u00ea a realiza com algu\u00e9m, por exemplo, se convidou um consultor externo. Sejamos honestos, a transforma\u00e7\u00e3o vai abalar tudo o que for poss\u00edvel.<\/strong>. Voc\u00ea est\u00e1 experimentando e n\u00e3o sabe para onde ir\u00e1, quais tecnologias e por que ir\u00e1 usar, onde e quais armadilhas nos processos podem surgir. Portanto, \u00e9 mais f\u00e1cil mudar para um novo.<\/p>\n

Se voc\u00ea faz tudo sozinho e a empresa n\u00e3o tem compet\u00eancia s\u00e9ria \u2014 vamos de novo servi\u00e7o. Se voc\u00ea conhece um consultor externo e tem recursos \u2014 escolha o antigo.<\/p><\/blockquote>\n

\nExistem servi\u00e7os que s\u00e3o apenas uma interface para os usu\u00e1rios, como um site simples ou um aplicativo m\u00f3vel. Mas existem coisas s\u00e9rias, como o billing. Se algo der errado com o billing \u2014 ser\u00e1 complicado resolver. Aqui tamb\u00e9m temos escolhas.<\/p>\n

Trabalhamos ou com um servi\u00e7o cr\u00edtico<\/strong>, mas j\u00e1 estamos sofrendo por causa dele, ele cria limita\u00e7\u00f5es, ou trabalhamos com a interface<\/strong>. Esse \u00e9 o segundo crit\u00e9rio de escolha. Da mesma forma, h\u00e1 a possibilidade de envolver um consultor experiente \u2014 vamos trabalhar com a op\u00e7\u00e3o mais dif\u00edcil.<\/p>\n

Mas mesmo assim, eu n\u00e3o recomendaria fazer isso, porque, enquanto n\u00e3o houver entendimento sobre com o que trabalhar e em qual dire\u00e7\u00e3o transformar, pegar algo cr\u00edtico e revis\u00e1-lo \u2014 n\u00e3o \u00e9 uma boa ideia. Portanto, neste caso, preferimos trabalhar com a interface, cuja falha n\u00e3o \u00e9 cr\u00edtica.<\/p>\n

Vamos considerar agora a equipe do servi\u00e7o<\/b>. Com aqueles que gerenciam esse servi\u00e7o, teremos que trabalhar constantemente e interagir em um contato muito pr\u00f3ximo.<\/p>\n

As pessoas na equipe podem ser divididas em duas categorias: conservadores<\/strong> \u2014 vivem no velho mundo ou simplesmente n\u00e3o sabem nada sobre DevOps, e inovadores<\/strong>, que trazem todas as pr\u00e1ticas da moda. Os segundos nem sempre entendem o assunto, mas pelo menos est\u00e3o prontos para ele.<\/p>\n

Por um lado, conservadores \u2014 pessoas experientes: est\u00e3o na empresa h\u00e1 muito tempo, entendem tudo, mas n\u00e3o sabem sobre as pr\u00e1ticas. Por outro lado \u2014 inovadores, que ouviram algo, mas provavelmente n\u00e3o trabalham na empresa h\u00e1 muito tempo. Com quem \u00e9 melhor trabalhar?<\/p>\n

Com os conservadores, teremos que interagir de qualquer forma, pois este \u00e9 o servi\u00e7o deles. Teremos que nos comunicar com eles, esclarecer a especificidade do servi\u00e7o, o que pode ser feito de uma maneira e o que pode ser feito de outra. Dependemos de suas consultas. Certamente teremos que delegar algo a eles, porque conhecem melhor seu servi\u00e7o. Portanto, \u00e9 importante com qual equipe teremos contato no final.<\/p>\n

\u00c9 l\u00f3gico escolher a equipe de inovadores, porque os conservadores podem ser obst\u00e1culos.\n<\/p><\/blockquote>\n

\nNa pr\u00e1tica, muitas vezes acontece que pessoas conservadoras t\u00eam experi\u00eancia substancial, mas n\u00e3o entendem como seguir adiante. Elas simplesmente t\u00eam medo de que, ap\u00f3s a transforma\u00e7\u00e3o e reestrutura\u00e7\u00e3o do servi\u00e7o, ser\u00e3o demitidas por n\u00e3o serem mais necess\u00e1rias. \u00c0s vezes, simplesmente por n\u00e3o entender o que est\u00e1 acontecendo, elas sabotam o trabalho.<\/p>\n

Tive um caso em que um membro da equipe consertava tudo o que pudesse, porque supostamente era mais cr\u00edtico do que o que est\u00e1vamos fazendo. Damos uma tarefa: implementar hoje este peda\u00e7o \u2014 n\u00e3o, do outro lado do mundo h\u00e1 um inc\u00eandio, vamos consert\u00e1-lo. \u00c9 dif\u00edcil trabalhar com pessoas assim.<\/p>\n

Pessoas da equipe de conservadores frequentemente ignoram as tarefas ou as adiavam at\u00e9 o \u00faltimo momento. E se, Deus nos livre, voc\u00ea cometeu um erro e atribuiu a eles KPI sobre a quantidade de tarefas conclu\u00eddas, mas alguma parte foi, de alguma forma, exclu\u00edda do KPI, ent\u00e3o eles n\u00e3o far\u00e3o nada. De certo modo, estar\u00e3o certos, porque assim perder\u00e3o o b\u00f4nus.<\/p>\n

Com os inovadores \u00e9 mais f\u00e1cil \u2014 eles s\u00e3o mais leais.<\/strong>. Eles j\u00e1 ouviram algo, querem avan\u00e7ar, ent\u00e3o ajudar\u00e3o. Precisamos de pessoas que est\u00e3o dispostas a enfrentar dificuldades no in\u00edcio: se o servi\u00e7o est\u00e1 mudando, todas as dificuldades e obst\u00e1culos cair\u00e3o sobre os inovadores como pioneiros. Os inovadores querem tudo o que \u00e9 novo e moderno, e est\u00e3o dispostos a sofrer.<\/p>\n

Os conservadores podem ser convertidos mais tarde \u00e0 sua f\u00e9. Quando voc\u00ea mostrar que mudou um peda\u00e7o e tudo funciona bem, provavelmente eles tamb\u00e9m v\u00e3o querer experimentar e aceitar a nova religi\u00e3o DevOps.<\/p>\n

\"Como
\n<\/p>\n

Em resumo. Se fizermos toda a transforma\u00e7\u00e3o em nossa empresa por conta pr\u00f3pria, escolheremos: um novo servi\u00e7o, de prefer\u00eancia com uma interface simples, para n\u00e3o sofremos muito com suas falhas, e uma equipe de inovadores.<\/p><\/blockquote>\n

\nSe houver a possibilidade de chamar um consultor externo, em vez de um novo, devemos utilizar o servi\u00e7o antigo, que j\u00e1 nos causa problemas. As pessoas que lidaram com a transforma\u00e7\u00e3o por um bom tempo em diferentes empresas viram v\u00e1rias situa\u00e7\u00f5es e j\u00e1 entendem como fazer a coisa certa e para onde realmente ir.<\/p>\n

Quem est\u00e1 envolvido?<\/h2>\n

\nPrecisamos encontrar todos aqueles que t\u00eam algum tipo de rela\u00e7\u00e3o com o servi\u00e7o: desenvolvedores, testadores, administradores, profissionais de seguran\u00e7a, gerentes e, possivelmente, Product Owners. Apesar de os Product Owners n\u00e3o serem t\u00e9cnicos, eles t\u00eam um papel no servi\u00e7o: tomam decis\u00f5es e definem tarefas.<\/p>\n

\"Como
\n<\/p>\n

Todos que tomam qualquer tipo de decis\u00e3o e influenciam o que acontece com o servi\u00e7o precisam ser encontrados, conhecidos e conversados.<\/p><\/blockquote>\n

\nPara que eles nos servem? Para saber com quem negociar.<\/strong>. Durante a transforma\u00e7\u00e3o, quando o princ\u00edpio habitual de trabalho com o servi\u00e7o muda, haver\u00e1 problemas inevitavelmente. Haver\u00e1 alguns erros durante um tempo enquanto testamos novas abordagens. As pessoas precisam estar preparadas para isso e concordar.<\/p>\n

Depois, teremos que construir o Value Stream Map e sem essas pessoas n\u00e3o conseguiremos, porque s\u00f3 elas juntas conhecem a vis\u00e3o completa do que est\u00e1 acontecendo. Uma \u00fanica pessoa nunca sabe tudo que acontece com o servi\u00e7o.<\/p>\n

Elas recomendar\u00e3o pessoas para a equipe. Mais tarde discutiremos por que precisamos de uma equipe separada. Teremos que incluir pessoas dos departamentos existentes. Aqueles que t\u00eam rela\u00e7\u00e3o com o servi\u00e7o poder\u00e3o indicar colegas que pensam em nossa dire\u00e7\u00e3o, que podem nos ajudar e t\u00eam compet\u00eancia no que precisamos.<\/p>\n

Em seguida, reunimos todas essas pessoas de diferentes departamentos em uma sala e come\u00e7amos a construir o Value Stream Map.<\/p>\n

Constru\u00edmos o Value Stream Map.<\/h2>\n

\nValue Stream Map \u00e9 um diagrama ou mapa que mostra o fluxo de valores at\u00e9 o cliente.<\/strong>\u00c9 todo o processo desde a concep\u00e7\u00e3o da ideia at\u00e9 sua implementa\u00e7\u00e3o, incluindo todas as etapas intermedi\u00e1rias e como o valor chega aos nossos clientes.<\/p>\n

O Value Stream Map \u00e9 necess\u00e1rio para visualizar todas as etapas de desenvolvimento,<\/strong>localizar problemas por meio de medi\u00e7\u00f5es que existem no processo atual e come\u00e7ar a resolv\u00ea-los, e definir um objetivo inicial.<\/strong>\u00c9 o lugar onde come\u00e7aremos a realmente fazer algo.<\/p>\n

M\u00e9tricas<\/h3>\n

\nNa literatura sobre Value Stream Map, muitas m\u00e9tricas diferentes s\u00e3o descritas, mas para come\u00e7ar, precisamos apenas de tr\u00eas.<\/p>\n

Lead Time \u2014 atraso\/espera.<\/strong> \u2014 o tempo que esperamos por algo. Por exemplo, um testador aguarda a libera\u00e7\u00e3o do ambiente para testes e, nesse tempo, n\u00e3o pode fazer nada.<\/p>\n

Tempo de Valor Agregado \u2014 tempo de trabalho \u00fatil<\/strong> \u2014 aquele que gastamos em determinada etapa para criar valor final para o usu\u00e1rio. Por exemplo, o testador iniciou seu teste e come\u00e7ou a revisar algo. Esse \u00e9 o tempo de trabalho \u00fatil, quando realmente fazemos algo para o produto. \u00c9 por isso que os clientes pagam \u2014 por software de qualidade.<\/p>\n

%C\/A \u2014 porcentagem de trabalho aceito. <\/strong>Temos uma etapa \u2014 desenvolvimento, a segunda etapa \u2014 testes. Quantas funcionalidades os testadores aceitaram dos desenvolvedores, e essa \u00e9 a porcentagem.<\/p>\n

Mais ou menos assim \u00e9 o nosso mapa.<\/p>\n

\"Como
\n
\nEle pode parecer diferente dependendo da estrutura organizacional, do n\u00famero de departamentos e do que voc\u00ea faz. Mas, de uma forma geral, o mapa ter\u00e1 duas etapas: a ideia <\/strong>e an\u00e1lise<\/strong>. Nesta etapa, esperamos dados, por exemplo, Lead Time de 2 semanas e Tempo de Valor Agregado de 2 dias.<\/p>\n

Estamos cobrindo absolutamente todas as etapas com m\u00e9tricas.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 quantas tarefas ficaram ap\u00f3s os analistas as terem concebido.<\/p>\n

Desenvolvimento<\/strong> \u2014 quantas semanas os desenvolvedores aguardaram esclarecimentos sobre as tarefas, ambientes ou equipamentos \u2014 n\u00e3o importa, mas eles est\u00e3o esperando por algo. Por exemplo, 4 dias para implementar uma funcionalidade. Aqui surge a m\u00e9trica %C\/A. Os desenvolvedores pegaram apenas 80% das tarefas do Backlog. Eles acreditam que as outras 20% n\u00e3o t\u00eam um T documento claro o suficiente e as enviaram para revis\u00e3o.<\/p>\n

Testes<\/strong>. No esquema, LT \u00e9 definido como 4 dias. Por exemplo, os testadores aguardaram a libera\u00e7\u00e3o do ambiente de teste, VA 2 dias eles realmente testaram algo, e %C\/A = 40%. \u2014 apenas 40% do c\u00f3digo ou funcionalidades que os desenvolvedores enviaram foram considerados adequados pelos testadores. O restante n\u00e3o foi aprovado por algum motivo.<\/p>\n

N\u00e3o vou me aprofundar em como fazer essas medi\u00e7\u00f5es, no final do artigo recomendarei literatura onde voc\u00ea pode aprender sobre isso.<\/p>\n

A \u00fanica coisa que recomendo \u2014 n\u00e3o acreditem nas pessoas que ir\u00e3o montar um Mapa de Fluxo de Valor com voc\u00ea. Elas estimam quanto tempo diferentes processos levam, mas essas estimativas nem sempre s\u00e3o precisas, ent\u00e3o \u00e9 melhor medir voc\u00ea mesmo.<\/p>\n

Tivemos uma situa\u00e7\u00e3o em que fomos ao departamento de Opera\u00e7\u00f5es e perguntamos quanto tempo leva para entregar uma nova funcionalidade em produ\u00e7\u00e3o. Nos disseram que eram 10 minutos, e pensamos: por que viemos a esta empresa? Descobrimos que 10 minutos \u00e9 o tempo que um script leva para pegar o c\u00f3digo e entreg\u00e1-lo no servidor. Mas antes disso, o release fica tr\u00eas dias no servidor apenas parado \u2014 h\u00e1 uma tarefa no Backlog que precisa ser implantada. Portanto, existe uma fase de espera antes da fase de implanta\u00e7\u00e3o, em que o projeto simplesmente fica parado. Se n\u00e3o tiv\u00e9ssemos ido com um bloco de notas, n\u00e3o tiv\u00e9ssemos nos fixado em uma tarefa no Jira e n\u00e3o come\u00e7\u00e1ssemos a rastre\u00e1-la etapa por etapa, acreditar\u00edamos que tudo estava \u00f3timo e que n\u00e3o havia problema algum.<\/p>\n

Portanto, voc\u00ea realmente ter\u00e1 que fazer medi\u00e7\u00f5es, de prefer\u00eancia n\u00e3o apenas uma vez, para ter uma no\u00e7\u00e3o mais pr\u00f3xima da realidade. Dependendo do Value Stream Map, voc\u00ea tomar\u00e1 uma decis\u00e3o sobre de onde come\u00e7ar e o que corrigir primeiro.<\/p>\n

Equipe tempor\u00e1ria<\/h2>\n

\nMuitas empresas que decidiram implementar DevOps criam uma equipe, mas n\u00e3o uma tempor\u00e1ria; elas existem por v\u00e1rios anos. Se voc\u00ea consultar um servi\u00e7o DevOps apologize, onde est\u00e3o descritos diferentes padr\u00f5es de constru\u00e7\u00e3o de estruturas organizacionais em DevOps, perceber\u00e1 que isso \u00e9 um antipadr\u00e3o.<\/p>\n

Quando a equipe DevOps existe continuamente por v\u00e1rios anos, \u00e9 um grande erro, porque DevOps \u00e9 sobre comunica\u00e7\u00e3o entre departamentos, sobre velocidade e efici\u00eancia.<\/p><\/blockquote>\n

\nSe uma equipe existe entre os departamentos apenas para fazer algo separado e existe por muito tempo, ela cria uma barreira desnecess\u00e1ria. Agora, em vez de o programador ir diretamente ao administrador para resolver a quest\u00e3o, ele precisa primeiro consultar o departamento de DevOps, que ent\u00e3o seguir\u00e1 adiante.<\/p>\n

Portanto, para come\u00e7ar, \u00e9 preciso criar uma equipe tempor\u00e1ria.<\/strong>. Ela vai durar condicionalmente seis meses, no m\u00e1ximo um ano, dependendo da tarefa em quest\u00e3o, apenas para eliminar uma limita\u00e7\u00e3o que escolhemos. Depois disso, ela vai morrer. Se escolhermos o pr\u00f3ximo ponto onde estamos com muita dor e entendermos que tamb\u00e9m precisamos de uma equipe separada para isso, ent\u00e3o a criaremos novamente. Mas em uma base 'permanente', tais equipes n\u00e3o devem existir \u2014 assim, elas apenas prejudicam a comunica\u00e7\u00e3o e assumem tarefas separadas, apenas para fazer algo. Essas tarefas podem estar completamente desconectadas de DevOps e de transforma\u00e7\u00e3o. Por que n\u00e3o delegar essa tarefa para departamentos existentes?<\/p>\n

Por que uma equipe tempor\u00e1ria \u00e9 necess\u00e1ria<\/h3>\n

\nConflito com os processos atuais<\/strong>. A transforma\u00e7\u00e3o DevOps \u00e9 uma mudan\u00e7a n\u00e3o apenas nas tecnologias e ferramentas que usamos, mas tamb\u00e9m na pr\u00f3pria forma de trabalho, no pensamento e nos valores. Se a equipe trabalhar como j\u00e1 est\u00e1 acostumada, n\u00e3o conseguir\u00e1 experimentar outras abordagens.<\/p>\n

Essas pessoas precisam viver com outras regras: ignorar todos os KPIs da empresa, porque est\u00e3o tentando trabalhar de forma diferente. Equipes tempor\u00e1rias n\u00e3o preencher\u00e3o requisi\u00e7\u00f5es para obter um servidor, mas ir\u00e3o diretamente ao departamento que os gerencia, exigindo que lhes forne\u00e7am imediatamente o que precisa, porque \u00e9 uma tarefa priorit\u00e1ria e porque est\u00e3o tentando viver de forma diferente. A equipe tem um conflito total com todos os processos atuais. Para que os m\u00e9todos de trabalho existentes n\u00e3o os atrapalhem agora e para que eles n\u00e3o atrapalhem os outros, isolamos essas pessoas, criando uma equipe separada.<\/p>\n

Evitando a burocracia em experimentos<\/strong>. Em equipes tempor\u00e1rias, n\u00e3o h\u00e1 burocracia, elas n\u00e3o preenchem relat\u00f3rios de horas trabalhadas, n\u00e3o prestam contas aos gerentes. Este \u00e9 um mundo absolutamente separado, onde as pessoas vivem e pensam de maneira diferente, e se ocupam com coisas completamente diferentes. N\u00e3o devemos atrapalh\u00e1-los desnecessariamente.<\/p>\n

Trabalho cont\u00ednuo no servi\u00e7o<\/strong>. No primeiro ponto, escolhemos algo em que iremos experimentar. Experimentar e buscar maneiras de trabalhar melhor \u00e9 bom, mas tamb\u00e9m queremos desenvolver funcionalidades. Se toda a equipe, em vez de se concentrar nas funcionalidades, se envolver com a transforma\u00e7\u00e3o, come\u00e7aremos a perder receitas, e os bugs ficar\u00e3o pendentes por muito tempo \u2014 isso n\u00e3o \u00e9 necess\u00e1rio. A cria\u00e7\u00e3o de uma equipe tempor\u00e1ria permite experimentar sem interromper o trabalho no produto.<\/p>\n

N\u00e3o gastar tempo em tarefas de trabalho<\/strong>. Isso novamente \u00e9 sobre o produto. Fazer a equipe experimentar outras ferramentas e afins leva muito tempo. Para que as pessoas aprendam a usar as ferramentas, comecem a implement\u00e1-las e us\u00e1-las adequadamente, levar\u00e1, no m\u00ednimo, seis meses. Se elas tamb\u00e9m estiverem envolvidas com o produto, esses seis meses se estender\u00e3o indefinidamente. Se as pessoas est\u00e3o lidando com o produto, elas acabam trabalhando com os processos antigos \u2014 o que n\u00e3o precisamos.<\/p>\n

Portanto, de diferentes departamentos, destacamos pessoas para uma equipe separada que ser\u00e1 respons\u00e1vel pela transforma\u00e7\u00e3o do servi\u00e7o. Como resultado, o servi\u00e7o funciona, continua a se desenvolver e ao mesmo tempo realizamos alguns experimentos nele.<\/p>\n

A equipe tempor\u00e1ria se dedica apenas \u00e0 transforma\u00e7\u00e3o DevOps \u2014 \u00e0 elimina\u00e7\u00e3o das restri\u00e7\u00f5es que encontramos, e nada mais.<\/p><\/blockquote>\n

\nA equipe \u00e9 composta por pessoas vers\u00e1teis<\/strong>. Isso significa que n\u00e3o trouxemos apenas desenvolvedores. N\u00e3o viemos ao servi\u00e7o e retiramos metade da equipe \u2014 n\u00e3o, n\u00f3s pegamos pessoas de diferentes departamentos<\/strong>. Alguns pontos atr\u00e1s, identificamos diferentes departamentos e diversos funcion\u00e1rios que t\u00eam a ver com o servi\u00e7o que est\u00e1 sendo transformado. Desses, estamos montando uma equipe porque ela precisa ser vers\u00e1til \u2014 n\u00f3s iremos mudar tanto o processo de teste quanto o processo de desenvolvimento e o processo de manuten\u00e7\u00e3o do servi\u00e7o. Compet\u00eancias variadas s\u00e3o necess\u00e1rias.<\/p>\n

Normalmente, escolhemos um desenvolvedor, um testador e um engenheiro \u2014 um de cada, e juntos inventamos uma solu\u00e7\u00e3o que permita viver de forma diferente.<\/p>\n

\u00c9 desej\u00e1vel que essas pessoas tenham autoridade na organiza\u00e7\u00e3o<\/strong>. Pode ser necess\u00e1rio trazer um conservador, mesmo que n\u00e3o queiramos. Se tivermos uma empresa grande, nem todos acreditar\u00e3o em nossa ideia, e alguns podem tentar colocar obst\u00e1culos, por exemplo, n\u00e3o liberando um ambiente de testes. \u00c9 aqui que ser\u00e1 necess\u00e1rio um 'autoridade' \u2014 uma pessoa respeit\u00e1vel com vasta experi\u00eancia, que conquistou o respeito dos colegas. A autoridade do funcion\u00e1rio na equipe facilitar\u00e1 a tarefa e o trabalho da equipe tempor\u00e1ria. As pessoas v\u00e3o pensar:<\/p>\n

\u2014 Ah, esse cara legal que todos n\u00f3s conhecemos e respeitamos se juntou \u2014 deve haver algo no DevOps que vale a pena conferir!<\/em><\/p>\n

Definimos um objetivo<\/h2>\n

\nReunimos pessoas, escolhemos um servi\u00e7o, examinamos as restri\u00e7\u00f5es, identificamos em quem vamos influenciar. Agora precisamos estabelecer um objetivo e ele deve ser bem definido em termos de SMART<\/strong> \u2014 tudo do jeito que gostamos.<\/p>\n

Espec\u00edfico \u2014 espec\u00edfico<\/strong>.<\/p>\n

Mensur\u00e1vel \u2014 mensur\u00e1vel<\/strong>. Este \u00e9 um ponto muito importante do SMART. Se voc\u00ea n\u00e3o consegue medir algo, n\u00e3o pode alter\u00e1-lo e entender o que voc\u00ea fez melhor ou pior.<\/p>\n

Ating\u00edvel \u2014 ating\u00edvel<\/strong>. Ajuste para a sua especificidade. Se voc\u00ea \u00e9 uma empresa enterprise com uma longa hist\u00f3ria e um grande peso de responsabilidades, que lan\u00e7a uma vers\u00e3o do produto uma vez por ano, voc\u00ea n\u00e3o conseguir\u00e1 lan\u00e7ar novas vers\u00f5es do produto a cada hora. Isso n\u00e3o vai funcionar. Portanto, defina uma meta realista, que seja alcan\u00e7\u00e1vel dentro de um prazo aceit\u00e1vel.<\/p>\n

Relevante \u2014 relevante. <\/strong>Eliminamos apenas a limita\u00e7\u00e3o que realmente afeta nossas metas atuais.<\/p>\n

Limitada no Tempo \u2014 limitada no tempo<\/strong>. Se n\u00e3o h\u00e1 um prazo, a equipe far\u00e1 qualquer coisa: tentar\u00e1 15 tecnologias em vez de 3, escrever\u00e1 relat\u00f3rios enormes, far\u00e1 pesquisas in\u00fateis, polir\u00e1 sua implementa\u00e7\u00e3o at\u00e9 brilhar, quando o objetivo j\u00e1 foi alcan\u00e7ado.<\/p>\n

A meta \u00e9 obtida com a ajuda do Value Stream Map \u2014 reunimos todas as pessoas e desenhamos. Mas agora, com base no Value Stream Map anterior, desenhamos o que queremos obter.<\/p>\n

\"Como
\n
\nIdentificamos uma limita\u00e7\u00e3o que vamos eliminar agora mesmo \u2014 isso \u00e9 o que a equipe far\u00e1. Para exemplo, eu peguei a espera entre o lan\u00e7amento conclu\u00eddo e sua implanta\u00e7\u00e3o em produ\u00e7\u00e3o \u2014 essa \u00e9 a limita\u00e7\u00e3o mais comum que as pessoas apresentam aos consultores.<\/p>\n

Com base nisso, formulamos uma tarefa: queremos que a espera entre o lan\u00e7amento conclu\u00eddo e a entrada em a\u00e7\u00e3o seja, no m\u00e1ximo, uma hora.<\/p>\n

Exemplos de tarefas.<\/p>\n