DevOps ટ્રાન્સફોર્મેશન કેવી રીતે શરૂ કરવું

જો તમે સમજી શકતા નથી કે DevOps શું છે, તો અહીં એક ઝડપી ચીટ શીટ છે. DevOps એ પ્રથાઓનો સમૂહ છે જે એન્જિનિયરોના ડરને ઘટાડે છે અને સોફ્ટવેર ઉત્પાદનમાં નિષ્ફળતાઓની સંખ્યા ઘટાડે છે. એક નિયમ તરીકે, તેઓ સમાન છે બજાર માટે સમય ઘટાડવો — વિચારથી ગ્રાહકોને અંતિમ ઉત્પાદનની ડિલિવરી સુધીનો સમયગાળો, જે ઝડપી અમલીકરણ માટે પરવાનગી આપે છે વ્યવસાય પ્રયોગો.

DevOps ટ્રાન્સફોર્મેશન કેવી રીતે શરૂ કરવું? ટૂંકમાં: અમે એવી સેવા પસંદ કરીએ છીએ કે જેની સાથે પ્રક્રિયા શરૂ કરવી હોય, સેવાથી સંબંધિત લોકોને ઓળખીએ, મૂલ્ય પ્રવાહનો નકશો બનાવીએ, એક અસ્થાયી ટીમ બનાવીએ જે પ્રથમ વખત પરિવર્તનનો સામનો કરશે અને તેના માટે એક કાર્ય સેટ કરશે. અમે ચક્રને જરૂરી સંખ્યામાં પુનરાવર્તન કરીએ છીએ.

કટ હેઠળના ઉદાહરણો અને સૂચનાઓ સાથે વિગતવાર DevOps ટ્રાન્સફોર્મેશન પ્લાન - ટ્રાન્સક્રિપ્ટમાં અહેવાલ આન્દ્રે એલેક્ઝાન્ડ્રોવ - એક્સપ્રેસ42માં એક એન્જિનિયર, જે DevOps અંકુરણ પર સલાહ આપે છે, આ પ્રક્રિયાને ઝડપી બનાવે છે કારણ કે તેણીએ પહેલેથી જ રેક મેપ બનાવ્યો છે. જો તમને એવું લાગે છે કે તમારે પરિવર્તનની જરૂર નથી, અથવા તમારી વિશિષ્ટતાઓ એવી છે કે DevOps પ્રેક્ટિસ યોગ્ય નથી, તો રિપોર્ટનો ઉપયોગ મર્યાદાઓ શોધવા અને દૂર કરવા માટેની સૂચનાઓ તરીકે કરો.

જો તમે DevOps ટ્રાન્સફોર્મેશનના મુદ્દા વિશે ચિંતિત છો, તો તમારી પાસે એક મોટી કંપની છે, અને તમારે આ પ્રક્રિયાને સમગ્ર માળખામાં ધીમે ધીમે સ્કેલ કરવાની જરૂર છે. જ્યાં સુધી આદેશને રૂપાંતરિત કરવાની અથવા અમુક મર્યાદાઓને દૂર કરવાની જરૂર હોય ત્યાં સુધી, નીચેનું અલ્ગોરિધમ પુનરાવર્તિત કરી શકાય છે.

સેવા પસંદ કરી રહ્યા છીએ

અમે એક યોજનાની રૂપરેખા આપી છે, ચાલો પ્રથમ પગલાથી પ્રારંભ કરીએ - સેવા પસંદ કરવી. પ્રથમ માપદંડ જીવનકાળ છે: ત્યાં જૂની સેવાઓ છે - વારસો, અને નવી. તમે બંને સાથે પ્રારંભ કરી શકો છો.

યુવાન સેવા પસંદ કરવી તે તાર્કિક છે. તે તાજી છે, તેની સાથે કામ કરતી ટીમમાં કામ કરવા માટે હજુ સુધી સ્થાપિત પ્રક્રિયા નથી. તેની આસપાસ તકનીકી દેવાનો કોઈ પર્વત નથી, તમારે તેને હંમેશાં ઠીક કરવાની જરૂર નથી. તેની સાથે આપણે જે ઈચ્છીએ તે કરી શકીએ છીએ.

જૂની સેવાના કિસ્સામાં, હકીકતને લગતી સમસ્યાઓ છે પરિવર્તન હંમેશા મુશ્કેલ હોય છે. ત્યાં પહેલેથી જ કેટલાક ગંભીર પ્રતિબંધોનો સમૂહ છે, પરંતુ કદાચ તેઓ એવા લોકો દ્વારા વ્યવહાર કરવામાં આવે છે જેઓ બધું પાવડો કરવા માટે તૈયાર છે - તેઓ થાકેલા છે અને કંઈક અલગ કરવા માંગે છે કારણ કે તેઓ પીડામાં છે.

જૂની સેવા સાથે કામ કરવું એ એક શક્તિશાળી મિસાલ સેટ કરે છે તમારી કંપનીમાં - તમે કંઈક બદલી શકો છો. જો તમે નવી સેવા બદલો છો, તો તે કલાકમાં 100 વખત નીચે આવે છે, અને બધું બરાબર છે, તો તમારી કંપનીના લોકો કદાચ કહેશે:

- આ એક નવી સેવા છે! ત્યાં બધું સરળ હતું, અમારા નંખાઈ સાથે કંઈક કરવાનો પ્રયાસ કરો.

જ્યારે તમે કોઈની સાથે લેગસી સેવાનો ઉપયોગ કરો છો, ઉદાહરણ તરીકે, જો તમે કોઈ બાહ્ય સલાહકારને આમંત્રિત કર્યા હોય, તો પરિવર્તન માટે લેગસી સેવાનો ઉપયોગ કરવો તે અર્થપૂર્ણ છે. ચાલો પ્રામાણિક બનો, પરિવર્તન શક્ય બધું હલાવી દેશે. તમે પ્રયોગો કરી રહ્યા છો અને તમે જાણતા નથી કે તમે ક્યાં સમાપ્ત થશો, તમે કઈ તકનીકોનો ઉપયોગ કરશો અને પ્રક્રિયામાં શા માટે, ક્યાં અને કઈ મુશ્કેલીઓ ઊભી થશે. તેથી, નવું બદલવું વધુ સરળ છે.

જો તમે બધું જાતે કરો છો, અને કંપની પાસે ગંભીર યોગ્યતા નથી, તો અમે નવી સેવા લઈએ છીએ. જો તમે કોઈ બાહ્ય સલાહકારને જાણો છો અને તમારી પાસે ભંડોળ છે, તો જૂનું પસંદ કરો.

એવી સેવાઓ છે જે વપરાશકર્તાઓ માટે ફક્ત એક ઇન્ટરફેસ છે, ઉદાહરણ તરીકે, એક સરળ વેબસાઇટ અથવા મોબાઇલ એપ્લિકેશન. પરંતુ બિલિંગની ભાવનામાં ગંભીર બાબતો છે. જો બિલિંગમાં કંઈક ખોટું થાય છે, તો તેને બહાર કાઢવું ​​મુશ્કેલ બનશે. અહીં અમારી પાસે પસંદગી પણ છે.

