DevOps പരിവർത്തനം എങ്ങനെ ആരംഭിക്കാം

DevOps എന്താണെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകുന്നില്ലെങ്കിൽ, ഒരു ദ്രുത ചീറ്റ് ഷീറ്റ് ഇതാ. DevOps എന്നത് ഒരു കൂട്ടം സമ്പ്രദായങ്ങളാണ് എഞ്ചിനീയർമാരുടെ ഭയം കുറയ്ക്കുന്നു സോഫ്റ്റ്‌വെയർ നിർമ്മാണത്തിലെ പരാജയങ്ങളുടെ എണ്ണം കുറയ്ക്കുക. ചട്ടം പോലെ, അവ സമാനമാണ് മാർക്കറ്റിലേക്കുള്ള സമയം കുറയ്ക്കുക - ആശയം മുതൽ അന്തിമ ഉൽപ്പന്നം ഉപഭോക്താക്കൾക്ക് കൈമാറുന്നത് വരെയുള്ള കാലയളവ്, ഇത് വേഗത്തിൽ നടപ്പിലാക്കാൻ അനുവദിക്കുന്നു ബിസിനസ്സ് പരീക്ഷണങ്ങൾ.

DevOps പരിവർത്തനം എങ്ങനെ ആരംഭിക്കാം? ചുരുക്കത്തിൽ: പ്രോസസ്സ് ആരംഭിക്കേണ്ട സേവനം ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്നു, സേവനവുമായി ബന്ധപ്പെട്ടവരെ തിരിച്ചറിയുക, ഒരു മൂല്യ സ്ട്രീം മാപ്പ് നിർമ്മിക്കുക, ആദ്യമായി പരിവർത്തനം കൈകാര്യം ചെയ്യുന്ന ഒരു താൽക്കാലിക ടീമിനെ സൃഷ്ടിക്കുകയും അതിനായി ഒരു ടാസ്ക് സജ്ജമാക്കുകയും ചെയ്യുന്നു. ആവശ്യമായ തവണ ഞങ്ങൾ സൈക്കിൾ ആവർത്തിക്കുന്നു.

കട്ടിന് കീഴിലുള്ള ഉദാഹരണങ്ങളും നിർദ്ദേശങ്ങളും അടങ്ങിയ വിശദമായ DevOps ട്രാൻസ്ഫോർമേഷൻ പ്ലാൻ - ട്രാൻസ്ക്രിപ്റ്റിൽ റിപ്പോർട്ട് ആൻഡ്രി അലക്സാണ്ട്രോവ് - Express42-ലെ ഒരു എഞ്ചിനീയർ, DevOps മുളയ്ക്കുന്നതിന് ഉപദേശം നൽകുന്നു, അവൾ ഇതിനകം ഒരു റേക്ക് മാപ്പ് നിർമ്മിച്ചതിനാൽ ഈ പ്രക്രിയ വേഗത്തിലാക്കുന്നു. നിങ്ങൾക്ക് പരിവർത്തനം ആവശ്യമില്ലെന്ന് തോന്നുന്നുവെങ്കിൽ, അല്ലെങ്കിൽ നിങ്ങളുടെ പ്രത്യേകതകൾ DevOps രീതികൾ അനുയോജ്യമല്ലെങ്കിൽ, പരിമിതികൾ കണ്ടെത്തുന്നതിനും ഇല്ലാതാക്കുന്നതിനുമുള്ള നിർദ്ദേശങ്ങളായി റിപ്പോർട്ട് ഉപയോഗിക്കുക.

DevOps പരിവർത്തനത്തിൻ്റെ പ്രശ്നത്തെക്കുറിച്ച് നിങ്ങൾക്ക് ആശങ്കയുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഒരു വലിയ കമ്പനിയുണ്ട്, കൂടാതെ മുഴുവൻ ഘടനയിലുടനീളം ഈ പ്രക്രിയ ക്രമേണ സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്. കമാൻഡ് പരിവർത്തനം ചെയ്യേണ്ടതോ ചില പരിമിതികൾ ഇല്ലാതാക്കുന്നതോ ഉള്ളിടത്തോളം, ചുവടെയുള്ള അൽഗോരിതം ആവർത്തിക്കാം.

ഒരു സേവനം തിരഞ്ഞെടുക്കുന്നു

ഞങ്ങൾ ഒരു പദ്ധതിയുടെ രൂപരേഖ തയ്യാറാക്കിയിട്ടുണ്ട്, ആദ്യ ഘട്ടത്തിൽ നിന്ന് ആരംഭിക്കാം - ഒരു സേവനം തിരഞ്ഞെടുക്കൽ. ആദ്യത്തെ മാനദണ്ഡം ജീവിതകാലം: പഴയ സേവനങ്ങളുണ്ട് - പാരമ്പര്യവും പുതിയവയും. രണ്ടിലും തുടങ്ങാം.

ഒരു യുവ സേവനം തിരഞ്ഞെടുക്കുന്നത് യുക്തിസഹമാണ്. ഇത് പുതിയതാണ്, അത് കൈകാര്യം ചെയ്യുന്ന ടീമിൽ പ്രവർത്തിക്കുന്നതിന് ഇതുവരെ ഒരു സ്ഥാപിത പ്രക്രിയ ഇല്ല. അതിന് ചുറ്റും സാങ്കേതിക കടത്തിൻ്റെ പർവതമില്ല, നിങ്ങൾ അത് എല്ലായ്പ്പോഴും പരിഹരിക്കേണ്ടതില്ല. അത് കൊണ്ട് നമുക്ക് എന്ത് വേണമെങ്കിലും ചെയ്യാം.

പഴയ സേവനത്തിൻ്റെ കാര്യത്തിൽ, വസ്തുതയുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങളുണ്ട് മാറ്റം എപ്പോഴും ബുദ്ധിമുട്ടാണ്. ഇതിനകം തന്നെ ചില ഗുരുതരമായ നിയന്ത്രണങ്ങൾ ഉണ്ട്, പക്ഷേ ഒരുപക്ഷേ എല്ലാം കോരിയെടുക്കാൻ തയ്യാറായ ആളുകളാണ് അവ കൈകാര്യം ചെയ്യുന്നത് - അവർ ക്ഷീണിതരും വേദനയുള്ളതിനാൽ വ്യത്യസ്തമായി എന്തെങ്കിലും ചെയ്യാൻ ആഗ്രഹിക്കുന്നു.

ഒരു പഴയ സേവനത്തിൽ പ്രവർത്തിക്കുന്നത് ശക്തമായ ഒരു മാതൃകയാണ് നിങ്ങളുടെ കമ്പനിയിൽ - നിങ്ങൾക്ക് എന്തെങ്കിലും മാറ്റാൻ കഴിയും. നിങ്ങൾ ഒരു പുതിയ സേവനം മാറ്റുകയാണെങ്കിൽ, അത് മണിക്കൂറിൽ 100 ​​തവണ കുറയുന്നു, എല്ലാം ശരിയാണ്, അപ്പോൾ നിങ്ങളുടെ കമ്പനിയിലെ ആളുകൾ ഇങ്ങനെ പറഞ്ഞേക്കാം:

- ഇതൊരു പുതിയ സേവനമാണ്! അവിടെ എല്ലാം ലളിതമായിരുന്നു, ഞങ്ങളുടെ തകരാർ ഉപയോഗിച്ച് എന്തെങ്കിലും ചെയ്യാൻ ശ്രമിക്കുക.

നിങ്ങൾ ആരെങ്കിലുമായി ചെയ്യുമ്പോൾ പരിവർത്തനത്തിനായി ലെഗസി സേവനം ഉപയോഗിക്കുന്നതിൽ അർത്ഥമുണ്ട്, ഉദാഹരണത്തിന്, നിങ്ങൾ ഒരു ബാഹ്യ കൺസൾട്ടൻ്റിനെ ക്ഷണിച്ചാൽ. നമുക്ക് സത്യസന്ധത പുലർത്താം, പരിവർത്തനം സാധ്യമായ എല്ലാറ്റിനെയും ഇളക്കും. നിങ്ങൾ പരീക്ഷണം നടത്തുകയാണ്, നിങ്ങൾ എവിടെയാണ് അവസാനിക്കുക, എന്ത് സാങ്കേതികവിദ്യകൾ ഉപയോഗിക്കും, എന്തുകൊണ്ട്, എവിടെ, എന്തൊക്കെ അപകടങ്ങൾ പ്രക്രിയകളിൽ ഉണ്ടാകുമെന്ന് അറിയില്ല. അതിനാൽ, പുതിയത് മാറ്റുന്നത് എളുപ്പമാണ്.

നിങ്ങൾ എല്ലാം സ്വയം ചെയ്യുകയാണെങ്കിൽ, കമ്പനിക്ക് ഗുരുതരമായ കഴിവ് ഇല്ലെങ്കിൽ, ഞങ്ങൾ ഒരു പുതിയ സേവനം സ്വീകരിക്കുന്നു. നിങ്ങൾക്ക് ഒരു ബാഹ്യ കൺസൾട്ടൻ്റിനെ അറിയുകയും ഫണ്ടുകൾ ഉണ്ടെങ്കിൽ, പഴയത് തിരഞ്ഞെടുക്കുക.

ഉപയോക്താക്കൾക്കുള്ള ഒരു ഇൻ്റർഫേസ് ആയ സേവനങ്ങളുണ്ട്, ഉദാഹരണത്തിന്, ഒരു ലളിതമായ വെബ്സൈറ്റ് അല്ലെങ്കിൽ മൊബൈൽ ആപ്ലിക്കേഷൻ. എന്നാൽ ബില്ലിംഗിൻ്റെ ആത്മാവിൽ ഗുരുതരമായ കാര്യങ്ങളുണ്ട്. ബില്ലിംഗിൽ എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ, അത് കണ്ടെത്തുന്നത് ബുദ്ധിമുട്ടായിരിക്കും. ഇവിടെ നമുക്കും ഒരു തിരഞ്ഞെടുപ്പുണ്ട്.

