Se non entendes o que é DevOps, aquí tes unha folla de trucos rápida. DevOps é un conxunto de prácticas que reduce os medos dos enxeñeiros e reducir o número de fallos na produción de software. Por regra xeral, son iguais reducir o tempo de comercialización — o período desde a idea ata a entrega do produto final aos clientes, o que lle permite levar a cabo rapidamente experimentos de negocios.
Como comezar a transformación DevOps? En resumo: seleccionamos o servizo co que iniciar o proceso, identificamos os que están relacionados co servizo, construímos un Value Stream Map, creamos un equipo temporal que se ocupará da transformación por primeira vez e establecemos unha tarefa para ela. Repetimos o ciclo o número de veces necesario.
Plan de transformación DevOps detallado con exemplos e instrucións baixo o corte - na transcrición Andrei Alexandrov - un enxeñeiro de Express42, que asesora sobre a xerminación de DevOps, acelerando este proceso porque xa construíu un mapa de rake. Se che parece que non necesitas transformación ou se as túas características específicas son tales que as prácticas de DevOps non son adecuadas, utiliza o informe como instrucións para atopar e eliminar limitacións.
Se estás preocupado polo problema da transformación de DevOps, entón tes unha gran empresa e necesitas escalar gradualmente este proceso en toda a estrutura. Sempre que sexa necesario transformar o comando ou eliminar algunha limitación, pódese repetir o seguinte algoritmo.
Selección dun servizo
Deseñamos un plan, imos comezar co primeiro paso: escoller un servizo. O primeiro criterio é a vida útil: hai servizos antigos - legados, e outros novos. Podes comezar con ambos.
É lóxico escoller un servizo novo. É fresco, aínda non hai un proceso establecido para traballar no equipo que se ocupa. Non hai ningunha montaña de débeda técnica ao seu redor, non é necesario arranxalo todo o tempo. Podemos facer o que queiramos con el.
No caso do antigo servizo, hai problemas relacionados co feito de que o cambio sempre é difícil. Xa hai un conxunto de restricións serias, pero quizais estean sendo tratadas por persoas que están dispostas a pala de todo: están cansos e queren facer algo diferente porque teñen dor.
Traballar cun servizo antigo establece un poderoso precedente na túa empresa, podes cambiar algo. Se cambias un servizo novo, baixa 100 veces por hora e todo está ben, entón as persoas da túa empresa poden dicir:
- Este é un servizo novo! Alí todo era sinxelo, tentar facer algo co noso pecio.
Ten sentido usar o servizo Legacy para a transformación cando o fas con alguén, por exemplo, se invitaches a un consultor externo. Sexamos sinceros, a transformación fará tremer todo o posible. Estás experimentando e non sabes onde vai parar, que tecnoloxías vai usar e por que, onde e que trampas aparecerán nos procesos. Polo tanto, é máis fácil cambiar un novo.
Se o fas ti mesmo e a empresa non ten unha competencia seria, tomamos un novo servizo. Se coñeces un consultor externo e tes os fondos, escolle o antigo.
Hai servizos que son simplemente unha interface para os usuarios, por exemplo, un simple sitio web ou aplicación móbil. Pero hai cousas serias no espírito da facturación. Se algo sae mal coa facturación, será difícil descifralo. Aquí tamén temos unha opción.
Traballamos tampouco cun servizo crítico, pero sufrimos por iso, crea restricións ou traballamos con interface. Este é o segundo criterio de selección. Do mesmo xeito, é posible atraer un consultor experimentado: traballamos coa opción difícil.
Pero mesmo neste caso, non recomendaría facelo, porque ata que non se entenda con que traballar e en que dirección transformar, tomar algo crítico e sacudilo non é moi boa idea. Polo tanto, neste caso, preferimos traballar cunha interface cuxa falla non sexa crítica.
Vexamos máis alá equipo de servizo. Teremos que traballar e interactuar constantemente con quen presta este servizo.
As persoas do equipo divídense en dúas categorías: conservadores — vivir no vello mundo, ou simplemente non saber nada sobre DevOps, e innovadores, que arrastran todas as prácticas de moda. Estes últimos non sempre entenden o tema, pero polo menos están preparados para iso.
Por unha banda, os conservadores son xente con experiencia: levan moito tempo na empresa, enténdeno por dentro e por fóra, pero non saben exactamente as prácticas. Por outra banda, hai innovadores que escoitaron algo, pero moi probablemente non levan moito tempo traballando na empresa. Con cal é mellor traballar?
En calquera caso, terás que interactuar cos conservadores, xa que este é o seu servizo. Terás que comunicarte con eles, coñecer as particularidades do servizo, que se pode facer deste xeito e que máis. Dependemos dos seus consellos. Probablemente teñas que confiarlles algo, porque coñecen mellor o seu servizo. Por iso, é importante con que equipo acabamos tendo contacto.
É lóxico escoller innovadores para o equipo, porque os conservadores poden poñerlle un porco.
Na práctica, moitas veces ocorre que as persoas conservadoras teñen unha experiencia significativa, pero non entenden como vivir máis lonxe. Simplemente teñen medo de que despois da transformación e redeseño do servizo, sexan despedidos por innecesarios. Ás veces, simplemente porque non entenden o que está pasando, sabotean o traballo.
Tiven un caso no que un tipo do equipo reparou todo, porque supostamente era máis crítico que o que estamos a facer agora. Nós puxémonos a tarefa: implementar esta peza hoxe - non, hai un incendio ao outro lado do mundo, imos arranxalo. É difícil traballar con esa xente.
A xente do equipo conservador adoita esquecerse das tarefas ou apórtalas ata o último momento. E se, John Willis prohíbese, cometeches un erro e asignaches un KPI para o número de tarefas completadas e, por algún motivo, algunha parte non se incluíu no KPI, entón non farán nada. En xeral, terán razón, porque entón perden a bonificación.
É máis fácil cos innovadores: son máis leais. Xa escoitaron algo, queren ir a algún sitio, así que axudarán. Necesitamos persoas que estean preparadas para sufrir por primeira vez: se o servizo cambia, entón os innovadores atraparán todos os golpes e os anciños como pioneiros. Os innovadores queren todo novo e de moda, e sofren.
Os conservadores poden converterse despois. Cando demostras que cambiaches unha peza e que todo funciona ben, o máis probable é que eles tamén queiran probalo e abrazan a nova relixión DevOps.
Imos resumir. Se nós mesmos facemos toda a transformación na nosa empresa, entón eliximos: un novo servizo, preferentemente unha interface sinxela para non sufrir demasiado a súa avaría, e un equipo de innovadores.
Se é posible chamar a un consultor externo, en lugar dun novo, collemos o servizo antigo, polo que xa estamos a sufrir. Persoas que levan moito tempo na transformación en distintas empresas viron casos diferentes e xa entenden como facelo ben, e en que dirección tomar en xeral.
Quen está implicado?
Necesitamos atopar a todos os que teñan polo menos algunha relación co servizo: desenvolvedores, probadores, administradores, especialistas en seguridade, xestores e, posiblemente, propietarios de produtos. A pesar de que os Product Owners non son especialistas técnicos, están relacionados co servizo: toman decisións, establecen tarefas.
Todos os que toman polo menos algunhas decisións e inflúen no que acontece co servizo deben ser atopados, atendidos e comunicados.
Para que os necesitamos? Para saber con quen negociar. Durante a transformación, cando cambie o principio habitual de traballar co servizo, aínda vai tremer. Haberá fallos durante un tempo mentres probamos novos enfoques. A xente debe estar preparada para iso e estar de acordo con iso.
A continuación terás que construír un Value Stream Map, e sen estas persoas non poderás crealo, porque só eles todos xuntos coñecen a imaxe completa do que está a suceder. Unha persoa nunca sabe todo o que acontece co servizo.
Recomendarán persoas para o equipo. Máis tarde comentaremos por que se necesita un equipo separado. Haberá que levar xente dos departamentos existentes. Os que estean implicados no servizo poderán recomendar compañeiros que pensen na nosa dirección, que nos poidan axudar e sexan competentes no que precisamos.
A continuación, reunimos a todas estas persoas de diferentes departamentos nunha sala e comezamos a construír un mapa de fluxo de valor.
Construír un mapa de fluxo de valor
Value Stream Map é un diagrama ou mapa que mostra o fluxo de valores ao cliente. Este é todo o proceso desde a idea dunha idea ata a súa implementación, incluíndo todas as etapas intermedias e como o valor chega finalmente aos nosos clientes.
É necesario o mapa de fluxo de valores visualizar todas as fases do desenvolvemento, localizar os problemas a través das medicións que existen no proceso actual e comezar a eliminar estes problemas, e establecer un obxectivo inicial. Aquí é onde comezamos a facer algo.
Métricas
Existen moitas métricas diferentes descritas na literatura do Value Stream Map, pero só tres son suficientes para comezar.
Prazo de execución - atraso/espera - un momento no que estamos agardando por algo. Por exemplo, un probador espera ata que o banco de probas estea libre e durante este tempo non pode facer nada.
Tempo de valor engadido - tempo útil de traballo - o que gastamos en tal ou cal etapa para crear o valor final para o usuario. Por exemplo, un probador lanzou a súa proba e comezou a comprobar algo. Este é o momento do traballo útil, cando realmente facemos algo polo produto. Isto é o que pagan os clientes: software de calidade.
%C/A é a porcentaxe de traballo aceptado. Temos unha fase - desenvolvemento, a segunda fase - probas. Cantos probadores de funcións aceptados dos desenvolvedores é esta porcentaxe.
Así é aproximadamente o noso mapa.
Pode ter un aspecto diferente dependendo da estrutura da organización, do número de departamentos e do que fagas. Pero, en xeral, haberá dúas etapas no mapa: a idea и analítica. Nesta fase, espéranse datos, por exemplo, o prazo de entrega 2 semanas e o tempo de valor engadido 2 días.
Cubrimos absolutamente todas as etapas con métricas.
Backlog - cantos problemas houbo despois de que os analistas se lles ocorreran.
Desenvolvemento - cantas semanas os desenvolvedores estiveron esperando aclaracións sobre tarefas, postos ou equipos - non importa, pero están esperando algo. Por exemplo, tardan 4 días en implementar unha función. Aquí é onde entra a métrica %C/A. Os desenvolvedores levaron só o 80% das tarefas do Backlog. Consideran que o 20% restante non ten unha especificación técnica suficientemente clara e enviáronos para revisión.
Probas. O diagrama LT está configurado para 4 días. Por exemplo, os probadores estaban esperando a que o banco de probas se liberase, VA estaban probando algo durante 2 días e %C/A = 40%. — Só o 40% do código ou das funcións enviadas polos desenvolvedores foron considerados adecuados polos probadores. Non lles gustou todo o demais por algún motivo.
Non me deterei en detalle sobre como levar a cabo estas medicións; ao final do artigo recomendarei literatura da que podes aprender sobre elas.
O único que podo recomendar é que non confíes nas persoas que compilarán contigo un Value Stream Map. Ofrecen unha idea do tempo que tardan os diferentes procesos, pero estas estimacións non sempre son correctas, polo que é mellor medirse.
Tivemos un caso cando chegamos ao departamento de Operacións e preguntamos canto tempo levaba entregar unha nova función á produción. Dixéronnos que serían 10 minutos, e pensamos, por que chegamos a esta empresa? Resultou que 10 minutos é o tempo de execución do script que toma o código e o envía ao servidor. Pero antes disto, a versión permanece no servidor durante tres días e simplemente está acumulando po: hai unha tarefa no Backlog que debe ser implementada. Acontece que antes da fase de implantación hai unha fase de espera, cando o proxecto só queda aí. Se non tivesemos ido cun bloc de notas, non nos chamaramos a atención na tarefa en Jira e comezamos a seguila paso a paso, pensariamos que todo foi xenial e non había ningún problema.
Polo tanto, aínda terás que facer ti mesmo as medicións, preferiblemente máis dunha vez, para ter unha idea próxima á realidade. Dependendo do mapa de fluxo de valor, decidirás por onde comezar e que arranxar primeiro.
Equipo temporal
Moitas empresas que deciden implementar DevOps crean un equipo, pero non temporal, senón que existe desde hai varios anos. Se vas ao servizo de desculpas de DevOps, que describe diferentes patróns para construír unha estrutura organizativa en DevOps, entenderás que este é un antipatrón.
Cando un equipo de DevOps existe de forma continua durante varios anos, este é un gran erro, porque DevOps trata sobre a comunicación entre departamentos, sobre a velocidade e a eficiencia.
Se un equipo existe entre departamentos só para facer outra cousa por separado, e existe durante moito tempo, entón crea unha barreira innecesaria. Agora o programador, en lugar de acudir inmediatamente ao administrador para resolver o problema, primeiro debe contactar co departamento de DevOps e seguirá adiante.
Polo tanto, para comezar, cómpre crear un equipo temporal. Existirá condicionalmente durante seis meses, como máximo un ano, dependendo da tarefa que se trate, só para eliminar unha limitación que escollemos. Entón ela morrerá. Se escollemos o seguinte punto no que teñamos moita dor e entendemos que tamén necesitamos un equipo separado para iso, crearémolo de novo. Pero tales equipos non deberían existir "de forma permanente"; entón só interrompen a comunicación e xeralmente asumen tarefas separadas só para facer algo. É posible que estas tarefas non estean relacionadas con DevOps ou transformación. Por que non damos esta tarefa aos departamentos existentes?
Por que é necesario un equipo temporal?
Conflito cos procesos actuais. A transformación de DevOps non é só un cambio nas tecnoloxías e ferramentas que usamos, senón un cambio no propio proceso de traballo, pensamento e valores. Se o equipo traballa como está acostumado, non poderá probar outros enfoques.
Estas persoas teñen que vivir con regras diferentes: ignorar todos os KPI da empresa porque intentan traballar de forma diferente. Os equipos interinos non cubrirán solicitudes para conseguir un servidor, senón que acudirán directamente ao departamento que os xestiona, esixindo que se lles dea antes o que necesitan, porque é prioritario e porque intentan vivir doutro xeito. O equipo está en completo conflito con todos os procesos actuais. Para garantir que as prácticas de traballo existentes non interfiran con elas agora e non interfiran con outras persoas, illamos a estas persoas nun equipo separado.
Evitando a burocracia nos experimentos. Os equipos temporais non teñen burocracia, non presentan informes de tempo, non informan aos directivos. Este é un mundo completamente separado no que a xente vive e pensa diferente e fai cousas completamente diferentes. Non hai que molestalos de novo.
Traballo sen parar no servizo. No primeiro punto, escollemos algo co que experimentaremos. Experimentar e atopar formas de traballar mellor é bo, pero tamén queremos crear funcións. Se todo o equipo se centra na transformación en lugar das funcións, entón comezaremos a perder ingresos, os erros perdurarán durante moito tempo; non o necesitamos. Crear un equipo temporal permítelle experimentar sen deixar de traballar no produto.
Non perdas o tempo en tarefas laborais. Trátase de novo do produto. O equipo leva moito tempo probar outras ferramentas e cousas. Tardará polo menos seis meses en dominar as ferramentas, comezar a implementalas e usalas con normalidade. Se tamén se centran no produto, seis meses estenderanse cosmicamente. Se a xente traballa no produto, volve traballar cos procesos antigos, non o necesitamos.
Por iso, asignamos persoas de diferentes departamentos a un equipo separado que transformará o servizo. Como resultado, o servizo funciona, segue a desenvolverse e, ao mesmo tempo, realizamos algúns experimentos sobre el.
O equipo temporal dedícase só á transformación de DevOps, eliminando a limitación que atopamos e nada máis.
O equipo está formado por persoas versátiles. Isto significa que non só contratamos desenvolvedores. Non vimos ao centro de servizos e levamos a metade do equipo de alí, non, levamos persoas de diferentes departamentos. Hai uns puntos atopamos diferentes departamentos e diferentes empregados que están relacionados co servizo transformado. Estamos a contratar un equipo deles, porque debe ser universal: cambiaremos o proceso de proba, o proceso de desenvolvemento e o proceso de mantemento do servizo. Son necesarias diferentes competencias.
Normalmente levamos un programador, un probador e un enxeñeiro, un a un, e xunto con eles chegamos a unha solución que nos permita vivir doutro xeito.
É desexable que estas persoas teñan autoridade na organización. Quizais teñas que tomar un conservador, aínda que non queiras. Se temos unha gran empresa, non todos crerán na nosa idea, e algúns poden poñer un raio nas nosas rodas, por exemplo, ao non proporcionar un soporte. Aquí é onde necesitarás unha "autoridade": unha persoa respectada con ampla experiencia que se gañou a boa actitude dos seus compañeiros. A autoridade do empregado no equipo simplificará a tarefa e o traballo do equipo temporal. A xente pensará:
- Si, este tipo xenial que todos coñecemos e que amamos encaixa aí; ao parecer, hai algo que vale a pena ver en DevOps.
Establecer un obxectivo
Reunimos xente, eliximos un servizo, analizamos as restricións e determinamos en que persoas influímos. Agora cómpre establecer un obxectivo e debe ser recto por SMART - todo o que amamos.
Específico - específico.
Medible - medible. Este é un punto SMART moi importante. Se non podes medir algo, entón non podes cambialo e entender que e como fixeches mellor ou peor.
Alcanzable - alcanzable. Fai axustes para atender ás túas necesidades específicas. Se es unha empresa empresarial cunha longa historia e unha gran carga de responsabilidades, que lanza unha versión do produto unha vez ao ano, entón non poderás conseguir o lanzamento de novas versións do produto cada hora en seis meses. Non funcionará así. Polo tanto, establece un obxectivo realista que sexa alcanzable nun prazo aceptable.
Relevante - relevante. Eliminamos só aquelas restricións que realmente serven aos nosos obxectivos actuais.
Tempo limitado - limitado no tempo. Se non hai prazo, o equipo fará o que queira: probar 15 tecnoloxías en lugar de 3, escribir informes enormes, realizar investigacións inútiles, pulir a súa implementación ata que brille cando xa se conseguiu o obxectivo.
Acadamos o obxectivo usando o Value Stream Map: recompilamos todas as persoas de novo e debuxámolas. Pero só agora, baseándonos no mapa de fluxo de valores anterior, debuxamos o que queremos obter.
Destacamos unha limitación que eliminaremos agora mesmo: isto é o que fará o equipo. Como exemplo, tomei a espera desde a versión final ata a súa implantación en produción: esta é a limitación máis común coa que a xente recorre aos consultores.
En base a isto, establecemos a tarefa: queremos que a espera entre o lanzamento rematado e a entrada en batalla sexa dun máximo dunha hora.
Exemplos de tarefas.
- Reduce o prazo de execución das probas de 4 días a 1 hora.
- Reduce o tempo de valor engadido para as probas de 2 días a 3 horas.
- Reduce o tempo de execución de 5 horas a 10 minutos.
- Aumentar o C/A do 50% ao 95%, é dicir, aumentar o número de funcións que aceptan os probadores, é dicir, mellorar a calidade do traballo dos desenvolvedores.
Os exemplos de tarefas non se toman da nosa cabeza; baséanse en medicións que fixemos ao desenvolver o Value Stream Map.
Fixemos unha tarefa semellante para o noso equipo e un límite de tempo. Dependendo do ben que lle vaia á túa empresa, estableces diferentes prazos. De media, adoita tardar seis meses en eliminar unha limitación, se a xente o fai por primeira vez e aínda non sabe con que tecnoloxías e como concretamente resolverá o problema.
Planificación curta
Así, créase o noso equipo, ten un obxectivo, a xente comeza a traballar. Un punto importante é unha pequena planificación do traballo: sprints dunha a dúas semanase non máis, melloras medibles todas as semanas e corrección do curso.
Por exemplo, moitas veces usamos o enfoque movendo-movendoCando todo o equipo se reúne ao comezo de cada semana, anota nun arquivo o que farán todos. Despois dunha semana, observamos o que se fixo e o que non, se non, entón por que, e pensamos que facer a continuación.
Os sprints permítenche facer correccións oportunas do curso.
Durante unha ou dúas semanas probaches algo: tecnoloxías, enfoques, formas de traballar, despois vuelves a medir e ves: foi mellor ou peor con este enfoque? Se é peor, significa que imos na dirección equivocada, hai que corrixir o rumbo: establecer unha tarefa diferente, tomar unha tecnoloxía diferente ou facer outra cousa. Os sprints curtos de 1-2 semanas permítenche manobrar e evitar malas decisións a tempo.
Compartindo éxito
O equipo consegue algún éxito, pequeno ou grande; non importa, sempre hai algún resultado. Todo o mundo debería saber este resultado: tanto os implicados en DevOps como os departamentos veciños. Nun mundo ideal, sería desexable que isto chegase a todas as persoas da empresa.
Para qué? Se queremos transformar non só unha parte da empresa, eliminar non só unha limitación, senón todo en xeral, para que a empresa se flexibilice, o código chegue rapidamente ao cliente e non se rompa nada, necesitamos que todos sexan fieis á idea. de DevOps. Non poderás aplicar o enfoque aos servizos e equipos que o están rotundamente en contra.
Para que apareza a lealdade, debemos dicirlle a todos que o probamos: temos resultados, proba tamén! Isto aumentará o interese e a lealdade polo que facemos, a xente comezará a tentar facer algo agora mesmo. Como demostra a práctica, cando vos contamos o que intentamos e o que conseguimos, outros equipos comezan a preguntarnos como e que fixemos. Miran implementacións, código, documentación, formulan preguntas e intentan cambiar algo por si mesmos.
Falar do que fixeches é importante. Deste xeito convencerás aos conservadores que querían facer todo a antiga forma de unirse ao teu campamento e transformalos en innovadores.
En total
Elixir un servizo, como punto de partida - o lugar onde comezaremos os cambios na empresa. Identificamos a todos os que teñen algo que ver co servizo e con eles creando un mapa de fluxo de valor, medimos e vemos onde e cales son as limitacións.
Creación dun novo equipo temporal, que resolverá o problema. Baseado en medicións e mapa de fluxos de valor debuxamos un novo mapa, onde destacamos a limitación que imos solucionar. En base a esta limitación establecer unha tarefa, do que se ocupará o equipo. A tarefa debería ser necesariamente SMART - específicos, medibles, relevantes para as tarefas actuais e limitados no tempo.
Repita o proceso, ata que transformemos absolutamente todos os nosos servizos ao formulario necesario e eliminemos todas as restricións.
Bonificación. Materiais útiles
Para aqueles que decidiron facer DevOps pola súa conta.
Proxecto "Phoenix"
O título orixinal é "The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win". Esta é unha novela sobre DevOps: a historia de como un empregado foi nomeado xefe dun departamento que sempre estaba en chamas. O novo xefe recibiu a tarefa:
"Tes uns anos para facer todo ben para que finalmente poidamos entregar o noso produto aos nosos clientes de forma rápida e eficiente".
"Proxecto Phoenix" Unha novela sobre como DevOps cambia a vida para mellor” é un libro para todos os directivos, porque son as persoas que toman decisións sobre o que acontece na empresa. Se es enxeñeiro ou programador e queres que comece o movemento e a transformación na túa empresa, compra un libro e dállo á dirección. Esta novela explica todo e é de lectura rápida e sinxela.
Guía DevOps
O libro é máis complicado. Publicouse hai varios anos en inglés baixo o título "The DevOps Handbook How to create world-class agility, reliability, and security in Technology organizations", pero agora xa está dispoñible en ruso. Isto é real manual - guía práctica: como realizar medicións, que é un Value Stream Map e por que é necesario, onde ir, en que orde. O libro é só para aqueles que queren facer todo eles mesmos. O máis importante é que contén exemplos de experiencias doutras empresas.
Por exemplo, conta como unha empresa construíu un Value Stream Map e deuse conta de que a súa limitación non estaba no produto, senón no feito de que o caixeiro camiñaba da tenda á seguinte oficina para usar este produto. En lugar de resolver o problema co programa, simplemente compraron tabletas para os seus vendedores, e agora ninguén vai a ningún lado e todas as accións realízanse no seu lugar de traballo. Conclusión: Value Stream Map pódese estender non só ao software, senón tamén a todos os procesos da organización.
Acelerar
Título completo: "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations". Este é o seguinte nivel: hardcore. O libro publicouse o ano pasado, ata agora só en inglés e trata de investigación. Os autores -Nicole Forsgren, Jez Humble e Gene Kim- estiveron utilizando diferentes prácticas en diferentes empresas durante moitos anos e investigando que prácticas afectan a que e como.
O segundo capítulo, sobre medición, menciona o Value Stream Map, as métricas que mencionei e moitas outras, e tamén describe o proceso de medición en detalle. Os autores miden mediante cuestionarios e tarefas de auto-seguimento. Describe en detalle cales son as métricas correctas para medir, cales non se deben medir e os erros humanos nas medicións. Se tes dificultades coas medidas, consulta o segundo capítulo do libro "Acelerar". Se o teu equipo simplemente ten moitas prácticas, pero non está claro que prácticas aplicar agora, cales despois, cales realmente funcionan e cales non, lea, o libro explica todo.
A transformación é un problema na intersección de DevOps e xestión. Nalgún lugar da mesma área de intersección de desenvolvemento, operacións e probas están os temas que tratamos de discutir en , a mesma integración é necesaria para crear un produto de calidade - o tema principal . Xestión do festival presentado - iso significa que todo o mundo está aí por ideas para a transformación. Acompáñanos os días 27 e 28 de maio, integraremos e transformaremos.
Fonte: www.habr.com