અમે કાં તો કામ કરીએ છીએ જટિલ સેવા સાથે, પરંતુ આપણે તેના કારણે સહન કરીએ છીએ, તે પ્રતિબંધો બનાવે છે, અથવા આપણે કામ કરીએ છીએ s ઇન્ટરફેસ. આ બીજો પસંદગી માપદંડ છે. એ જ રીતે, અનુભવી સલાહકારને આકર્ષવું શક્ય છે - અમે મુશ્કેલ વિકલ્પ સાથે કામ કરીએ છીએ.

પરંતુ આ કિસ્સામાં પણ, હું આ કરવાની ભલામણ કરીશ નહીં, કારણ કે જ્યાં સુધી તેની સાથે કામ કરવું અને કઈ દિશામાં રૂપાંતર કરવું તેની સમજ ન હોય ત્યાં સુધી, કોઈ મહત્વપૂર્ણ વસ્તુ લેવી અને તેને હલાવો એ બહુ સારો વિચાર નથી. તેથી, આ કિસ્સામાં, અમે એવા ઇન્ટરફેસ સાથે કામ કરવાનું પસંદ કરીએ છીએ જેની નિષ્ફળતા મહત્વપૂર્ણ નથી.

ચાલો આગળ જોઈએ સેવા ટીમ. આ સેવા આપનારાઓ સાથે અમારે સતત કામ કરવું પડશે અને ખૂબ નજીકથી સંપર્ક કરવો પડશે.

ટીમના લોકોને બે કેટેગરીમાં વહેંચવામાં આવ્યા છે: રૂઢિચુસ્ત — જૂની દુનિયામાં રહો, અથવા ફક્ત DevOps વિશે કંઈપણ જાણતા નથી, અને સંશોધકો, જે તમામ ફેશનેબલ પ્રથાઓને ખેંચે છે. બાદમાં હંમેશા વિષયને સમજી શકતા નથી, પરંતુ ઓછામાં ઓછા તેઓ તેના માટે તૈયાર છે.

એક તરફ, રૂઢિચુસ્તો અનુભવી લોકો છે: તેઓ લાંબા સમયથી કંપનીમાં છે, તેઓ તેને અંદર અને બહાર સમજે છે, પરંતુ તેઓ પ્રથાઓ વિશે જાણતા નથી. બીજી બાજુ, એવા સંશોધકો છે કે જેમણે કંઈક સાંભળ્યું છે, પરંતુ સંભવતઃ તેઓ લાંબા સમયથી કંપનીમાં કામ કરતા નથી. જેની સાથે કામ કરવું વધુ સારું છે?

તમારે કોઈ પણ સંજોગોમાં રૂઢિચુસ્તો સાથે વાતચીત કરવી પડશે, કારણ કે આ તેમની સેવા છે. તમારે તેમની સાથે વાતચીત કરવી પડશે, સેવાની વિશિષ્ટતાઓ શોધવી પડશે, આ રીતે શું કરી શકાય છે અને બીજું શું. અમે તેમની સલાહ પર આધાર રાખીએ છીએ. તમારે કદાચ તેમને કંઈક સોંપવું પડશે, કારણ કે તેઓ તેમની સેવાને વધુ સારી રીતે જાણે છે. તેથી, આપણે કઈ ટીમ સાથે સંપર્ક કરીએ છીએ તે મહત્વનું છે.

ટીમ માટે સંશોધકો પસંદ કરવાનું તાર્કિક છે, કારણ કે રૂઢિચુસ્તો તેમાં ડુક્કર મૂકી શકે છે.

વ્યવહારમાં, એવું ઘણીવાર બને છે કે રૂઢિચુસ્ત લોકો પાસે નોંધપાત્ર અનુભવ હોય છે, પરંતુ તેમને આગળ કેવી રીતે જીવવું તેની સમજ હોતી નથી. તેઓ ફક્ત ડરતા હોય છે કે સેવાના પરિવર્તન અને ફરીથી ડિઝાઇન પછી, તેઓને બિનજરૂરી તરીકે બરતરફ કરવામાં આવશે. કેટલીકવાર, ફક્ત કારણ કે તેઓ સમજી શકતા નથી કે શું થઈ રહ્યું છે, તેઓ કામમાં તોડફોડ કરે છે.

મારી પાસે એક કેસ હતો જ્યાં ટીમના એક વ્યક્તિએ બધું સમારકામ કર્યું હતું, કારણ કે તે માનવામાં આવે છે કે આપણે અત્યારે શું કરી રહ્યા છીએ તેના કરતાં તે વધુ જટિલ હતું. અમે કાર્ય સેટ કર્યું છે: આજે આ ભાગને અમલમાં મૂકવા માટે - ના, વિશ્વની બીજી બાજુએ આગ છે, અમે તેને ઠીક કરવા જઈ રહ્યા છીએ. આવા લોકો સાથે કામ કરવું મુશ્કેલ છે.

રૂઢિચુસ્ત ટીમના લોકો ઘણીવાર કાર્યો વિશે ભૂલી જાય છે અથવા તેમને છેલ્લી ઘડી સુધી અટકાવી દે છે. અને જો, જ્હોન વિલિસે મનાઈ કરી હોય, તો તમે ભૂલ કરી છે અને તેમને પૂર્ણ કરેલા કાર્યોની સંખ્યા માટે KPI સોંપેલ છે, અને કોઈ કારણોસર અમુક ભાગ KPI માં શામેલ કરવામાં આવ્યો નથી, તો તેઓ કંઈપણ કરશે નહીં. સામાન્ય રીતે, તેઓ સાચા હશે, કારણ કે પછી તેઓ બોનસ ગુમાવે છે.

સંશોધકો સાથે તે સરળ છે - તેઓ વધુ વફાદાર છે. તેઓએ પહેલેથી જ કંઈક સાંભળ્યું છે, તેઓ ક્યાંક જવા માંગે છે, તેથી તેઓ મદદ કરશે. અમને એવા લોકોની જરૂર છે કે જેઓ પ્રથમ વખત ભોગવવા માટે તૈયાર હોય: જો સેવા બદલાય છે, તો નવીનતાઓ અગ્રણી તરીકે તમામ મુશ્કેલીઓ અને રેક્સને પકડી લેશે. ઇનોવેટર્સ બધું નવું અને ફેશનેબલ ઇચ્છે છે અને પીડાય છે.

રૂઢિચુસ્તોને પાછળથી રૂપાંતરિત કરી શકાય છે. જ્યારે તમે બતાવો કે તમે એક ભાગ બદલ્યો છે અને બધું બરાબર કામ કરે છે, ત્યારે સંભવતઃ તેઓ તેને પણ અજમાવવા માંગશે અને નવા DevOps ધર્મને સ્વીકારશે.