ഞങ്ങൾ ഒന്നുകിൽ പ്രവർത്തിക്കുന്നു നിർണായക സേവനത്തോടൊപ്പം, എന്നാൽ ഞങ്ങൾ അത് കാരണം കഷ്ടപ്പെടുന്നു, അത് നിയന്ത്രണങ്ങൾ സൃഷ്ടിക്കുന്നു, അല്ലെങ്കിൽ ഞങ്ങൾ പ്രവർത്തിക്കുന്നു ഇൻ്റർഫേസ് ഉപയോഗിച്ച്. ഇതാണ് രണ്ടാമത്തെ തിരഞ്ഞെടുപ്പ് മാനദണ്ഡം. അതുപോലെ, പരിചയസമ്പന്നനായ ഒരു കൺസൾട്ടൻ്റിനെ ആകർഷിക്കാൻ കഴിയും - ഞങ്ങൾ ബുദ്ധിമുട്ടുള്ള ഓപ്ഷനുമായി പ്രവർത്തിക്കുന്നു.

എന്നാൽ ഈ സാഹചര്യത്തിൽ പോലും, ഇത് ചെയ്യാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നില്ല, കാരണം എന്തിനൊപ്പം പ്രവർത്തിക്കണം, ഏത് ദിശയിലേക്ക് പരിവർത്തനം ചെയ്യണം എന്നതിനെക്കുറിച്ച് ഒരു ധാരണ ഉണ്ടാകുന്നതുവരെ, ഒരു നിർണായക കാര്യം എടുത്ത് കുലുക്കുന്നത് വളരെ നല്ല ആശയമല്ല. അതിനാൽ, ഈ സാഹചര്യത്തിൽ, പരാജയം നിർണായകമല്ലാത്ത ഒരു ഇൻ്റർഫേസുമായി പ്രവർത്തിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

നമുക്ക് കൂടുതൽ നോക്കാം സേവന സംഘം. ഈ സേവനം നൽകുന്നവരുമായി ഞങ്ങൾ നിരന്തരം പ്രവർത്തിക്കുകയും വളരെ അടുത്ത് ഇടപഴകുകയും വേണം.

ടീമിലെ ആളുകളെ രണ്ട് വിഭാഗങ്ങളായി തിരിച്ചിരിക്കുന്നു: യാഥാസ്ഥിതികർ - പഴയ ലോകത്ത് ജീവിക്കുക, അല്ലെങ്കിൽ DevOps-നെ കുറിച്ച് ഒന്നും അറിയില്ല, കൂടാതെ പുതുമയുള്ളവർ, എല്ലാ ഫാഷനബിൾ സമ്പ്രദായങ്ങളും വലിച്ചിടുന്നു. രണ്ടാമത്തേത് എല്ലായ്പ്പോഴും വിഷയം മനസ്സിലാക്കുന്നില്ല, പക്ഷേ കുറഞ്ഞത് അവർ അതിന് തയ്യാറാണ്.

ഒരു വശത്ത്, യാഥാസ്ഥിതികർ പരിചയസമ്പന്നരായ ആളുകളാണ്: അവർ വളരെക്കാലമായി കമ്പനിയിലാണ്, അവർ അത് അകത്തും പുറത്തും മനസ്സിലാക്കുന്നു, പക്ഷേ അവർക്ക് സമ്പ്രദായങ്ങളെക്കുറിച്ച് കൃത്യമായി അറിയില്ല. മറുവശത്ത്, എന്തെങ്കിലും കേട്ടിട്ടുള്ള പുതുമയുള്ളവരുണ്ട്, പക്ഷേ മിക്കവാറും കമ്പനിയിൽ വളരെക്കാലമായി ജോലി ചെയ്തിട്ടില്ല. ഏതാണ് പ്രവർത്തിക്കാൻ നല്ലത്?

ഏത് സാഹചര്യത്തിലും നിങ്ങൾ യാഥാസ്ഥിതികരുമായി സംവദിക്കേണ്ടിവരും, കാരണം ഇത് അവരുടെ സേവനമാണ്. നിങ്ങൾ അവരുമായി ആശയവിനിമയം നടത്തണം, സേവനത്തിൻ്റെ പ്രത്യേകതകൾ കണ്ടെത്തണം, ഈ രീതിയിൽ എന്തുചെയ്യാൻ കഴിയും, മറ്റെന്താണ്. ഞങ്ങൾ അവരുടെ ഉപദേശത്തെ ആശ്രയിച്ചിരിക്കുന്നു. ഒരുപക്ഷേ നിങ്ങൾ അവരെ എന്തെങ്കിലും ഏൽപ്പിക്കേണ്ടിവരും, കാരണം അവർക്ക് അവരുടെ സേവനം നന്നായി അറിയാം. അതിനാൽ, ഏത് ടീമുമായാണ് ഞങ്ങൾ ബന്ധപ്പെടുന്നത് എന്നത് പ്രധാനമാണ്.

ടീമിനായി പുതുമയുള്ളവരെ തിരഞ്ഞെടുക്കുന്നത് യുക്തിസഹമാണ്, കാരണം യാഥാസ്ഥിതികർക്ക് അതിൽ ഒരു പന്നി ഇടാം.

പ്രായോഗികമായി, യാഥാസ്ഥിതികരായ ആളുകൾക്ക് കാര്യമായ അനുഭവം ഉണ്ടെന്ന് പലപ്പോഴും സംഭവിക്കുന്നു, പക്ഷേ എങ്ങനെ കൂടുതൽ ജീവിക്കണം എന്നതിനെക്കുറിച്ച് ഒരു ധാരണയില്ല. സേവനത്തിൻ്റെ പരിവർത്തനത്തിനും പുനർരൂപകൽപ്പനയ്ക്കും ശേഷം, അവരെ അനാവശ്യമായി പുറത്താക്കുമെന്ന് അവർ ഭയപ്പെടുന്നു. ചിലപ്പോൾ, എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസ്സിലാകാത്തതിനാൽ, അവർ ജോലി അട്ടിമറിക്കുന്നു.

ടീമിലെ ഒരാൾ എല്ലാം നന്നാക്കിയ ഒരു കേസ് എനിക്കുണ്ടായിരുന്നു, കാരണം ഞങ്ങൾ ഇപ്പോൾ ചെയ്യുന്നതിനേക്കാൾ അത് കൂടുതൽ നിർണായകമാണ്. ഞങ്ങൾ ചുമതല സജ്ജമാക്കി: ഇന്ന് ഈ കഷണം നടപ്പിലാക്കാൻ - ഇല്ല, ലോകത്തിൻ്റെ മറുവശത്ത് ഒരു തീയുണ്ട്, ഞങ്ങൾ അത് പരിഹരിക്കാൻ പോകുന്നു. ഇത്തരക്കാരുടെ കൂടെ ജോലി ചെയ്യാൻ ബുദ്ധിമുട്ടാണ്.

യാഥാസ്ഥിതിക ടീമിൽ നിന്നുള്ള ആളുകൾ പലപ്പോഴും ടാസ്ക്കുകൾ മറക്കുകയോ അവസാന നിമിഷം വരെ മാറ്റിവയ്ക്കുകയോ ചെയ്യും. ജോൺ വില്ലിസ് വിലക്കുകയാണെങ്കിൽ, നിങ്ങൾ ഒരു തെറ്റ് ചെയ്യുകയും പൂർത്തിയാക്കിയ ടാസ്ക്കുകളുടെ എണ്ണത്തിന് അവർക്ക് ഒരു കെപിഐ നൽകുകയും ചെയ്തു, ചില കാരണങ്ങളാൽ കെപിഐയിൽ ചില ഭാഗങ്ങൾ ഉൾപ്പെടുത്തിയിട്ടില്ലെങ്കിൽ, അവർ ഒന്നും ചെയ്യില്ല. പൊതുവേ, അവർ ശരിയായിരിക്കും, കാരണം അവർക്ക് ബോണസ് നഷ്ടപ്പെടും.

പുതുമയുള്ളവരിൽ ഇത് എളുപ്പമാണ് - അവർ കൂടുതൽ വിശ്വസ്തരാണ്. അവർ ഇതിനകം എന്തെങ്കിലും കേട്ടിട്ടുണ്ട്, അവർ എവിടെയെങ്കിലും പോകാൻ ആഗ്രഹിക്കുന്നു, അതിനാൽ അവർ സഹായിക്കും. ആദ്യമായി കഷ്ടപ്പെടാൻ തയ്യാറായ ആളുകളെ ഞങ്ങൾക്ക് ആവശ്യമുണ്ട്: സേവനം മാറുകയാണെങ്കിൽ, പുതുമയുള്ളവർ എല്ലാ ബമ്പുകളും റേക്കുകളും പയനിയർമാരായി പിടിക്കും. പുതുമയുള്ളവർ എല്ലാം പുതിയതും ഫാഷനും ആഗ്രഹിക്കുന്നു, കഷ്ടപ്പെടുന്നു.

യാഥാസ്ഥിതികരെ പിന്നീട് പരിവർത്തനം ചെയ്യാം. നിങ്ങൾ ഒരു കഷണം മാറ്റി, എല്ലാം നന്നായി പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കുമ്പോൾ, മിക്കവാറും അവരും അത് പരീക്ഷിക്കാൻ ആഗ്രഹിക്കുകയും പുതിയ DevOps മതം സ്വീകരിക്കുകയും ചെയ്യും.

നമുക്ക് സംഗ്രഹിക്കാം. ഞങ്ങളുടെ കമ്പനിയിലെ മുഴുവൻ പരിവർത്തനവും ഞങ്ങൾ സ്വയം ചെയ്യുകയാണെങ്കിൽ, ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്നു: ഒരു പുതിയ സേവനം, വെയിലത്ത് ഒരു ലളിതമായ ഇൻ്റർഫേസ്, അതിൻ്റെ തകർച്ചയിൽ നിന്ന് വളരെയധികം കഷ്ടപ്പെടാതിരിക്കാൻ, ഒപ്പം പുതുമയുള്ള ഒരു ടീമും.