ચાલો સારાંશ આપીએ. જો અમે અમારી કંપનીમાં સંપૂર્ણ પરિવર્તન જાતે કરીએ છીએ, તો પછી અમે પસંદ કરીએ છીએ: એક નવી સેવા, પ્રાધાન્યમાં એક સરળ ઇન્ટરફેસ જેથી તેના ભંગાણથી વધુ પીડાય નહીં, અને નવીનતાઓની ટીમ.

જો બાહ્ય સલાહકારને બોલાવવાનું શક્ય હોય તો, નવીને બદલે, અમે જૂની સેવા લઈએ છીએ, જેના કારણે આપણે પહેલેથી જ પીડાઈ રહ્યા છીએ. જે લોકો વિવિધ કંપનીઓમાં લાંબા સમયથી પરિવર્તન સાથે સંકળાયેલા છે તેઓ જુદા જુદા કેસ જોયા છે અને પહેલાથી જ સમજી ગયા છે કે તે કેવી રીતે કરવું અને સામાન્ય રીતે કઈ દિશામાં જવું.

કોણ સામેલ છે?

અમારે દરેકને શોધવાની જરૂર છે કે જેઓ સેવા સાથે ઓછામાં ઓછા કેટલાક સંબંધ ધરાવે છે: વિકાસકર્તાઓ, પરીક્ષકો, સંચાલકો, સુરક્ષા નિષ્ણાતો, સંચાલકો અને, સંભવતઃ, ઉત્પાદન માલિકો. ઉત્પાદન માલિકો તકનીકી નિષ્ણાતો નથી તે હકીકત હોવા છતાં, તેઓ સેવા સાથે સંબંધિત છે: તેઓ નિર્ણયો લે છે, કાર્યો સેટ કરે છે.

દરેક વ્યક્તિ જે ઓછામાં ઓછા કેટલાક નિર્ણયો લે છે અને સેવા સાથે શું થાય છે તેને પ્રભાવિત કરે છે તેને શોધવાની, મળવાની અને વાતચીત કરવાની જરૂર છે.

આપણે તેમની શું જરૂર છે? કોની સાથે વાટાઘાટો કરવી તે જાણવા માટે. પરિવર્તન દરમિયાન, જ્યારે સેવા સાથે કામ કરવાનો સામાન્ય સિદ્ધાંત બદલાય છે, તે હજી પણ હચમચી જશે. જ્યારે અમે નવા અભિગમોનું પરીક્ષણ કરીએ છીએ ત્યારે થોડા સમય માટે અવરોધો આવશે. લોકોએ આ માટે તૈયાર રહેવું જોઈએ અને તેની સાથે સંમત થવું જોઈએ.

આગળ તમારે વેલ્યુ સ્ટ્રીમ મેપ બનાવવો પડશે, અને આ લોકો વિના તમે તેને બનાવી શકશો નહીં, કારણ કે શું થઈ રહ્યું છે તેનું સંપૂર્ણ ચિત્ર ફક્ત તેઓ જ બધા સાથે જ જાણે છે. એક વ્યક્તિ ક્યારેય જાણતી નથી કે સેવા સાથે શું થાય છે.

તેઓ ટીમ માટે લોકોની ભલામણ કરશે પછીથી અમે ચર્ચા કરીશું કે શા માટે અલગ ટીમની જરૂર છે. તેમાં હાલના વિભાગોના લોકોને લેવા પડશે. જેઓ સેવા સાથે સંકળાયેલા છે તેઓ સાથીદારોની ભલામણ કરી શકશે જેઓ અમારી દિશામાં વિચારે છે, જેઓ અમને મદદ કરી શકે છે અને અમને જે જોઈએ છે તેમાં સક્ષમ છે.

આગળ, અમે આ બધા લોકોને વિવિધ વિભાગોના એક રૂમમાં ભેગા કરીએ છીએ અને મૂલ્ય પ્રવાહનો નકશો બનાવવાનું શરૂ કરીએ છીએ.

મૂલ્ય પ્રવાહનો નકશો બનાવવો

વેલ્યુ સ્ટ્રીમ મેપ એ એક ડાયાગ્રામ અથવા નકશો છે જે ક્લાયન્ટને મૂલ્યોનો પ્રવાહ દર્શાવે છે. આ એક વિચાર સાથે તેના અમલીકરણ સુધીની આખી પ્રક્રિયા છે, જેમાં તમામ મધ્યવર્તી તબક્કાઓ અને આખરે અમારા ગ્રાહકોને મૂલ્ય કેવી રીતે મળે છે.

મૂલ્ય પ્રવાહ નકશો જરૂરી છે વિકાસના તમામ તબક્કાઓની કલ્પના કરો, વર્તમાન પ્રક્રિયામાં અસ્તિત્વમાં છે તે માપ દ્વારા સમસ્યાઓનું સ્થાનિકીકરણ કરો અને આ સમસ્યાઓને દૂર કરવાનું શરૂ કરો, અને પ્રારંભિક ધ્યેય સેટ કરો. આ તે છે જ્યાં આપણે ખરેખર કંઈક કરવાનું શરૂ કરીએ છીએ.

મેટ્રિક્સ

મૂલ્ય પ્રવાહ નકશા સાહિત્યમાં વર્ણવેલ ઘણાં વિવિધ મેટ્રિક્સ છે, પરંતુ ફક્ત ત્રણ જ અમને પ્રારંભ કરવા માટે પૂરતા છે.

લીડ ટાઈમ - વિલંબ/પ્રતીક્ષા - એવો સમય જ્યારે આપણે કોઈ વસ્તુની રાહ જોઈ રહ્યા છીએ. ઉદાહરણ તરીકે, ટેસ્ટર બેન્ચ ફ્રી હોય ત્યાં સુધી રાહ જુએ છે અને આ સમય દરમિયાન કંઈ કરી શકતું નથી.

મૂલ્યવર્ધિત સમય - ઉપયોગી કાર્ય સમય - વપરાશકર્તા માટે અંતિમ મૂલ્ય બનાવવા માટે અમે આવા અને આવા તબક્કે શું ખર્ચ્યું. ઉદાહરણ તરીકે, એક પરીક્ષકે તેનું પરીક્ષણ શરૂ કર્યું અને કંઈક તપાસવાનું શરૂ કર્યું. આ ઉપયોગી કાર્યનો સમય છે, જ્યારે આપણે ખરેખર ઉત્પાદન માટે કંઈક કરીએ છીએ. આ તે છે જેના માટે ગ્રાહકો ચૂકવણી કરે છે - ગુણવત્તાયુક્ત સોફ્ટવેર.

%C/A એ સ્વીકૃત કાર્યની ટકાવારી છે. અમારી પાસે એક તબક્કો છે - વિકાસ, બીજો તબક્કો - પરીક્ષણ. ડેવલપર્સ પાસેથી ટેસ્ટર્સે કેટલી સુવિધાઓ સ્વીકારી છે તે આ ટકાવારી છે.

આ લગભગ અમારો નકશો જેવો દેખાય છે.

સંસ્થાના બંધારણ, વિભાગોની સંખ્યા અને તમે શું કરો છો તેના આધારે તે અલગ દેખાઈ શકે છે. પરંતુ સામાન્ય રીતે નકશા પર બે તબક્કા હશે: વિચાર и વિશ્લેષણ. આ તબક્કે, ડેટા અપેક્ષિત છે, ઉદાહરણ તરીકે, લીડ ટાઇમ 2 અઠવાડિયા અને મૂલ્ય વર્ધિત સમય 2 દિવસ.

અમે મેટ્રિક્સ સાથે સંપૂર્ણપણે તમામ તબક્કાઓને આવરી લઈએ છીએ.

બેકલોગ - વિશ્લેષકો તેમની સાથે આવ્યા પછી કેટલી સમસ્યાઓ હતી.

વિકાસ - વિકાસકર્તાઓ કેટલા અઠવાડિયાથી કાર્યો, સ્ટેન્ડ અથવા સાધનો પર સ્પષ્ટતા માટે રાહ જોઈ રહ્યા છે - તેનાથી કોઈ ફરક પડતો નથી, પરંતુ તેઓ કંઈકની રાહ જોઈ રહ્યા છે. ઉદાહરણ તરીકે, તેમને કોઈ સુવિધા લાગુ કરવામાં 4 દિવસ લાગે છે. આ તે છે જ્યાં %C/A મેટ્રિક આવે છે. વિકાસકર્તાઓએ બેકલોગમાંથી માત્ર 80% કાર્યો લીધા. તેઓ માને છે કે બાકીના 20% પાસે સ્પષ્ટ પર્યાપ્ત તકનીકી સ્પષ્ટીકરણો નથી, અને તેમને પુનરાવર્તન માટે મોકલ્યા છે.

પરીક્ષણ. એલટી ડાયાગ્રામ 4 દિવસ માટે સેટ કરેલ છે. ઉદાહરણ તરીકે, પરીક્ષકો ટેસ્ટ બેન્ચ ફ્રી થવાની રાહ જોઈ રહ્યા હતા, VA તેઓ ખરેખર 2 દિવસ માટે કંઈક પરીક્ષણ કરી રહ્યા હતા, અને %C/A = 40%. — વિકાસકર્તાઓ દ્વારા મોકલવામાં આવેલ કોડ અથવા ફીચર્સમાંથી માત્ર 40% જ પરીક્ષકો દ્વારા પર્યાપ્ત ગણવામાં આવ્યા હતા. તેમને કોઈ કારણસર બીજું બધું ગમતું ન હતું.

હું આ માપદંડોને કેવી રીતે હાથ ધરવા તે વિશે વિગતવાર ધ્યાન આપીશ નહીં;

હું ફક્ત એક જ વસ્તુની ભલામણ કરી શકું છું કે તમે એવા લોકો પર વિશ્વાસ કરશો નહીં જેઓ તમારી સાથે વેલ્યુ સ્ટ્રીમ મેપ કમ્પાઇલ કરશે. તેઓ વિવિધ પ્રક્રિયાઓમાં કેટલો સમય લે છે તેનો ખ્યાલ આપે છે, પરંતુ આ અંદાજો હંમેશા સાચા હોતા નથી, તેથી તમારી જાતને માપવાનું શ્રેષ્ઠ છે.

અમારી પાસે એક કેસ હતો જ્યારે અમે ઓપરેશન્સ વિભાગમાં આવ્યા અને પૂછ્યું કે ઉત્પાદનમાં નવી સુવિધા પહોંચાડવામાં કેટલો સમય લાગ્યો. તેઓએ અમને કહ્યું કે 10 મિનિટ થશે, અને અમે વિચાર્યું કે અમે આ કંપનીમાં કેમ આવ્યા? તે બહાર આવ્યું છે કે 10 મિનિટ એ સ્ક્રિપ્ટનો ચાલતો સમય છે જે કોડ લે છે અને તેને સર્વર પર પહોંચાડે છે. પરંતુ આ પહેલાં, રિલીઝ ત્રણ દિવસ માટે સર્વર પર બેસે છે અને તે ફક્ત ધૂળ એકઠી કરી રહી છે - બેકલોગમાં એક કાર્ય છે જેને જમાવવાની જરૂર છે. તે તારણ આપે છે કે જમાવટના તબક્કા પહેલાં એક રાહ જોવાનો તબક્કો છે, જ્યારે પ્રોજેક્ટ ફક્ત ત્યાં બેસે છે. જો અમે નોટપેડ સાથે ન ગયા હોત, જીરાના કાર્ય પર અમારી નજર ન લીધી હોત અને તેને સ્ટેપ બાય ટ્રૅક કરવાનું શરૂ કર્યું હોત, તો અમે વિચાર્યું હોત કે બધું સરસ છે અને કોઈ સમસ્યા નથી.

તેથી, વાસ્તવિકતાની નજીકનો વિચાર મેળવવા માટે તમારે હજી પણ જાતે માપન કરવું પડશે, પ્રાધાન્યમાં એક કરતા વધુ વખત. મૂલ્ય પ્રવાહના નકશા પર આધાર રાખીને, તમે નક્કી કરશો કે ક્યાંથી શરૂઆત કરવી અને પહેલા શું ઠીક કરવું.

કામચલાઉ ટીમ

ઘણી કંપનીઓ કે જેઓ DevOps ને અમલમાં મૂકવાનું નક્કી કરે છે તે એક ટીમ બનાવે છે, પરંતુ તે અસ્થાયી નથી, પરંતુ એક કે જે ઘણા વર્ષોથી અસ્તિત્વમાં છે. જો તમે DevOps માફી માગવાની સેવા પર જાઓ છો, જે DevOpsમાં સંગઠનાત્મક માળખું બનાવવા માટે વિવિધ પેટર્નનું વર્ણન કરે છે, તો તમે સમજી શકશો કે આ એક એન્ટિ-પેટર્ન છે.

જ્યારે DevOps ટીમ ઘણા વર્ષો સુધી સતત અસ્તિત્વમાં રહે છે, ત્યારે આ એક મોટી ભૂલ છે, કારણ કે DevOps એ વિભાગો વચ્ચેના સંચાર, ઝડપ અને કાર્યક્ષમતા વિશે છે.

જો કોઈ ટીમ અલગ અલગ કંઈક કરવા માટે જ વિભાગો વચ્ચે અસ્તિત્વ ધરાવે છે, અને લાંબા સમય સુધી અસ્તિત્વમાં છે, તો તે બિનજરૂરી અવરોધ બનાવે છે. હવે, સમસ્યાના નિરાકરણ માટે તરત જ એડમિનિસ્ટ્રેટર પાસે જવાને બદલે, પ્રોગ્રામરે પહેલા DevOps વિભાગનો સંપર્ક કરવો જોઈએ, અને તે આગળ વધશે.