ഒരു ബാഹ്യ കൺസൾട്ടൻ്റിനെ വിളിക്കാൻ കഴിയുമെങ്കിൽ, പുതിയതൊന്ന് പകരം, ഞങ്ങൾ പഴയ സേവനം എടുക്കുന്നു, അതിനാലാണ് ഞങ്ങൾ ഇതിനകം കഷ്ടപ്പെടുന്നത്. വ്യത്യസ്ത കമ്പനികളിൽ ദീർഘകാലമായി പരിവർത്തനത്തിൽ ഏർപ്പെട്ടിരിക്കുന്ന ആളുകൾ വ്യത്യസ്ത കേസുകൾ കണ്ടു, അത് എങ്ങനെ ശരിയായി ചെയ്യണമെന്ന് ഇതിനകം മനസ്സിലാക്കിയിട്ടുണ്ട്, പൊതുവായി ഏത് ദിശയിലേക്ക് പോകണം.

ആരാണ് ഉൾപ്പെട്ടിരിക്കുന്നത്?

സേവനവുമായി എന്തെങ്കിലും ബന്ധമെങ്കിലും ഉള്ള എല്ലാവരെയും ഞങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ട്: ഡെവലപ്പർമാർ, ടെസ്റ്റർമാർ, അഡ്മിനുകൾ, സുരക്ഷാ വിദഗ്ധർ, മാനേജർമാർ, ഒരുപക്ഷേ, ഉൽപ്പന്ന ഉടമകൾ. ഉൽപ്പന്ന ഉടമകൾ സാങ്കേതിക വിദഗ്ധരല്ല എന്ന വസ്തുത ഉണ്ടായിരുന്നിട്ടും, അവർ സേവനവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു: അവർ തീരുമാനങ്ങൾ എടുക്കുന്നു, ചുമതലകൾ സജ്ജമാക്കുന്നു.

ചില തീരുമാനങ്ങളെങ്കിലും എടുക്കുകയും സേവനത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് സ്വാധീനിക്കുകയും ചെയ്യുന്ന എല്ലാവരെയും കണ്ടെത്തുകയും കണ്ടുമുട്ടുകയും ആശയവിനിമയം നടത്തുകയും വേണം.

നമുക്ക് അവരെ എന്താണ് വേണ്ടത്? ആരുമായി ചർച്ച നടത്തണം എന്നറിയാൻ. പരിവർത്തന സമയത്ത്, സേവനവുമായി പ്രവർത്തിക്കുന്നതിനുള്ള സാധാരണ തത്വം മാറുമ്പോൾ, അത് ഇപ്പോഴും കുലുങ്ങും. ഞങ്ങൾ പുതിയ സമീപനങ്ങൾ പരീക്ഷിക്കുമ്പോൾ കുറച്ച് സമയത്തേക്ക് തകരാറുകൾ ഉണ്ടാകും. ജനങ്ങൾ ഇതിന് തയ്യാറാകുകയും അംഗീകരിക്കുകയും വേണം.

അടുത്തതായി നിങ്ങൾ ഒരു മൂല്യ സ്ട്രീം മാപ്പ് നിർമ്മിക്കേണ്ടതുണ്ട്, ഈ ആളുകളില്ലാതെ നിങ്ങൾക്ക് അത് നിർമ്മിക്കാൻ കഴിയില്ല, കാരണം എന്താണ് സംഭവിക്കുന്നതെന്നതിൻ്റെ പൂർണ്ണ ചിത്രം അവർക്കെല്ലാം ഒന്നിച്ച് മാത്രമേ അറിയൂ. സേവനത്തിൽ സംഭവിക്കുന്നതെല്ലാം ഒരു വ്യക്തിക്ക് ഒരിക്കലും അറിയില്ല.

അവർ ടീമിനായി ആളുകളെ ശുപാർശ ചെയ്യും, എന്തുകൊണ്ടാണ് ഒരു പ്രത്യേക ടീം ആവശ്യമെന്ന് ഞങ്ങൾ പിന്നീട് ചർച്ച ചെയ്യും. നിലവിലുള്ള വകുപ്പുകളിൽ നിന്ന് ആളുകളെ എടുക്കേണ്ടിവരും. സേവനത്തിൽ ഏർപ്പെട്ടിരിക്കുന്നവർക്ക് നമ്മുടെ ദിശയിൽ ചിന്തിക്കുന്ന, ഞങ്ങളെ സഹായിക്കാൻ കഴിയുന്ന, ഞങ്ങൾക്ക് ആവശ്യമുള്ളതിൽ കഴിവുള്ള സഹപ്രവർത്തകരെ ശുപാർശ ചെയ്യാൻ കഴിയും.

അടുത്തതായി, വ്യത്യസ്ത ഡിപ്പാർട്ട്‌മെൻ്റുകളിൽ നിന്നുള്ള എല്ലാ ആളുകളെയും ഞങ്ങൾ ഒരു മുറിയിലേക്ക് കൂട്ടിച്ചേർത്ത് ഒരു മൂല്യ സ്ട്രീം മാപ്പ് നിർമ്മിക്കാൻ തുടങ്ങുന്നു.

ഒരു മൂല്യ സ്ട്രീം മാപ്പ് നിർമ്മിക്കുന്നു

ക്ലയൻ്റിലേക്കുള്ള മൂല്യങ്ങളുടെ ഒഴുക്ക് കാണിക്കുന്ന ഒരു ഡയഗ്രം അല്ലെങ്കിൽ മാപ്പ് ആണ് മൂല്യ സ്ട്രീം മാപ്പ്. എല്ലാ ഇൻ്റർമീഡിയറ്റ് ഘട്ടങ്ങളും മൂല്യം ആത്യന്തികമായി ഞങ്ങളുടെ ക്ലയൻ്റുകളിലേക്ക് എങ്ങനെ ലഭിക്കുന്നു എന്നതുൾപ്പെടെ, ഒരു ആശയം കൊണ്ടുവരുന്നത് മുതൽ അതിൻ്റെ നടപ്പാക്കൽ വരെയുള്ള മുഴുവൻ പ്രക്രിയയും ഇതാണ്.

മൂല്യ സ്ട്രീം മാപ്പ് ആവശ്യമാണ് വികസനത്തിൻ്റെ എല്ലാ ഘട്ടങ്ങളും ദൃശ്യവൽക്കരിക്കുക, നിലവിലെ പ്രക്രിയയിൽ നിലനിൽക്കുന്ന അളവുകളിലൂടെ പ്രശ്നങ്ങൾ പ്രാദേശികവൽക്കരിക്കുകയും ഈ പ്രശ്നങ്ങൾ ഇല്ലാതാക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു ഒരു പ്രാരംഭ ലക്ഷ്യം വെച്ചു. ഇവിടെയാണ് നമ്മൾ യഥാർത്ഥത്തിൽ എന്തെങ്കിലും ചെയ്യാൻ തുടങ്ങുന്നത്.

മെട്രിക്സ്

മൂല്യ സ്ട്രീം മാപ്പ് സാഹിത്യത്തിൽ വിവരിച്ചിരിക്കുന്ന നിരവധി വ്യത്യസ്ത അളവുകൾ ഉണ്ട്, എന്നാൽ ഞങ്ങൾക്ക് ആരംഭിക്കാൻ മൂന്ന് മാത്രം മതി.

ലീഡ് സമയം - താമസം/കാത്തിരിപ്പ് - നമ്മൾ എന്തിനോ വേണ്ടി കാത്തിരിക്കുന്ന സമയം. ഉദാഹരണത്തിന്, ടെസ്റ്റ് ബെഞ്ച് സ്വതന്ത്രമാകുന്നതുവരെ ഒരു ടെസ്റ്റർ കാത്തിരിക്കുന്നു, ഈ സമയത്ത് ഒന്നും ചെയ്യാൻ കഴിയില്ല.

മൂല്യവർദ്ധിത സമയം - ഉപയോഗപ്രദമായ ജോലി സമയം - ഉപയോക്താവിന് അന്തിമ മൂല്യം സൃഷ്ടിക്കാൻ ഞങ്ങൾ അത്തരമൊരു ഘട്ടത്തിൽ ചെലവഴിച്ചത്. ഉദാഹരണത്തിന്, ഒരു ടെസ്റ്റർ തൻ്റെ പരീക്ഷണം ആരംഭിച്ച് എന്തെങ്കിലും പരിശോധിക്കാൻ തുടങ്ങി. ഇത് ഉപയോഗപ്രദമായ ജോലിയുടെ സമയമാണ്, ഞങ്ങൾ യഥാർത്ഥത്തിൽ ഉൽപ്പന്നത്തിനായി എന്തെങ്കിലും ചെയ്യുമ്പോൾ. ഗുണമേന്മയുള്ള സോഫ്‌റ്റ്‌വെയർ - ഇതാണ് ക്ലയൻ്റുകൾ നൽകുന്നത്.

%C/A എന്നത് അംഗീകരിക്കപ്പെട്ട ജോലിയുടെ ശതമാനമാണ്. ഞങ്ങൾക്ക് ഒരു ഘട്ടമുണ്ട് - വികസനം, രണ്ടാം ഘട്ടം - പരിശോധന. ഡവലപ്പർമാരിൽ നിന്ന് എത്ര ഫീച്ചറുകൾ ടെസ്റ്റർമാർ സ്വീകരിച്ചു എന്നത് ഈ ശതമാനമാണ്.

ഞങ്ങളുടെ ഭൂപടം ഏകദേശം ഇങ്ങനെയാണ്.

ഓർഗനൈസേഷൻ്റെ ഘടന, വകുപ്പുകളുടെ എണ്ണം, നിങ്ങൾ ചെയ്യുന്ന കാര്യങ്ങൾ എന്നിവയെ ആശ്രയിച്ച് ഇത് വ്യത്യസ്തമായി കാണപ്പെടാം. എന്നാൽ പൊതുവേ, മാപ്പിൽ രണ്ട് ഘട്ടങ്ങൾ ഉണ്ടാകും: ആശയം и അനലിറ്റിക്സ്. ഈ ഘട്ടത്തിൽ, ഡാറ്റ പ്രതീക്ഷിക്കുന്നു, ഉദാഹരണത്തിന്, ലീഡ് സമയം 2 ആഴ്ചയും മൂല്യവർദ്ധിത സമയം 2 ദിവസവും.