તેથી, પ્રારંભ કરવા માટે, તમારે અસ્થાયી ટીમ બનાવવાની જરૂર છે. તે શરતી રીતે છ મહિના માટે અસ્તિત્વમાં રહેશે, વધુમાં વધુ એક વર્ષ, હાથ પરના કાર્યના આધારે, ફક્ત અમે પસંદ કરેલી એક મર્યાદાને દૂર કરવા માટે. પછી તેણી મરી જશે. જો આપણે આગળનો મુદ્દો પસંદ કરીએ કે જ્યાં આપણને ઘણું દુઃખ છે અને તે માટે આપણને અલગ ટીમની પણ જરૂર છે, તો આપણે તેને ફરીથી બનાવીશું. પરંતુ આવી ટીમો "સ્થાયી ધોરણે" અસ્તિત્વમાં હોવી જોઈએ નહીં - પછી તેઓ ફક્ત સંદેશાવ્યવહારમાં વિક્ષેપ પાડે છે અને સામાન્ય રીતે કંઈક કરવા માટે અલગ કાર્યો કરે છે. આ કાર્યો DevOps અથવા રૂપાંતરણ સાથે બિલકુલ સંબંધિત ન હોઈ શકે. શા માટે આપણે હાલના વિભાગોને આ કાર્ય સોંપતા નથી?

શા માટે કામચલાઉ ટીમની જરૂર છે?

વર્તમાન પ્રક્રિયાઓ સાથે વિરોધાભાસ. DevOps રૂપાંતરણ એ માત્ર અમે જે તકનીકો અને સાધનોનો ઉપયોગ કરીએ છીએ તેમાં ફેરફાર નથી, પરંતુ કાર્ય, વિચાર અને મૂલ્યોની પ્રક્રિયામાં ફેરફાર છે. જો ટીમ જે રીતે કામ કરે છે તે રીતે કામ કરે છે, તો તે અન્ય અભિગમો અજમાવી શકશે નહીં.

આ લોકોને અલગ-અલગ નિયમો દ્વારા જીવવું પડે છે: કંપનીમાં તમામ KPIs ને અવગણો કારણ કે તેઓ અલગ રીતે કામ કરવાનો પ્રયાસ કરી રહ્યા છે. અસ્થાયી ટીમો સર્વર મેળવવા માટે અરજીઓ ભરશે નહીં, પરંતુ તેઓ સીધા જ તેમનું સંચાલન કરતા વિભાગમાં જશે, અને માંગણી કરશે કે તેઓને જે જોઈએ છે તે પ્રથમ આપવામાં આવે, કારણ કે તે એક અગ્રતા છે અને કારણ કે તેઓ અલગ રીતે જીવવાનો પ્રયાસ કરી રહ્યા છે. ટીમ તમામ વર્તમાન પ્રક્રિયાઓ સાથે સંપૂર્ણ સંઘર્ષમાં છે. હાલની કાર્ય પ્રથાઓ હવે તેમની સાથે દખલ ન કરે અને તેઓ અન્ય લોકો સાથે દખલ ન કરે તેની ખાતરી કરવા માટે, અમે આ લોકોને એક અલગ ટીમમાં અલગ પાડીએ છીએ.

પ્રયોગોમાં નોકરિયાતથી દૂર રહેવું. અસ્થાયી ટીમો પાસે અમલદારશાહી નથી, તેઓ સમયના અહેવાલો ફાઇલ કરતા નથી, તેઓ મેનેજરોને જાણ કરતા નથી. આ એક સંપૂર્ણપણે અલગ દુનિયા છે જેમાં લોકો રહે છે અને અલગ રીતે વિચારે છે અને સંપૂર્ણપણે અલગ વસ્તુઓ કરે છે. તેમને ફરીથી ખલેલ પહોંચાડવાની જરૂર નથી.

સેવા પર નોન-સ્ટોપ કાર્ય. પ્રથમ બિંદુમાં, અમે કંઈક પસંદ કર્યું છે જેનો અમે પ્રયોગ કરીશું. પ્રયોગ કરવો અને વધુ સારી રીતે કામ કરવાની રીતો શોધવી સારી છે, પરંતુ અમે સુવિધાઓ પણ બનાવવા માંગીએ છીએ. જો આખી ટીમ સુવિધાઓને બદલે પરિવર્તન પર ધ્યાન કેન્દ્રિત કરશે, તો અમે આવક ગુમાવવાનું શરૂ કરીશું, બગ્સ લાંબા સમય સુધી અટકી જશે - અમને આની જરૂર નથી. અસ્થાયી ટીમ બનાવવાથી તમે ઉત્પાદન પર કામ બંધ કર્યા વિના પ્રયોગ કરી શકો છો.

કામના કાર્યોમાં સમય બગાડો નહીં. તે ફરીથી ઉત્પાદન વિશે છે. ટીમને અન્ય સાધનો અને સામગ્રી અજમાવવામાં ઘણો સમય લાગે છે. લોકોને ટૂલ્સમાં નિપુણતા પ્રાપ્ત કરવામાં, તેનો અમલ કરવાનું શરૂ કરવામાં અને સામાન્ય રીતે તેનો ઉપયોગ કરવામાં ઓછામાં ઓછા છ મહિનાનો સમય લાગશે. જો તેઓ ઉત્પાદન પર પણ ધ્યાન કેન્દ્રિત કરશે, તો છ મહિના વૈશ્વિક રીતે લંબાશે. જો લોકો ઉત્પાદન પર કામ કરે છે, તો તેઓ ફરીથી જૂની પ્રક્રિયાઓ સાથે કામ કરે છે - અમને તેની જરૂર નથી.

તેથી, અમે અલગ-અલગ વિભાગના લોકોને એક અલગ ટીમમાં સોંપીએ છીએ જે સેવામાં પરિવર્તન લાવશે. પરિણામે, સેવા કાર્ય કરે છે, વિકાસ કરવાનું ચાલુ રાખે છે, અને તે જ સમયે અમે તેના પર કેટલાક પ્રયોગો કરીએ છીએ.

કામચલાઉ ટીમ માત્ર DevOps ટ્રાન્સફોર્મેશન માટે સમર્પિત છે - અમને જે મર્યાદા મળી છે તેને દૂર કરવી, અને વધુ કંઈ નથી.

ટીમમાં બહુમુખી પ્રતિભા ધરાવતા લોકોનો સમાવેશ થાય છે. આનો અર્થ એ છે કે અમે માત્ર વિકાસકર્તાઓને જ રાખ્યા નથી. અમે સર્વિસ સેન્ટર પર આવ્યા નથી અને ત્યાંથી અડધી ટીમ લીધી - ના, અમે લીધી વિવિધ વિભાગોના લોકો. થોડાક મુદ્દાઓ પહેલા, અમને વિવિધ વિભાગો અને જુદા જુદા કર્મચારીઓ મળ્યા જેઓ પરિવર્તિત સેવા સાથે સંબંધિત છે. અમે તેમની પાસેથી એક ટીમની ભરતી કરી રહ્યા છીએ, કારણ કે તે સાર્વત્રિક હોવી જોઈએ - અમે પરીક્ષણ પ્રક્રિયા, વિકાસ પ્રક્રિયા અને સેવા જાળવણી પ્રક્રિયામાં ફેરફાર કરીશું. વિવિધ ક્ષમતાઓ જરૂરી છે.

સામાન્ય રીતે અમે એક સમયે એક ડેવલપર, એક ટેસ્ટર અને એક એન્જિનિયર લઈએ છીએ અને તેમની સાથે મળીને અમે એવા ઉકેલ સાથે આવીએ છીએ જે આપણને અલગ રીતે જીવવા દે છે.

આ લોકો સંસ્થામાં સત્તા ધરાવે છે તે ઇચ્છનીય છે. તમારે એક રૂઢિચુસ્ત લેવું પડશે, જો કે તમે ઇચ્છતા નથી. જો અમારી પાસે મોટી કંપની છે, તો દરેક જણ અમારા વિચારમાં વિશ્વાસ કરશે નહીં, અને કેટલાક અમારા વ્હીલ્સમાં સ્પોક મૂકી શકે છે, ઉદાહરણ તરીકે, સ્ટેન્ડ ન આપીને. આ તે છે જ્યાં તમારે "ઓથોરિટી" ની જરૂર પડશે - વ્યાપક અનુભવ ધરાવતો આદરણીય વ્યક્તિ જેણે તેના સાથીદારોનું સારું વલણ મેળવ્યું છે. ટીમમાં કર્મચારીની સત્તા કામચલાઉ ટીમના કાર્ય અને કાર્યને સરળ બનાવશે. લોકો વિચારશે:

- હા, આ શાનદાર મિત્રને આપણે બધા જાણીએ છીએ અને પ્રેમ ત્યાં બંધબેસે છે - દેખીતી રીતે DevOps માં જોવા જેવું કંઈક છે!

એક ધ્યેય સુયોજિત

અમે લોકોને ભેગા કર્યા, સેવા પસંદ કરી, પ્રતિબંધો જોયા અને નક્કી કર્યું કે અમે કયા લોકોને પ્રભાવિત કરીશું. હવે તમારે એક ધ્યેય સેટ કરવાની જરૂર છે અને તે સીધો હોવો જોઈએ SMART દ્વારા - અમને ગમે છે તે બધું.

ચોક્કસ - ચોક્કસ.

માપી શકાય તેવું - માપી શકાય તેવું. આ એક ખૂબ જ મહત્વપૂર્ણ SMART બિંદુ છે. જો તમે કંઈક માપી શકતા નથી, તો તમે તેને બદલી શકતા નથી અને સમજી શકતા નથી કે તમે શું અને કેવી રીતે સારું કર્યું કે ખરાબ.

પ્રાપ્ય - પ્રાપ્ત કરી શકાય તેવું. તમારી ચોક્કસ જરૂરિયાતોને અનુરૂપ ગોઠવણો કરો. જો તમે લાંબો ઈતિહાસ ધરાવતી એન્ટરપ્રાઈઝ કંપની છો અને જવાબદારીઓના મોટા ભાર સાથે, જે વર્ષમાં એકવાર પ્રોડક્ટનું વર્ઝન રિલીઝ કરે છે, તો પછી તમે છ મહિનામાં દર કલાકે પ્રોડક્ટના નવા વર્ઝનને રિલીઝ કરવામાં સમર્થ હશો નહીં. તે તે રીતે કામ કરશે નહીં. તેથી, એક વાસ્તવિક ધ્યેય સેટ કરો જે સ્વીકાર્ય સમયમર્યાદામાં પ્રાપ્ત કરી શકાય.

સંબંધિત - સંબંધિત. અમે ફક્ત તે જ પ્રતિબંધોને દૂર કરીએ છીએ જે ખરેખર અમારા વર્તમાન લક્ષ્યોને પૂર્ણ કરે છે.

સમય મર્યાદિત - સમય મર્યાદિત. જો ત્યાં કોઈ સમયમર્યાદા ન હોય, તો ટીમ તેઓ જે ઇચ્છે તે કરશે: 15 ને બદલે 3 તકનીકોનો પ્રયાસ કરો, વિશાળ અહેવાલો લખો, નકામું સંશોધન કરો, જ્યારે લક્ષ્ય પ્રાપ્ત થઈ ગયું હોય ત્યારે તે ચમકે ત્યાં સુધી તેમના અમલીકરણને પોલિશ કરો.

અમે વેલ્યુ સ્ટ્રીમ મેપનો ઉપયોગ કરીને ધ્યેય લઈએ છીએ - અમે બધા લોકોને ફરીથી એકત્રિત કરીએ છીએ અને તેમને દોરીએ છીએ. પરંતુ માત્ર હવે, અગાઉના મૂલ્ય પ્રવાહના નકશાના આધારે, અમે જે મેળવવા માગીએ છીએ તે દોરીએ છીએ.

અમે એક મર્યાદા પ્રકાશિત કરીએ છીએ જેને અમે હમણાં જ દૂર કરીશું - આ તે છે જે ટીમ કરશે. ઉદાહરણ તરીકે, મેં ફિનિશ્ડ રીલીઝથી તેના ઉત્પાદનમાં જમાવટ સુધી રાહ જોવી - આ સૌથી સામાન્ય મર્યાદા છે જેની સાથે લોકો સલાહકારો તરફ વળે છે.

આના આધારે, અમે કાર્ય સેટ કરીએ છીએ: અમે ઇચ્છીએ છીએ કે સમાપ્ત થયેલ પ્રકાશન અને યુદ્ધમાં જવા વચ્ચેનો સમય મહત્તમ એક કલાકનો હોય.

કાર્યોના ઉદાહરણો.

• પરીક્ષણનો લીડ સમય 4 દિવસથી ઘટાડીને 1 કલાક કરો.
• પરીક્ષણ માટેનો મૂલ્ય વર્ધિત સમય 2 દિવસથી ઘટાડીને 3 કલાક કરો.
• જમાવટનો લીડ સમય 5 કલાકથી ઘટાડીને 10 મિનિટ કરો.
• C/A ને 50% થી 95% સુધી વધારો, એટલે કે, પરીક્ષકો સ્વીકારે તેવી સુવિધાઓની સંખ્યામાં વધારો, બીજા શબ્દોમાં કહીએ તો, વિકાસકર્તાઓના કાર્યની ગુણવત્તામાં સુધારો.

કાર્યોના ઉદાહરણો અમારા માથા પરથી લેવામાં આવતા નથી - તે મૂલ્ય પ્રવાહ નકશો વિકસાવતી વખતે અમે કરેલા માપ પર આધારિત છે.

અમે અમારી ટીમ માટે સમાન કાર્ય અને સમય મર્યાદા સેટ કરી છે. તમારી કંપની કેટલી સારી રીતે કામ કરી રહી છે તેના આધારે, તમે અલગ અલગ સમયમર્યાદા સેટ કરો છો. સરેરાશ, સામાન્ય રીતે મર્યાદાને દૂર કરવામાં છ મહિના લાગે છે, જો લોકો આવું પ્રથમ વખત કરી રહ્યા હોય અને હજુ સુધી તેઓ જાણતા ન હોય કે કઈ તકનીકોથી અને કેવી રીતે તેઓ સમસ્યાનું નિરાકરણ લાવશે.