ഞങ്ങൾ എല്ലാ ഘട്ടങ്ങളും മെട്രിക്സ് ഉപയോഗിച്ച് കവർ ചെയ്യുന്നു.

ബാജോജി - വിശകലന വിദഗ്ധർ അവരുമായി വന്നതിന് ശേഷം എത്ര പ്രശ്നങ്ങൾ ഉണ്ടായിരുന്നു.

വികസനം - ടാസ്‌ക്കുകൾ, സ്റ്റാൻഡുകൾ അല്ലെങ്കിൽ ഉപകരണങ്ങൾ എന്നിവയെക്കുറിച്ചുള്ള വ്യക്തതയ്ക്കായി ഡവലപ്പർമാർ എത്ര ആഴ്ചകളായി കാത്തിരിക്കുന്നു - ഇത് പ്രശ്നമല്ല, പക്ഷേ അവർ എന്തെങ്കിലും കാത്തിരിക്കുകയാണ്. ഉദാഹരണത്തിന്, ഒരു ഫീച്ചർ നടപ്പിലാക്കാൻ അവർക്ക് 4 ദിവസമെടുക്കും. ഇവിടെയാണ് %C/A മെട്രിക് വരുന്നത്. ഡെവലപ്പർമാർ ബാക്ക്‌ലോഗിൽ നിന്ന് 80% ടാസ്‌ക്കുകൾ മാത്രമാണ് എടുത്തത്. ബാക്കിയുള്ള 20% പേർക്ക് മതിയായ സാങ്കേതിക സ്പെസിഫിക്കേഷൻ ഇല്ലെന്ന് അവർ വിശ്വസിക്കുന്നു, അവ പുനരവലോകനത്തിനായി അയച്ചു.

പരിശോധിക്കുന്നു. LT ഡയഗ്രം 4 ദിവസമായി സജ്ജീകരിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, ടെസ്റ്റർ ബെഞ്ച് സ്വതന്ത്രമാകാൻ കാത്തിരിക്കുകയായിരുന്നു, VA അവർ 2 ദിവസത്തേക്ക് എന്തെങ്കിലും പരീക്ഷിക്കുകയായിരുന്നു, %C/A = 40%. - ഡവലപ്പർമാർ അയച്ച കോഡിൻ്റെയോ ഫീച്ചറുകളുടെയോ 40% മാത്രമേ ടെസ്റ്റർമാർ പര്യാപ്തമായി കണക്കാക്കുന്നുള്ളൂ. ചില കാരണങ്ങളാൽ അവർക്ക് മറ്റെല്ലാം ഇഷ്ടപ്പെട്ടില്ല.

ഈ അളവുകൾ എങ്ങനെ നടപ്പിലാക്കണം എന്നതിനെക്കുറിച്ച് ഞാൻ വിശദമായി സംസാരിക്കില്ല, ലേഖനത്തിൻ്റെ അവസാനം നിങ്ങൾക്ക് അവയെക്കുറിച്ച് പഠിക്കാൻ കഴിയുന്ന സാഹിത്യം ഞാൻ ശുപാർശ ചെയ്യും.

നിങ്ങളോടൊപ്പം ഒരു മൂല്യ സ്ട്രീം മാപ്പ് കംപൈൽ ചെയ്യുന്ന ആളുകളെ നിങ്ങൾ വിശ്വസിക്കരുത് എന്നതാണ് എനിക്ക് ശുപാർശ ചെയ്യാൻ കഴിയുന്ന ഒരേയൊരു കാര്യം. വ്യത്യസ്ത പ്രക്രിയകൾ എത്ര സമയമെടുക്കുമെന്നതിനെക്കുറിച്ചുള്ള ഒരു ആശയം അവർ നൽകുന്നു, എന്നാൽ ഈ കണക്കുകൾ എല്ലായ്പ്പോഴും ശരിയല്ല, അതിനാൽ സ്വയം അളക്കുന്നതാണ് നല്ലത്.

ഞങ്ങൾ ഓപ്പറേഷൻസ് ഡിപ്പാർട്ട്‌മെൻ്റിൽ വന്ന് ഒരു പുതിയ ഫീച്ചർ പ്രൊഡക്ഷനിൽ എത്തിക്കാൻ എത്ര സമയമെടുത്തു എന്ന് ചോദിച്ചപ്പോൾ ഞങ്ങൾക്ക് ഒരു കേസ് ഉണ്ടായിരുന്നു. 10 മിനിറ്റ് ആകുമെന്ന് അവർ ഞങ്ങളോട് പറഞ്ഞു, ഞങ്ങൾ ചിന്തിച്ചു, ഞങ്ങൾ എന്തിനാണ് ഈ കമ്പനിയിലേക്ക് വന്നത്? കോഡ് എടുത്ത് സെർവറിലേക്ക് ഡെലിവർ ചെയ്യുന്ന സ്‌ക്രിപ്റ്റിൻ്റെ പ്രവർത്തന സമയമാണ് 10 മിനിറ്റ് എന്ന് മനസ്സിലായി. എന്നാൽ ഇതിന് മുമ്പ്, റിലീസ് മൂന്ന് ദിവസത്തേക്ക് സെർവറിൽ ഇരിക്കുകയും പൊടി ശേഖരിക്കുകയും ചെയ്യുന്നു - ബാക്ക്‌ലോഗിൽ വിന്യസിക്കേണ്ടതുണ്ട്. വിന്യാസ ഘട്ടത്തിന് മുമ്പ്, പ്രോജക്റ്റ് അവിടെ ഇരിക്കുമ്പോൾ ഒരു കാത്തിരിപ്പ് ഘട്ടമുണ്ടെന്ന് ഇത് മാറുന്നു. ഞങ്ങൾ ഒരു നോട്ട്പാഡുമായി പോയില്ലായിരുന്നെങ്കിൽ, ജീരയിലെ ടാസ്‌ക്കിൽ ഞങ്ങളുടെ ശ്രദ്ധ പിടിച്ചുപറ്റുകയും പടിപടിയായി അത് ട്രാക്ക് ചെയ്യാൻ തുടങ്ങുകയും ചെയ്തിരുന്നെങ്കിൽ, എല്ലാം മികച്ചതാണെന്നും ഒരു പ്രശ്‌നവുമില്ലെന്നും ഞങ്ങൾ കരുതുമായിരുന്നു.

അതിനാൽ, യാഥാർത്ഥ്യത്തോട് അടുത്ത് ഒരു ആശയം ലഭിക്കുന്നതിന് നിങ്ങൾ ഇപ്പോഴും അളവുകൾ സ്വയം ചെയ്യേണ്ടിവരും, ഒന്നിലധികം തവണ. മൂല്യ സ്ട്രീം മാപ്പിനെ ആശ്രയിച്ച്, എവിടെ തുടങ്ങണം, എന്താണ് ആദ്യം പരിഹരിക്കേണ്ടത് എന്ന് നിങ്ങൾ തീരുമാനിക്കും.

താൽക്കാലിക ടീം

DevOps നടപ്പിലാക്കാൻ തീരുമാനിക്കുന്ന പല കമ്പനികളും ഒരു ടീമിനെ സൃഷ്ടിക്കുന്നു, പക്ഷേ ഒരു താൽക്കാലിക ഒന്നല്ല, മറിച്ച് നിരവധി വർഷങ്ങളായി നിലനിൽക്കുന്ന ഒന്നാണ്. DevOps-ൽ ഒരു ഓർഗനൈസേഷണൽ ഘടന കെട്ടിപ്പടുക്കുന്നതിനുള്ള വ്യത്യസ്ത പാറ്റേണുകൾ വിവരിക്കുന്ന DevOps ക്ഷമാപണം എന്ന സേവനത്തിലേക്ക് നിങ്ങൾ പോയാൽ, ഇതൊരു വിരുദ്ധ പാറ്റേണാണെന്ന് നിങ്ങൾക്ക് മനസ്സിലാകും.

ഒരു DevOps ടീം വർഷങ്ങളോളം തുടർച്ചയായി നിലനിൽക്കുമ്പോൾ, ഇതൊരു വലിയ തെറ്റാണ്, കാരണം DevOps എന്നത് ഡിപ്പാർട്ട്‌മെൻ്റുകൾ തമ്മിലുള്ള ആശയവിനിമയത്തെക്കുറിച്ചും വേഗതയെക്കുറിച്ചും കാര്യക്ഷമതയെക്കുറിച്ചും ഉള്ളതാണ്.

ഡിപ്പാർട്ട്‌മെൻ്റുകൾക്കിടയിൽ മറ്റെന്തെങ്കിലും പ്രത്യേകമായി ചെയ്യാൻ മാത്രമായി ഒരു ടീം നിലവിലുണ്ടെങ്കിൽ, അത് വളരെക്കാലം നിലനിൽക്കുകയാണെങ്കിൽ, അത് അനാവശ്യമായ ഒരു തടസ്സം സൃഷ്ടിക്കുന്നു. ഇപ്പോൾ പ്രോഗ്രാമർ, പ്രശ്നം പരിഹരിക്കാൻ ഉടൻ അഡ്മിനിസ്ട്രേറ്ററിലേക്ക് പോകുന്നതിനുപകരം, ആദ്യം DevOps ഡിപ്പാർട്ട്മെൻ്റുമായി ബന്ധപ്പെടണം, അവൻ മുന്നോട്ട് പോകും.