ટૂંકું આયોજન

તેથી, અમારી ટીમ બનાવવામાં આવી છે, તેનો એક ધ્યેય છે, લોકો કામ કરવાનું શરૂ કરે છે. એક મહત્વપૂર્ણ મુદ્દો એ કાર્યનું ટૂંકું આયોજન છે: સ્પ્રિન્ટ એક થી બે અઠવાડિયાઅને વધુ નહીં, માપી શકાય તેવા સુધારા દર અઠવાડિયે અને કોર્સ કરેક્શન.

ઉદાહરણ તરીકે, અમે ઘણીવાર અભિગમનો ઉપયોગ કરીએ છીએ હલનચલનજ્યારે આખી ટીમ દરેક સપ્તાહની શરૂઆતમાં એકત્ર થાય છે, ત્યારે તેઓ એક ફાઇલમાં લખે છે કે દરેક શું કરશે. એક અઠવાડિયા પછી, અમે નોંધ કરીએ છીએ કે શું કરવામાં આવ્યું છે અને શું નથી, જો નહીં, તો શા માટે, અને અમે આગળ શું કરવું તે વિશે વિચારીએ છીએ.

સ્પ્રિન્ટ્સ તમને સમયસર કોર્સ સુધારણા કરવા દે છે.

એક કે બે અઠવાડિયા સુધી તમે કંઈક અજમાવ્યું: તકનીકો, અભિગમો, કાર્ય કરવાની રીતો, તે પછી તમે ફરીથી માપો અને જુઓ - શું આ અભિગમ સાથે તે વધુ સારું કે ખરાબ બન્યું છે? જો તે વધુ ખરાબ છે, તો તેનો અર્થ એ છે કે આપણે ખોટી દિશામાં જઈ રહ્યા છીએ, અમારે કોર્સ સુધારવાની જરૂર છે: એક અલગ કાર્ય સેટ કરો, એક અલગ તકનીક લો અથવા કંઈક બીજું કરો. 1-2 અઠવાડિયાના ટૂંકા સ્પ્રિન્ટ્સ તમને દાવપેચ કરવા અને સમયસર ખરાબ નિર્ણયો ટાળવા દે છે.

શેરિંગ સફળતા

ટીમ થોડી સફળતા પ્રાપ્ત કરે છે, નાની કે મોટી - તેનાથી કોઈ ફરક પડતો નથી, હંમેશા કંઈક પરિણામ આવે છે. દરેક વ્યક્તિએ આ પરિણામ વિશે જાણવું જોઈએ: DevOps અને પડોશી વિભાગો સાથે સંકળાયેલા બંને. એક આદર્શ વિશ્વમાં, આ બધાનું આગમન થાય તે ઇચ્છનીય હશે કંપનીના તમામ લોકોને.

શેના માટે? જો આપણે ફક્ત કંપનીના ભાગને જ નહીં, માત્ર એક મર્યાદાને જ નહીં, પરંતુ સામાન્ય રીતે દરેક વસ્તુને દૂર કરવા માગીએ છીએ, જેથી કંપની લવચીક બને, કોડ ઝડપથી ક્લાયન્ટ સુધી પહોંચે, અને કંઈ તૂટતું ન હોય, તો અમારે દરેક વ્યક્તિએ વિચાર પ્રત્યે વફાદાર રહેવાની જરૂર છે. DevOps ના. તમે સેવાઓ અને ટીમો માટે અભિગમ લાગુ કરી શકશો નહીં જે તેની વિરુદ્ધ છે.

વફાદારી દેખાય તે માટે, આપણે દરેકને કહેવું જોઈએ કે અમે આ પ્રયાસ કર્યો - અમારી પાસે પરિણામ છે, તે પણ અજમાવી જુઓ! આનાથી આપણે જે કરીએ છીએ તેમાં રસ અને વફાદારી વધશે, લોકો હમણાં જ કંઈક કરવાનો પ્રયાસ શરૂ કરશે. પ્રેક્ટિસ બતાવે છે તેમ, જ્યારે અમે તમને કહીએ છીએ કે અમે શું પ્રયાસ કર્યો અને અમે શું હાંસલ કર્યું, ત્યારે અન્ય ટીમો પૂછવા લાગે છે કે અમે કેવી રીતે અને શું કર્યું. તેઓ અમલીકરણ, કોડ, દસ્તાવેજીકરણ જુએ છે, પ્રશ્નો સાથે આવે છે અને પોતાને કંઈક બદલવાનો પ્રયાસ કરે છે.

તમે શું કર્યું તે વિશે વાત કરવી મહત્વપૂર્ણ છે. આ રીતે તમે રૂઢિચુસ્તોને મનાવી શકશો કે જેઓ તમારી શિબિરમાં જોડાવા અને તેમને નવીનતાઓમાં પરિવર્તિત કરવા માટે જૂની રીતે બધું કરવા માંગતા હતા.

કુલ

સેવા પસંદ કરી રહ્યા છીએ, પ્રારંભિક બિંદુ તરીકે - તે સ્થાન જ્યાં અમે કંપનીમાં ફેરફારો શરૂ કરીશું. અમે દરેક વ્યક્તિને ઓળખીએ છીએ જેમને સેવા સાથે કોઈ લેવાદેવા છે અને તેમની સાથે મૂલ્ય પ્રવાહનો નકશો બનાવવો, અમે માપીએ છીએ અને જોઈએ છીએ કે ક્યાં અને શું મર્યાદાઓ છે.

નવી કામચલાઉ ટીમ બનાવી રહી છે, જે સમસ્યા હલ કરશે. માપ અને મૂલ્ય પ્રવાહના નકશા પર આધારિત અમે એક નવો નકશો દોરીએ છીએ, જ્યાં અમે મર્યાદાને પ્રકાશિત કરીએ છીએ જે અમે હલ કરીશું. આ મર્યાદાના આધારે એક કાર્ય સેટ કરો, જેની સાથે ટીમ ડીલ કરશે. કાર્ય હોવું જોઈએ જરૂરી SMART - ચોક્કસ, માપી શકાય તેવું, વર્તમાન કાર્યો સાથે સંબંધિત અને સમય મર્યાદિત.

પ્રક્રિયાને પુનરાવર્તિત કરો, જ્યાં સુધી અમે અમારી બધી સેવાઓને જરૂરી સ્વરૂપમાં સંપૂર્ણપણે રૂપાંતરિત ન કરીએ અને તમામ પ્રતિબંધો દૂર કરીએ.

બોનસ. ઉપયોગી સામગ્રી

જેઓ તેમના પોતાના પર DevOps કરવાનું નક્કી કરે છે તેમના માટે.

ફોનિક્સ પ્રોજેક્ટ