അതിനാൽ, ആരംഭിക്കുന്നതിന്, നിങ്ങൾ ഒരു താൽക്കാലിക ടീമിനെ സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഞങ്ങൾ തിരഞ്ഞെടുത്ത ഒരു പരിമിതി ഇല്ലാതാക്കാൻ, കൈയിലുള്ള ചുമതലയെ ആശ്രയിച്ച്, ഇത് ആറ് മാസത്തേക്ക്, പരമാവധി ഒരു വർഷത്തേക്ക് സോപാധികമായി നിലനിൽക്കും. അപ്പോൾ അവൾ മരിക്കും. ഞങ്ങൾക്ക് ഒരുപാട് വേദനയുള്ള അടുത്ത പോയിൻ്റ് തിരഞ്ഞെടുക്കുകയും അതിനായി ഒരു പ്രത്യേക ടീം കൂടി ആവശ്യമാണെന്ന് മനസ്സിലാക്കുകയും ചെയ്താൽ, ഞങ്ങൾ അത് വീണ്ടും സൃഷ്ടിക്കും. എന്നാൽ അത്തരം ടീമുകൾ "സ്ഥിരമായ അടിസ്ഥാനത്തിൽ" നിലനിൽക്കരുത് - അപ്പോൾ അവർ ആശയവിനിമയം തടസ്സപ്പെടുത്തുകയും സാധാരണയായി എന്തെങ്കിലും ചെയ്യുന്നതിനായി പ്രത്യേക ചുമതലകൾ ഏറ്റെടുക്കുകയും ചെയ്യുന്നു. ഈ ടാസ്ക്കുകൾ DevOps അല്ലെങ്കിൽ പരിവർത്തനവുമായി ബന്ധപ്പെട്ടതല്ലായിരിക്കാം. എന്തുകൊണ്ടാണ് നമ്മൾ ഈ ചുമതല നിലവിലുള്ള വകുപ്പുകൾക്ക് നൽകാത്തത്?

എന്തുകൊണ്ട് ഒരു താൽക്കാലിക ടീം ആവശ്യമാണ്?

നിലവിലെ പ്രക്രിയകളുമായുള്ള വൈരുദ്ധ്യം. DevOps പരിവർത്തനം എന്നത് നമ്മൾ ഉപയോഗിക്കുന്ന സാങ്കേതികവിദ്യകളിലും ടൂളുകളിലും ഉള്ള ഒരു മാറ്റം മാത്രമല്ല, മറിച്ച് ജോലി, ചിന്ത, മൂല്യങ്ങൾ എന്നിവയുടെ പ്രക്രിയയിലെ തന്നെ മാറ്റമാണ്. ടീം പഴയ രീതിയിൽ പ്രവർത്തിക്കുകയാണെങ്കിൽ, മറ്റ് സമീപനങ്ങൾ പരീക്ഷിക്കാൻ കഴിയില്ല.

ഈ ആളുകൾ വ്യത്യസ്ത നിയമങ്ങൾക്കനുസൃതമായി ജീവിക്കണം: കമ്പനിയിലെ എല്ലാ കെപിഐകളെയും അവഗണിക്കുക, കാരണം അവർ വ്യത്യസ്തമായി പ്രവർത്തിക്കാൻ ശ്രമിക്കുന്നു. താത്കാലിക ടീമുകൾ സെർവർ ലഭിക്കാൻ അപേക്ഷകൾ പൂരിപ്പിക്കില്ല, മറിച്ച് അവർക്ക് ആവശ്യമുള്ളത് ആദ്യം നൽകണമെന്ന് ആവശ്യപ്പെട്ട് അവരെ നിയന്ത്രിക്കുന്ന വകുപ്പിലേക്ക് നേരിട്ട് പോകും, ​​അത് മുൻഗണനയായതിനാലും വ്യത്യസ്തമായി ജീവിക്കാൻ ശ്രമിക്കുന്നതിനാലും. നിലവിലെ എല്ലാ പ്രക്രിയകളുമായും ടീം പൂർണ്ണമായും വൈരുദ്ധ്യത്തിലാണ്. നിലവിലുള്ള തൊഴിൽ രീതികൾ ഇപ്പോൾ അവരെ തടസ്സപ്പെടുത്തുന്നില്ലെന്നും അവർ മറ്റുള്ളവരുമായി ഇടപെടുന്നില്ലെന്നും ഉറപ്പാക്കാൻ, ഞങ്ങൾ ഈ ആളുകളെ ഒരു പ്രത്യേക ടീമായി ഒറ്റപ്പെടുത്തുന്നു.

പരീക്ഷണങ്ങളിൽ ബ്യൂറോക്രസി ഒഴിവാക്കുന്നു. താൽക്കാലിക ടീമുകൾക്ക് ബ്യൂറോക്രസി ഇല്ല, അവർ സമയ റിപ്പോർട്ടുകൾ ഫയൽ ചെയ്യുന്നില്ല, മാനേജർമാർക്ക് റിപ്പോർട്ട് ചെയ്യുന്നില്ല. ഇത് തികച്ചും വ്യത്യസ്തമായ ഒരു ലോകമാണ്, അതിൽ ആളുകൾ ജീവിക്കുകയും വ്യത്യസ്തമായി ചിന്തിക്കുകയും തികച്ചും വ്യത്യസ്തമായ കാര്യങ്ങൾ ചെയ്യുകയും ചെയ്യുന്നു. അവരെ വീണ്ടും ശല്യപ്പെടുത്തേണ്ട ആവശ്യമില്ല.

സേവനത്തിൽ നിർത്താതെയുള്ള ജോലി. ആദ്യ പോയിൻ്റിൽ, ഞങ്ങൾ പരീക്ഷിക്കാൻ പോകുന്ന എന്തെങ്കിലും തിരഞ്ഞെടുത്തു. മികച്ച രീതിയിൽ പ്രവർത്തിക്കാനുള്ള വഴികൾ പരീക്ഷിക്കുകയും കണ്ടെത്തുകയും ചെയ്യുന്നത് നല്ലതാണ്, എന്നാൽ ഫീച്ചറുകൾ ഉണ്ടാക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. മുഴുവൻ ടീമും സവിശേഷതകൾക്ക് പകരം പരിവർത്തനത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുകയാണെങ്കിൽ, ഞങ്ങൾക്ക് വരുമാനം നഷ്‌ടപ്പെടാൻ തുടങ്ങും, ബഗുകൾ വളരെക്കാലം തൂങ്ങിക്കിടക്കും - ഞങ്ങൾക്ക് ഇത് ആവശ്യമില്ല. ഒരു താൽക്കാലിക ടീം സൃഷ്ടിക്കുന്നത് ഉൽപ്പന്നത്തിൽ ജോലി നിർത്താതെ തന്നെ പരീക്ഷണം നടത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ജോലി ജോലികളിൽ സമയം കളയരുത്. ഇത് വീണ്ടും ഉൽപ്പന്നത്തെക്കുറിച്ചാണ്. മറ്റ് ഉപകരണങ്ങളും മറ്റും പരീക്ഷിക്കാൻ ടീമിന് വളരെയധികം സമയമെടുക്കും. ആളുകൾക്ക് ഉപകരണങ്ങൾ മാസ്റ്റർ ചെയ്യാനും അവ നടപ്പിലാക്കാനും സാധാരണ രീതിയിൽ ഉപയോഗിക്കാനും തുടങ്ങുന്നതിന് കുറഞ്ഞത് ആറ് മാസമെടുക്കും. അവരും ഉൽപന്നത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുകയാണെങ്കിൽ, ആറുമാസം പ്രാപഞ്ചികമായി നീളും. ആളുകൾ ഉൽപ്പന്നത്തിൽ പ്രവർത്തിക്കുകയാണെങ്കിൽ, അവർ വീണ്ടും പഴയ പ്രക്രിയകളിൽ പ്രവർത്തിക്കുന്നു - ഞങ്ങൾക്ക് അത് ആവശ്യമില്ല.

അതിനാൽ, സേവനത്തെ പരിവർത്തനം ചെയ്യുന്ന ഒരു പ്രത്യേക ടീമിലേക്ക് ഞങ്ങൾ വിവിധ വകുപ്പുകളിൽ നിന്നുള്ള ആളുകളെ നിയോഗിക്കുന്നു. തൽഫലമായി, സേവനം പ്രവർത്തിക്കുന്നു, വികസിപ്പിക്കുന്നത് തുടരുന്നു, അതേ സമയം ഞങ്ങൾ അതിൽ ചില പരീക്ഷണങ്ങൾ നടത്തുന്നു.

താൽക്കാലിക ടീം DevOps പരിവർത്തനത്തിനായി മാത്രം സമർപ്പിച്ചിരിക്കുന്നു - ഞങ്ങൾ കണ്ടെത്തിയ പരിമിതി ഇല്ലാതാക്കുന്നു, അതിൽ കൂടുതലൊന്നും ഇല്ല.

ബഹുമുഖ പ്രതിഭകൾ അടങ്ങുന്നതാണ് ടീം. ഡെവലപ്പർമാരെ മാത്രമല്ല ഞങ്ങൾ നിയമിച്ചത് എന്നാണ് ഇതിനർത്ഥം. ഞങ്ങൾ സേവന കേന്ദ്രത്തിൽ വന്ന് പകുതി ടീമിനെ അവിടെ നിന്ന് കൊണ്ടുപോയില്ല - ഇല്ല, ഞങ്ങൾ എടുത്തു വിവിധ വകുപ്പുകളിൽ നിന്നുള്ള ആളുകൾ. കുറച്ച് പോയിൻ്റുകൾക്ക് മുമ്പ്, രൂപാന്തരപ്പെട്ട സേവനവുമായി ബന്ധപ്പെട്ട വിവിധ വകുപ്പുകളെയും വ്യത്യസ്ത ജീവനക്കാരെയും ഞങ്ങൾ കണ്ടെത്തി. ഞങ്ങൾ അവരിൽ നിന്ന് ഒരു ടീമിനെ റിക്രൂട്ട് ചെയ്യുന്നു, കാരണം അത് സാർവത്രികമായിരിക്കണം - ടെസ്റ്റിംഗ് പ്രക്രിയ, വികസന പ്രക്രിയ, സേവന പരിപാലന പ്രക്രിയ എന്നിവ ഞങ്ങൾ മാറ്റും. വ്യത്യസ്ത കഴിവുകൾ ആവശ്യമാണ്.

സാധാരണയായി ഞങ്ങൾ ഒരു ഡെവലപ്പർ, ഒരു ടെസ്റ്റർ, എഞ്ചിനീയർ എന്നിവരെ ഓരോന്നായി എടുക്കുന്നു, അവരോടൊപ്പം ഞങ്ങൾ വ്യത്യസ്തമായി ജീവിക്കാൻ അനുവദിക്കുന്ന ഒരു പരിഹാരവുമായി വരുന്നു.

ഈ ആളുകൾക്ക് സംഘടനയിൽ അധികാരം ഉണ്ടായിരിക്കുന്നത് അഭികാമ്യമാണ്. നിങ്ങൾക്ക് താൽപ്പര്യമില്ലെങ്കിലും ഒരു യാഥാസ്ഥിതികനെ എടുക്കേണ്ടി വന്നേക്കാം. ഞങ്ങൾക്ക് ഒരു വലിയ കമ്പനി ഉണ്ടെങ്കിൽ, എല്ലാവരും ഞങ്ങളുടെ ആശയത്തിൽ വിശ്വസിക്കില്ല, ചിലർ നമ്മുടെ ചക്രങ്ങളിൽ ഒരു സ്‌പോക്ക് ഇട്ടേക്കാം, ഉദാഹരണത്തിന്, ഒരു നിലപാട് നൽകാതെ. ഇവിടെയാണ് നിങ്ങൾക്ക് ഒരു "അതോറിറ്റി" ആവശ്യമായി വരുന്നത് - തൻ്റെ സഹപ്രവർത്തകരുടെ നല്ല മനോഭാവം സമ്പാദിച്ച വിപുലമായ അനുഭവപരിചയമുള്ള ഒരു ബഹുമാന്യനായ വ്യക്തി. ടീമിലെ ജീവനക്കാരൻ്റെ അധികാരം താൽക്കാലിക ടീമിൻ്റെ ചുമതലയും പ്രവർത്തനവും ലളിതമാക്കും. ആളുകൾ ചിന്തിക്കും:

- അതെ, നമുക്കെല്ലാവർക്കും അറിയാവുന്നതും ഇഷ്ടപ്പെടുന്നതുമായ ഈ നല്ല സുഹൃത്ത് അവിടെ യോജിക്കുന്നു - DevOps-ൽ കാണേണ്ട ചിലതുണ്ട്!

ഒരു ലക്ഷ്യം വെക്കുന്നു

ഞങ്ങൾ ആളുകളെ ശേഖരിച്ചു, ഒരു സേവനം തിരഞ്ഞെടുത്തു, നിയന്ത്രണങ്ങൾ നോക്കി, ഏത് ആളുകളെയാണ് ഞങ്ങൾ സ്വാധീനിക്കേണ്ടത് എന്ന് നിശ്ചയിച്ചു. ഇപ്പോൾ നിങ്ങൾ ഒരു ലക്ഷ്യം സജ്ജീകരിക്കേണ്ടതുണ്ട്, അത് നേരെയായിരിക്കണം സ്മാർട്ട് വഴി - നമ്മൾ ഇഷ്ടപ്പെടുന്ന എല്ലാം.

നിർദ്ദിഷ്ട - നിർദ്ദിഷ്ട.

അളക്കാവുന്ന - അളക്കാവുന്ന. ഇത് വളരെ പ്രധാനപ്പെട്ട ഒരു SMART പോയിൻ്റാണ്. നിങ്ങൾക്ക് എന്തെങ്കിലും അളക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, അത് മാറ്റാനും നിങ്ങൾ എന്താണ്, എങ്ങനെ മികച്ചതോ മോശമായതോ ചെയ്തുവെന്ന് മനസിലാക്കാൻ കഴിയില്ല.

നേടാവുന്നത് - നേടിയെടുക്കാവുന്നത്. നിങ്ങളുടെ പ്രത്യേക ആവശ്യങ്ങൾക്ക് അനുയോജ്യമായ മാറ്റങ്ങൾ വരുത്തുക. വർഷത്തിലൊരിക്കൽ ഉൽപ്പന്നത്തിൻ്റെ ഒരു പതിപ്പ് പുറത്തിറക്കുന്ന, നീണ്ട ചരിത്രവും ഉത്തരവാദിത്തങ്ങളുടെ ഒരു വലിയ ഭാരവുമുള്ള ഒരു എൻ്റർപ്രൈസ് കമ്പനിയാണെങ്കിൽ, ആറ് മാസത്തിനുള്ളിൽ ഓരോ മണിക്കൂറിലും ഉൽപ്പന്നത്തിൻ്റെ പുതിയ പതിപ്പുകൾ റിലീസ് ചെയ്യാൻ നിങ്ങൾക്ക് കഴിയില്ല. അത് ആ രീതിയിൽ പ്രവർത്തിക്കില്ല. അതിനാൽ, സ്വീകാര്യമായ സമയപരിധിക്കുള്ളിൽ കൈവരിക്കാൻ കഴിയുന്ന ഒരു യഥാർത്ഥ ലക്ഷ്യം സജ്ജമാക്കുക.

പ്രസക്തമായ - പ്രസക്തമായ. ഞങ്ങളുടെ നിലവിലെ ലക്ഷ്യങ്ങൾ നിറവേറ്റുന്ന നിയന്ത്രണങ്ങൾ മാത്രമേ ഞങ്ങൾ നീക്കംചെയ്യൂ.

സമയ പരിമിതി - സമയപരിധി. സമയപരിധി ഇല്ലെങ്കിൽ, ടീം അവർ ആഗ്രഹിക്കുന്നതെന്തും ചെയ്യും: 15-ന് പകരം 3 സാങ്കേതികവിദ്യകൾ പരീക്ഷിക്കുക, വലിയ റിപ്പോർട്ടുകൾ എഴുതുക, ഉപയോഗശൂന്യമായ ഗവേഷണം നടത്തുക, ലക്ഷ്യം ഇതിനകം കൈവരിക്കുമ്പോൾ അത് തിളങ്ങുന്നതുവരെ അവ നടപ്പിലാക്കുക.

മൂല്യ സ്ട്രീം മാപ്പ് ഉപയോഗിച്ച് ഞങ്ങൾ ലക്ഷ്യം നേടുന്നു - ഞങ്ങൾ എല്ലാ ആളുകളെയും വീണ്ടും ശേഖരിച്ച് അവരെ വരയ്ക്കുന്നു. എന്നാൽ ഇപ്പോൾ മാത്രം, മുമ്പത്തെ മൂല്യ സ്ട്രീം മാപ്പിനെ അടിസ്ഥാനമാക്കി, നമുക്ക് ലഭിക്കാൻ ആഗ്രഹിക്കുന്നത് വരയ്ക്കുന്നു.

ഞങ്ങൾ ഇപ്പോൾ ഇല്ലാതാക്കുന്ന ഒരു പരിമിതി ഞങ്ങൾ ഉയർത്തിക്കാട്ടുന്നു - ഇതാണ് ടീം ചെയ്യുന്നത്. ഒരു ഉദാഹരണമായി, പൂർത്തിയായ റിലീസ് മുതൽ ഉൽപ്പാദനത്തിൽ വിന്യാസം വരെയുള്ള കാത്തിരിപ്പ് ഞാൻ എടുത്തു - ഇതാണ് ആളുകൾ കൺസൾട്ടൻ്റുകളിലേക്ക് തിരിയുന്ന ഏറ്റവും സാധാരണമായ പരിമിതി.

ഇതിനെ അടിസ്ഥാനമാക്കി, ഞങ്ങൾ ടാസ്‌ക് സജ്ജമാക്കി: പൂർത്തിയായ റിലീസിനും യുദ്ധത്തിലേക്ക് പോകുന്നതിനും ഇടയിലുള്ള കാത്തിരിപ്പ് പരമാവധി ഒരു മണിക്കൂർ ആയിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ജോലികളുടെ ഉദാഹരണങ്ങൾ.

• പരിശോധനയുടെ ലീഡ് സമയം 4 ദിവസത്തിൽ നിന്ന് 1 മണിക്കൂറായി കുറയ്ക്കുക.
• പരിശോധനയ്ക്കുള്ള മൂല്യവർദ്ധിത സമയം 2 ദിവസത്തിൽ നിന്ന് 3 മണിക്കൂറായി കുറയ്ക്കുക.
• വിന്യാസത്തിൻ്റെ ലീഡ് സമയം 5 മണിക്കൂറിൽ നിന്ന് 10 മിനിറ്റായി കുറയ്ക്കുക.
• C/A 50% ൽ നിന്ന് 95% ആയി വർദ്ധിപ്പിക്കുക, അതായത്, ടെസ്റ്റർമാർ അംഗീകരിക്കുന്ന സവിശേഷതകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുക, മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, ഡവലപ്പർമാരുടെ ജോലിയുടെ ഗുണനിലവാരം മെച്ചപ്പെടുത്തുക.

ടാസ്‌ക്കുകളുടെ ഉദാഹരണങ്ങൾ ഞങ്ങളുടെ തലയിൽ നിന്ന് എടുത്തിട്ടില്ല - അവ മൂല്യ സ്ട്രീം മാപ്പ് വികസിപ്പിക്കുമ്പോൾ ഞങ്ങൾ നടത്തിയ അളവുകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

ഞങ്ങളുടെ ടീമിന് സമാനമായ ഒരു ടാസ്‌ക്കും സമയപരിധിയും ഞങ്ങൾ സജ്ജമാക്കി. നിങ്ങളുടെ കമ്പനി എത്ര നന്നായി പ്രവർത്തിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച്, നിങ്ങൾ വ്യത്യസ്ത സമയപരിധികൾ സജ്ജമാക്കി. ആളുകൾ ആദ്യമായിട്ടാണ് ഇത് ചെയ്യുന്നതെങ്കിൽ, ഏതൊക്കെ സാങ്കേതിക വിദ്യകൾ ഉപയോഗിച്ചാണ് അവർ പ്രശ്‌നം പരിഹരിക്കുകയെന്നും ഇതുവരെ അറിയില്ലെങ്കിൽ, ഒരു പരിമിതി ഇല്ലാതാക്കാൻ ശരാശരി ആറ് മാസമെടുക്കും.