મૂળ શીર્ષક છે “ધી ફોનિક્સ પ્રોજેક્ટ: એ નોવેલ અબાઉટ ઇટ, ડેવોપ્સ અને હેલ્પિંગ યોર બિઝનેસ જીત.” આ DevOps વિશેની નવલકથા છે - કેવી રીતે એક કર્મચારીને એવા વિભાગના વડા બનાવવામાં આવ્યા હતા જે હંમેશા આગમાં રહે છે. નવા બોસને કાર્ય આપવામાં આવ્યું હતું:

"તમારી પાસે બધું બરાબર કરવા માટે થોડા વર્ષો છે જેથી કરીને અમે અમારા ગ્રાહકોને અમારા ઉત્પાદનને ઝડપથી અને અસરકારક રીતે પહોંચાડી શકીએ."

"પ્રોજેક્ટ ફોનિક્સ" DevOps જીવનને વધુ સારા માટે કેવી રીતે બદલી નાખે છે તે વિશેની નવલકથા” બધા મેનેજરો માટે એક પુસ્તક છે, કારણ કે આ તે લોકો છે જેઓ કંપનીમાં શું થાય છે તે અંગે નિર્ણય લે છે. જો તમે એન્જિનિયર અથવા પ્રોગ્રામર છો અને તમારી કંપનીમાં ચળવળ અને પરિવર્તનની શરૂઆત કરવા માંગો છો, તો એક પુસ્તક ખરીદો અને મેનેજમેન્ટને આપો. આ નવલકથા બધું સમજાવે છે અને તે ઝડપી અને સરળ વાંચન છે.

DevOps માર્ગદર્શિકા

પુસ્તક વધુ જટિલ છે. તે ઘણા વર્ષો પહેલા અંગ્રેજીમાં “The DevOps હેન્ડબુક હાઉ ટુ ક્રિએટ વર્લ્ડ-ક્લાસ ચપળતા, ટેક્નોલોજી સંસ્થાઓમાં વિશ્વસનીયતા અને સુરક્ષા” શીર્ષક હેઠળ પ્રકાશિત કરવામાં આવી હતી, પરંતુ હવે તે પહેલેથી જ રશિયનમાં ઉપલબ્ધ છે. આ સાચું છે હેન્ડબુક - વ્યવહારુ માર્ગદર્શિકા: માપન કેવી રીતે કરવું, મૂલ્ય પ્રવાહ નકશો શું છે અને શા માટે તેની જરૂર છે, ક્યાં જવું, કયા ક્રમમાં. પુસ્તક ફક્ત તે લોકો માટે છે જેઓ બધું જાતે કરવા માંગે છે. સૌથી અગત્યનું, તેમાં અન્ય કંપનીઓના અનુભવોના ઉદાહરણો છે.

ઉદાહરણ તરીકે, તે જણાવે છે કે કેવી રીતે એક કંપનીએ વેલ્યુ સ્ટ્રીમ મેપ બનાવ્યો અને સમજાયું કે તેની મર્યાદા ઉત્પાદનમાં નથી, પરંતુ હકીકત એ છે કે કેશિયર આ ઉત્પાદનનો ઉપયોગ કરવા માટે સ્ટોરમાંથી આગલી ઓફિસમાં ચાલ્યો ગયો. પ્રોગ્રામ સાથે સમસ્યા હલ કરવાને બદલે, તેઓએ ફક્ત તેમના વેચાણકર્તાઓ માટે ગોળીઓ ખરીદી, અને હવે કોઈ ક્યાંય જતું નથી, અને બધી ક્રિયાઓ તેમના કાર્યસ્થળ પર કરવામાં આવે છે. નિષ્કર્ષ: વેલ્યુ સ્ટ્રીમ મેપને માત્ર સોફ્ટવેર સુધી જ નહીં, પરંતુ સંસ્થાની તમામ પ્રક્રિયાઓ માટે પણ વિસ્તૃત કરી શકાય છે.

વેગ

સંપૂર્ણ શીર્ષક: "વેગ કરો: લીન સોફ્ટવેર અને ડેવઓપ્સનું વિજ્ઞાન: બિલ્ડીંગ અને સ્કેલિંગ હાઇ પરફોર્મિંગ ટેક્નોલોજી સંસ્થાઓ." આ આગલું સ્તર છે - હાર્ડકોર. પુસ્તક ગયા વર્ષે પ્રકાશિત થયું હતું, અત્યાર સુધી માત્ર અંગ્રેજીમાં અને તે સંશોધન વિશે છે. લેખકો-નિકોલ ફોર્સગ્રેન, જેઝ હમ્બલ અને જીન કિમ-ઘણા વર્ષોથી જુદી જુદી કંપનીઓમાં વિવિધ પ્રેક્ટિસનો ઉપયોગ કરી રહ્યાં છે અને સંશોધન કરી રહ્યાં છે કે કઈ પદ્ધતિઓ શું અને કેવી રીતે અસર કરે છે.

બીજું પ્રકરણ, માપન પર, મૂલ્ય પ્રવાહના નકશા, મેં ઉલ્લેખિત મેટ્રિક્સ અને અન્ય ઘણાનો ઉલ્લેખ કરે છે, અને માપન પ્રક્રિયાનું વિગતવાર વર્ણન પણ કરે છે. લેખકો પ્રશ્નાવલિ અને સ્વ-ટ્રેકિંગ કાર્યોનો ઉપયોગ કરીને માપન કરે છે. તે વિગતવાર વર્ણન કરે છે કે કયા મેટ્રિક્સ માપવા યોગ્ય છે, કયા માપવા જોઈએ નહીં અને માપમાં માનવીય ભૂલો. જો તમને માપન સાથે મુશ્કેલીઓ હોય, તો પુસ્તક "વેગ કરો" ના બીજા પ્રકરણનો સંદર્ભ લો. જો તમારી ટીમ પાસે ઘણી બધી પ્રેક્ટિસ છે, પરંતુ તે સ્પષ્ટ નથી કે કઈ પદ્ધતિઓ હવે લાગુ કરવી, કઈ પછીથી, કઈ ખરેખર કામ કરે છે અને કઈ નથી - વાંચો, પુસ્તક બધું સમજાવે છે.

ટ્રાન્સફોર્મેશન એ DevOps અને મેનેજમેન્ટના આંતરછેદ પરનો મુદ્દો છે. વિકાસના આંતરછેદના સમાન ક્ષેત્રમાં ક્યાંક, ઓપરેશન્સ અને ટેસ્ટિંગ એવા વિષયો છે કે જેના પર આપણે ચર્ચા કરવાનો પ્રયાસ કરીએ છીએ. DevOpsConf, ગુણવત્તાયુક્ત ઉત્પાદન બનાવવા માટે સમાન એકીકરણની જરૂર છે - મુખ્ય વિષય QualityConf. ફેસ્ટિવલ મેનેજમેન્ટ RIT++ પ્રસ્તુત વ્હેલ રાઇડર - તેનો અર્થ એ છે કે દરેક વ્યક્તિ પરિવર્તન માટેના વિચારો માટે છે. 27 અને 28 મેના રોજ અમારી સાથે જોડાઓ, અમે એકીકૃત થઈશું અને પરિવર્તન કરીશું.

સોર્સ: www.habr.com