ഹ്രസ്വ ആസൂത്രണം

അതിനാൽ, ഞങ്ങളുടെ ടീം സൃഷ്ടിക്കപ്പെട്ടു, അതിന് ഒരു ലക്ഷ്യമുണ്ട്, ആളുകൾ പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു. ഒരു പ്രധാന കാര്യം ജോലിയുടെ ഒരു ഹ്രസ്വ ആസൂത്രണമാണ്: ഒന്ന് മുതൽ രണ്ടാഴ്ച വരെ സ്പ്രിൻ്റ്സ്ഇനി വേണ്ട, അളക്കാവുന്ന മെച്ചപ്പെടുത്തലുകൾ എല്ലാ ആഴ്ചയും ഒപ്പം കോഴ്സ് തിരുത്തൽ.

ഉദാഹരണത്തിന്, ഞങ്ങൾ പലപ്പോഴും സമീപനം ഉപയോഗിക്കുന്നു ചലിക്കുന്ന-ചലിക്കുന്നഓരോ ആഴ്‌ചയുടെയും തുടക്കത്തിൽ ടീം മുഴുവനും ഒത്തുകൂടുമ്പോൾ, എല്ലാവരും എന്തുചെയ്യുമെന്ന് അവർ ഒരു ഫയലിൽ രേഖപ്പെടുത്തുന്നു. ഒരാഴ്‌ചയ്‌ക്ക് ശേഷം, എന്താണ് ചെയ്‌തതെന്നും അല്ലാത്തത് എന്താണെന്നും ഞങ്ങൾ ശ്രദ്ധിക്കുന്നു, ഇല്ലെങ്കിൽ എന്തുകൊണ്ട്, അടുത്തതായി എന്തുചെയ്യണമെന്ന് ഞങ്ങൾ ചിന്തിക്കുന്നു.

സമയബന്ധിതമായ കോഴ്സ് തിരുത്തലുകൾ നടത്താൻ സ്പ്രിൻ്റുകൾ നിങ്ങളെ അനുവദിക്കുന്നു.

ഒന്നോ രണ്ടോ ആഴ്‌ച നിങ്ങൾ എന്തെങ്കിലും പരീക്ഷിച്ചു: സാങ്കേതികവിദ്യകൾ, സമീപനങ്ങൾ, പ്രവർത്തന രീതികൾ, അതിനുശേഷം നിങ്ങൾ വീണ്ടും അളക്കുകയും കാണുക - ഈ സമീപനത്തിലൂടെ ഇത് മികച്ചതോ മോശമോ ആയതാണോ? ഇത് മോശമാണെങ്കിൽ, അതിനർത്ഥം നമ്മൾ തെറ്റായ ദിശയിലേക്കാണ് പോകുന്നതെന്നാണ്, ഞങ്ങൾ കോഴ്സ് ശരിയാക്കേണ്ടതുണ്ട്: മറ്റൊരു ടാസ്ക് സജ്ജമാക്കുക, മറ്റൊരു സാങ്കേതികവിദ്യ എടുക്കുക അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും ചെയ്യുക. 1-2 ആഴ്‌ചത്തെ ഷോർട്ട് സ്‌പ്രിൻ്റുകൾ കൃത്യസമയത്ത് തെറ്റായ തീരുമാനങ്ങൾ കൈകാര്യം ചെയ്യാനും ഒഴിവാക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

വിജയം പങ്കിടുന്നു

ടീം ചെറുതോ വലുതോ ആയ ചില വിജയങ്ങൾ കൈവരിക്കുന്നു - അത് പ്രശ്നമല്ല, എല്ലായ്പ്പോഴും ചില ഫലങ്ങളുണ്ട്. ഈ ഫലത്തെക്കുറിച്ച് എല്ലാവരും അറിഞ്ഞിരിക്കണം: DevOps-ലും അയൽ വകുപ്പുകളിലും ഉൾപ്പെട്ടിരിക്കുന്നവർ. ഒരു ആദർശ ലോകത്ത്, ഇത് എല്ലായിടത്തും എത്തിച്ചേരുന്നത് അഭികാമ്യമാണ് കമ്പനിയിലെ എല്ലാ ആളുകൾക്കും.

എന്തിനുവേണ്ടി? കമ്പനിയുടെ ഒരു ഭാഗം മാത്രമല്ല, ഒരു പരിമിതി മാത്രമല്ല, പൊതുവായി എല്ലാം ഇല്ലാതാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, കമ്പനി വഴക്കമുള്ളതായിത്തീരുന്നു, കോഡ് വേഗത്തിൽ ക്ലയൻ്റിലേക്ക് എത്തുന്നു, ഒന്നും തകരുന്നില്ല, എല്ലാവരും ആശയത്തോട് വിശ്വസ്തരായിരിക്കണം. DevOps-ൻ്റെ. നിങ്ങൾക്ക് എതിരായി പ്രവർത്തിക്കുന്ന സേവനങ്ങളിലേക്കും ടീമുകളിലേക്കും സമീപനം പ്രയോഗിക്കാൻ കഴിയില്ല.

വിശ്വസ്തത പ്രത്യക്ഷപ്പെടുന്നതിന്, ഞങ്ങൾ ഇത് പരീക്ഷിച്ചുവെന്ന് എല്ലാവരോടും പറയണം - ഞങ്ങൾക്ക് ഫലങ്ങളുണ്ട്, ഇത് പരീക്ഷിക്കുക! ഇത് നമ്മൾ ചെയ്യുന്ന കാര്യങ്ങളിൽ താൽപ്പര്യവും വിശ്വസ്തതയും വർദ്ധിപ്പിക്കും, ആളുകൾ ഇപ്പോൾ എന്തെങ്കിലും ചെയ്യാൻ ശ്രമിക്കും. പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, ഞങ്ങൾ എന്താണ് ശ്രമിച്ചതെന്നും എന്താണ് നേടിയതെന്നും ഞങ്ങൾ നിങ്ങളോട് പറയുമ്പോൾ, ഞങ്ങൾ എങ്ങനെ, എന്ത് ചെയ്തുവെന്ന് മറ്റ് ടീമുകൾ ചോദിക്കാൻ തുടങ്ങുന്നു. അവർ നടപ്പിലാക്കലുകൾ, കോഡ്, ഡോക്യുമെൻ്റേഷൻ എന്നിവ നോക്കുന്നു, ചോദ്യങ്ങളുമായി വന്ന് തങ്ങളിൽ എന്തെങ്കിലും മാറ്റാൻ ശ്രമിക്കുന്നു.

നിങ്ങൾ ചെയ്ത കാര്യങ്ങളെക്കുറിച്ച് സംസാരിക്കുന്നത് പ്രധാനമാണ്. പഴയ രീതിയിൽ എല്ലാം ചെയ്യാൻ ആഗ്രഹിക്കുന്ന യാഥാസ്ഥിതികരെ നിങ്ങളുടെ ക്യാമ്പിൽ ചേരാനും അവരെ പുതുമയുള്ളവരാക്കി മാറ്റാനും ഇതുവഴി നിങ്ങൾ ബോധ്യപ്പെടുത്തും.

ആകെ

ഒരു സേവനം തിരഞ്ഞെടുക്കുന്നു, ഒരു ആരംഭ പോയിൻ്റായി - ഞങ്ങൾ ആരംഭിക്കുന്ന സ്ഥലം കമ്പനിയിൽ മാറുന്നു. സേവനവുമായി എന്തെങ്കിലും ബന്ധമുള്ള എല്ലാവരെയും ഞങ്ങൾ തിരിച്ചറിയുന്നു അവരോടൊപ്പം ഒരു മൂല്യ സ്ട്രീം മാപ്പ് നിർമ്മിക്കുന്നു, പരിമിതികൾ എവിടെ, എന്തൊക്കെയെന്ന് ഞങ്ങൾ അളക്കുകയും കാണുകയും ചെയ്യുന്നു.

ഒരു പുതിയ താൽക്കാലിക ടീമിനെ സൃഷ്ടിക്കുന്നു, ഏത് പ്രശ്നം പരിഹരിക്കും. അളവുകളും മൂല്യ സ്ട്രീം മാപ്പും അടിസ്ഥാനമാക്കി ഞങ്ങൾ ഒരു പുതിയ മാപ്പ് വരയ്ക്കുന്നു, അവിടെ ഞങ്ങൾ പരിഹരിക്കുന്ന പരിമിതി ഹൈലൈറ്റ് ചെയ്യുന്നു. ഈ പരിമിതിയെ അടിസ്ഥാനമാക്കി ഒരു ടാസ്ക് സജ്ജമാക്കുക, ഏത് ടീം കൈകാര്യം ചെയ്യും. ചുമതല ആയിരിക്കണം നിർബന്ധമായും സ്മാർട്ട് - നിർദ്ദിഷ്ടവും അളക്കാവുന്നതും നിലവിലെ ജോലികൾക്ക് പ്രസക്തവും സമയപരിധി പരിമിതവുമാണ്.

പ്രക്രിയ ആവർത്തിക്കുക, ഞങ്ങളുടെ എല്ലാ സേവനങ്ങളും ആവശ്യമായ ഫോമിലേക്ക് മാറ്റുകയും എല്ലാ നിയന്ത്രണങ്ങളും ഇല്ലാതാക്കുകയും ചെയ്യുന്നത് വരെ.

ബോണസ്. ഉപയോഗപ്രദമായ വസ്തുക്കൾ

സ്വന്തമായി DevOps ചെയ്യാൻ തീരുമാനിച്ചവർക്ക്.

പ്രോജക്റ്റ് "ഫീനിക്സ്"

യഥാർത്ഥ തലക്കെട്ട് "ദി ഫീനിക്സ് പ്രോജക്റ്റ്: എ നോവൽ എബൗട്ട് ഇറ്റ്, ഡെവോപ്സ്, ഹെൽപ്പിംഗ് യുവർ ബിസിനസ്സ്." ഇത് DevOps-നെ കുറിച്ചുള്ള ഒരു നോവലാണ് - ഒരു ജീവനക്കാരനെ എപ്പോഴും തീപിടിച്ചിരുന്ന ഒരു വകുപ്പിൻ്റെ തലവനാക്കിയതിൻ്റെ കഥ. പുതിയ ബോസിന് ചുമതല നൽകി:

"എല്ലാം ശരിയാക്കാൻ നിങ്ങൾക്ക് കുറച്ച് വർഷങ്ങളുണ്ട്, അതിനാൽ ഞങ്ങൾക്ക് ഞങ്ങളുടെ ഉൽപ്പന്നം ഞങ്ങളുടെ ഉപഭോക്താക്കൾക്ക് വേഗത്തിലും കാര്യക്ഷമമായും എത്തിക്കാനാകും."

"പ്രോജക്റ്റ് ഫീനിക്സ്" DevOps എങ്ങനെ ജീവിതത്തെ മികച്ച രീതിയിൽ മാറ്റുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു നോവൽ" എന്നത് എല്ലാ മാനേജർമാർക്കുമുള്ള ഒരു പുസ്തകമാണ്, കാരണം കമ്പനിയിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് തീരുമാനിക്കുന്നത് ഇവരാണ്. നിങ്ങൾ ഒരു എഞ്ചിനീയറോ പ്രോഗ്രാമറോ ആണെങ്കിൽ നിങ്ങളുടെ കമ്പനിയിൽ ചലനവും പരിവർത്തനവും ആരംഭിക്കാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഒരു പുസ്തകം വാങ്ങി മാനേജ്മെൻ്റിന് നൽകുക. ഈ നോവൽ എല്ലാം വിശദീകരിക്കുന്നു, വേഗത്തിലും എളുപ്പത്തിലും വായിക്കാവുന്നതാണ്.

DevOps ഗൈഡ്

പുസ്തകം കൂടുതൽ സങ്കീർണ്ണമാണ്. "ടെക്‌നോളജി ഓർഗനൈസേഷനുകളിൽ ലോകോത്തര ചാപല്യവും വിശ്വാസ്യതയും സുരക്ഷയും എങ്ങനെ സൃഷ്ടിക്കാം" എന്ന ശീർഷകത്തിൽ ഇംഗ്ലീഷിൽ ഇത് വർഷങ്ങൾക്ക് മുമ്പ് പ്രസിദ്ധീകരിച്ചു, എന്നാൽ ഇപ്പോൾ ഇത് റഷ്യൻ ഭാഷയിൽ ലഭ്യമാണ്. ഇത് യഥാര്ത്ഥമാണ് കൈപ്പുസ്തകം - പ്രായോഗിക ഗൈഡ്: അളവുകൾ എങ്ങനെ നടത്താം, എന്താണ് ഒരു മൂല്യ സ്ട്രീം മാപ്പ്, എന്തുകൊണ്ട് അത് ആവശ്യമാണ്, എവിടെ പോകണം, ഏത് ക്രമത്തിൽ. എല്ലാം സ്വയം ചെയ്യാൻ ആഗ്രഹിക്കുന്നവർക്ക് മാത്രമുള്ളതാണ് പുസ്തകം. ഏറ്റവും പ്രധാനമായി, മറ്റ് കമ്പനികളുടെ അനുഭവങ്ങളുടെ ഉദാഹരണങ്ങൾ ഇതിൽ അടങ്ങിയിരിക്കുന്നു.

ഉദാഹരണത്തിന്, ഒരു കമ്പനി എങ്ങനെ ഒരു മൂല്യ സ്ട്രീം മാപ്പ് നിർമ്മിച്ചുവെന്നും അതിൻ്റെ പരിമിതി ഉൽപ്പന്നത്തിലല്ലെന്നും കാഷ്യർ ഈ ഉൽപ്പന്നം ഉപയോഗിക്കുന്നതിന് സ്റ്റോറിൽ നിന്ന് അടുത്ത ഓഫീസിലേക്ക് നടന്നുവെന്നും മനസ്സിലാക്കിയതെങ്ങനെയെന്ന് ഇത് പറയുന്നു. പ്രോഗ്രാമിലെ പ്രശ്നം പരിഹരിക്കുന്നതിനുപകരം, അവർ അവരുടെ വിൽപ്പനക്കാർക്കായി ടാബ്‌ലെറ്റുകൾ വാങ്ങി, ഇപ്പോൾ ആരും എവിടെയും പോകുന്നില്ല, എല്ലാ പ്രവർത്തനങ്ങളും അവരുടെ ജോലിസ്ഥലത്ത് നടത്തുന്നു. ഉപസംഹാരം: മൂല്യ സ്ട്രീം മാപ്പ് സോഫ്‌റ്റ്‌വെയറിലേക്ക് മാത്രമല്ല, ഓർഗനൈസേഷനിലെ എല്ലാ പ്രക്രിയകളിലേക്കും വ്യാപിപ്പിക്കാം.

വേഗത്തിലാക്കുക

പൂർണ്ണമായ തലക്കെട്ട്: "ത്വരിതപ്പെടുത്തുക: മെലിഞ്ഞ സോഫ്റ്റ്‌വെയറിൻ്റെയും ഡെവഓപ്‌സിൻ്റെയും സയൻസ്: ഉയർന്ന പ്രകടനമുള്ള സാങ്കേതിക ഓർഗനൈസേഷനുകളുടെ നിർമ്മാണവും സ്കെയിലിംഗും." ഇതാണ് അടുത്ത ലെവൽ - ഹാർഡ്‌കോർ. പുസ്തകം കഴിഞ്ഞ വർഷം പ്രസിദ്ധീകരിച്ചു, ഇതുവരെ ഇംഗ്ലീഷിൽ മാത്രമാണ്, അത് ഗവേഷണത്തെക്കുറിച്ചാണ്. രചയിതാക്കളായ നിക്കോൾ ഫോർസ്‌ഗ്രെൻ, ജെസ് ഹംബിൾ, ജീൻ കിം എന്നിവർ വർഷങ്ങളായി വ്യത്യസ്‌ത കമ്പനികളിൽ വ്യത്യസ്ത രീതികൾ ഉപയോഗിക്കുകയും ഏതൊക്കെ രീതികളാണ് എന്ത്, എങ്ങനെ എന്നിവയെ ബാധിക്കുകയെന്ന് ഗവേഷണം നടത്തുകയും ചെയ്യുന്നു.

അളവെടുപ്പിനെക്കുറിച്ചുള്ള രണ്ടാമത്തെ അധ്യായത്തിൽ, മൂല്യ സ്ട്രീം മാപ്പ്, ഞാൻ സൂചിപ്പിച്ച മെട്രിക്കുകൾ, കൂടാതെ മറ്റു പലതും പരാമർശിക്കുന്നു, കൂടാതെ അളക്കൽ പ്രക്രിയയെ വിശദമായി വിവരിക്കുന്നു. രചയിതാക്കൾ ചോദ്യാവലികളും സ്വയം ട്രാക്കിംഗ് ജോലികളും ഉപയോഗിച്ച് അളക്കുന്നു. ഏത് അളവുകോലുകളാണ് അളക്കാൻ ശരിയെന്നും ഏതൊക്കെ അളക്കാൻ പാടില്ലെന്നും അളവുകളിലെ മാനുഷിക പിഴവുകളെക്കുറിച്ചും ഇത് വിശദമായി വിവരിക്കുന്നു. അളവുകളിൽ നിങ്ങൾക്ക് ബുദ്ധിമുട്ടുകൾ ഉണ്ടെങ്കിൽ, "ത്വരിതപ്പെടുത്തുക" എന്ന പുസ്തകത്തിൻ്റെ രണ്ടാം അധ്യായം കാണുക. നിങ്ങളുടെ ടീമിന് ധാരാളം പരിശീലനങ്ങൾ ഉണ്ടെങ്കിൽ, എന്നാൽ ഏതൊക്കെ രീതികളാണ് ഇപ്പോൾ പ്രയോഗിക്കേണ്ടത്, ഏതൊക്കെയാണ് പിന്നീട്, ഏതാണ് ശരിക്കും പ്രവർത്തിക്കുന്നത്, ഏതാണ് ചെയ്യാത്തത് എന്ന് വ്യക്തമല്ല - വായിക്കുക, പുസ്തകം എല്ലാം വിശദീകരിക്കുന്നു.

DevOps-ൻ്റെയും മാനേജ്മെൻ്റിൻ്റെയും കവലയിൽ പരിവർത്തനം ഒരു പ്രശ്നമാണ്. വികസനം, പ്രവർത്തനങ്ങൾ, പരിശോധന എന്നിവയുടെ കവലയുടെ അതേ പ്രദേശത്ത് എവിടെയോ ഞങ്ങൾ ചർച്ച ചെയ്യാൻ ശ്രമിക്കുന്ന വിഷയങ്ങളാണ് DevOpsConf, ഒരു ഗുണനിലവാരമുള്ള ഉൽപ്പന്നം സൃഷ്ടിക്കാൻ ഇതേ സംയോജനം ആവശ്യമാണ് - പ്രധാന വിഷയം ക്വാളിറ്റി കോൺഫ്. ഫെസ്റ്റിവൽ മാനേജ്മെൻ്റ് RIT++ സമർപ്പിച്ചു തിമിംഗല റൈഡർ - അതിനർത്ഥം പരിവർത്തനത്തിനുള്ള ആശയങ്ങൾക്കായി എല്ലാവരും ഉണ്ട് എന്നാണ്. മെയ് 27, 28 തീയതികളിൽ ഞങ്ങളോടൊപ്പം ചേരൂ, ഞങ്ങൾ സംയോജിപ്പിക്കുകയും രൂപാന്തരപ്പെടുകയും ചെയ്യും.

അവലംബം: www.habr.com