Рут Маланның алғы сөзімен

Кэтиге, менің өмірлік серігім және отбасымның тірегіне — шаршамайтын махаббатың мен қолдауың үшін рақмет.

Дэн мен Бенге, күнделікті жылулық көздеріне — бұл кітап әкелерінің өмір сүру үшін немен айналысатынын түсінуге көмектеседі деп үміттенемін.

Мэттью Скелтон мен Мануэль Пайс өздерінің бай тәжірибелерін осы әртүрлі командалық формалардың табысты болуы үшін не қажет екенін сипаттауға жұмсады, сонымен қатар контексттегі өзгерістерді атап өтіп, олардың дизайнға әсерін көрсетті және аулақ болу керек анти-паттерндерді белгіледі. Олар сондай-ақ үлкен жомарттықпен басқа жұмыстардан алынған түсініктер мен сілтемелерді біріктіреді. Бұл жағдайлық зерттеулер жиынтығымен бірге кітапты одан әрі байыта түседі.

Командалар әрқашан жетілдіруді қажет ететін процесс болып табылады, бірақ сонымен бірге олар бизнестің мақсаттарына сәйкес келе отырып, құндылықты үздіксіз және тұрақты түрде жеткізудің ең жақсы мүмкіндігі болып табылады. Идеалды жағдайда командалар ұзақ өмір сүретін, автономды және құрамында ынталы мүшелері болуы керек. Дегенмен, командалар оқшауланған күйде өмір сүрмейді. Олар бір-бірімен қалай және қашан әрекеттесу керектігін түсінуі қажет. Және бұл командалық өзара әрекеттесулер өнімдер мен технологиялардың өмірлік циклі кезіндегі ізденіс пен орындаудың ерекше кезеңдерін қолдау үшін уақыт өте келе дамып отыруы тиіс. Қысқасы, ұйымдар тек автономды командаларға ұмтылып қана қоймай, сонымен бірге тұтынушыларға құндылықты тез жеткізу үшін өзін-өзі үздіксіз ойластырып, дамытып отыруы керек.

Бұл кітап біз қолданған және әртүрлі кемелдік деңгейіндегі бизнестерде жұмыс істейтінін көрген ұйымдық дизайнның практикалық, қадамдық, бейімделгіш моделін ұсынады: <span data-term="true">Team Topologies</span> (Командалық топологиялар — командалық құрылымдар мен олардың өзара әрекеттесу үлгілері).

Дегенмен, Team Topologies — бұл бағдарламалық жүйелерді сәтті құру мен іске қосудың әмбебап формуласы емес. Осы жерде сипатталған және ұсынылғаннан мүлдем басқа ұйымдық динамикамен табысқа жеткен командалар мен ұйымдар бар (әсіресе тамаша мәдениеті мен озық тәжірибелері қалыптасқан ұйымдарда).

Team Topologies көптеген әртүрлі командалар мен ұйымдар үшін түсінуге және орындауға оңай нақты үлгілерді ұсынуға арналған, ол үздік ойыншыларға қалай әрекет ету керектігін бұйырмайды. Біз Team Topologies-ті жеке джаз трубашысына арналған әуен емес, оркестр немесе биг-бэндке арналған партитуралар жиынтығы ретінде қарастырғанды ұнатамыз. Үлкен музыкалық ансамбльге арналған ноталар топтың табысқа жетуіне көмектеседі, бірақ орындаудың әрбір аспектісін айқындамайды; көптеген бөлшектерді ансамбль жағдайға, орынға немесе ойыншылардың құрамына қарай өздері түсіндіреді. Сол сияқты, бағдарламалық қамтамасыз етуді жақсы жеткізуге қол жеткізу үшін бірыңғай сөздік қор мен бірлесіп жұмыс істеу тәсіліне келісудің мәні өте зор.

Team Topologies тәсілі өздерінің командалық құрылымын оңтайландыру жолын іздеп жүрген ұйымдарға немесе командалық дизайнның бизнес нәтижелеріне және бағдарламалық жүйелерге тигізетін әсерін әлі түсінбегендерге көмектеседі. Team Topologies ұйымдарға бұрынғыдан да тезірек және үздіксіз табысқа жетуге көмектеседі.

Бұл кітап бағдарламалық жүйелерді жеткізу мен пайдаланудың тиімділігіне бей-жай қарамайтын кез келген адамға арналған: C-деңгейіндегі басшылар (соның ішінде CTO/CIO, CEO, CFO және т. б. ), менеджерлер, бөлім басшылары, бағдарламалық қамтамасыз ету архитекторлары мен жүйелік архитекторлар және осы жүйелерді жеткізу мен іске қосуды тиімдірек еткісі келетін бағдарламалық жүйелерді құруға немесе басқаруға қатысатын кез келген адам үшін.

Мануэль Мэттьюден 2015 жылы QCon London бағдарламалық қамтамасыз етуді әзірлеу конференциясында сұхбат алды, онда Мэттью Конвей заңы мен алғашқы DevOps топологиясының үлгілері туралы баяндама жасаған болатын. Нәтижесінде «Әртүрлі командалық топологиялар DevOps мәдениетіне қалай әсер етеді» атты мақала InfoQ арқылы жарияланып, бірнеше тілге аударылды. Сол жылдың соңында Мануэль DevOps топологиясының үлгілерін кеңейтуге көмектесті және қоғамдастық тарапынан да үлестер қосылды.

Содан бері DevOps топологиясы үлгілерінің қолданылуы күрт өсті. Олар баяндамаларда, мақалаларда және әңгімелерде қайта-қайта сілтеме жасалды. Олар бүкіл әлем бойынша әртүрлі салалардағы және кез келген көлемдегі ұйымдарға командалар арасындағы қарым-қатынастар және олардың өзара әрекеттесуі ұйымдық мәдениетке де, бағдарламалық жасақтама архитектурасына да қалай әсер ететіні туралы ойлануға көмектесті.

Уақыт өте келе біз түпнұсқа DevOps топологиялары командалар арасындағы өзара байланыстардың статикалық көрінісін ұсынғанын түсіндік, бұл бастапқы талқылаулар үшін пайдалы болғанымен, ауқымы жағынан өте шектеулі еді. Дүние жүзіндегі ұйымдарды оқыту мен кеңес берудегі біздің бірлескен тәжірибеміз арқылы кейбір командалар салыстырмалы түрде оқшауланған немесе автономды түрде жақсы жұмыс істейтінін, ал басқа командалар тығыз ынтымақтастықта жақсы жұмыс істейтінін байқадық. Біз мұның себебін сұрадық және клиенттеріміздің кері байланысы негізінде идеяларымызды дамыта бердік.

Ақыр соңында, бұл осы кітапта ұсынылған Team Topologies-ке алып келді: әртүрлі географиялар мен салалардағы нақты сценарийлерге негізделген ұйымдық дизайнға динамикалық және дамымалы тәсіл.

Team Topologies функционалды кітап болуға арналған. Біздің мақсатымыз — интерактивті және осы беттерге сыйдыра алатын барынша көп білім беретін мазмұнды ұсыну. Бұл үшін біз сізге осы кітапты шарлауға көмектесетін кейбір дизайн шешімдерін қабылдадық.

Біріншіден, кітап үш бөлімнен тұрады:

Кітаптың I бөлімі Конвей заңын, ұйымдық өзара байланыстар біз құратын жүйелердің дизайнын қалай шектейтінін және бұл тенденцияны өз пайдамызға қалай қолдана алатынымызды зерттейді. Содан кейін біз командалар дегенді қалай түсінетінімізді анықтаймыз және тиімді командалық жұмысқа әсер ететін кейбір практикалық шектеулерді қарастырамыз.

II бөлімде біз салада өзін дәлелдеген статикалық командалық үлгілер жиынтығын және Конвей заңы мен ұйымдық контекстті ескере отырып, бір үлгіні екіншісінен таңдаудың салдарын зерттейміз. Бұл бөлім сіздің ұйымдық контекстіңізге сәйкес келетін командалық топологиялар туралы ойлануға көмектесуі керек. Сондай-ақ, бұл бөлім Конвей заңы мен іргелі командалық топологияларды ескере отырып, командаларды жүйенің аймақтарына қалай сәйкестендіруді шешуде бағыт-бағдар береді.

Соңында, III бөлімде біз тез өзгеретін жұмыс контекстіне жауап ретінде инновациялар мен жылдам жеткізу үшін қуатты мүмкіндіктерді қамтамасыз ету мақсатында ұйымдық дизайнды дамыту жолдарын қарастырамыз. Біз нарық пен пайдаланушы сұраныстарына жауап беретін «сезімтал» ұйым құру үшін Team Topologies тәсілін қалай қолдану керектігін және мұның жұмысқа қабылдау мен дағдыларға тигізетін салдарын түсіндіреміз.

Әрбір бөлім әр тараудың негізгі тұжырымдарының тізімімен ашылады. Тараулар бойы біз білуге немесе сілтеме жасауға пайдалы деп санайтын ақпаратты ерекшелеу үшін суреттер мен түсіндірмелерді қостық. Сондай-ақ, біз жол бойында оңай танылатын сценарийлерді, кейс-стадилерді және әртүрлі жағдайларға арналған нақты ұсыныстарды береміз.

Ақыр соңында, көптеген суреттерде кездесетін фигуралар, түстер мен үлгілер кітап бойында тұрақты мағынаға ие. Міне, олардың сипаттамасы:

Толық түсіну үшін кітапты басынан аяғына дейін оқып шығу керек, өйткені тақырып тараудан тарауға ұласады. Дегенмен, біз материалды әр бөлім салыстырмалы түрде тәуелсіз болатындай етіп жаздық.

Осы орайда, сіздің қазіргі жағдайыңызға сәйкес келуі мүмкін кітапты оқудың кейбір сценарийлері мен тәсілдері:

Өз тәжірибемізден бөлек, бұл кітапқа бірнеше байланысты тәсілдер мен ойлау бағыттары қатты әсер етті. Біріншіден, біз ұйымды оның ішіндегі жеке тұлғалар мен командалардың өзара әрекеттесуінен қалыптасатын әлеуметтік-техникалық жүйе немесе экожүйе деп санаймыз; басқаша айтқанда, ұйым — бұл адамдар мен технология арасындағы өзара әрекеттесу. Осы аспектіде кітап келесі салалардағы идеялармен сәйкес келеді: кибернетика (әсіресе ұйымды «сезімтал механизм» ретінде пайдалану, бұл Норберт Винердің «Кибернетика немесе жануарлар мен машиналардағы басқару және байланыс» атты кітабы алғаш рет жарық көрген 1948 жылдан бастау алады), жүйелік ойлау (әсіресе У. Эдвардс Демингтің жұмыстары) және домендік күрделілікті бағалауға арналған Cynefin фреймворкі (Дэйв Сноуден мен Мэри Бун 2007 жылғы Harvard Business Review мақаласында сипаттаған) және бейімделгіш структураландыру теориясы (бұл терминді Джерардин ДеСанктис пен Маршалл Скотт Пул енгізген, олар технологияның әсері алдын ала белгілі емес, өйткені ол топтар мен ұйымдардың оны қалай қабылдайтынына байланысты екенін атап өткен).

Екіншіден, біз «команда» — бұл жай ғана адамдар жиынтығынан өзгеше әрекет ететін нәрсе екенін және команданың дамуы мен жұмысында оған қолдау көрсетіп, күту керек деп есептейміз. Осыған байланысты біз Брюс Такманның (1965 жылғы мақаласында команданың дамуының төрт кезеңін — қалыптасу, қақтығыс, қалыпқа келу, нәтиже көрсету — ұсынған), Расс Форрестер мен Аллан Дрекслердің, Памела Найттың, Патрик Ленсионидің (өзінің «Команданың бес ақауы» атты кітабында өзара әрекеттесу мәселелерін зерттейтін) және соған ұқсас командаға бағытталған теориялар мен зерттеулердің идеяларына сүйенеміз.

Ақыр соңында, біз Adidas, Auto Trader, Ericsson, Netflix, Spotify, TransUnion және басқалары сияқты ұйымдарды қоса алғанда, ауқымды бағдарламалық жүйелерді әзірлеу мен іске қосудағы көптеген практикалық жетістіктерді сипаттайтын дереккөздерге жүгінеміз. Бұл ұйымдардың көлемі мен жылдамдығы бірнеше айдан бірнеше жылға дейінгі уақыт ішінде ұйымдық құрылым мен командалық өзара әрекеттесудегі өзгерістерден нақты табыстарды көруге мүмкіндік берді.

Осы кітапты оқу барысында сіз командалар, олардың құрылымдары және олардың қалай жұмыс істейтіні туралы ойлау тәсіліңізге жаңаша қарауға шабыт аласыз деп үміттенеміз.

1-ТАРАУ - Конвей заңы бағдарламалық қамтамасыз ету архитектурасы мен командалық өзара әрекеттесуді бірге жобалаудан үлкен табысқа жетуге болатынын көрсетеді, өйткені олар ұқсас күштер болып табылады. - Team Topologies команданың мақсаты мен жауапкершілігін нақтылайды, бұл олардың өзара байланыстарының тиімділігін арттырады. - Team Topologies бағдарламалық жүйелерді құруға гуманистік тұрғыдан қарайды және ұйымдарды стратегиялық бейімделуге дайындайды.

2-ТАРАУ - Ұйымдар коммуникация жолдарын көрсететін дизайндарды шығаруға мәжбүр. - Ұйымның дизайны мүмкін болатын бағдарламалық қамтамасыз ету дизайндарын шектей отырып, «шешімді іздеу кеңістігін» тарылтады. - Әрбір адамнан әрбір адаммен байланысуды талап ету — бұл былыққа апаратын жол. - Команда аясындағы ағынды ынталандыратын бағдарламалық архитектураларды таңдаңыз. - Коммуникация жолдарын нақты анықталған командалық өзара әрекеттесулермен шектеу модульдік, байланысы аз жүйелерді тудырады.

Технология қызметкерлері тұрақты әрекет үстінде: жүйелерді керемет жылдамдықпен жасайды және жаңартады, сондай-ақ тартымды пайдаланушы тәжірибесін жасау үшін технологияның әртүрлі түрлерін біріктіреді. Мобильді қосымшалар; бұлттық қызметтер; веб-қосымшалар; және кірістірілген, киілетін немесе өнеркәсіптік IoT құрылғылары — бұлардың барлығы қажетті бизнес нәтижелеріне қол жеткізу үшін тиімді түрде өзара әрекеттесуі керек.

Бүгінгі таңда бұл жүйелер адамдардың күнделікті өмірінің барлық аспектілеріне терең әсер етеді. Егер бағдарламалық қамтамасыз ету нашар жобаланған болса — немесе одан да маңыздысы, бағдарламалық қамтамасыз етудің, провайдердің және тұтынушының өзара әрекеттесуінде сәйкессіздік болса — адамдар зардап шегеді. Егер такси шақыру қосымшасы істен шықса, олар үйінен алыс жерде қалып қоюы мүмкін. Интернет-банкингке арналған бағдарламалық қамтамасыз ету немесе процестер істен шықса, олар жалдау ақысын төлей алмауы мүмкін. Егер медициналық құрылғы істен шықса, олардың өміріне қауіп төнуі де мүмкін. Бұрын-соңды нақты әлеуметтік-техникалық дизайн мұндай маңызды болған емес.

Осы өте күрделі, өзара байланысты бағдарламалық жүйелерді құру және іске қосу — бұл әртүрлі платформаларда әртүрлі дағдылары бар адамдардың бірлескен күш-жігерін талап ететін командалық әрекет. Сонымен қатар, заманауи IT ұйымдары бағдарламалық жүйелерді жылдам және қауіпсіз жеткізуі және басқаруы тиіс, сонымен бірге бизнестегі немесе нормативтік ортадағы өзгерістер мен қысымдарға бейімделіп, өсіп отыруы керек. Бизнестер енді тұрақтылықты оңтайландыру мен жылдамдықты оңтайландыру арасында таңдау жасай алмайды.

Бірақ осы тәуекелдер мен талаптарға қарамастан, көптеген ұйымдар әлі де өз адамдары мен командаларын заманауи бағдарламалық қамтамасыз етуді әзірлеу мен пайдалануға кедергі келтіретіндей етіп ұйымдастыруда. Жұмысты бөлу және бақылау үшін ұйымдық схемалар (org charts) мен матрицаларға тым көп сенетін ұйымдар жылдам қарқынмен жеткізе отырып, инновацияларды қабылдауға қажетті жағдайларды жасай алмайды. Бұған қол жеткізу үшін ұйымдарға тұрақты командалар және тиімді командалық үлгілер мен өзара әрекеттесулер қажет. Олар ептілік пен бейімделгіштіктің негізі ретінде өкілеттігі бар, білікті командаларға инвестиция салуы керек. Барған сайын бәсекелестік күшейіп жатқан нарықтарда тірі қалу үшін ұйымдарға контекст өзгергенін сезіп, соған сәйкес дами алатын командалар мен адамдар қажет.

Жақсы жаңалық — командалар мен адамдарды орталыққа қоя отырып, бейімделгіштікке, сондай-ақ қайталануға баса назар аударатын құралдармен және дұрыс ойлау жүйесімен жылдам әрі қауіпсіз болуға болады. Марк Шварц пен оның авторластары 2016 жылғы «Thinking Environments» мақаласында айтқандай, «ұйымдық құрылым жоғары сапалы, әсерлі бағдарламалық қамтамасыз етуді жеткізу мақсаттарын қолдау үшін жауапкершіліктерді үйлестіруі тиіс».

Осы интерфейстерді басқаратын технологиялық командалардың мүшелері ретінде біз ойлау тәсілімізді өзгертуіміз керек: командаларды «дұрыс» процесті орындап, «дұрыс» құралдарды қолданған жағдайда табысқа жететін алмастырылатын адамдар жиынтығы ретінде қарастырудан, адамдар мен технологияны біртұтас адам/компьютер, көміртекті/кремнийлі әлеуметтік-техникалық экожүйе ретінде қарастыруға көшуіміз керек. Сонымен қатар, біз мұндай жүйе ішінде командалардың ішкі мотивациясы болуын және оларға өз жұмысын барынша жақсы атқаруға нақты мүмкіндік берілуін қамтамасыз етуіміз керек.

Бұл тарау Team Topologies-ті бизнеске жылдамдық пен тұрақтылыққа қол жеткізуге мүмкіндік беретін технологиялық ұйым дизайнының бейімделгіш моделі ретінде таныстырады. Бірақ алдымен, көптеген ұйымдардағы нақты коммуникациялық құрылымдар ұйымдық схема бізге айтатын нәрседен қалай ерекшеленетінін және мұның салдары қандай екенін қарастырайық.

Көптеген ұйымдар өз командалары мен адамдарының «ұйымдық схема» (org chart) деп аталатын бірыңғай көрінісін қалайды немесе болуы талап етіледі. Бұл схема командаларды, бөлімдерді, бөлімшелерді және басқа ұйымдық бірліктерді, сондай-ақ олардың бір-бірімен қалай байланысатынын көрсетеді. Ол әдетте ұйымның «жоғары және төмен» бағытындағы коммуникация желілерін білдіретін иерархиялық есеп беру желілерін көрсетеді.

Ұйымдық схеманың бағдарламалық жүйелерді құру контекстінде, әсіресе нормативтік және заңды сәйкестікке қатысты өз пайдасы бар. Дегенмен, нәтижелерге қатысты белгісіздікке толы тығыз ынтымақтастық контекстінде атқарылатын жұмысты бөлудің негізгі механизмі ретінде ұйымдық схемаға сену шындыққа жанаспайтын күтулерге алып келеді. Оның орнына біз жылдамдық пен қауіпсіздікті теңестіру міндетін орындау үшін тиімді жұмыс істей алатын оқшауланған, ұзақ өмір сүретін командаларға сенуіміз керек.

Ұйымдық схеманы шындық ретінде қабылдаудың мәселесі — біз ақыр соңында адамдарды бағдарламалық қамтамасыз ету сияқты архитектуралауға тырысамыз, олардың қарым-қатынасын қабылданған желілер ішінде ұқыпты сақтаймыз. Бірақ адамдар өз коммуникацияларын схемадағы сол қосылған желілермен ғана шектемейді. Біз жұмысты аяқтау үшін кімге тәуелді болсақ, соған жүгінеміз. Мақсаттарымызға жету үшін қажет болған жағдайда ережелерді бұзамыз. Сондықтан нақты коммуникация желілері 1. 1-суретте көрсетілгендей ұйымдық схемадан мүлдем басқаша көрінеді.

Іс жүзінде адамдар жұмысты орындау үшін басқа есеп беру желілеріндегі адамдармен көлденеңінен немесе «горизонталды» сөйлеседі. Бұл шығармашылық пен мәселелерді шешу қабілетін ұйымның игілігі үшін дамыту керек, оны жоғарыдан төменге/төменнен жоғарыға коммуникация мен есеп беруді оңтайландыру үшін шектемеу керек.

Дәстүрлі ұйымдық схемалар біздің ұйымдағы коммуникацияның нақты үлгілері қандай екенін түсінуге көмектеспейді, бұл 1. 1-суретте көрсетілген. Оның орнына ұйымдар жеке тұлғалар мен командалар арасындағы күтілетін және нақты болып жатқан коммуникацияның шынайырақ көрінісін жасауы керек. Олқылықтар ұйым үшін жүйелердің қандай түрлері қолайлы екенін анықтауға көмектеседі.

Сонымен қатар, ұйымдық схема құрылымына негізделген шешімдер жоғары және төменгі ағындық әсерлерді ескермей, ұйымның тек бір бөлігін ғана оңтайландыруға бейім келеді. Локалды оңтайландырулар тікелей қатысатын командаларға көмектеседі, бірақ олар міндетті түрде тұтынушыларға құндылықты жеткізудің жалпы процесін жақсартуға көмектеспейді. Егер жұмыс ағынында үлкенірек кедергілер болса, олардың әсері мардымсыз болуы мүмкін. Мысалы, командалардың бұлттық технологияларды және код ретіндегі инфрақұрылымды қолдануы жаңа инфрақұрылымды орнату уақытын апталардан немесе айлардан минуттарға немесе сағаттарға дейін қысқартуы мүмкін. Бірақ егер әрбір өзгеріс аптасына бір рет жиналатын кеңестің мақұлдауын талап етсе, онда жеткізу жылдамдығы ең жақсы жағдайда апта сайын болып қала береді.

Жүйелік ойлау бүкіл жұмыс ағынын қарастырып, бүгінгі таңдағы ең үлкен кедергінің не екенін анықтап, оны жою арқылы тұтастықты оңтайландыруға бағытталған. Содан кейін қайталау. Team Topologies командаларға жаңа жағдайларға тез бейімделуге және бағдарламалық қамтамасыз етуді жылдам әрі қауіпсіз жеткізуге көмектесетін динамикалық командалық құрылымдар мен өзара әрекеттесу режимдерін қалай орнатуға болатынына назар аударады. Бұл бүгінгі күні сіздің ең үлкен кедергіңіз болмауы мүмкін, бірақ ақыр соңында сіз коммуникациясы нашар және/немесе процестері сәйкес келмейтін, жеткізуді баяулататын қатаң командалық құрылымдар мәселесіне тап боласыз.

Ұйымдық схеманы (org chart) жұмыстың қалай орындалатынының және командалардың бір-бірімен қалай әрекеттесетінінің шынайы көрінісі ретінде қарастыру — жұмыс пен жауапкершілікті бөлудегі тиімсіз шешімдерге әкеледі. Бағдарламалық жасақтаманың архитектуралық құжаты әзірлеу басталған бойда ескіретіні сияқты, ұйымдық схема да әрдайым шындықпен сәйкес келмейді.

Әрине, ресми ұйымдық құрылымдар мен жұмыстың нақты орындалу тәсілі арасындағы тепе-теңдіктің бұзылуын алғаш болып біз байқаған жоқпыз. Гири Раммлер мен Алан Брачтың "Өнімділікті арттыру: Ұйымдық схемадағы ақ кеңістікті қалай басқаруға болады" атты кітабы бизнесті үздіксіз жетілдіруге және басқаруға негіз қалады. Соңғы кездері (кем дегенде АТ саласында) Мик Керстеннің жобадан өнімге көшу туралы кітабында сипатталғандай, өнім мен командаға басымдық беру тағы бір маңызды кезең болды. Біз Team Topologies тәсілін осы пазлдың тағы бір бөлігі — атап айтқанда, командалардың анық әрі икемді құрылымдарын, жауапкершіліктерін және өзара әрекеттесу режимдерін айқындау деп санаймыз.

Сонымен, егер ұйымдық схемалар ұйымдық құрылымдардың дәл көрінісі болмаса, онда не дәл? "Күрделілікке арналған ұйымдастыру" (Organize for Complexity) авторы Нильс Пфлаегинг әрбір ұйымда бір емес, үш түрлі ұйымдық құрылымды анықтайды:

Пфлаегингтің пікірінше, білімге негізделген сәтті ұйымдардың кілті — бейресми құрылым мен құндылық жасау құрылымы арасындағы өзара әрекеттесуде (яғни, адамдар мен командалар арасындағы байланыс). Фредерик Лалу ("Ұйымдарды қайта құру") немесе Брайан Робертсон (Холакратия тәсілі) сияқты басқа авторлар да осыған ұқсас сипаттамалар ұсынған.

Team Topologies тәсілі Пфлаегинг анықтаған бейресми және құндылық жасау құрылымдарының маңыздылығын мойындайды. Командаларға өкілеттік беру және оларды іргелі құрылыс блоктары ретінде қарастыру арқылы команда ішіндегі адамдар жай топ емес, нағыз команда ретінде әрекет ету үшін бір-біріне жақындай түседі. Екінші жағынан, басқа командалармен өзара әрекеттесу режимдерін нақты келісу арқылы мінез-құлыққа қатысты күтулер айқындалып, командааралық сенім артады.

Team Topologies тәсілі дәстүрлі ұйымдық дизайнда жетіспейтін, технологиялық ұйымдар үшін қажетті динамикалық және "сезу" (sensing) аспектілерін қосады.

Қазіргі заманғы бағдарламалық жүйелердің тиімді нәтижелері үшін ұйымдық схема немесе матрицалық басқару сияқты бір ғана статикалық ұйымдық құрылымға сену мүмкін емес екені барған сайын анық болып келеді. Бір ғана құрылымның орнына қазіргі жағдайға бейімделетін, командалардың қалай өсетінін және бір-бірімен қалай әрекеттесетінін ескеретін модель қажет. Team Topologies барлық ұйымдар үшін командаларды, процестерді және технологияларды сәйкестендіруге қажетті (р)эволюциялық тәсілді ұсынады.

Наоми Стенфорд өзінің 2015 жылғы "Ұйымдық дизайн бойынша нұсқаулық" атты тамаша кітабында ұйымдарды жобалаудың бес ережесін атап өтеді:

Осы кітапты оқу барысында біз ұйымдық дизайнға арналған осы бес эвристиканы қалай жүзеге асыру керектігін зерттейтін боламыз.

Team Topologies тәсілі корпоративтік бағдарламалық жасақтаманы жеткізу үшін тиімді командалық құрылымдар туралы жаңа ойлау тәсілін әкеледі. Ол технологиялық, адамдық және бизнестік өзгерістерге үздіксіз төтеп беру үшін команда дизайнын дамыту бойынша дәйекті, іс-қимылға негізделген нұсқаулықты ұсынады. Бұл нұсқаулық қазіргі заманғы бағдарламалық жүйелерді құратын және басқаратын командалардың өлшемін, пішінін, орналасуын, жауапкершіліктерін, шекараларын және өзара әрекеттесуін қамтиды.

Атап айтқанда, ол әртүрлі командалық топологиялардың технологиялық және ұйымдық кемелденуіне қарай қалай дами алатынын қарастырады. Техникалық және өнімді зерттеу кезеңдері сәтті болу үшін әдетте жоғары деңгейдегі ынтымақтастық ортасын (командалық шекаралардың бір-бірімен тоғысуымен) талап етеді. Бірақ зерттеу аяқталғаннан кейін (технологиялар мен өнім қалыптасқанда) сол құрылымдарды сақтап қалу күшті босқа жұмсауға және түсініспеушіліктерге әкелуі мүмкін.

Ұйымдық дизайнның бейімделгіш моделіне баса назар аудара отырып және командалардың өзара байланысына белсенді түрде басымдық бере отырып, Team Topologies тәсілі қазіргі заманғы бағдарламалық қамтамасыз етуге негізделген кәсіпорындар үшін стратегияны (бизнес немесе технология тұрғысынан) қашан өзгерту керектігін сезудің негізгі механизмін ұсынады. Түпкі мақсат — командаларға тұтынушы қажеттіліктеріне сәйкес келетін және құруға, басқаруға және иелік етуге оңай бағдарламалық жасақтаманы шығаруға көмектесу.

Team Topologies сонымен қатар бағдарламалық жүйелерді жобалау мен құруға гуманистік көзқараспен қарауды насихаттайды. Ол команданы бағдарламалық жасақтаманы жеткізудің бөлінбейтін элементі ретінде қарастырады және командалардың құрметтелуі тиіс шектеулі когнитивті сыйымдылығы бар екенін мойындайды. Конвей заңына негізделген динамикалық команда дизайнымен бірге Team Topologies шешімдерді табудың стратегиялық құралына айналады.

Біз Конвей заңының команда дизайны мен эволюциясының қозғаушы күші ретіндегі маңыздылығын атап өттік. Бірақ бұл заң нақты не туралы?

1968 жылы компьютерлік жүйелерді зерттеуші Мел Конвей "Datamation" журналында "Комитеттер қалай ойлап табады? " атты мақаласын жариялады, онда ол ұйымдық құрылым мен жүйелердің нәтижесіндегі дизайны арасындағы байланысты зерттеді. Мақала терең түсініктерге толы, бірақ Конвей заңы ретінде танымал болған фраза мынау:

Конвей өз бақылауын алғашқы электронды компьютерлік жүйелерді құратын ұйымдарға негіздеді. Оның айтуынша, бұл "заң" ұйымның нақты коммуникация жолдары мен нәтижесінде пайда болатын бағдарламалық архитектура арасындағы немесе автор Аллан Келли "гомоморфты күш" (бірдей пішінге келтіруші күш) деп атайтын құбылыс арасындағы күшті корреляцияны көрсетеді. Бұл гомоморфты күш бағдарламалық архитектура мен командалық құрылымдар арасындағы заттарды бірдей пішінге келтіруге бейім. Басқаша айтқанда, бағдарламалық жасақтаманы құру бағдарламалық архитектураның қандай түрлері мүмкін екенін шынайы қарастыру үшін командалар арасындағы коммуникацияны түсінуді талап етеді. Егер қажетті теориялық жүйе архитектурасы ұйымдық модельге сәйкес келмесе, онда екеуінің бірі өзгеруі керек.

Эрик Рэймонд мұны өзінің "Жаңа хакер сөздігі" атты кітабында әзілмен былай деп білдірді: "Егер сізде компилятормен жұмыс істейтін төрт топ болса, сіз 4 кезеңді компилятор аласыз".

1968 жылдан бері Конвей заңының барлық құрылған бағдарламалық жасақтамаларға қолданылатыны барған сайын анық бола түсті. Архитектуралық жоспарға сәйкес келуі тиіс бағдарламалық жүйелерді құрғандарымыз, архитектура бізге көмектесудің орнына, онымен күресіп жатқандай сезінген кездерімізді еске түсіре аламыз. Бұл — Конвей заңының іс жүзіндегі көрінісі.

Мұндағы басты қорытынды — бағдарламалық архитектураны оқшауланған күйде жобалауға болатын және содан кейін кез келген командалар тобы жүзеге асыра алатын дербес тұжырымдама ретінде қарастыру түбегейлі қате. Архитектура мен командалық құрылымдар арасындағы бұл алшақтық клиент-серверден бастап SOA-ға, тіпті микросервистерге дейінгі архитектураның барлық түрлерінде байқалады. Дәл сол себепті монолиттерді (атап айтқанда, кез келген бір команданың когнитивті сыйымдылығынан асатын кез келген бөлінбейтін бағдарламалық бөлікті) командаға назар аудара отырып бөлшектеу қажет, бұл тақырыпты біз 6-тарауда егжей-тегжейлі талқылайтын боламыз.

Когнитивті жүктеме туралы айтқанда, кез келген адамның кез келген уақытта миында қанша ақпарат ұстай алатынының шегі бар екенін түсіну оңай. Команданың барлық мүшелерінің когнитивті мүмкіндіктерін қосу арқылы кез келген команда үшін де солай болады.

Дегенмен, біз белгілі бір командаға жауапкершіліктерді немесе бағдарламалық бөліктерді тағайындаған кезде когнитивті жүктемені сирек талқылаймыз. Мүмкін, бұл қолжетімді сыйымдылықты да, когнитивті жүктеменің қандай болатынын да сандық түрде анықтау қиын болғандықтан шығар. Немесе командадан сұрақ қоймай, тапсырылған іске бейімделуі күтілетіндіктен болар.

Когнитивті жүктеме ескерілмегенде, командалар шамадан тыс жауапкершіліктер мен домендерді қамтуға тырысып, күштері таусылады. Мұндай команданың өз ісінің шебері болуға мүмкіндігі болмайды және контексттерді жиі ауыстырудың зардабын тартады.

Мигель Антунес, OutSystems компаниясының ҒЗТКЖ бойынша жетекші инженері, осы қиындықтың мысалын келтірді. Олардың OutSystems-тегі Engineering Productivity командасы бес жаста еді. Команданың миссиясы өнім командаларына жинақтарды (builds) тиімді орындауға, инфрақұрылымды қолдауға және тестілеуді жақсартуға көмектесу болатын. Команда өсе келе, үздіксіз интеграция (CI), үздіксіз жеткізу (CD) және инфрақұрылымды автоматтандыру бойынша қосымша жауапкершіліктерді алды.

Өз жетістіктерінің құрбаны болған, сегіз адамнан тұратын команданың спринтті жоспарлауы әртүрлі жауапкершіліктер бойынша сұраныстардың жиынтығына айналды. Басымдық беру қиын болды, тіпті бір спринт ішінде контекстті жиі ауыстыру адамдардың мотивациясының төмендеуіне әкелді. Егер біз Дэн Пинктің ішкі мотивацияның үш элементін қарастырсақ, бұл таңқаларлық емес: автономия (бірнеше команданың сұраныстары мен басымдықтарын үнемі жонглерлік етуден жойылды), шеберлік ("бәрін біледі, бірақ ештеңенің маманы емес") және мақсат (жауапкершілік домендері тым көп).

Бұл мысалдағы команда әзірлеушілер командаларына ішкі қызметтер көрсеткенімен, сыртқы тұтынушыларға арналған бағдарламалық жасақтамамен жұмыс істейтін командалар үшін де әсері бірдей. Өнім командасы жауап беретін қызметтер мен компоненттердің саны (басқаша айтқанда, командаға түсетін сұраныс) әдетте уақыт өте келе өсе береді. Дегенмен, жаңа қызметтерді әзірлеу көбінесе команданың бос уақыты толық және когнитивті жүктемесі нөлге тең сияқты жоспарланады. Бұл немқұрайлылық проблемалық болып табылады, өйткені командадан бұрыннан бар қызметтерді жөндеу және жақсарту әлі де талап етіледі. Соңында команда жеткізу кедергісіне (bottleneck) айналады, өйткені олардың когнитивті сыйымдылығы шамадан тыс асып кеткен, бұл кідірістерге, сапа мәселелеріне және жиі команда мүшелерінің мотивациясының төмендеуіне әкеледі.

Біз команданы бірінші орынға қойып, олардың когнитивті жүктемелерін шектеуді жақтауымыз керек. Когнитивті жүктеме туралы нақты ойлану команда өлшемін шешуде, жауапкершіліктерді тағайындауда және басқа командалармен шекараларды орнатуда қуатты құрал бола алады. (Біз мұны 3-тарауда егжей-тегжейлі қарастырамыз. )

Жалпы алғанда, Team Topologies тәсілі өзгерістер ағыны мен жұмыс істеп тұрған жүйелерден келетін кері байланысты оңтайландыратын ұйымдық дизайнды жақтайды. Бұл командаларға түсетін когнитивті жүктемені шектеуді және бізге қажетті бағдарламалық жүйелер архитектурасын жасауға көмектесу үшін олардың арасындағы өзара байланысты нақты жобалауды талап етеді (Конвей заңына негізделген).

Қазіргі заманғы, өзара байланысқан жүйелер мен қызметтер үшін бағдарламалық жасақтаманы тиімді әзірлеу және пайдалану ұйымдардан көптеген әртүрлі аспектілерді ескеруді талап етеді. Тарихи тұрғыдан алғанда, ұйымдардың көбі бағдарламалық жасақтаманы әзірлеуді функционалдық мамандықтарға бөлінген жеке тұлғалар орындайтын, ірі жобалары алдын ала жоспарланатын және әлеуметтік-техникалық динамика аз ескерілетін өндірістің бір түрі ретінде қарастырды. Бұл 12-беттегі 1. 2-суретте көрсетілген басым мәселелерге әкелді.

Agile, Lean IT және DevOps қозғалыстары бизнес ағынына сәйкес келетін, шағын, итеративті циклдермен әзірлейтін және шығаратын, сондай-ақ пайдаланушылардың кері байланысы негізінде бағытын түзетіп отыратын кішігірім, автономиялық командалардың орасан зор құндылығын көрсетуге көмектесті. Lean IT және DevOps сонымен қатар жүйелер мен командалар үшін телеметрия мен метрика құралдарын дамытуға ықпал етті, бұл бағдарламалық жасақтаманы құратын және басқаратын адамдарға мәселелер туындаған кезде жай ғана жауап берудің орнына, өткен тенденциялар негізінде белсенді, ерте шешімдер қабылдауға көмектесті.

Дегенмен, дәстүрлі ұйымдар өздерінің ұйымдық модельдеріне байланысты Agile, Lean IT және DevOps артықшылықтарын толық пайдалануда жиі шектеулерге тап болды. Мәдени және ұйымдық өзгерістер бейберекет шешіліп жатқанда, дереу автоматтандыруға және құралдарды енгізуге баса назар аударылуы таңқаларлық емес. Соңғы өзгерістерді визуалды түрде көрсету, тіпті олардың тиімділігін өлшеу әлдеқайда қиын. Дегенмен, дұрыс командалық құрылымның, тәсілдің және өзара әрекеттесудің болуы және олардың уақыт өте келе даму қажеттілігін түсіну — ұзақ мерзімді перспективада табыстың негізгі саралаушысы болып табылады.

Атап айтқанда, дәстүрлі ұйымдық схемалар белгісіздік пен жаңалыққа толы ортадағы бірлескен білім жұмысы үшін командаларды жиі қайта құрудың жаңа шындығына сәйкес келмейді. Оның орнына, біз Конвей заңын (ұйымдық дизайн бағдарламалық архитектура дизайнынан басым болады), когнитивті жүктеме шектеулерін және нақты мақсаттары бар командаларды жобалау үшін "командаға басымдық беру" тәсілін пайдалануымыз керек, сондай-ақ бағдарламалық жасақтаманы жеткізу ағыны мен стратегиялық бейімделгіштікке басымдық беретін командалық өзара әрекеттесуді ынталандыруымыз қажет.

Team Topologies мақсаты — ұйымыңызға бейімделуге және ынтымақтастық қажет болатын орындар мен уақытты, сондай-ақ орындауға назар аударып, коммуникациялық шығындарды азайту жақсы болатын кезді динамикалық түрде табуға мүмкіндік беретін тәсіл мен ойлау құралдарын беру.

1-тарауда біз неліктен ұйымдар командалық ұйымдастыруды табыстың ажырамас факторы ретінде қарастыруы керектігін талқыладық. Сондай-ақ, командалардың ұйым ішінде қалай жұмыс істейтінін түсінуге көмектесетін негізгі идеялар мен принциптерді қарастырдық. Кітап барысында біз негізге алатын кейбір маңызды ұғымдарды енгіздік. I бөлімнің қалған тарауларында біз Конвей заңының командалар, ұйымдық құрылым және бағдарламалық архитектура туралы не ашатынын егжей-тегжейлі талқылаймыз; содан кейін "командаға басымдық беру" тәсілінің нені білдіретінін қарастырамыз. I бөлімнің мақсаты — Team Topologies-ті қарастыра бастағанда түсінуіңіз керек ұйымдық және командалық дизайнның іргелі принциптерін беру.

Конвей заңы командаларды ұйымдастыру кезіндегі күштерді түсіну үшін өте маңызды, себебі олар біздің бағдарламалық жүйелерімізге ұзақ мерзімді әсер етеді, өйткені соңғылары бұрынғыдан да үлкен және өзара байланысты бола бастады. Бірақ сіз 1968 жылғы бағдарламалық архитектура туралы заң уақыт сынынан өтті ме деп ойлауыңыз мүмкін.

Біз бәрібір үлкен жолдан өттік: микросервистер, бұлтты технологиялар, контейнерлер, серверсіз есептеулер. Біздің тәжірибемізде мұндай жаңалықтар командаларға жергілікті жерде жақсаруға көмектеседі, бірақ ұйым неғұрлым үлкен болса, соғұрлым толық пайда алу қиындай түседі. Командалардың құрылу және өзара әрекеттесу тәсілі көбінесе өткен жобаларға және/немесе ескі технологияларға негізделген (бұл ондаған жылдар болмаса да, бірнеше жыл бұрынғы ұйымдық схема дизайнын көрсетеді).

Егер сіз қашан да үлкен ұйымда жұмыс істеген болсаңыз, бүкіл бизнесті жұмыс істетіп тұрған монолитті ортақ дерекқорлардың мысалдарын көрген боларсыз. Әрине, DevOps пен микросервистер пайда болғанға дейін монолитті дерекқорлардың басым болуының негізді тарихи себептері болды (мысалы, техникалық стек қабаттары бойынша адамдар мен командалардың мамандануының артуы). Жобаға бағытталу, аутсорсинг арқылы шығындарды азайту немесе тәжірибесі жеткіліксіз жас командалар сияқты факторлар бұл (қазір танымал) анти-патерннің сақталуына ықпал етті. Монолитті дерекқорлар оларға тәуелді бағдарламаларды бір-бірімен байланыстырады және дерекқор деңгейіндегі шағын бизнес-логикалық өзгерістер үшін магнитке айналады (бұл туралы 6-тарауда толығырақ). Дегенмен, оларды болдырмау үшін ұйымдарға тек жақсы архитектуралық тәжірибелер ғана емес, сонымен қатар осы жаңа ойлау тәсіліне сәйкес келетін нақты командалық құрылымдар мен құрам қажет.

Команданы бірінші орынға қою тәсілінде бүкіл команда ортақ күш-жігері үшін марапатталады. 1990-шы және 2000-шы жылдардағы табысты кезеңінде Nokia технологиялық компаниясындағы жұмыстың айқындаушы ерекшеліктерінің бірі мынадай болды: «Ұйым бойынша жалақы айырмашылығы төмендетілді. Бонустар аз болды және әдетте жеке емес, командалық негізде және компанияның жалпы көрсеткіштеріне байланысты төленді». 21

Дәл осы қағиданы оқыту бюджеттеріне де қолдануға болады. Команданы бірінші орынға қою тәсілінде әрбір жеке тұлғаға емес, бүкіл командаға бірыңғай оқыту бюджеті бөлінеді. Егер команда бір адамды жыл бойы алты немесе жеті конференцияға жібергісі келсе (себебі ол алған білімін командаға өте жақсы жеткізе біледі), бұл команданың өз шешімі болуы керек.

Когнитивті жүктеме код жазумен аз айналысатын, бірақ дәстүрлі операциялық немесе инфрақұрылымдық команда сияқты тапсырмаларды орындаумен көбірек айналысатын командаларға да қатысты. Олар да жауапкершілік салалары, басқаруы тиіс қосымшалар саны мен құралдар тұрғысынан шамадан тыс когнитивті жүктемеден зардап шегуі мүмкін.

Команданы бірінші орынға қою тәсілінде команданың міндеттері ол көтере алатын когнитивті жүктемеге сәйкес келеді. Бұның оң әсері командалардың қалай құрылатынын және олардың ұйым бойынша бір-бірімен қалай әрекеттесетінін өзгерте алады.

Бағдарламалық жасақтаманы жеткізу командалары үшін когнитивті жүктемеге командалық тұрғыдан қарау — команда жұмыс істейтін жүйенің көлемін шектеуді білдіреді; яғни ұйымдар бағдарламалық жүйенің когнитивті жүктемеден асып кетуіне жол бермеуі керек. Бұл бағдарламалық жүйелердің формасы мен архитектурасына үлкен және түбегейлі әсер етеді, бұны біз кітаптың келесі бөлімдерінде көреміз.

Жалпы айтқанда, заманауи бағдарламалық жүйелерді тиімді жеткізу және пайдалану үшін ұйымдар ішкі когнитивті жүктемені азайтуға (оқыту, технологияларды дұрыс таңдау, жұмысқа алу, жұптық бағдарламалау және т. б. арқылы) және сыртқы когнитивті жүктемені толығымен жоюға (жұмыс жадында сақтаудың мәні аз және автоматтандыруға болатын жалықтыратын немесе артық тапсырмалар) тырысуы керек. Бұл маңызды когнитивті жүктемеге (яғни, «қосымша құн» тудыратын ойлау процесіне) көбірек орын қалдырады.

Осы тараудың басында көргеніміздей, бағдарламалық жүйелерді құратын және басқаратын команда үшін жетіден тоғыз мүшеге дейінгі тиімді максималды шек бар (34-беттегі 3. 1-суретті қараңыз), сондықтан белгілі бір команда көтере алатын когнитивті жүктеменің де шегі болады. Көптеген ұйымдар бағдарламалық жүйенің бөліктеріне жауапкершілік тағайындау кезінде командалардың когнитивті жүктемесін ескермейді, керісінше, мәселеге көбірек команда қосу арқылы когнитивті жүктеме командалар арасында бөлінеді деп есептейді. Оның орнына, командалар Брукс заңында айтылғандай коммуникация мен өзара әрекеттесу қиындықтарынан зардап шегеді.

Егер біз командаға оның когнитивті мүмкіндігінен тыс жүйе бөлігі үшін жауапкершілік беріп, оған қысым жасасақ, ол жоғары нәтижелі бірлік ретінде жұмыс істеуін тоқтатады. Команда мүшелері бұл шешімдердің команда мүддесіне сай келетінін ойлауға мұршасы болмай, тек өз тапсырмаларын орындауға тырысатын жеке тұлғалардың тобына айналады.

Команда үшін когнитивті жүктемені шектеу — команда жұмыс істейтін жүйе асты бөлігінің немесе аймағының көлемін шектеуді білдіреді. Дрискелл мен оның әріптестері өздерінің ғылыми мақаласында мынадай тактиканы ұсынды: «Тиімді командалық жұмыс маңызды болып табылатын жағдайларда, тапсырманы жеңілдету үшін оны құрылымдау қажет болуы мүмкін (яғни, ішкі тапсырмаларды басқаларға тапсыру арқылы), осылайша назар негізгі тапсырма мен командалық жұмысқа аударылады». 24

Сонымен қатар, командаға қазіргі ішкі және сыртқы жүктемені (оқыту, жаттығу, автоматтандыру және басқа да пайдалы әдістер арқылы) үнемі азайтуға тырысу үшін мүмкіндік беру керек.

Когнитивті жүктемені бағалаудың қарапайым және жылдам жолы — командадан ешқандай сынсыз сұрау: «Сіз өзіңізді тиімді сезінесіз бе және сізге берілген жұмысқа уақтылы жауап бере аласыз ба? »

Когнитивті жүктемені өлшегенде, бізді шын мәнінде доменнің күрделілігі қызықтырады — бағдарламалық жасақтама арқылы шешуге тырысатын мәселеміз қаншалықты күрделі? Домен (сала) — бағдарламалық жасақтама көлеміне қарағанда кеңірек ұғым. Мысалы, үздіксіз жеткізуді (CD) қолдау үшін құралдар тізбегін іске қосу және дамыту әдетте көптеген құралдарды біріктіруді және тестілеуді талап етеді. Біраз автоматтандыру коды қажет болады, бірақ ол тұтынушыға арналған қосымшаны құруға қажетті кодтан әлдеқайда аз. Домендер бізге жалпылама ойлауға және ортақ эвристикаларды қолдануға көмектеседі.

Когнитивті жүктеме үшін нақты формула болмаса да, біз белгілі бір команда жауапты домендердің санын және салыстырмалы күрделілігін (ұйым ішіндегі) бағалай аламыз. Бірінші тарауда айтқан OutSystems компаниясының Engineering Productivity командасы өздері жауапты домендердің (құрастыру және үздіксіз интеграция, үздіксіз жеткізу, тестілеуді автоматтандыру және инфрақұрылымды автоматтандыру) өздерін шамадан тыс жүктегенін түсінді. Команда үнемі тым көп жұмысқа тап болды және контекстті ауыстыру (бір жұмыстан екіншісіне көшу) басым болды. Командада домендік білім жеткіліксіз деген жалпы сезім болды, бірақ оны меңгеруге инвестиция салуға уақыт болмады. Іс жүзінде олардың когнитивті жүктемесінің көп бөлігі сыртқы (артық) болды, бұл маңызды ішкі немесе маңызды жүктемеге өте аз орын қалдырды.

Команда әрқайсысы бір доменге/өнім аймағына жауапты микро-командаларға бөліну туралы батыл шешім қабылдады: IDE өнімділігі, платформалық сервер өнімділігі және инфрақұрылымды автоматтандыру. Өнімділік бойынша екі микро-команда тиісті өнім аймақтарымен сәйкестендірілді. Домендер бір-бірімен сирек қабаттасатын; сондықтан бұрынғы бір командалық модель ережеге емес, ерекше жағдайларға оңтайландырылған еді. Жаңа құрылымда командалар домен аралық мәселелер бойынша тығыз жұмыс істеді (тіпті қажет болған жағдайда уақытша микро-командалар құрды), бірақ бұл тұрақты құрылым емес еді.

Бірнеше айдан кейін нәтижелер олардың ең жақсы күткендерінен де асып түсті. Әрбір микро-команда бір доменді меңгеруге назар аудара алғандықтан, мотивация артты (сонымен қатар оларда енді жетекші болмады, бұл командалық шешімдерге мүмкіндік берді). Әр команданың миссиясы түсінікті болды, контекстті ауыстыру азайды және команда ішілік байланыс жиіледі. Тұтастай алғанда, жұмыс ағыны мен сапасы айтарлықтай жақсарды.

Анықтап айтсақ, «бұл команда үшін домендердің дұрыс саны мен түрі осы ма? » деген сұраққа нақты жауап жоқ. Домендер де, команданың когнитивті мүмкіндігі де тұрақты емес. Бірақ доменнің салыстырмалы күрделілігі туралы ой толғау командалардың жауапкершілігі мен шекараларын қалыптастыруға көмектеседі. Доменнің күрделілігіне күмәнданған кезде, әрқашан жауапты команданың сезіміне басымдық беріңіз. Көбірек доменді бір командаға сыйғызу үшін күрделілікті төмендетіп көрсету (мысалы, «Үздіксіз жеткізуге арналған құралдар көп — бұл қиын емес») тек сәтсіздікке әкеледі.

Бірінші эвристика — әр доменді бір командаға тағайындау. Егер домен бір команда үшін тым үлкен болса, бір доменнің жауапкершілігін бірнеше командаға бөлмей, алдымен доменді ішкі домендерге бөліп, содан кейін әрбір жаңа ішкі доменді бір командаға тағайындаңыз. (Үлкен домендерді қалай бөлуге болатыны туралы көбірек ақпаратты 6-тараудан қараңыз. )

Екінші эвристика — бір команда (жетіден тоғыз адамға дейінгі оңтайлы мөлшерді ескере отырып) екі-үш «қарапайым» доменді қамти алуы керек. Мұндай домендер процедуралық сипатта болғандықтан, домендер арасында контекстті ауыстыру шығыны төзімдірек болады, себебі жауаптар механикалық болып келеді. Бұл контекстте команда үшін қарапайым домен — бұл тек шағын, кездейсоқ, қарапайым өзгерістері бар ескі бағдарламалық жүйе болуы мүмкін. Дегенмен, жұмыстың күнделікті сипатына байланысты команда мүшелерінің мотивациясы төмендеу қаупі бар.

Үшінші эвристика — өте күрделі доменге жауапты командаға басқа домен берілмеуі керек, тіпті қарапайым болса да. Бұл жұмыс ағынының бұзылу шығынына (күрделі мәселелерді шешу уақыт пен зейінді талап етеді) және басымдық беруге (қарапайым, болжамды мәселелерді олар пайда болған бойда шешуге бейімділік болады, бұл бизнес үшін маңызды өте күрделі мәселелердің шешілуін одан әрі кешіктіреді) байланысты.

Соңғы эвристика — екі күрделілеу доменге жауапты бір командадан аулақ болу. Бұл сегіз немесе тоғыз адамнан тұратын үлкенірек командада мүмкін болып көрінуі мүмкін, бірақ іс жүзінде команда екі ішкі команда (әр доменге біреуден) ретінде әрекет етеді, бірақ бәрінен екі доменді де білу талап етіледі, бұл когнитивті жүктемені және үйлестіру шығындарын арттырады. Оның орнына, команданы бес адамнан тұратын екі бөлек командаға бөлген дұрыс (тағы бір-екі мүшені жұмысқа алу арқылы), сонда олардың әрқайсысы көбірек зейін қойған және автономды бола алады. (44-беттегі 3. 2-суретті қараңыз. )

Әдеттегідей, бұл тек ұсыныстар, табысқа жететін нақты жол емес. Бұл нұсқаулықтарды ұйымыңыз дамып, тәжірибе жинақтаған сайын бейімделуге болатын бастапқы нүкте ретінде пайдаланыңыз. Әрқашан есте сақтаңыз: соңында, домендерді бөлу қисынды болып көрінсе де, жұмысты орындайтын командалар әлі де шамадан тыс жүктемені сезінсе, стресс жинақталып, рух әлсірейді, бұл нашар нәтижелерге әкеледі.

Бағдарламалық жасақтаманы жеткізу командалары тиімді болуы және жүйелердің бөліктерін басқара алуы үшін біз бағдарламалық жүйелердің көлеміне және шекаралардың орналасуына команданы бірінші орынға қою тәсілін қолдануымыз керек. Жүйені дерексіз түрде жобалаудың орнына, біз жүйені және оның бағдарламалық шекараларын жеткізу командаларындағы қолжетімді когнитивті жүктемеге сәйкес келетіндей етіп жобалауымыз керек.

Монолитті архитектура немесе микросервистік архитектура арасында таңдау жасаудың орнына, бағдарламалық жасақтаманы команданың максималды когнитивті жүктемесіне сәйкес келетіндей етіп жобалаңыз. Тек сонда ғана біз тұрақты, қауіпсіз және жылдам бағдарламалық жасақтаманы жеткізуге үміттене аламыз. Бағдарламалық шекараларға арналған бұл командалық тәсіл кішігірім, бөлектелген сервистер сияқты бағдарламалық архитектураның белгілі бір стильдерін қолдауға әкеледі. Біз бағдарламалық жүйелер шекараларына арналған бұл командалық тәсілді 3. 3-суреттен көре аламыз (45-бетті қараңыз).

Команда жауапты бағдарламалық жүйенің немесе доменнің көлемін арттыру үшін команданың когнитивті мүмкіндігін барынша арттыру мақсатында (ішкі және сыртқы жүктеме түрлерін азайту арқылы) команда жұмыс істейтін экожүйені реттеңіз:

Осы және ұқсас тәсілдер арқылы командалар мен оның мүшелері үшін артық ақыл-ой шығындарын белсенді түрде азайта отырып, ұйымдар командаларға бағдарламалық жүйелердің неғұрлым күрделі бөліктерін қабылдауға көбірек когнитивті кеңістік бере алады. Керісінше, егер ұйымда командаға бағытталған кеңсе кеңістігі, жақсы басқару тәжірибесі және әсіресе командаға бағытталған платформа болмаса, онда командалар қабылдай алатын бағдарламалық жүйелердің көлемі кішірек болады. Кішігірім бөліктердің көп болуы олармен жұмыс істеу үшін көбірек командаларды қажет етеді, бұл шығындарды арттырады. Когнитивті жүктемені ескере отырып жобалау арқылы бағдарламалық жүйе шекараларына командалық тұрғыдан қарау — бақытты командаларды және (соңында) шығындардың төмендеуін білдіреді.

Бұл жоғары нәтижелі команда өздері қолдайтын бағдарламалық өнімдердің саны артқан сайын өз иықтарына көбірек жауапкершілік жүктей берді. Соңында, кейбір жұмыс ағындары басқаларының шығарылуына кедергі келтіруіне байланысты олар қиындықтарға тап бола бастады. Команда тарапынан түсінікті қарсылыққа қарамастан, Бертилссон мен Котте команда мүшелерін бір код базасында іс жүзінде екі өнім бар екеніне және Конвей заңына сүйеніп, команданы екіге бөлу керек екеніне сендіре алды. Мұнда ескеретін қызықты жайт — бұл барлық ішкі мотиваторлары (автономия, шеберлік және мақсат) бар жоғары нәтижелі команда болса да, олар бәрібір когнитивті шамадан тыс жүктеменің зардабын сезінді.

Бағдарламалық шекараларға командалық тұрғыдан қараудың тағы бір артықшылығы — команда жұмыс істеп жатқан бағдарламалық жасақтаманың ортақ ментальды моделін оңай қалыптастыруға бейім болады. Зерттеулер көрсеткендей, командалық ментальды модельдердің ұқсастығы команда жұмысының жақсы көрсеткіші болып табылады, бұл қателіктердің азаюын, неғұрлым біртұтас кодты және нәтижелердің жылдамырақ жеткізілуін білдіреді. 27 Біз команда үшін көбірек оңтайландыруды бастаған сайын, артықшылықтар оң бағытта еселене түседі.

Енді біз команданы жеткізудің негізгі құралы ретінде көргендіктен, команда айналасында басқа нәрселерді жобалауды бастай аламыз. Бұл бөлімде біз анық байланысатын командалардың біртұтас, динамикалық желісін құру тәсілдері ретінде командалық API және жақсы анықталған командалық өзара әрекеттесу сияқты ұғымдарды зерттейміз.

Нұсқалау: команданың өз коды мен сервистеріндегі өзгерістер туралы хабарлау тәсілі (мысалы, нәрселерді бүлдірмеу туралы «командалық уәде» ретінде <span data-term="true">SemVer</span> — бағдарламалық жасақтама нұсқаларының маңыздылығын білдіретін семантикалық нұсқалауды қолдану).

Wiki және құжаттама: әсіресе команда иелігіндегі бағдарламалық жасақтаманы қолдану бойынша нұсқаулықтар.

Тәжірибелер мен принциптер: команданың жұмыс істеудің қолайлы әдістері.

Коммуникация: команданың чаттар мен бейнеконференциялар сияқты қашықтан байланысу құралдарына деген көзқарасы.

Жұмыс туралы ақпарат: команда қазір немен айналысып жатыр, алда не күтіп тұр және қысқа немесе орта мерзімді перспективадағы жалпы басымдықтар.

Басқалары: басқа командаларға осы командамен әрекеттесу үшін қажет болуы мүмкін кез келген нәрсе.

Жақсы командалық API-ды құрайтын көптеген мінез-құлықтар мен үлгілер жалпы жақсы платформа мен командалық өзара әрекеттесулерге де тән.

Ұқсас дағдылары мен тәжірибесі бар әртүрлі командалардың адамдары бір-бірінен үйрену және кәсіби құзыреттіліктерін дамыту үшін жиналуына уақыт, кеңістік және қаражат бөлу маңызды.

Бұл командалық өзара әрекеттесу негізгі бағдарламалық жүйелерді құру мен іске қосудан тыс болғандықтан, Конвей заңы әлдеқайда аз рөл атқарады және командалар арасында еркін байланыс орнайды. Ең бастысы, осындай контексттерде өздерінің командалық өзара әрекеттесулерін жаттықтыруға мүмкіндігі бар командалар бағдарламалық жүйелерді құру және іске қосу кезінде басқа командалармен әрекеттесуді оңайырақ табады.

Командалар білім алуы және сенім ұялатуы үшін саналы түрде жобаланған физикалық және виртуалды орталар қажет. Дегенмен, әртүрлі адамдарға нәтижелі болу үшін әртүрлі уақытта әртүрлі орта қажет. Кейбір тапсырмалар (мысалы, күрделі алгоритмді енгізу және тестілеу) толық зейінді және төмен шу деңгейін талап етуі мүмкін. Басқа тапсырмалар өте тығыз ынтымақтастықты қажет етеді (мысалы, пайдаланушы хикаяларын және қабылдау критерийлерін анықтау). Күні бойы құлаққаппен жұмыс істейтін адамдар антиәлеуметтік ретінде көрінеді және олардың мінез-құлқы өзара әрекеттесу мен ынтымақтастыққа ықпал етпейді; бірақ кеңсе ортасы жалпы шулы болуы мүмкін және бұл адамдар тиімді болу үшін тыныш ортаны қажет етуі ықтимал.

Жеке кабиналар да, толық ашық жоспарлы (open-plan) орындар да командалар үшін әдетте жарамсыз: бізге жақсырақ нәрсе керек. Командаларға ішкі жағынан жиі, ал сыртқы жағынан (басқа командалармен) тек кейде ынтымақтастық жасау мүмкіндігі қажет. Бұл тепе-теңдікке ашық жоспарлы орналасуда (команда үшін арнайы жұмыс аймағы жоқ) және жеке жұмыс кеңістігінде (бірге өткізетін уақытты алдын ала жоспарлау керек және жиналыс бөлмелері жиі тапшы) қол жеткізу қиын. Spotify бұны ерте кезеңде түсініп, кеңсе кеңістігін екі қажеттілікті де қолдайтындай етіп ұйымдастырды.

Тиімді бағдарламалық жасақтаманы жеткізуге арналған кеңсе дизайны келесі жұмыс режимдерінің барлығын қамтуы керек: шоғырландырылған жеке жұмыс, команда ішіндегі бірлескен жұмыс және командааралық бірлескен жұмыс.

Қандай жұмыс түрі жүріп жатқанын нақты көрсететін жұмыс кеңістігінің болуы да мазасыздықты және қажетсіз кедергілерді азайтуға көмектеседі.

CDL — бөлшек сауданы сақтандыру секторында нарық көшбасшысы болып табылатын Ұлыбританияда орналасқан компания.

CDL-де біздің Agile жолымыз көптеген жағынан дамыды. Көптеген адамдарды қызықтыратын мәселелердің бірі — біздің командалар үшін жұмыс ортасын қалай ұйымдастыратынымыз. Бастапқыда біз өз командаларымызды бір жерде орналастыра алдық. Жаңа кеңсеге көшіп, кейін оған сыймай қалған соң, біз әзірлеушілер командаларын ескі штаб-пәтерімізге көшірдік, бұл бізге әр команда өз үйін құра алатын бірнеше шағын бөлмелерді берді. Бізге бұл орын мен иелік ету сезімі ұнады, бірақ командааралық байланыс пен басқа командалардың көрінуі оңтайлы болмады. Біздің жаңа ғимаратымыз — «The Codeworks» салынған кезде, біз әзірлеу аймақтарының жоспары қандай болуы керектігін мұқият ойластырдық.

Біз бәрін визуалды түрде көрсеттік, сондықтан көптеген магнитті тақталар маңызды болды. Бізге ескі ғимарат берген командалық кеңістік ұнады, бірақ командалардың оқшаулануын азайту керек болды. Біз «benched bay» (орындықтар мен үстелдер қатары) тәсілін ойлап таптық: әр команда үшін бір ұзын үстел және әр үстел тақта бөлімдерімен қоршалған. Команда үстелі қабырғаға тірелетін жерлерде біз оған сурет салуға болатындай арнайы бояумен боядық.

Командалардың көлемі мен өсуі де дизайндағы маңызды фактор болып табылады. Біздің үстелдер орналасуы команданың оңай өсуіне мүмкіндік берді. Команда тым үлкен болғанда, біз оны екі шағын командаға бөлдік. Бұның артықшылығы — әр команда ескі команданың мәдениетін өзімен бірге ала кетеді. Біз әдейі әртүрлі көлемдегі бөлімдерді жасадық, онда қажет болса қосымша бір-екі үстел орналастыруға болады.

Кейінірек біз үстелдерді бір шетіне жақынырақ орналастыру тиімдірек екенін түсіндік. Бұл бір жағында команданың жиналуы үшін көбірек орын берді, сонымен қатар қарама-қарсы тақталарды тиімді пайдалануға мүмкіндік берді.

Бұл дизайн мінсіз емес. Біз қателесеміз, бірақ үйренуді және бейімделуді жалғастырамыз. Бір тәжірибеміз — үстелдердің ортасындағы шағын шыны бөлімдерді алып тастау болды. Тағы бірі — үстелдердің шетінде бойына қарай реттелетін бөліктерді орнату болды.

CDL кейс-стадиі көрсеткендей, физикалық жұмыс ортасы командалардың тиімді әрекеттесу қабілетіне айтарлықтай әсер етеді. Табысты ұйымдар өз қызметкерлері үшін жақсы физикалық ортаға қол жеткізуге уақыт пен қаражат жұмсайды.

2013 жылы біз баспа бизнесінен 100% цифрлық бизнеске көше бастағанда, ынтымақтастықты жақсарту және жұмыс ағынын оңтайландыру жолдарын іздестірдік. Біз он бес кеңсені үшеуге айналдырдық. Жұмыс ортасы мүмкіндігінше ашық жоспарлы етіп жасалды, барлық аға менеджерлер өз командаларымен бірге отырды және жеке кабинеттер болмады.

Біздің жаңа кеңселеріміз ынтымақтастық үшін салынды:

Таза үстел саясаты: Біз жеке заттар үшін шкафтар бердік және адамдарды кеңседе қозғалуға, сол күні құндылық қосу үшін қажет жерде отыруға ынталандырдық.

Технологиялық шектеулер: Үстелдер бір монитормен жасалды, сонда адамдар қарсы отырғандарды көріп, еркін араласа алады. Үстелдердің аяқтары да адамдар арасында кедергісіз қозғалуға ыңғайлы етіп жасалды.

Жазуға болатын қабырғалар: Бейресми, шығармашылық әңгімелерді ынталандыру үшін қабырғаларға жазуға болатын етіп жасалды. Жиналыс бөлмелерінің көбі шыныдан жасалды.

Іс-шаралар кеңістігі: Біз ұйымнан тыс адамдармен танысу және жұмыс істеу үшін іс-шаралар өткізетін кеңістіктер жасадық.

Қазір бізде белгілі бір бизнес бөліміндегі барлық адамдар бірге отырады. Бұл бір бизнес ағынындағы барлық адамдардың «қиындықты бірге сезінуін» және барлық шешімдердің бірлесіп қабылдануын білдіреді.

Біздің кеңсе жоспарымыз ағынға және нақты ынтымақтастыққа көмектесу үшін өте мұқият жасалған. Бұл орналасу командаларға өздерінің бизнес ағынына назар аударуға көмектеседі, күнделікті жұмысты орындау үшін басқа бизнес аймақтарының командаларымен сөйлесу қажеттілігін азайтады.

Виртуалды орта да өте маңызды, өйткені көптеген ұйымдар «қашықтан жұмыс бірінші кезекте» саясатын қабылдауда. Виртуалды орта wiki, ішкі және сыртқы блогтар, чат құралдары, жұмысты қадағалау жүйелері және т. б. цифрлық кеңістіктерден тұрады. Тиімді қашықтан жұмыс істеу тек қажетті құралдардың болуымен шектелмейді; командалар жұмыс уақыты, жауап беру уақыты, бейнебайланыс, коммуникация тоны және басқа да практикалық аспектілер бойынша негізгі ережелерді келісіп алуы керек.

Коммуникация тиімділігі тұрғысынан виртуалды ортада шарлау оңай болуы керек. Атап айтқанда, чат құралдарында арна атаулары болжауға және іздеуге оңай болуы керек, топтық чаттар үшін префикстер қолданылуы тиіс:

Жылдам өзгеретін және қиын контекстте командалар жеке адамдар топтарына қарағанда тиімдірек. Табысты ұйымдар команданы жұмысты орындаудың негізгі құралы ретінде қарастырады. Командалар әдетте шағын, тұрақты және ұзақ өмір сүреді, бұл команда мүшелеріне өздерінің жұмыс үлгілері мен командалық динамикасын дамытуға уақыт пен кеңістік береді.

Ең маңыздысы, команда мөлшерінің шектеулеріне (Данбар саны) байланысты, бір команда көтере алатын когнитивтік жүктеменің тиімді жоғарғы шегі бар. Бұл кез келген команда жұмыс істеуі керек бағдарламалық жүйелердің көлемі мен домендердің күрделілігіне шектеу қоюды талап етеді. Команда өздері жауапты жүйеге немесе қосалқы жүйелерге иелік етуі керек. Бірнеше код базасында жұмыс істейтін командаларда иелік ету сезімі және тиісті жүйелерді түсіну мен сау күйде ұстау үшін ақыл-ой кеңістігі жетіспейді.

4-тарауда біз командаларды саналы түрде жобалау қажеттілігінен және жақсы немесе нашар команда үлгілері ұйымның көлемі, жетілуі және бағдарламалық қамтамасыз ету ауқымы сияқты көптеген факторларға байланысты екенін түсінуден бастаймыз. Бүгінгі таңда командаларды құрудың немесе қайта ұйымдастырудың басым тәсілі — ұзақ мерзімді бейімделу қабілетіне емес, шұғыл қажеттіліктерге бағытталған жүйесіз (ad hoc) тәсіл.

Бірақ алдымен, жүйесіз команда дизайнының нәтижесінде пайда болатын бірнеше жалпы анти-үлгілерге (anti-patterns) тоқталайық.

Көріп отырғанымыздай, Конвей заңына сәйкес, бағдарламалық жүйелерді жасау және пайдалану үшін адамдардың командаларға қалай ұйымдастырылғаны алынған жүйелердің сипатына қатты әсер етеді.

Ұйымдар командалық құрылымдар мен өзара әрекеттесу үлгілері туралы анық ойланбаған кезде, олар бағдарламалық жүйелерді құру мен іске қосуда күтпеген қиындықтарға тап болады. Клиенттермен жұмыс істеу барысында біз әртүрлі көлемдегі ұйымдарда команда құрудың екі ерекше анти-үлгісін байқадық.

Ұйымдар мынадай сұрақтарды қою арқылы командаларды мақсатты түрде жобалауы керек: Біздің дағдыларымызды, шектеулерімізді, мәдени және инженерлік жетілуімізді, қажетті бағдарламалық архитектура мен бизнес мақсаттарымызды ескере отырып, қандай команда топологиясы нәтижелерді тезірек және қауіпсіз жеткізуге көмектеседі? Негізгі өзгерістер ағынында командалар арасындағы жұмыс тапсыруды (handovers) қалай азайтуға немесе болдырмауға болады? Жүйенің өміршеңдігін сақтау және жылдам ағынды ынталандыру үшін бағдарламалық жүйенің шекаралары қай жерде болуы керек? Біздің командалар осыған қалай бейімделе алады?

Ауқымды бағдарламалық жүйелерді құратын және іске қосатын ұйымдар идеядан жұмыс істейтін бағдарламалық жасақтамаға дейінгі өзгерістер ағынына — біз «кедергісіз» бағдарламалық қамтамасыз етуді жеткізу деп атайтын нәрсеге басымдық беретін ұйымдық дизайндарға көшуде. Түрлі департаменттер арасында функционалдық силостары бар, аутсорсингті көп қолданатын және командалар арасында жұмысты бірнеше рет тапсыратын ескі ұйымдық модельдер қазіргі заманғы бизнес қызметтерінің дамуы үшін қажетті жылдамдық пен қауіпсіздікті қамтамасыз ете алмайды. Наоми Стэнфорд атап өткендей, «егер ұйым саналы түрде жобаланған болса, оның табысқа жету мүмкіндігі жоғары болады».

Көптеген ұйымдар Spotify командалық келісімдерінің негізгі мақсатын, мәдениетін, динамикасын немесе даму жолын түсінбестен, осы модельді қате көшіріп алды. Книберг пен Иварссон өз мақалаларында анық айтқандай: «Біз бұл модельді ойлап тапқан жоқпыз. Spotify (кез келген жақсы Agile компаниясы сияқты) тез дамып келеді. Бұл мақала біздің қазіргі жұмыс істеу тәсіліміздің бір сәттік көрінісі ғана — бұл аяқталған сапар емес, жалғасып жатқан сапар».

Командалардың өзара әрекеттесу дизайнын қарастырған кезде ұйымдар адамдарды жай ғана статикалық орналастырудан гөрі көбірек нәрсені ескеруі өте маңызды.

Көптеген ұйымдарда бағдарламалық жүйелерді құру және іске қосу бөлігі ретінде командалардың өзара әрекеттесу тәсілінде айтарлықтай кемшіліктер бар. Атап айтқанда, мұндай ұйымдар бағдарламалық қамтамасыз етуді жеткізу — бұл сипаттамадан дизайнға, дизайндан кодтауға, кодтаудан тестілеуге және шығаруға, ал шығарудан күнделікті жұмысқа (BAU) апаратын бір жақты процесс деп есептейтін сияқты (4. 1-суретті қараңыз).

Бұл өзгерістердің сызықтық, кезеңдік тізбегі — әдетте әр кезең үшін бөлек функционалды силостық бөлімдері бар (4. 1-суретте көрсетілгендей) — қазіргі заманғы бағдарламалық жүйелердің өзгеру жылдамдығы мен күрделілігіне мүлдем сәйкес келмейді. Бағдарламалық жасақтаманы әзірлеу процесі оның тірі ортада қалай жұмыс істейтінінен ештеңе үйренбейді деген болжам түбегейлі қате. Керісінше, әзірлеушілер командаларын бағдарламалық жасақтаманың тірі ортада жұмыс істеуіне қатыстыратын ұйымдар пайдаланушыларға көрінетін және операциялық мәселелерді оқшауланған бәсекелестеріне қарағанда әлдеқайда жылдам шешеді (65-беттегі 4. 2-суретті қараңыз).

«Accelerate» кітабында Николь Форсгрен, Джез Хамбл және Джин Ким дүние жүзіндегі жүздеген ұйымдардың бағдарламалық қамтамасыз етуді әзірлеу тәжірибесі туралы деректер жинап, келесідей қорытындыға келді: «біз... жеткізу командаларының кросс-функционалды болуын, яғни жүйені жобалау, әзірлеу, тестілеу, орналастыру және пайдалану үшін қажетті барлық дағдылардың бір командада болуын қамтамасыз етуіміз керек». Жұмыс істеп тұрған (өндірістік) жүйелерден келетін ақпараттық кері байланысты бағалайтын ұйымдар бағдарламалық жасақтаманы тезірек жетілдіріп қана қоймай, сонымен қатар тұтынушылар мен пайдаланушыларға деген жоғары сезімталдықты дамыта алады.

Біз мұндай сезуді тек ұйымның шетінде ғана емес, сонымен бірге ұйым ішінде — командалар арасында — қолданғанда, біз платформалардағы, қызметтердегі және интерфейстердегі кемшіліктерді жылдам анықтау үшін түбегейлі жақсартылған стратегиялық мүмкіндікті қамтамасыз ете аламыз. Бұл мәселелерді ерте шешуге және жалпы АТ тиімділігін арттыруға мүмкіндік береді. (Біз бұл ұйымдық сезуді III бөлімде толығырақ қарастырамыз. )

DevOps-тың басты үлесі — командалардың жеткізу тізбегінде қалай әрекеттесетініндегі (немесе әрекеттеспейтініндегі) кешігулерге, қайта өңдеулерге, сәтсіздіктерге және басқа командаларға деген түсіністік пен эмпатияның болмауына себеп болатын мәселелер туралы хабардарлықты арттыру болды. Сондай-ақ мұндай мәселелер тек қолданбаларды әзірлеу және операциялық топтар арасында ғана емес, сонымен қатар QA, InfoSec, желілік қызмет және т. б. сияқты бағдарламалық жасақтаманы жеткізуге қатысатын басқа да көптеген командалар арасында болатыны белгілі болды.

Көптеген адамдар DevOps-ты іргелі түрде автоматтандыру мен құрал-сайманның технологиялық аспектілері деп санаса да, тек командалар арасындағы іргелі сәйкессіздіктерді шешетін ұйымдар ғана DevOps-ты енгізуден толық әлеуетті пайда ала алады.

DevOps Topologies каталогы (бастапқыда 2013 жылы Мэттью Скелтон жасаған және кейінірек Мануэль Паис кеңейткен) — бұл технологиялық командалар арасындағы жауапкершіліктер, интерфейстер және ынтымақтастық туралы әңгімелерді бастау үшін жақсы жұмыс істейтін командалық дизайн мен өзара әрекеттесу үлгілері мен анти-үлгілерінің онлайн жинағы. Ең бастысы, сәтті үлгілер ұйым мен өнім көлемі, инженерлік жетілу және ортақ мақсаттар сияқты контекстік аспектілерге қатты тәуелді.

Топологиялар корпоративтік бағдарламалық жасақтаманы жеткізу үшін командалық құрылымдардың тиімді анықтамалығына айналды; дегенмен, олар ешқашан статикалық құрылымдар болуға арналмаған, керісінше жеткізілетін өнімдердің түрі, техникалық көшбасшылық және операциялық тәжірибе сияқты көптеген факторлардың әсерінен белгілі бір уақыт сәтінің бейнесі болды. Командалар уақыт өте келе дамып, өзгеруі керек деген астарлы идея болды.

Бұл тарауда ұйымдық контекст пен қажеттіліктерді ескере отырып, командалық құрылымдарды таңдау туралы ойлауды суреттеуге көмектесу үшін DevOps топологиялары каталогындағы кейбір үлгілер ұсынылған. Бұл онлайн режимінде қолжетімді DevOps топологияларын терең зерттеуге арналмаған; керісінше, бұл DevOps-қа қолданылатын технологиялық командаларға арналған командалық дизайнға пайдалы кіріспе. Кітаптың қалған бөлігі DevOps-тан тыс бизнес және технологиялық командалардың кеңірек контекстіне арналады.

DevOps топологиялары екі негізгі идеяны көрсетеді: (1) DevOps табысына жету үшін командаларды құрудың әмбебап тәсілі жоқ. Кез келген берілген топологияның жарамдылығы мен тиімділігі ұйымның контекстіне байланысты. (2) DevOps табысына зиян тигізетін бірнеше топологиялар (анти-үлгілер) бар, өйткені олар DevOps-тың негізгі қағидаларын ескермейді немесе оларға қайшы келеді. Қысқасы, «дұрыс» топология жоқ, бірақ кез келген ұйым үшін бірнеше «нашар» топология бар.

Топологияны жеткіліксіз таңдау міндетті түрде қажетті нәтижелер жақсы емес дегенді білдірмейді. Жиі кездесетін жағдай: белгілі бір топология нәтиже бермейді, өйткені жаңа командалық құрылымға назар аударылады, бірақ қоршаған командалар мен құрылымдар жеткілікті түрде ескерілмейді. Командалардың әртүрлі түрлерінің табыстылығы тек команда мүшелерінің дағдылары мен тәжірибесіне ғана емес; ол сондай-ақ (мүмкін ең маңыздысы) қоршаған ортаға, командаларға және өзара әрекеттесулерге байланысты.

Кросс-функционалды фича-команда өз өзгерістерін жасап, оларды бір релизге синхрондайтын бірнеше компоненттік командаларға қарағанда, тұтынушыға бағытталған функцияларды әлдеқайда жылдам жеткізу арқылы ұйымға жоғары құндылық әкеле алады. Бірақ бұл фича-команда өзін-өзі қамтамасыз ете алатын болғанда, яғни басқа командаларды күтпестен функцияларды өндіріске жеткізе алғанда ғана мүмкін болады.

Фича-командаға әдетте әртүрлі компоненттік командаларға тиесілі бірнеше код базаларына тиісу керек болады. Егер команданың инженерлік жетілу деңгейі жоғары болмаса, олар жаңа пайдаланушы сценарийлері үшін тестілеуді автоматтандырмау немесе «бойскаут ережесін» (кодты тапқаннан да жақсырақ күйде қалдыру) сақтамау сияқты жеңіл жолдарды таңдауы мүмкін. Уақыт өте келе бұл техникалық қарыздың жиналуына және жеткізу жылдамдығының баяулауына байланысты командалар арасындағы сенімнің бұзылуына әкеледі.

Командалар арасындағы тәртіп жоғары болмаса, бірнеше команданың бір код базасында жұмыс істеуінің жиынтық әсерінен ортақ кодқа иелік ету сезімі жоғалуы мүмкін.

2015 жылдар шамасында Ericsson «Бағдарламалық-анықталатын желілер» (Software-Defined Networking) немесе «Желілік функцияларды виртуализациялау» (Network Functions Virtualization) сияқты жаңа телекоммуникациялық бизнес салалары үшін бағдарламалық жасақтаманы құру және іске қосуда DevOps тәсіліне көшті. Бұл саладағы командалар өз бағдарламалық жасақтамасын әзірлеуге және оны өндірісте қолдауға жауапты болды.

Ericsson-ның бірнеше қосалқы жүйелерден тұратын кейбір ауқымды жобалары бірнеше жерде жұмыс істейтін командаларды қажет етеді. Әр команда бес-тоғыз мүшеден тұрады және бір қосалқы жүйені бірнеше команда әзірлеуі мүмкін. Дегенмен, командалар өз функцияларын тәуелсіз түрде әзірлеу және қолдау үшін барлық негізгі мүмкіндіктерді/рөлдерді қамтуы керек. Кейде өте үлкен функцияларды бір жерде орналасқан бірнеше команда бірлесіп, бір үлкен фича-команда ретінде орындайды.

Алайда, қосалқы жүйе ішіндегі функциялармен жұмыс істейтін командалар арқасында командааралық байланыс пен тәуелділік айтарлықтай азайғанымен, біреу әлі де жүйені тұтастай қадағалап, қосалқы жүйелердің қажетті пайдаланушы тәжірибесіне, өнімділігіне және сенімділігіне сәйкес интеграциялануын және өзара әрекеттесуін қамтамасыз етуі керек болды. Сондықтан жүйелік архитекторлар, жүйе иелері немесе интеграция жетекшілері сияқты арнайы рөлдер құрылды. Ең бастысы, бұл рөлдердегі адамдар бүкіл жоба/ұйым бойынша «байланыс арналары» сияқты жұмыс істейді, фича-командалармен тікелей және жиі әрекеттеседі. Олар фичаларды жеткізудің тұрақты қарқынын сақтауға мүмкіндік беру үшін командаларға қосалқы жүйеаралық мәселелерде (интерфейстер мен интеграция сияқты) қолдау көрсетеді.

Өнім командалары (мақсаты мен сипаттамасы бойынша фича-командаға ұқсас, бірақ бір немесе бірнеше өнімнің барлық функцияларына иелік етеді) өз жұмыстарының соңғы пайдаланушыларға қолжетімді болуы үшін әлі де инфрақұрылымға, платформаға, тестілеу орталарына, жинақтау жүйелеріне және жеткізу құбырларына (және т. б. ) тәуелді. Олар осы тәуелділіктердің кейбірін толық бақылай алады, бірақ команданың танымдық және тәжірибелік шектеулеріне байланысты (3-тарауда түсіндірілгендей) басқалары бойынша көмек қажет болуы мүмкін.

Өнім командаларына бұлтта өз орталары мен ресурстарын дайындау, қажет болған жағдайда жаңа кескіндер мен шаблондар жасау үшін дербестік қажет. Бұлттық команда ресурстармен қамтамасыз ету процесіне иелік ете алады — қажетті бақылау, саясат және аудиттің болуын қамтамасыз етеді (әсіресе қатаң реттелетін салаларда), бірақ олардың негізгі назары өнім командаларының қажеттіліктеріне де, тәуекелдер мен комплаенсты басқару талаптарына да сәйкес келетін жоғары сапалы өзіне-өзі қызмет көрсету мүмкіндіктерін ұсыну болуы керек.

Басқаша айтқанда, бұлттық инфрақұрылым процесін жобалау жауапкершілігі (бұлттық команда тарапынан) мен қолданба ресурстарын нақты дайындау және жаңарту (өнім командалары тарапынан) арасында бөлініс болуы керек.

SRE моделі жаңа функциялардың жылдамдығы мен бағдарламаның сенімділігін теңгерімдеу үшін <span data-term="true">service-level objectives (SLO)</span> (қызмет көрсету деңгейінің мақсаттары) және қателіктер бюджетін пайдалану арқылы әзірлеу және SRE командалары арасында салауатты және өнімді өзара әрекеттестікті орнатады.

Иә, солай: Google-дағы әрбір әзірлеу командасы SRE-ді қолданбайды. «Егер жобаңыздың ауқымы кішірейсе, SRE қолдауын азайтыңыз, ал егер масштаб SRE қолдауын қажет етпесе, әзірлеу командасына SRE жұмысын өздеріне алуға мүмкіндік беріңіз», — дейді Яана Б. Доган, Google SRE маманы.

SRE тәсілі — бұл ауқымды бағдарламалық жүйелерді құру мен іске қосудың өте серпінді жолы. SRE командасы әртүрлі факторларға (пайдаланушылар саны, сенімділік деңгейі, қажетті қолжетімділік және т. б. ) байланысты әртүрлі уақытта қолданбаларды әзірлеу командаларымен бірнеше түрлі өзара әрекеттестікте болады. 4. 3-суретте бұл көрсетілген.

SRE командасы мен қолданба әзірлеу командасы арасындағы қарым-қатынас бағдарламаның өмірлік циклінің әртүрлі кезеңдерінде және тіпті ай сайын өзгереді. Бастапқыда (4. 3-суретте №1), әзірлеу командасы масштаб SRE көмегін қажет еткенге дейін бағдарламаны өндірісте жалғыз құрады және іске қосады. Екінші кезеңде (4. 3-суретте №2), қолданбаны пайдалану артқан сайын, SRE әзірлеу командасына қолданбаны жаһандық ауқымда жақсырақ жұмыс істету туралы нұсқаулар береді (жасыл түспен көрсетілген). Кейінірек, масштаб сәйкес келгенде (4. 3-суретте №3), SRE қолданбаны іске қосуға және қолдауға толық қатысады (бірақ бәрібір қолданба командасымен ынтымақтасады). Бұл кезде қолданбаның өнім иесі тиісті қателіктер бюджеті бар қолайлы қызмет көрсету деңгейінің мақсатын (SLO) шешуі керек. Егер қандай да бір сәтте (4. 3-суретте №4) қолданбаны пайдалану қиындығына байланысты қолдау көрсету мүмкін болмаса немесе оны пайдалану азайса, қолданба командасы операциялық жауапкершілікті қайтадан өз мойнына алады. Егер қолданбаның жұмыс істеу қабілеті жақсарса және пайдалану көлемі артса, қарым-қатынас №3 кезеңге оралуы мүмкін.

SRE және әзірлеу командалары арасындағы серпінді өзара әрекеттестік — бұл SRE тәсілінің Google және ұқсас ұйымдар үшін жақсы жұмыс істеуінің бір себебі: ол бағдарламалық жүйелерді құру мен іске қосуды зауыттағы конвейер емес, <span data-term="true">sociotechnical</span> (әлеуметтік-техникалық — адамдар мен технологиялардың өзара байланысы) әрекет екенін мойындайды.

Ұйымның контексті белгілі бір команда түрлерін сәтті құруға әсер етеді. Төменде топологияны таңдау кезінде ескеру қажет әртүрлі факторларды сипаттаймыз.

Техникалық және мәдени кемелдіктің (maturity) әртүрлі кезеңдеріндегі ұйымдар әртүрлі команда құрылымдарын тиімді деп табады. Мысалы, 2013 жылға қарай Amazon да, Netflix те ұйымның қалған бөлігіне ұсынатын қызметтері үшін толық жауапкершілігі бар кросс-функционалды командаларды қолданатын қалыптасқан стратегияға ие болды.

Сонымен қатар, Agile-ді қабылдайтын дәстүрлі ұйымдар көбінесе уақыт өте келе тұрақты қарқынды сақтау үшін қажетті кемелденген инженерлік тәжірибелерге (автоматтандырылған тестілеу, орналастыру немесе мониторинг сияқты) ие болмады. Олар сараптама әкелу үшін және, ең бастысы, ортақ тәжірибелер мен құралдар бойынша ынтымақтасу арқылы командаларды біріктіру үшін тәжірибелі инженерлері бар уақытша DevOps командасынан пайда көре алады.

Дегенмен, мұндай DevOps командасының нақты миссиясы мен аяқталу мерзімі болмаса, бұл үлгі мен сәйкес анти-үлгі арасындағы жіңішке шекарадан өтіп, ұйымда тағы бір оқшауланған білімі бар «силосқа» (DevOps командасы) айналуы оңай.

Екінші жағынан, DevOps-ты жаппай енгізу жоғарыдан төменге және төменнен жоғарыға сәйкестендіруді талап ететін ірі кәсіпорын үшін ұйымның басқа бөліктеріндегі алғашқы жетістіктерді насихаттайтын <span data-term="true">DevOps evangelists</span> (DevOps насихаттаушылары) командасына инвестиция салудың мағынасы бар.

Жақсы команда топологиясын таңдау ұйым мен ондағы командалардың жағдайына байланысты. Ең кем дегенде, ұйым көлемі (немесе бағдарлама масштабы) және инженерлік кемелдік DevOps контекстінде қай топологиялар таңдалатынына әсер етуі керек (4. 4-суретте көрсетілген).

Ұйым көлемі мен инженерлік тәртіп командалардың өзара әрекеттесу үлгілерінің тиімділігіне әсер етеді.

Кемелдігі төмен ұйымдарға дербес командалар үшін қажетті инженерлік және өнімді әзірлеу мүмкіндіктерін игеру үшін уақыт қажет. Осы арада мамандандырылған командалар (әзірлеу, операциялар, қауіпсіздік және басқалар) күту уақытын азайту және мәселелерді тез шешу үшін тығыз жұмыс істесе, бұл қолайлы ымыра болып табылады. Орташа масштабтағы ұйымдар үшін командалар арасындағы жедел ынтымақтастыққа баса назар аударатын үлгілер жақсы жұмыс істейді. Ұйым немесе бағдарлама масштабы артқан сайын, негізгі инфрақұрылымды немесе платформаны қызмет ретінде ұсынуға назар аудару сенімділік пен тұтынушылардың үміттерін қанағаттандыру тұрғысынан маңызды артықшылықтар әкеледі. Егер ұйымның инженерлік кемелдігі мен тәртібі жоғары болса, онда жоғарыда сипатталған SRE моделі ауқымды деңгейде тиімді болуы мүмкін.

Кейде біз белгілі бір командаларға тәуелділікті олардың жауапкершілігін бөлу және басқа командаларға солардың кейбірін орындауға мүмкіндік беру арқылы азайта аламыз. Мысалы, соңғы бірнеше жылда көптеген ұйымдарда деректер базасын әзірлеу (DB Dev) мен деректер базасын басқару (DBA) әрекеттерін бөлу үрдісі байқалады.

Бұрын бұл екі жұмыс деректер базасы командасының ішінде бірге болатын, бірақ өзгерістер ағынын жылдамдату қажеттілігі бұл рөлдерді бөлуді тиімдірек етеді. Іс жүзінде DBA рөлі ішкі немесе бұлттық провайдердің «деректер базасы қызмет ретінде» ұсынысының бөлігіне айналады.

Барлық мысалдар командалардың мүмкіндіктерін (немесе олардың жетіспеушілігін) және бұл командалар арасындағы тәуелділікке қалай әкелетінін ойлаудың маңыздылығын көрсетеді. Жұмыс жүктемесі артқанда жай ғана командаларды көбейте бермей, қай тәуелділіктерді жою керек және қайсысын ашық қабылдау керек екенін ойлану маңызды.

2012 жылғы «А Taxonomy of Dependencies in Agile Software Development» еңбегінде Даян Строд пен Сид Хафф тәуелділіктің үш санатын ұсынады: білім, тапсырма және ресурс тәуелділіктері. Мұндай жіктеу командалар арасындағы тәуелділіктер мен жұмыс ағынына ықтимал шектеулерді алдын ала анықтауға көмектеседі.

Қандай құрал қолданылса да, әр сала бойынша тәуелділіктер санын қадағалау және белгілі бір жағдай үшін маңызды шекті мәндер мен ескертулерді орнату маңызды. Тәуелділіктер санының бақылаусыз өсуіне жол бермеу керек. Керісінше, мұндай өсім команда дизайны мен тәуелділіктерге түзетулер енгізуге түрткі болуы тиіс.

Ұйымдар, командалар мен стратегиялар уақыт өте келе жоспарлы әрекеттер немесе нарық пен технологиядағы өзгерістерге байланысты өзгереді. Көптеген ұйымдар DevOps топологиялары каталогын команда құрылымдары бойынша «сәттік» кеңес ретінде қарастырса, кейбіреулері бұдан әріге барып, эволюциялық жолды жоспарлады.

Төменде жаңа контексттерге бейімделу үшін уақыт өте келе дамып отырған DevOps топологияларының мысалдары берілген.

Пулак Агравал мен Джонатан Хаммант Accenture кеңес беретін ұйымдарды, атап айтқанда 2017 жылдың сәуірінде DevOps командасынан бастаған денсаулық сақтау саласындағы клиентті қалай дамытқанын айтып берді. Олар көп ұзамай анти-үлгіге тап болғанын түсінді, өйткені DevOps командасы әкелген құрал-саймандық тәжірибе тағы да оқшауланған «силоста» қалып қойды.

2018 жылдың қаңтарында олар әзірлеу, операциялар және DevOps құралдар командасын жақындату үшін құрылымдарын өзгертті. Эволюцияның үшінші кезеңі DevOps командасын орындаушы рөлінен насихаттаушы (evangelizing) рөліне толық ауыстыруға бағытталды, осылайша әзірлеу және операциялық командалар өзін-өзі қамтамасыз ететін болды.

Ян Уотсон, DevOps бөлімінің басшысы, TransUnion

TransUnion (бұрынғы Callcredit) — Испания, АҚШ, Дубай және Литвада кеңселері бар Ұлыбританиядағы екінші ірі несиелік анықтамалық агенттік (CRA).

2014 жылы TransUnion-дағы біздің технологиялық топ бағдарламалық шешімдерге деген өсіп келе жатқан сұранысты қанағаттандыру үшін кеңейе бастады. Біз тиімді масштабтау үшін әртүрлі технологиялық командалар арасындағы өзара байланысты ескеру қажет екенін білдік. Біз цифрлық трансформацияны жоспарлау үшін DevOps топологияларының үлгілеріне жүгіндік. Біз әзірлеу (Dev) мен операцияларды (Ops) жақындатқымыз келді, бірақ бөлек «DevOps командасынан» аулақ болдық. Оның орнына біз гибридті модельді қабылдадық, онда екі уақытша DevOps командасы Dev және Ops-ты біріктіруге көмектесті.

Біздің TransUnion-дағы DevOps саяхатымыз статикалық қайта құруға емес, командалық қарым-қатынастардың эволюциясына негізделуі керек екенін түсіндік. Топология үлгілері бізге цифрлық трансформацияның қалай жүретінін түсінуге көмектесті және бұлттық технологиялар мен автоматтандыру тәсілдерін қабылдауымызды жеделдетті. Бұл үлгілер бөлек DevOps командасы сияқты кейбір қателіктерден аулақ болуға және команда жауапкершілігін тиімдірек анықтауға көмектесті.

Өнімді масштабтау немесе жаңа технологияларды енгізу қажеттілігіне байланысты жаңа командалық құрылымдарды реактивті түрде құру қазіргі сәтте көмектесуі мүмкін, бірақ көбінесе жақсы ойластырылған топологиялардың жылдамдығы мен тиімділігіне жете алмайды.

Мұндай шешімдер көбінесе жеке команда негізінде қабылданатындықтан, оларда техникалық және мәдени кемелдік, ұйым көлемі немесе командааралық тәуелділіктер сияқты маңызды факторлар ескерілмейді. Нәтижесінде, команда құрылымдары уақыт өте келе жаңа мәселелерге бейімделудің орнына, уақытша немесе шектеулі мәселелер үшін оңтайландырылады.

«DevOps командасы» анти-үлгісі — бұған нақты мысал. Қағаз жүзінде автоматтандыру мамандарын тарту қисынды көрінеді. Дегенмен, бұл команда әр қолданбаны жеткізу жолындағы қадамдарды орындауды сұрағанда, қолданба командалары үшін «қатаң тәуелділікке» айналуы мүмкін. Оның орнына олар қолданба командалары дербес сүйенетін өзіне-өзі қызмет көрсету мүмкіндіктерін жобалауға көмектесуі керек.

Белгілі бір сәттегі мәселені шешетін құрылымдарды емес, ұйымдық контекстке (ол баяу дамиды) сәйкес келетін топологияларды қабылдау өте маңызды. Болашақты ойлайтын ұйымдар бүгінгі жұмыс істейтін нәрсе бірнеше жылдан немесе тіпті айдан кейін тиімді болмауы мүмкін екенін түсініп, команда дизайнына көп сатылы тәсілмен қарайды.

Жүйенің архитектурасы оны әзірлейтін командалардың формасында бекітіледі.

Көптеген ұйымдарда командалардың түрлері сан алуан, тіпті бірнеше рөлді қатар атқаратын командалар да кездеседі (мысалы, инфрақұрылым және құрал-сайман командасы). Мұндай бытыраңқылық ұйымның толық бейнесін көруді қиындатады: Бізде дұрыс командалар жиқталған ба? Кейбір салаларда ешбір команда айналыспай жатқан құзыреттер жетіспей ме? Командалардың дербестігі мен басқа командалардың қолдауы арасында қажетті тепе-теңдік сақталған ба?

Егер біз команда нұсқаларының санын төрт негізгі команда топологиясына дейін азайтсақ, бұл сұрақтарға жауап беру оңайырақ болады:

<span data-term="true">Enabling team</span> (басқа командаларға жаңа дағдыларды меңгеруге көмектесетін қолдаушы команда)

Мұқият қолданылған жағдайда, заманауи бағдарламалық жүйелерді құру және іске қосу үшін осы төрт команда топологиясы жеткілікті. Тиімді бағдарламалық шекаралармен (6-тарауда айтылғандай) және командалық өзара әрекеттесумен (7-тарауда айтылғандай) ұштасқанда, бұл төрт команда түрі ұйымды тиімді жобалау үшін қуатты үлгіге айналады (80-беттегі 5. 1-суретті қараңыз).

Төрт негізгі команда топологиясы — ағынға бағытталған, қолдаушы, күрделі кіші жүйе және платформалық — барлық команда түрлері үшін «магнит» рөлін атқаруы тиіс. Барлық командалар осы төрт магниттік полюстің біріне қарай жылжуы керек; яғни біз осы түрлерге басымдық беріп, ұйымдағы әрбір команда үшін осы негізгі түрлердің мақсатын, рөлін, жауапкершілігін және өзара әрекеттесу тәртібін қабылдауға ұмтылуымыз қажет. Команда түрлерін тек осы төртеуіне дейін азайту ұйым ішіндегі түсініксіздікті азайтуға көмектеседі. Цзяо Луо және оның әріптестері 2018 жылы жарияланған зерттеуде анықтағандай, ұйымдағы рөлдерге қатысты түсініксіздіктің азаюы — заманауи ұйымдық дизайнның сәтті болуының басты шарты. 1

Ірі немесе орташа ұйымда әрбір негізгі топологияның бір немесе бірнеше командасы болуы мүмкін; ағынға бағытталған бірнеше команда — бұл бастапқы нүкте (осы тарауда көретініміздей), бірақ ұйымда бірнеше платформалық команда, әртүрлі мақсаттарға арналған бірнеше қолдаушы команда (мүмкін, бірі CI/CD мәселелерін, екіншісі инфрақұрылым немесе архитектураны шешетін болар) және өте қажет болған жағдайда, бір немесе екі күрделі кіші жүйе командасы болуы мүмкін.

Операциялық (Ops) команда қайда? Қолдау көрсету командасы қайда?

Негізгі топологияларда «Операциялық» (Ops) немесе «Қолдау көрсету» командасы жоқ және бұл әдейі жасалған. Жүйелерді құратын тұрақты командалар өздері жасап жатқан жүйелердің нақты жұмыс істеу процесіне (live operation) өте жақын болады. Жұмысты бөлек Ops немесе қолдау көрсету командасына «өткізіп беру» (handover) деген жоқ; тіпті SRE моделінде де (4-тарауды қараңыз), командалар тығыз байланыста болады. Ағынға бағытталған командалар бағдарламалық жасақтаманы жеткізудің жақсы тәжірибелерін (үздіксіз жеткізу және пайдалануға жарамдылық сияқты) ұстанады және код өте аз жазылса да, жүйенің нақты жұмысына жауап береді. Шын мәнінде, операциялық жұмыстар мен қолдау көрсету негізінен ағындарға сәйкес келеді. (Осы тараудың соңында сәтті ұйымдардың өзгерістердің жылдам әрі қауіпсіз ағыны жағдайында қолдау көрсету әрекеттерін қалай басқаратынын егжей-тегжейлі қарастырамыз).

Енді төрт негізгі команда топологиясының әрқайсысына толығырақ тоқталайық.

«Ағын» — бұл бизнес доменіне немесе ұйымның мүмкіндіктеріне сәйкес келетін жұмыстың үздіксіз үрдісі. Үздіксіз ағын мақсат пен жауапкершіліктің нақты болуын талап етеді, сонда әрқайсысының өз жұмыс ағыны бар бірнеше команда қатар өмір сүре алады.

Ағынға бағытталған команда — бұл жұмыстың бір құнды ағынына бағытталған команда; бұл бір өнім немесе сервис, мүмкіндіктердің (features) бір жиынтығы, бір қолданушы жолы (user journey) немесе бір қолданушы персонасы болуы мүмкін. Сонымен қатар, командаға тұтынушы немесе қолданушы үшін құндылықты мүмкіндігінше тез, қауіпсіз және дербес түрде жасауға және жеткізуге өкілеттік беріледі, бұл ретте жұмыстың бір бөлігін орындау үшін басқа командаларға жүгінудің қажеті болмайды.

Ағынға бағытталған команда жеткізудің барлық спектрімен жұмыс істейтіндіктен, олар табиғи түрде тұтынушыға жақын болады және бағдарламалық жасақтаманы өндірістік ортада (production) бақылай отырып, тұтынушылардың кері байланысын тез ескере алады. Мұндай команда жүйелік мәселелерге нақты уақыт режимінде жауап беріп, жұмысты қажетінше бағыттай алады. Дон Райнертсеннің сөзімен айтқанда: «Өнімді әзірлеуде біз үлкен командаға қарағанда, жоғары білікті адамдардан тұратын шағын команда болғанда бағытты тезірек өзгерте аламыз». 2

Ұйымда әртүрлі ағындар қатар өмір сүре алады: нақты тұтынушы ағындары, бизнес-сала ағындары, географиялық ағындар, өнім ағындары, қолданушы персонасының ағындары немесе тіпті комплаенс ағындары (қатаң реттелетін салаларда). Ағын тіпті ірі компания ішіндегі дербес фокусы мен мақсаты бар шағын кәсіпорын (мысалы, әлі жоқ өнімдерді инновациялау) түрінде де болуы мүмкін. Ағынға бағытталған команда қандай өзгерістер ағынына бағытталмасын, бұл команда өтпелі жоба ретінде емес, жұмыс портфолиосының немесе бағдарламасының бөлігі ретінде ұзақ мерзімді, тұрақты түрде қаржыландырылады.

Заманауи бағдарламалық қамтамасыз ету ұйымында біз командалардың көпшілігі ағынға бағытталған болады деп күтеміз. Жұмыс ағыны анық және әрбір ағынның ағынға бағытталған команда басымдық бере алатын тұрақты, болжамды жұмыс көлемі бар.

Бұл дәстүрлі жұмыс бөлу әдісіне мүлдем қайшы келеді, мұнда бір тұтынушының үлкен сұранысы немесе бірнеше тұтынушының кішігірім сұраныстары жиынтығы жобаға айналады. Жоба мақұлданып, қаржыландырылғаннан кейін, оған бірнеше команда (мысалы, фронтенд, бакенд және DBA командалары) тартылуы мүмкін және олар жаңа жұмысты өздерінің бұрыннан бар тапсырыстар тізіміне (backlog) сыйғызуы қажет болады.

2002 жылдың өзінде Amazon өте тәуелсіз командаларды қолданатын командалық топологияны қабылдады. Бұл бас директор Джефф Безостың Amazon иелігіндегі әрбір сервис немесе қосымшаның шын мәнінде тәуелсіз болуын қамтамасыз ету үшін берген әдейі тапсырмасы болды — бұл Конвей заңын ескеру және командалардың да тәуелсіз болуын қамтамасыз ету еді. 3 Amazon сонымен қатар жауапкершілікті арттыру және жеткізу мен жаңаны ашу жылдамдығын арттыру үшін бағдарламалық командалардың көлемін «екі пиццамен тамақтандыруға болатын» адам санымен шектеуімен танымал. 4

2002 жыл шамасында Джефф Безос Amazon-ның инженерлік бөліміне командаларды ұйымдастырудың нақты ережелерін белгілейтін мандат жіберді:5

Amazon-ның техникалық директоры Вернер Фогельс танымал еткен «өзің құрсаң, өзің іске қос» (you build it, you run it) принципіне сәйкес, «сервис командалары» (іштей солай аталады) кросс-функционалды болуы тиіс және олардың құрамына өз сервистерін басқару, сипаттау, жобалау, әзірлеу, тестілеу және пайдалану (соның ішінде инфрақұрылымды дайындау және тұтынушыларды қолдау) үшін барлық қажетті мүмкіндіктер кіруі керек. Бұл құзыреттер міндетті түрде жеке тұлғаларға бекітілмейді; команда тұтастай алғанда оларды қамтамасыз етуі тиіс. Әрбір адамның негізгі сараптама саласы бар, бірақ олардың үлесі онымен шектелмейді.

Сервис командалары арасында өте аз үйлестіру қажет, бұл микросервистердің жоғары деңгейде бөлінген және әртүрлі стекіне әкеледі. Қызығы, тестілеуге қатысты ерекшелік бар, өйткені тестілеу бойынша бағдарламалық қамтамасыз ету инженерлері (SDETs) бүкіл ұйым бойынша жұмыс істейді, командалар арасында жақсы тестілеу тәжірибелері мен құралдарын насихаттауға тырысады (бірақ әр команданың құрамында күнделікті тестілеу рөлі бар). Олар сондай-ақ сервистер арасында, құрылғылар арасында және географиялық аймақтар арасында қолданушының үздіксіз тәжірибесін қамтамасыз етеді. SDET рөлі өнімділік немесе құрал-сайман командасындағы адамдар беретін құнды ақпаратты ұсынады, бұл командалар арасында жақсы тәжірибелерді енгізуге ықпал етеді және көмектеседі.

Amazon-ның «екі пиццалық команда» моделі — ағынға бағытталған командалардың мысалы: командалар айтарлықтай тәуелсіз, өз сервистеріне иелік етеді және өздері жазған бағдарламалық жасақтаманың жұмыс уақытындағы сәттілігіне жауап береді. Amazon-ның бұл модельді он жеті жылдан астам уақыт бойы қолданып келе жатқандығы командаларды өзгерістердің тәуелсіз ағындарына бағыттау қаншалықты тиімді болатынын көрсетеді.

Жалпы айтқанда, әрбір ағынға бағытталған команда жұмысты бастапқы (талаптарды) зерттеу кезеңдерінен өндіріске дейін жеткізу үшін белгілі бір құзыреттер жиынтығын қажет етеді. Бұл құзыреттерге мыналар кіреді (бірақ олармен шектелмейді):

Коммерциялық және операциялық өміршеңдік талдауы

Дизайн және архитектура

Әзірлеу және код жазу

Инфрақұрылым және пайдалануға жарамдылық (operability)

Метрикалар мен мониторинг

Өнімді басқару және иелік ету

Тестілеу және сапаны қамтамасыз ету

Қолданушы тәжірибесі (UX)

Әрбір құзыретті командадағы жеке рөлге теңестірмеу өте маңызды; бұл жоғарыдағы тізімге сәйкес келу үшін командалар кем дегенде тоғыз мүшеден тұруы керек дегенді білдірер еді. Керісінше, біз команда ретінде жоғарыда аталған құзыреттерді түсіну және соған сәйкес әрекет ету қабілеті туралы айтып отырмыз. Бұл әмбебап мамандар (generalists) мен бірнеше тар шеңберлі мамандардың (specialists) қоспасы болуы мүмкін дегенді білдіреді. Тек тар шеңберлі рөлдердин болуы, жұмыстың бір бөлігі дәл қазір бос болмауы мүмкін маманға тәуелді болған сайын «тар бұғазға» (bottleneck) әкеледі.

Google компаниясы алғаш енгізген Сайт сенімділігі инженерлері (SRE) командалары шын мәнінде ағынға бағытталған команданың ерекше түрі болып табылады, өйткені олар өндірісте жұмыс істейтін ірі қосымшалардың сенімділігіне жауап береді. SRE командалары негізінен қосымшаларды әзірлеуге жауапты бір немесе бірнеше ағынға бағытталған командалармен өзара әрекеттеседі және бағдарламалық жасақтаманы өзгерту ағыны көбінесе ағынға сәйкес келеді.

Бұрын бағдарламалық жасақтаманы жеткізудің көптеген әдістемелері құнды бағдарламалық нәтижелерді басынан аяғына дейін жеткізуге өкілеттігі бар командаларды атау үшін «өнім командасы» немесе «мүмкіндік командасы» терминдерін қолданған, бірақ қазіргі уақытта өнімдер немесе мүмкіндіктер туралы емес, ағындар туралы айтудың мағынасы зор болуының көптеген себептері бар. Команданың мақсатын ағынмен сәйкестендіру ұйым деңгейінде ағынға назар аударуды күшейтуге көмектеседі — ағын кедергісіз жүруі тиіс.

IoT (Заттар интернеті), барлық жерде орнатылған құрылғылар және сервисті басқаруға кешенді көзқарастардың пайда болуымен қолданушының басынан аяғына дейінгі тәжірибесі басқаша көрінеді. Тұтынушылар тек жеке бағдарламалық бөлікпен ғана емес, мобильді құрылғылардан бастап орнатылған жүйелер мен дауыспен басқарылатын құралдарға дейінгі әртүрлі бағдарламалық жасақтамамен жұмыс істейтін бірқатар өнімдер мен құрылғылармен әрекеттеседі. Тұтынушылар сонымен қатар брендтермен бірнеше арналар (жеке, әлеуметтік желілер, веб-сайт, телефон) арқылы байланысады және жүйелі жауаптар мен интерфейстерді күтеді. Джефф Суссна «Designing Delivery» кітабында осы қиындықтарды жеңу үшін командаларға «үздіксіз дизайн» (continuous design) мүмкіндіктерін қосу қажеттілігі туралы айтады: үздіксіз дизайн арқылы біз «сервис, кері байланыс, сәтсіздік және оқу сияқты идеяларды бірінші дәрежелі ұғымдар ретінде қарастырамыз», және бұған қол жеткізудің ең жақсы жолы — ағынға баса назар аударатын өзгерістерге бағытталған көзқарас. 6

Осы көп арналы, жоғары деңгейде байланысқан контексте «өнім» өте әртүрлі мағынаны білдіруі мүмкін, бұл «өнім командасының» жауапкершілігі қандай екенін түсінуді қиындатады. Мысалы, өндірістік компанияларда өнім бірнеше жыл бойы инженерлік команда құрастыратын, содан кейін өнім ескірген соң команда таратылатын, қызмет ету мерзімі бекітілген физикалық құрылғы болуы мүмкін.

«Ағынға бағытталған» термині «өнім» немесе «мүмкіндік» терминдеріне қарағанда кең ауқымды жағдайларға қолайлы болып қана қоймайды, сонымен қатар «ағынға бағытталған» термині ағын сезімін (өйткені ағын ағады) біріктіруге және баса көрсетуге көмектеседі. Соңында, бағдарламалық жасақтаманың барлық жағдайлары өнімдерді немесе мүмкіндіктерді қажет етпейді (әсіресе мемлекеттік қызметтерді ұсынуға бағытталғандар), бірақ барлық бағдарламалық жағдайлар ағынмен үйлесуден пайда көреді.

Көріп отырғанымыздай, ағынға бағытталған командалардың миссиясы — көбінесе бизнес саласына қатысты, бірақ әрдайым емес, белгілі бір ағын үшін жұмыстың кедергісіз жүруін қамтамасыз ету.

Тиімді ағынға бағытталған командада қандай іс-әрекеттер мен нәтижелерді көреміз деп күтеміз?

Ағынға бағытталған команда соңғы өзгерістерден алынған кері байланыс негізінде бағытты тез түзете алады.

Ағынға бағытталған команда өнімнің дамуына эксперименттік көзқараспен қарайды, үнемі үйренуді және бейімделуді күтеді.

Ағынға бағытталған команда жұмысты басқа командаларға барынша аз (ең дұрысы нөл) өткізеді.

Ағынға бағытталған команда ол өндіретін өзгерістердің тұрақты ағыны бойынша бағаланады (кейбір қосымша техникалық және команданың саулығы метрикаларымен бірге).

Ағынға бағытталған командада кодты өзгерту қауіпсіз әрі оңай болып қалуын қамтамасыз ету үшін код сапасына қатысты өзгерістерді (кейде «техникалық қарыз» деп аталады) шешуге уақыт пен орын болуы керек.

Ағынға бағытталған команда қолдау көрсететін негізгі топологиялық командалармен (күрделі кіші жүйе, қолдаушы және платформалық) белсенді және жүйелі түрде байланысады.

Ағынға бағытталған команда мүшелері Даниэль Пинк бойынша білім қызметкерлерінің үш негізгі құрамдас бөлігі — «автономия, шеберлік және мақсатқа» қол жеткізгенін немесе оған жету жолында екенін сезінеді. 7

(Ағынға бағытталған командалардың платформамен байланысы туралы толығырақ 8-тарауда қарастырамыз).

«Accelerate» кітабында Форсгрен, Хамбл және Ким алда болу үшін жоғары өнімді командалар өз мүмкіндіктерін үнемі жетілдіріп отыратынын айтады. Бірақ басынан аяғына дейін иелік ететін ағынға бағытталған команда зерттеуге, оқуға, білім алуға және жаңа дағдыларды үйренуге қалай уақыт таба алады? Ағынға бағытталған командалар сонымен қатар өзгерістерді жылдам жеткізуге және оларға жауап беруге үнемі қысым көреді.

Қолдаушы команда белгілі бір техникалық (немесе өнім) саласындағы мамандардан тұрады және олар осы құзыреттілік алшақтығын жоюға көмектеседі. Мұндай командалар ағынға бағытталған командалармен қиылысады және зерттеуге, нұсқаларды сынап көруге және қосымша стегіне қатысты сәйкес құралдар, тәжірибелер, фреймворктер және экожүйе таңдаулары бойынша негізделген ұсыныстар жасауға қажетті мүмкіндікке ие. Бұл ағынға бағытталған командаға тиісті күш жұмсамай-ақ (біздің тәжірибемізде мұндай күш-жігер мен олардың команданың қалған бөлігіне тигізетін әсері он-он бес есеге дейін төмен бағаланады) құзыреттерді иеленуге және дамытуға уақыт береді.

Қолдаушы командалардың табиғаты өте ұжымдық болып келеді; олар тиімді нұсқаулар беру үшін ағынға бағытталған командалардың мәселелері мен кемшіліктерін түсінуге тырысады. Ютта Экштейн оларды «Техникалық кеңес беру командалары»8 деп атайды, бұл анықтама ұйымның ішінде немесе сыртында болсын, консалтингтік команда ұсынуы керек нәрсеге (орындау емес, нұсқау беру) жақсы сәйкес келеді.

Қолдаушы командалар басқа командалар орындауы тиіс техникалық таңдауларды бұйыратын «піл сүйегінен жасалған мұнараларға» (ivory towers — өмірден алшақ, оқшауланған білім ортасы) айналудан аулақ болады, сонымен бірге командаларға ұйым бойынша техникалық шектеулерді түсінуге және сақтауға көмектеседі. Бұл «қызмет етуші көшбасшылық» (servant leadership) идеясына ұқсас, бірақ жеке тұлғаларға емес, командалық өзара әрекеттесуге қолданылады. Қолдаушы команданың түпкі мақсаты — шешімдердің өзіне емес, ең алдымен мәселелерге назар аудара отырып, ағынға бағытталған командалардың құзыреттерін арттыру арқылы олардың автономиясын арттыру. Егер қолдаушы команда өз жұмысын жақсы атқарса, ол көмектесіп жатқан командаға бірнеше апта немесе айдан кейін қолдаушы команданың көмегі қажет болмауы керек; қолдаушы командаға тұрақты тәуелділік болмауы тиіс.

Бір қолдаушы команда біз алдыңғы бөлімде тізімдеген ағынға бағытталған команда құзыреттерінің кез келгеніне сәйкес келуі мүмкін (қолданушы тәжірибесі, архитектура, тестілеу және т. б. ), бірақ көбінесе олар құрастыру инженериясы, үздіксіз жеткізу, деплоймент немесе нақты клиенттік технология үшін (мысалы, десктоп, мобильді, веб) тестілеуді автоматтандыру сияқты нақты салаларға шоғырланады. Мысалы, қолдаушы команда деплоймент пайплайнының негізгі қаңқасын (walking skeleton) немесе автоматтандыру құралдары мен кейбір бастапқы сценарийлер мен мысалдарды біріктіретін негізгі тестілеу фреймворкін құра алады.

Қолдаушы және ағынға бағытталған команда арасындағы білім беру уақытша негізде (мысалы, ағынға бағытталған команда контейнерлеу сияқты жаңа технологияны қабылдағанда) немесе ұзақ мерзімді негізде (тезірек жинақтау немесе тезірек тест орындау сияқты үнемі жетілдіріліп отыратын аспектілер үшін) болуы мүмкін. Жұптық жұмыс (Pairing) «Инфрақұрылым код ретінде» (Infrastructure-as-Code) сияқты тәжірибелердің кейбір түрлері үшін өте тиімді болуы мүмкін.

Көріп отырғанымыздай, қолдаушы командалардың миссиясы — ағынға бағытталған командаларға, әдетте белгілі бір техникалық немесе өнімді басқару саласында жетіспейтін құзыреттерді иеленуге көмектесу.

Тиімді қолдаушы командада қандай іс-әрекеттер мен нәтижелерді көреміз деп күтеміз?

Қолдаушы команда ағынға бағытталған командалардың нақты қажеттілігі туындағанға дейін өз сараптама саласындағы жаңа тәсілдерді, құралдарды және тәжірибелерді зерттеп, оқиғалардан озып жүреді. Бұрын бұл архитектура немесе инновациялық командалардың миссиясы болған, бірақ басқа командаларға мүмкіндік беруге назар аудару жақсырақ динамика жасайды.

Қолдаушы команда жақсы жаңалықтардың да (мысалы, «Біздің тестілеу кодымызды 50%-ға азайтатын жаңа UI автоматтандыру фреймворкі бар. ») жаман жаңалықтардың да (мысалы, «Біз кеңінен қолданып жүрген X Javascript фреймворкі енді қолдау көрсетілмейді. ») хабаршысы ретінде әрекет етеді. Бұл технологиялық өмірлік циклді басқаруға көмектеседі.

Кейде қолдаушы команда ағынға бағытталған командалар тікелей пайдалануы қазіргі уақытта тым қиын сыртқы (немесе ішкі) сервистер үшін делдал рөлін атқаруы мүмкін.

Қолдаушы команда тек өз ішінде ғана емес, ағынға бағытталған командалар арасында да оқуды насихаттайды, ұйым ішінде білімді тиісінше бөлісуге ықпал ететін куратор ретінде әрекет етеді (Том ДеМарко мен Тим Листер «оқудың негізгі функциясы» деп атайтын нәрсені қолдайды). 10

2017 жылы мен ірі заң ұйымында жаңадан құрылған инженерлік қолдау көрсету командасымен бір жылдық консалтингтік жобаны басқардым. Ұйымның бағдарламалық қамтамасыз етуді әзірлеу мүмкіндігі бірнеше жаһандық командалар арасында бөлінген болатын.

Инженерлік қолдау көрсету командасы ұйым бойынша сезіліп жүрген бірқатар ауыр белгілерге жауап ретінде құрылды, олар: мүмкіндіктерді (features) жеткізу уақытының ұзақтығы, бөлек жүйелер үшін байланысқан релиз циклдері, команданың төмен рухы, оқшауланған техникалық білім және (ең бастысы) өзгерістердің инновациялық қарқынын сақтай алмау салдарынан ұйымның бәсекелестерден қалып қоюы еді.

Күніне орындалатын сәтті деплойменттердің абсолюттік саны

Сәтсіз деплойментті түзетуге кететін уақыт

Кодты енгізуден бастап деплойментке дейінгі уақыт (цикл уақыты)

Күніне деплоймент конвейерін іске қосу саны 700%-ға артты

Деплоймент конвейерінің жұмыс істеу ұзақтығы 98%-ға қысқарды (он сағаттан он бес минутқа дейін! )

Сәтсіз жинақтар орта есеппен жиырма үш сағат ішінде түзетілді (бұрын бірде-бір сәтті жинақ болмаған! )

Ішкі жүйені жеткізу жылдамдығы мен сапасы оны ағынға бағытталған команда әзірлеген кезден (бөлу туралы шешім қабылданғанға дейін) айтарлықтай жоғары болады.

Команда ағынға бағытталған командалардың қажеттіліктерін ескере отырып, алдағы жұмыстарды дұрыс басымдыққа қояды және орындайды.

«Цифрлық платформа — бұл өзіне-өзі қызмет көрсететін API-лер, құралдар, қызметтер, білім мен қолдаудың негізі, олар тартымды ішкі өнім ретінде жинақталған. Автономиялы командалар өнім функцияларын жылдамырақ және үйлестіруді аз қажет ететіндей жеткізу үшін осы платформаны пайдалана алады». 12

Команда жылдам прототиптеу әдістерін қолданады және кері байланыс алу үшін ағынға бағытталған команда мүшелерін тартады.

Платформалық команда қызметтердің ыңғайлылығы мен сенімділігіне баса назар аударады (платформаны өнім ретінде қарастырады) және олардың әлі де тиімді екенін үнемі тексеріп отырады.

Платформалық команда үлгі көрсетеді: өздері ұсынатын қызметтерді іштей қолданады, басқа командалармен серіктес болады және мүмкіндігінше төмен деңгейлі платформаларды пайдаланады.

Команда жаңа қызметтердің бірден емес, уақыт өте келе қабылданатынын түсінеді.

Sky Betting & Gaming — Leeds қаласында орналасқан британдық құмар ойындар компаниясы. 1999 жылы негізі қаланған компания онлайн бәс тігу индустриясында инновациялардың көшбасшысы болды. 2009 жылдан бастап компания жылдам инновациялар мен 24/7 жұмыс режимін қамтамасыз ету үшін ішкі техникалық тәжірибеге көп қаражат бөле бастады.

Мен 2012 жылы қосылғаннан бері SB&G тұрақты әрі жылдам өзгерістер орнына айналды. Басында технологиялық бөлім тек сыртқы әзірлеушілер жасаған қосымшаларды хостингпен қамтамасыз етуге бағытталған инфрақұрылымдық функция болды. 2009 жылы бизнес тезірек қозғалып, көбірек бақылауға ие болу керек деген шешім қабылдады.

Біздің бағдарламалық жасақтаманы жеткізуіміз әрқашан Agile тәсілін қолданды. Уақыт өте келе біз бірнеше ұйымдық өзгерістерді бастан өткердік. Осы процестің басында біз жұмыс тәсілімізге DevOps-ты енгізе бастадық. Біз нақты мақсаттардан және арнайы «бастапқы» командадан бастадық. Мысалы, жинақтау және шығару құралдарын жақсартуды қолға алдық, өйткені бағдарламалық жасақтаманы әзірлеуде Agile болғанымызбен, оны тікелей қолданысқа енгізуде қиындықтар туындады. Кейінірек біз DevOps тәжірибелерін командалардың негізгі бөлігіне айналдырдық.

Осы жылдам өсу кезеңінде біз конфигурацияны басқару мәселесін шешуіміз керек болды. Біз бағдарламалық және инфрақұрылымдық мамандардан тұратын платформаны дамыту командасын құрдық. Бұл команданың басты басымдығы Chef құралын пайдаланып конфигурацияны басқару жүйесін енгізу болды.

Көп ұзамай біз маңызды сабақ алдық. Chef-тің алғашқы енгізілуі орталықтандырылған функцияның өнімі болды және ол жылдам өзгеру кезеңінде үлкен кедергіге айналды. Дизайн тәсілі шектеуші фактор болды. Бізде үлкен Chef ортасы және оның айналасында көптеген адамдар қолданатын құралдар жиынтығы болды. Көп ұзамай командалар бір-біріне кедергі келтіре бастады — ортақ тәуелділіктер, әртүрлі басымдықтар, жаңартудағы қиындықтар сияқты көптеген командалар арасындағы ортақ жүйелердің барлық әдеттегі мәселелері туындады.

(8-тарауда жалғасады)

Auto Trader — Ұлыбританиядағы ең ірі цифрлық автокөлік нарығы. Ол Ұлыбританиядағы көлік сатып алу және сату процесін үнемі жақсартуды мақсат етеді. Auto Trader — 100% цифрлық бизнес. 1977 жылы жергілікті журнал ретінде жұмысын бастап, ол өз тұтынушыларымен бірге дамыды. 2013 жылы баспа өнімінен толық цифрлық нарыққа көшуді сәтті аяқтады. Қазіргі уақытта ол FTSE 250 индексінің мүшесі болып табылады.

Платформа сквадтарға тек өнімнің көрінетін мүмкіндіктеріне ғана емес, сонымен қатар Auto Trader сияқты заманауи цифрлық ұсыныстар үшін маңызды болып табылатын көзге көрінбейтін операциялық мәселелерге де назар аударуға мүмкіндік береді. Платформа өнім сквадтарына жұмысқа қабілеттілік туралы қамқорлық жасауға уақыт береді. Қызығы, басқа ұйымдардан айырмашылығы, біз ешқашан Ops (пайдалану) мамандарын Dev сквадтарына қоспадық. Оның орнына бізде әрбір Dev сквад үшін Ops «сквад досы» (squad buddy) бар — бұл нақты Dev сквадтарымен үнемі жұмыс істейтін, олардың жиналыстарына қатысатын және Dev пен Ops арасындағы «байланыстырушы» рөлін атқаратын Ops маманы.

Жалпы айтқанда, егер біз бағдарламалық жасақтаманы жылдам әрі қауіпсіз жеткізгіміз келсе, тек бір функционалдық мамандығы бар адамдардан тұратын командалардан аулақ болуымыз керек. Дәстүрлі түрде көптеген ұйымдар қызметкерлерді келесідей топтастыру арқылы функционалдық сараптаманың «аралдарын» немесе «оқшауланған бағаналарын» (silos) құрды:

Өзгерістердің қауіпсіз және жылдам ағыны үшін оңтайландырылған ұйымдар жұмыс ағынына сәйкес келетін әртүрлі пәндік немесе кросс-функционалды командаларды қолдануға бейім — біз оларды ағынға бағытталған командалар деп атаймыз. Кейде белгілі бір сала өте күрделі болғандықтан, арнайы күрделі ішкі жүйе командасы қажет болуы мүмкін (осы тараудың алдыңғы бөлімін қараңыз). Бірақ мұндай командалар ешқашан өзгерістер ағынының ортасында тұрмайды; оның орнына олар ағынға бағытталған командаларға қызмет көрсетеді. Жұмыс ешқашан кейінгі кезең үшін басқа командаға тапсырылмайды.

Кросс-функционалды, ағынға бағытталған командаларды пайдаланудың өте пайдалы жанама әсері бар. Дәл осы командалар әртүрлі дағдылары бар адамдардан тұратындықтан, кез келген жағдайда ең қарапайым, пайдаланушыға ыңғайлы шешімді табуға деген күшті ұмтылыс болады. Бір салада терең білімді қажет ететін шешімдер, ағынға бағытталған команданың барлық мүшелеріне түсінікті қарапайым шешімдерден жеңіліп қалуы мүмкін.

Хенрик Книберг «тұтынушыға бағытталған платформалық командалар» деп атайтын жақсы жобаланған және жақсы басқарылатын платформа ұйымдар ішінде бағдарламалық жасақтаманы жеткізу үшін маңызды «күш еселеуші» бола алады, бірақ платформаның әрқашан оны қолданатын қосымшалар мен қызметтердің қажеттіліктеріне қызмет етуін қадағалау керек, керісінше емес.

Жақсы платформа Dev командаларына тез және тиімді жаңалықтар енгізу үшін стандарттарды, шаблондарды, API-лерді және жақсы тексерілген озық тәжірибелерді ұсынады. Жақсы платформа Dev командаларына ұйым үшін дұрыс нәрселерді дұрыс жолмен жасауды жеңілдетуі керек; бұл тек бағдарламалық жасақтамаға ғана емес, өнімді әзірлеудің барлық түрлеріне қатысты. Көбінесе платформа бұрынғы жүйелік әкімшілерге бағдарламалық жасақтаманы әзірлеудің жақсы анықталған әдістерін (Agile тәжірибелері, TDD, үздіксіз жеткізу, өнімді басқару және т. б. ) қолданбай құруға және басқаруға қалдырылады; немесе ұйым тарапынан соншалықты аз қаржыландыру мен назарға ие болады, сондықтан ол басқа командаларға көмектесудің орнына, тек кедергі келтіреді.

Ең қарапайым платформа — бұл жай ғана вики-беттегі бағдарламалық жасақтама қолданатын негізгі компоненттердің немесе қызметтердің тізімі. Егер бұл компоненттер мен қызметтер әрқашан сенімді жұмыс істесе, онда толық уақытты платформалық команданың қажеті жоқ. Дегенмен, негізгі субстрат күрделене түскен сайын — тіпті барлық компоненттер мен қызметтер сырттан алынса да — платформалық команда жаңа және ескірген API-лер мен компоненттерді үйлестірумен айналыса отырып, платформаның егжей-тегжейлеріне құнды басқару абстракциясын ұсына алады. Егер ұйымға Dev командаларының қажеттіліктерін қанағаттандыру үшін платформаға арнайы шешімдер мен интеграциялар құру қажет болса, онда платформалық команданың қызмет аясы одан әрі кеңейеді.

Dev командаларының когнитивтік жүктемесін азайтуға ұмтыла отырып, жақсы платформа оларға мәселенің маңызды (ерекшеленетін) аспектілеріне назар аударуға көмектеседі, жеке және командалық деңгейдегі жұмыс қарқынын арттырады және бүкіл команданың тиімдірек болуына мүмкіндік береді. Жаһандық Conde Nast International баспа компаниясының қызметкері Кеничи Шибата айтқандай: «Платформаның ең маңызды бөлігі — оның әзірлеушілер үшін жасалғандығында».

Жақсы UX/DevEx-ке назар аудару платформаны пайдалануға тартымды етеді және платформа API-лері мен мүмкіндіктерінің жұмыс істеу тәсілінде жүйелілік сезіледі. Нұсқаулықтар мен басқа құжаттамалар жан-жақты (бірақ артық сөзсіз), өзекті болады және платформаның әрбір бұрышын сипаттауға емес, нақты тапсырмаларды орындауға бағытталады.

Платформа Dev командаларына «кедергі жасамауға» тырысады, бұл оларға командалардың қалай жұмыс істеуі керектігі туралы ешқандай алдын ала түсініксіз қажетті нәрсені құруға мүмкіндік береді. DevEx үшін жақсы тест — жаңа әзірлеушіні платформаға қосудың қаншалықты оңай екендігі.

Әрбір бағдарламалық қосымша және әрбір бағдарламалық қызмет платформада құрылады. Көбінесе платформа жасырын немесе байқалмайды, бірақ ол бәрібір бар. Философиялық сөзбен айтқанда: бұл «тасбақалардың үстіндегі тасбақалар» (төмен қарай шексіз кете беретін қабаттар).

Платформаның пайдаланушылары (Dev командалары) және нақты анықталған белсенді жұмыс сағаттары бар (Dev командалары оны пайдаланған кез келген уақытта). Пайдаланушылар платформаның сенімділігіне тәуелді болады және жаңа мүмкіндіктердің қашан пайда болатынын, ал ескілерінің қашан тоқтатылатынын түсінуі керек. Сондықтан Dev командаларының барынша тиімді болуына көмектесу үшін бізге: (1) платформаға тірі/өндірістік жүйе ретінде қарау, кез келген тоқтап қалуды жоспарлау және басқару, және (2) бағдарламалық өнімді басқару және қызметті басқару әдістерін қолдану қажет.

Платформаға тірі немесе өндірістік жүйе ретінде қараған кезде, біз кез келген басқа тірі жүйе сияқты барлық қалыпты әрекеттерді орындауымыз керек: жұмыс сағаттарын анықтау, оқиғалар мен қолдау көрсетуге жауап беру уақытын анықтау, платформаны қолдау үшін кезекшілік кестесін қамтамасыз ету, оқиғалар мен жоспарланбаған тоқтауларды тиісті байланыс арналары (мысалы, қызмет күйі беттері) арқылы басқару және т. б. Әрине, платформа ұлғайған сайын, ұйымдағы командаларға нақты не қажет екенін және сырттан не алуға болатынын қайта қарастыру пайдалы болуы мүмкін, осылайша платформалық командалардың операциялық қолдау жүктемесін азайтуға болады.

Сонымен, нақты пайдаланушылары мен жұмыс сағаттары бар тірі бағдарламалық жүйені қалай басқарамыз? Бағдарламалық өнімді басқару әдістерін қолдану арқылы. Сондықтан платформаның өнімді басқару мамандары жасаған, пайдаланушылардың (Dev командаларының) қажеттіліктеріне негізделген даму жоспары (roadmap) болуы керек. Платформалық команда пайдаланушылардың кейіпкерлерімен (мысалы, веб-әзірлеуші Самир, тестілеуші Дженнифер, өнім иесі Мани, қызмет көрсету инженері Джек және т. б. ) жұмыс істейтіні сөзсіз. Пайдаланушы кейіпкерлері платформалық командаға платформаның типтік пайдаланушыларының қажеттіліктерін, кедергілерін және мақсаттарын түсінуге көмектеседі. Платформалық команда мүшелері тұтынушыларға не қажет екенін түсіну үшін олармен үнемі байланыста болады.

Ең бастысы, платформалық «өнімнің» эволюциясы жай ғана Dev командаларының сұраныстарымен ғана жүрмейді; керісінше, ол ұзақ мерзімді перспективада олардың қажеттіліктерін қанағаттандыру үшін мұқият қалыптастырылады. Мүмкіндіктердің қолданылуы метрикалармен бақыланады және басымдықтарды анықтау үшін қолданылады. Платформа — бұл тек Dev командаларының бұрын сұраған мүмкіндіктерінің жиынтығы емес, ол саладағы технологиялық өзгерістер мен ұйымның өзгеретін қажеттіліктерін ескеретін тұтас, жақсы жасалған дүние. Жақсы платформа сонымен қатар қауіпсіздік және аудит командаларының Dev командаларымен өткізетін уақытын азайтуға қызмет етеді.

Көптеген ұйымдар өз командаларының анықтамасы мен мақсатын нақтылаудан пайда көрер еді. Шын мәнінде, біздің ойымызша, көптеген ұйымдар әр командасын төрт негізгі топологияның біріне сәйкестендіру арқылы тиімділікті айтарлықтай арттыра алады; яғни, әр команда үшін төрт негізгі топологияның қайсысы ең жақсы жұмыс тәсілі болатынын анықтап, содан кейін сол команданың өкілеттігін сол топологияның мақсаты мен мінез-құлық үлгілерін қабылдау үшін өзгерту керек.

Ағынға оңтайландырылған ұйымдағы командалардың көпшілігі ұзақ мерзімді, көпфункционалды, ағынға бағытталған командалар болуы керек. Бұл командалар функционалдықтың жекелеген бөліктеріне немесе пайдаланушы нәтижелеріне иелік етеді, бизнес өкілдерімен және басқа жеткізу командаларымен берік және тұрақты қарым-қатынас орнатады. Ағынға бағытталған командалар мүмкіндік беруші командалардың, платформалық командалардың және күрделі ішкі жүйе командаларының қолдауының арқасында өз мүмкіндіктеріне сәйкес келетін когнитивтік жүктемені күте алады.

Дәстүрлі түрде көптеген инфрақұрылымдық командалар тірі/өндірістік инфрақұрылымның барлық аспектілеріне, соның ішінде сол инфрақұрылымда орналасқан қосымшаларға енгізілетін кез келген өзгерістерге жауапты болды (5. 3-суретте көрсетілгендей):

Көптеген дәстүрлі инфрақұрылымдық командалар (оң жақта) өндірістік инфрақұрылымдағы барлық өзгерістерге, соның ішінде қосымшалардағы өзгерістерге жауапты бола отырып, жұмыс ағынын бөгеді. Dev командаларының жұмысы (сол жақта) орналастыру үшін инфрақұрылымдық немесе Ops командаларына тапсырылатын, бұл ағынға кедергі келтіретін.

Инфрақұрылымдық команданы платформалық командаға айналдыру платформа ішінде де, ең бастысы, ағынға бағытталған командалар ішінде де өзгерістердің жылдам әрі қауіпсіз ағынына мүмкіндік береді.

Инфрақұрылымдық командадан платформалық командаға ауысу оңай емес, өйткені платформа инфрақұрылым мамандарына бейтаныс болуы мүмкін бағдарламалық жасақтаманы әзірлеудің тексерілген әдістерін қолдана отырып, өнім ретінде басқарылады. Бірақ осы тараудың басқа жерлеріндегі мысалдар көрсеткендей, бұл — өте тиімді тәсіл.

Технологиялық компонентке негізделген қолданыстағы командалар не таратылып, жұмыс ағынға бағытталған командаларға берілуі керек, не басқа команда түріне айналуы керек: платформаның бір бөлігі ретінде (егер компонент төменгі деңгейдегі «платформалық» компонент болса), мүмкіндік беруші командаға (егер компонентпен ағынға бағытталған командалардың жұмыс істеуі оңай болса) немесе күрделі ішкі жүйе командасына (егер ішкі жүйе шынымен қажет болса және ағынға бағытталған командалар үшін тым күрделі болса). Кез келген жағдайда команда сәйкес командалық мінез-құлық пен өзара әрекеттесу режимдерін қабылдауы керек.

Мысалы, деректер базасының әкімшілері (DBA) командалары, егер олар бағдарламалық қосымша деңгейінде жұмыс істеуді тоқтатып, ағынға бағытталған командаларға деректер базасының өнімділігі, мониторингі және т. б. туралы білімді таратуға назар аударса, мүмкіндік беруші командаларға айнала алады. Кейбір ұйымдар DBA командасын платформаның бір бөлігіне айналдырып, деректер базасының өнімділігі, конфигурациясы, қолжетімділігі және т. б. бойынша мамандандырылған қызмет көрсете бастады, бірақ DBA командасы енді схема өзгерістеріне немесе қосымша деңгейіндегі деректер базасының мәселелеріне жауапты емес.

Сол сияқты, «ортаңғы деңгей» (middleware) командалары да, егер олар жүйенің сол бөліктерін ағынға бағытталған командалар үшін пайдалануды жеңілдетсе, платформалық командаларға айнала алады. Олар ортаңғы деңгейді ұйымның негізгі мақсаттарына сәйкес келетін, өздігінен қызмет көрсететін қарапайым қызметтерге айналдыру арқылы әзірлеушілердің когнитивтік жүктемесін азайтады.

Егер команданың бастапқы өкілеттігі нақты немесе уақытпен шектелмеген болса, құрал-сайман командасы уақыт өте келе оқшауланған құралдарға техникалық қызмет көрсету командасына оңай айналып кетуі мүмкін. Құралдар тізбегіне эмоционалды түрде байланудан бөлек, команда мүшелерінің техникалық дағдылары ескіруі мүмкін және олардың күш-жігері нақты қажеттіліктерге емес, инерцияға негізделген шағын жақсартуларға босқа жұмсалуы мүмкін.

Құрал-сайман командалары әдетте не қысқа мерзімді және жоғары фокусталған өкілеттігі бар мүмкіндік беруші командалар ретінде, не платформаның бір бөлігі ретінде (нақты, жақсы негізделген даму жоспарымен) жақсырақ жұмыс істейді.

Дәстүрлі түрде көптеген ұйымдар тірі/өндірістік ортадағы қосымшалар мен қызметтерді қолдау үшін бір кросс-сервистік команданы қолданды. Өзгерістер жылдамдығы мен жүйенің күрделілігі төмен болған кезде, бұл модель ұйымдарға қолдау көрсету командасындағы адамдардың саны мен дағдылары бойынша шығындарды оңтайландыруға мүмкіндік берді.

Дегенмен, бағдарламалық жүйелердегі жылдам және тұрақты өзгерістерге байланысты сәтті ұйымдар қазір өзгерістер ағынына жылдам әрі қауіпсіз көмектесу үшін қолдау көрсету командаларының құрамы мен орналасуын қайта қарастыруда. IT қолдауының ең жақсы жұмыс істейтін моделі екі аспектіден тұрады: (1) өзгерістер ағынына сәйкес келетін қолдау көрсету командалары және (2) тірі қызмет оқиғаларын шешуге арналған динамикалық кросс-командалық әрекеттер.

Қазіргі заманғы тиімді бағдарламалық жасақтаманы әзірлеу үшін архитектуралық команда басқа командаларға дизайнды немесе технологиялық таңдауларды таңудың орнына, олардың барынша тиімді жұмыс істеуіне қолдау көрсетуі керек. Forsgren, Humble және Kim «Accelerate» кітабында айтқандай: «Архитекторлар өз пайдаланушыларымен — жүйелерді құратын және басқаратын инженерлермен — тығыз жұмыс істеуі керек, бұл оларға жақсы нәтижелерге қол жеткізуге көмектесіп, соған қажетті құралдар мен технологияларды ұсынуы тиіс».

Бағдарламалық жасақтаманы жылдам әрі тұрақты жеткізуде қиындық көріп жүрген көптеген ұйымдарда командалардың түрлері өте көп және олардың міндеттері көбіне нашар анықталған. Бұл мәселені болдырмау үшін командаларды тек төрт негізгі түрмен шектеңіз: стримге бағытталған (stream-aligned), көмекші (enabling), күрделі ішкі жүйе (complicated subsystem) және платформалық (platform). Бұл ұйымның назарын жеке және ұйымдық деңгейде жұмыс ағынын (flow) жақсартатын өзара әрекеттесу үлгілеріне аударады.

Бүгінгі таңда күрделі бағдарламалық жүйелерді әзірлейтін және басқаратын ұйымдар өз командаларын өндірістік жүйелердің қалай жұмыс істейтініне (немесе істен шығатынына) негізделген қауіпсіз және жылдам өзгерістер ағынына оңтайландыруы қажет. Бұл дегеніміз, командалардың көпшілігі бос байланысқан (loosely coupled), өзгерістер ағынына («стримге») сәйкестендірілген және өздері жауапты өнімге немесе қызметке құндылық қоса алатын қабілетті болуы тиіс.

Стримге бағытталған командаларға бұл жоғары жылдамдыққа қол жеткізуге көмектесетіндер: көмекші командалар (кедергілерді анықтайды және жаңа тәсілдерді енгізуді жеңілдетеді), күрделі ішкі жүйе командалары (қажет болған жағдайда жүйенің нақты бөліктеріне терең мамандандырылған сараптама әкеледі) және платформалық командалар (стримге бағытталған командалар өнімдерді минималды кедергімен құрып, қолдай алатын негізгі «субстратты» қамтамасыз етеді).

Команда түрлері мен міндеттерін осылайша стандарттау командалардың көпшілігінің стримге бағытталғанын және оларға көмекші, күрделі ішкі жүйе және платформалық командалар тарапынан қолдау көрсетілетінін қамтамасыз ету арқылы жұмыс ағынын арттыруға көмектеседі.

Стримге бағытталған командалардың жылдам жұмыс істеуіне мүмкіндік беруге назар аудару ұйымның барлық деңгейінде шешім қабылдауға көмектеседі және барлық командалар үшін ортақ миссияны қамтамасыз етеді.

Әрбір команда басқа көптеген командалармен өзара әрекеттесудің күрделі торына тәуелді болғанда, жұмыс ағынына қол жеткізу қиын. Бағдарламалық жүйелердегі өзгерістер ағыны жылдам болуы үшін біз жұмысты бір-біріне беру (hand-offs) процестерін алып тастап, командалардың көпшілігін ұйымдағы негізгі өзгерістер ағындарына сәйкестендіруіміз керек. Алайда, көптеген ұйымдар командаларға жүктелген жауапкершілік шекараларына қатысты үлкен мәселелерге тап болады. Әдетте, шекаралардың команда үшін қолайлылығына аз көңіл бөлінеді, бұл иелік ету сезімінің жоқтығына, жұмысқа ынтаның төмендеуіне және жеткізу жылдамдығының тым баяулауына әкеп соғады.

Бұл тарауда біз командаларға өз жүйесін тиімді және тұрақты түрде басқаруға мүмкіндік беретін қолайлы шекараларды анықтау жолдарын қарастырамыз. Бұл әдістер монолитті бағдарламалық жасақтамаға да, еркін байланысқан жүйелерге де бірдей тиімді. Ең бастысы, бұл шекаралар «команда өлшемінде» болады: біз бағдарламалық қамтамасыз ету мен жүйе шекараларын бір команданың мүмкіндіктеріне сәйкестендіреміз, бұл жауапкершілікті өз мойнына алуды және бағдарламаны тұрақты дамытуды әлдеқайда жеңілдетеді.

Бағдарламалық жасақтаманы жеткізудегі көптеген мәселелер командалар арасындағы шекаралар мен олардың міндеттерінің анық болмауынан туындайды. Конвей заңы айтқандай, бұл көбінесе әртүрлі бөліктер арасындағы жоғары байланысы бар (тіпті қағаз жүзінде архитектура модульдік болып көрінсе де) бағдарламалық архитектураның көлеңкесінде қалады. Мұндай жүйе әдетте «монолит» деп аталады.

«Accelerate» кітабында жарияланған зерттеулер тығыз байланысқан архитектуралардың нақты жауапкершілігі бар автономды командалардың жұмысына теріс әсер ететінін дәлелдейді. Авторлар мұндай архитектураларды бөлуге көмектесетін тәсілдерді де атайды: «Командаларға дизайннан бастап енгізуге дейінгі толық иелік етуді қолдайтын архитектуралық тәсілдерге үлкен домендерді кішірек, еркін байланысқан бөліктерге бөлу жолы ретінде шектелген контекстер мен API-лерді қолдану жатады».

Командалық аспектіні ескермей, біз монолитті қате жерлерден бөліп алу немесе тіпті бір-біріне тәуелді сервистердің күрделі жүйесін жасап алу қаупін тудырамыз. Бұл «таратылған монолит» (distributed monolith) деп аталады және командалардың өз сервистері бойынша автономиясын жоғалтуына әкеледі, өйткені кез келген өзгеріс басқа сервистерді де жаңартуды талап етеді. Amazon-ның сервис командалары сияқты мысалдар (4-тарау) сервистің қажетті тәуелсіздігіне қол жеткізу үшін командалық өзара әрекеттесуді ойластыру және бағыттау қажеттігін көрсетеді.

Монолитті бағдарламалық жасақтаманың көптеген түрлері бар, олардың кейбіреуін бірден анықтау қиын. Мысалы, көптеген ұйымдар қолданбалы монолитті кішірек сервистерге бөлуге көп уақыт пен күш жұмсайды, бірақ соңында жеткізу құбырында (deployment pipeline) монолитті релиз жасап, жылдамырақ және қауіпсіз қозғалу мүмкіндігін жоғалтады. Өзгерістер жасамас бұрын біз қандай монолиттермен жұмыс істеп жатқанымызды толық түсінуіміз керек.

Монолиттің әр түрінің өз кемшіліктері бар, бірақ бағдарламалық жасақтаманы бөлу кезінде де сақ болу керек қауіптер бар. Бөлу бағдарлама бөліктері арасындағы сәйкестікті азайтып, деректердің кездейсоқ қайталануына әкелуі мүмкін. Егер біз біртұтас UX-ке қол жеткізбесек, пайдаланушы тәжірибесі нашарлауы мүмкін.

Әдетте, бағдарламалық шекараларды әртүрлі бизнес-домен салаларына сәйкестендіру ең дұрыс жол болып табылады. Егер монолит бірнеше бизнес саласына қызмет етсе, бұл жұмыс ағынына және пайдаланушы тәжірибесіне теріс әсер етеді. Алайда, тек бизнес-домендер ғана емес, басқа да мүмкін болатын сызат жазықтықтары бар.

Мартин Фаулер шектелген контекстің домендік аймақтың ішкі үйлесімді моделі болуы керек екенін түсіндіреді:

Шектелген контекстерді анықтау бизнес білімін және техникалық тәжірибені талап етеді, сондықтан бастапқыда қателіктер жіберу қалыпты жағдай. Бірақ бұл сізді жақсартудан және бейімделуден тежемеуі керек.

DDD-ні қолданудың басқа артықшылықтарына негізгі күрделілікке назар аудару, бизнес сарапшыларымен ынтымақтастық арқылы модельдерді зерттеу және бизнес иелері мен техниктердің бір тілде сөйлесуі жатады.

Қорытындылай келе, бизнес-доменнің сызат жазықтығы технологияны бизнеспен сәйкестендіреді, терминологиядағы алшақтықтарды азайтады және өзгерістер ағынын жақсартады.

Біз домендерді (бизнес салаларын) нақты бөлу арқылы командаларға дербестік беру маңызды екенін білдік. Сондықтан әр доменнің қаншалықты тәуелсіз екенін бағалап, ақ тақталарда сценарийлерді талдап, бағдарламаны осы домендік шекаралар бойынша бөлдік. Біз Конвей заңының теріс әсеріне ұшырамау үшін домендердің тиімді бөлінуін қамтамасыз етуге тырыстық.

Біз өзімізді «матрицалық өнім командалары» ретінде ұйымдастырдық. Бұл өнімнің белгілі бір саласына толық жауап беретін кросс-функционалды командалар. Команда мүшелері тұтынушылармен тікелей сөйлеседі, шешімдерді жобалайды, құрастырады және олардың сапасына жауап береді.

Біздің жеткізу командаларымыздың көбі электрондық пошта, күнтізбе, адамдар, сауалнамалар сияқты бизнес-домендерге сәйкес бөлінген. Сондай-ақ нормативтік шекараларға (ақпараттық қауіпсіздік бойынша ISO 27001) жауап беретін бөліктер де бар.

Оның орнына технологиялық шекаралар бойынша командаларды ұйымдастыруға болады (орнатылған бағдарлама тобы, бұлттық топ және мобильді қолданба тобы). Бұл технологиялар арасындағы айырмашылық (дағдылар мен жеткізу жылдамдығы тұрғысынан) әрқайсысы үшін бөлек команда болуының негізгі себебі болып табылады.

Бұл жағдайда екі негізгі нұсқа бар (124-беттегі 6. 1-суретті қараңыз): (1) Бұлттық бағдарламаны платформа ретінде, ал мобильді және IoT бағдарламаларын платформаның тұтынушылары ретінде қарастыру. (2) IoT құрылғыларын платформа ретінде қарастырып, бұлт пен мобильді қолданбаларды соның тұтынушылары ету.

Бұл тәсіл екі немесе одан да көп технологиялық саланы қамтитын функциялар үшін командалар арасында тұрақты үйлестіруді талап етеді. Бірақ бұл үйлестіру сонымен қатар командалар арасында ортақ жұмыс әдістерін (мысалы, семантикалық нұсқалау, лог жүргізу тәсілдері) қалыптастыруға қызмет етуі керек.

Уақыт өте келе, бұл ортақ тәжірибелер мен білім технологиялар арасындағы өзгеріс қарқыны теңелген сайын команда шекараларын болашақта қайта құруға мүмкіндік беруі мүмкін.

Ешқандай сөзді блоктама Html tag керек емес

Сонымен қатар, біз жұмыс ағынына кедергі келтіретін және командалар арасында қажетсіз тәуелділіктерді тудыратын монолиттердің әртүрлі түрлерін білуіміз керек. Біз әдетте жүйелік архитектураны монолит деп ойлағанымызбен, жүйелік архитектура модульдік болған күннің өзінде де байланыстың (coupling) еніп кетуінің басқа да жасырын жолдары бар (мысалы, ортақ дерекқорлар, байланысқан жинақтар және/немесе релиздер және т. б. ). Эми Филлипс айтқандай: «Егер сізде микросервистер болса, бірақ релиз алдында олардың комбинациясын бастан-аяқ тестілеуді (end-to-end testing) күтсеңіз, онда сіздегі нәрсе — бөлінген монолит». 10

Жарықшақ жазықтықтары командалар арасында жұмысты бір-біріне тапсырудан (hand-offs) аулақ болу және ағынды ілгерілету үшін нақты мәселелердің (мысалы, технология, реттеу, өнімділік, қызметкерлердің географиялық орналасуы, пайдаланушы персонаждары) айналасында таңдалуы мүмкін.

Барлық жағдайда бағдарламалық жасақтама сегменттерін команда өлшеміне сәйкес жасау өте маңызды, сонда командалар өздерінің бағдарламалық жасақтамасына тиімді иелік ете алады және оны тұрақты түрде дамыта алады.

Жұмысты бастаңыз: командадан бастаңыз, ағындарды анықтаңыз, ең кіші өміршең платформаны (thinnest viable platform) анықтаңыз, құзыреттілік алшақтықтарын анықтаңыз және командалық өзара әрекеттесулерді іс жүзінде қолданыңыз.

II бөлімде біз төрт негізгі командалық топологияның комбинациясы — ағынға бағытталған, қолдаушы (enabling), күрделі ішкі жүйе және платформа — жылдам ағынмен бағдарламалық жасақтаманы жеткізудің нақты үлгісін қалай қамтамасыз ететінін көрдік. Дегенмен, командаларды жай ғана үлгілерге бөлу жоғары тиімділік үшін жеткіліксіз; сонымен қатар бұл командалардың қалай өзара әрекеттесетінін және командалар мен олардың әрекеттесулерін қашан өзгерту керектігін анықтау қажет.

III бөлімде командалық өзара әрекеттесулердің эволюциясы бағдарламалық жүйелерді құратын ұйымдар үшін қалай стратегиялық артықшылыққа айналатыны қарастырылады. Жақсы анықталған командалық өзара әрекеттесу үлгілері мен командалық топологияларды дамытудың нақты эвристикаларын біріктіру арқылы ұйымдар командалық өзара әрекеттесулерді инновацияларды сезіну механизмі ретінде және тұтынушы немесе пайдаланушы үшін жақсырақ нәтижелерге бағытталған өзін-өзі басқару құралы ретінде пайдалана алады.

Осы уақытқа дейін біз әртүрлі сценарийлер үшін жақсы жұмыс істейтін бірнеше статикалық (уақыттың белгілі бір сәтіндегі) командалық топологияларды, сондай-ақ қолайлы командалық шекараларды таңдау бойынша кейбір нұсқаулықтарды көрдік. Дегенмен, командалық шекараны бір рет таңдап, бұдан былай ешқандай өзгеріс болмайды деп күту жеткіліксіз; керісінше, ұйымдар бизнес, ұйымдық, нарықтық, технологиялық және кадрлық қажеттіліктерді қанағаттандыру үшін командалық үлгілердің эволюция қажеттілігін алдын ала болжауы керек.

Командалар бір салада көбірек тәжірибе жинақтаған сайын, жаңа технологиялар пайда болған сайын немесе ұйым көлемі ұлғайып-кішірейген сайын, командалар арасындағы динамика мен экономика (әсіресе ауқымды үнемдеу) өзгереді және командалық топологияларды таңдау бұл өзгерісті жеңілдетуге көмектеседі. Кейбір жағдайларда, ең тиімді бағдарламалық жасақтаманы жеткізу нәтижелеріне қол жеткізу үшін бір уақытта екі команда тығыз жұмыс істеуі керек болса, алты немесе тоғыз айдан кейін олар тәуелсіз болуы мүмкін. Қолданылатын командалық топологиялар І бөлімде кездесетін негізгі командаға бағытталған және архитектуралық ойларды сақтай отырып, туындайтын қиындықтарға бейімделуі және дамуы керек.

Бұл тарауда біз бағдарламалық жүйелерді құратын командалар арасындағы қажетті өзара әрекеттесуді жеңілдететін және түсіндіретін үш негізгі командалық өзара әрекеттесу режимін қарастырамыз: коллаборация, X-қызмет ретінде және фасилитация. Бұл командалық өзара әрекеттесу режимдері ұйымдағы барлық командалар үшін күтілетін нәтижелер мен мінез-құлық үлгілерін анықтайды, командалық өзара әрекеттесулерді қарапайым етеді және сәйкес келмейтін шекараларды анықтау тәсілі ретінде қызмет етеді.

Біз сондай-ақ командалық топологиялардың эволюциясын таңдауға бағыт беретін кейбір маңызды командалық өзара әрекеттесу режимдерін зерттейміз. Командалық өзара әрекеттесу режимдерінің артындағы динамика командалық топологияларды тиімді таңдаудың негізі болып табылады. Ең бастысы, жақсы анықталған командалық өзара әрекеттесу үлгілерінің жиынтығын пайдалану көптеген команда-бағдарламалық жасақтама қатынастарындағы түсініксіздіктен аулақ болуға көмектеседі, осылайша неғұрлым үйлесімді ішкі жүйе шекаралары мен API-лерді жасайды.

Көптеген ұйымдарда нашар анықталған командалық өзара әрекеттесулер мен жауапкершіліктер үйкеліс пен тиімсіздіктің көзі болып табылады. Командаға оның автономды және өзін-өзі ұйымдастырушы екендігі айтылуы мүмкін, бірақ команда мүшелері өз жұмыстарын аяқтау үшін басқа көптеген командалармен өзара әрекеттесуге мәжбүр екенін түсінеді; және бұл көңіл қалдырады. Басқа бір команда API немесе қызмет көрсетуге жауапты болуы мүмкін, бірақ оларда мұны тиімді жасау үшін тәжірибе жеткіліксіз болуы мүмкін.

Кез келген командалар арасындағы қарым-қатынасты қарастырған кезде, негізгі шешім — мақсатқа жету үшін басқа командамен бірлесе жұмыс істеу (коллаборация) немесе басқа команданы қызмет көрсетуші ретінде қарастыру (133-беттегі 7. 1-суретті қараңыз). Коллаборация немесе қызметті тұтыну арасындағы бұл таңдау ұйымның көптеген әртүрлі деңгейлерінде жасалуы мүмкін: инфрақұрылымды қызмет ретінде тұтыну (мысалы, AWS, Azure немесе Google Cloud-тан), логтау және метрикалар бойынша бірлесе жұмыс істеу, күрделі аудио өңдеу кодегін жасау үшін күрделі ішкі жүйе командасына сену немесе қосымшаны орналастыру (deployment) бойынша бірге жұмыс істеу. Біз аулақ болуымыз керек нәрсе — барлық командалардың өз мақсаттарына жету үшін барлық басқа командалармен байланысу қажеттілігі; джаз-бенд өзі ойнайтын музыканы үйлестіретіні сияқты, біз де ұйым ішінде болатын коммуникацияны мұқият реттеуіміз керек.

Коллаборация белгіленген салаларда нақты бірлесіп жұмыс істеуді білдіреді. X-қызмет ретінде бір команданың басқа командадан бір нәрсені «қызмет ретінде» тұтынуын білдіреді.

Жақында зерттеушілер күрделі мәселелерді командалық шешудің тиімділігін бағалау үшін тапқыр эксперимент ойлап тапты. Бернштейн мен оның әріптестері: «Мүшелері тек ара-тұра өзара әрекеттесетін топтардың... шешімдерінің орташа сапасы үнемі өзара әрекеттесетін топтармен бірдей болды, бірақ олар кейбір ең жақсы шешімдерді табу үшін жеткілікті түрлендіруді сақтап қалды» деген қорытындыға келді. 1 Ара-тұра болатын коллаборация тұрақты өзара әрекеттесуге қарағанда жақсырақ шешімдер тапты.

Бағдарламалық жүйелер үшін «Командалық топологиялар» моделін қалай және қашан бейімдеу керектігін түсіну үшін біз командалардың өзара әрекеттесуінің үш маңызды жолын анықтап, түсінуіміз керек, бұл ретте «алдымен команда» динамикасы мен Конвей заңын ескеру қажет:

Орта және ірі кәсіпорындардың көпшілігі үшін осы үш командалық өзара әрекеттесу режимінің комбинациясы қажет болуы мүмкін (және бұл режимдерді шағын ұйымдарға көптеген адамдар күткеннен ертерек енгізу пайдалы). Сонымен қатар, бір команда өзі жұмыс істейтін екі әртүрлі команда үшін екі әртүрлі өзара әрекеттесу режимін пайдалануы мүмкін. Біз бұл әртүрлі өзара әрекеттесу режимдерін 7. 2-суреттегі үлгілерді пайдаланып графикалық түрде көрсетеміз:

Коллаборация режимі диагональды штрихтаумен, X-қызмет ретінде режимі жақшалармен, ал фасилитация нүктелермен көрсетілген.

Мысалы, А командасы жеке қаржыны басқаруға арналған бағдарламалық жасақтамамен жұмыс істейтін ағынға бағытталған команда болсын. Олар жаңа бұлттық мониторинг құралдары бойынша В командасымен өзара әрекеттесу үшін коллаборация режимін пайдалануы мүмкін және бағдарламалық жасақтама жұмыс істейтін платформаны қамтамасыз ететін С командасымен өзара әрекеттесу үшін X-қызмет ретінде режимін пайдалануы мүмкін (135-беттегі 7. 3-суретті қараңыз).

Ағынға бағытталған А командасы күрделі ішкі жүйе В командасымен коллаборация жасайды (штрихтаумен көрсетілген), сонымен бірге X-қызмет ретінде режимін пайдаланып (жақшалармен көрсетілген) С командасы ұсынатын платформаны тұтынады.

Бағдарламалық жүйелерді құру кезінде командалардың өзара әрекеттесу тәсілдерін ресімдеу командалар арасындағы интерфейстерді нақтырақ анықтау арқылы бағдарламалық жасақтаманы жеткізудің көптеген аспектілерінің тиімділігін оңайырақ бағалауға көмектеседі; өз кезегінде (Конвей заңы бойынша) бұл интерфейстер құрылып жатқан бағдарламалық жүйелерде көрініс табады деп күтіледі. Жапондық өндіруші Toyota-ның зор табысын қарастыра отырып, Майк Ротер былай деп жазды: «Toyota табысының тамыры оның ұйымдық құрылымында емес, оның адамдарының қабілеттері мен дағдыларын дамытуда жатыр». 2

Өзара әрекеттесу режимдері командалық әдетке айналуы керек. Осындай командалық өзара әрекеттесулерді күту және оларға қол жеткізуге көмектесу арқылы командалар мақсаттың анықтығын сезінеді, командалық белсенділік артады және басқа командалармен туындайтын түсініспеушіліктер азаяды. Командалық өзара әрекеттесуді осылайша шектеу Конвей заңынан туындайтын жүйелерді құрудың гомоморфтық (құрылымдық ұқсастық) аспектілерін де саналы түрде қарастырады (2-тарауды қараңыз). Командалар мынаны сұрауы керек: «Біз бұл басқа командамен қандай өзара әрекеттесуде болуымыз керек? Біз басқа командамен тығыз коллаборация жасауымыз керек пе? Біз қызметті күтуіміз немесе ұсынуымыз керек пе? Әлде біз фасилитацияны күтуіміз немесе ұсынуымыз керек пе? »

<span data-term="true">Коллаборация</span>: басқа командамен тығыз бірлесе жұмыс істеу

Коллаборация режимі жоғары дәрежедегі бейімделу немесе жаңалық ашу қажет болғанда, әсіресе жаңа технологиялар мен әдістерді зерттеу кезінде қолайлы. Коллаборация режимі жаңа нәрселерді жылдам табу үшін жақсы, өйткені ол командалар арасындағы қымбат жұмыс тапсыру процестерінен аулақ болуға көмектеседі. Мысалы, екі қолданыстағы команданың, А командасы мен В командасының сараптамасын қамтитын кеңістікте маңызды инновация болуы мүмкін, мысалы, бұлттық сенсорларды басқару (бұлттық технологиялар мен сенсорлық технологияларды біріктіру) немесе киілетін құрылғылармен қауіпсіз жергілікті желі құру (желілік білім мен киім өнеркәсібінің тәжірибесін біріктіру). Коллаборация режимі командалар арасында жақсы үйлесімділікті және бірге жұмыс істеуге деген үлкен ынта мен қабілетті талап етеді.

Жаңа жүйелерді әзірлеудің алғашқы кезеңдерінде және жаңа ақпаратты, технологиялық шектеулерді және қолайлы тәжірибелерді жылдам табу қажет болатын кезеңдерде коллаборация режимі өте құнды. Себебі коллаборацияны пайдаланатын командалық топологиялар жұмыстың жаңа тәсілдерін және технологиялардың күтпеген мінез-құлқын жылдам анықтай алады.

Бұл коллаборация күрделі мәселелерді шешу үшін көптеген адамдардың біріккен білімі мен тәжірибесін біріктіру мақсатында әртүрлі дағдылар жиынтығы бар топтар арасында орын алады. Коллаборация технологиялардың қалай жұмыс істейтіні туралы жаңа түсініктерге әкеледі, ал алынған білім басқа командаларға қайтарылады (бұл доктор Кюнг Хи Ким мен Роберт А. Пирстің «дивергентті ойлау» тәсілдеріне сәйкес келеді3).

Коллаборация режимін пайдаланатын командалардың өзара әрекеттесуін визуализациялаудың екі пайдалы жолы бар. Біріншісі — әртүрлі сараптамасы мен жауапкершілігі бар екі команданың шағын мәселелер жиынтығында бірге жұмыс істеуін елестету. Бұл жағдайда екі команда өздерінің табиғи назар аудару саласы бойынша жауапкершілігі мен сараптамасын негізінен сақтайды және іс-әрекеттер мен бөлшектердің белгілі бір кіші жиынтығында бірге жұмыс істейді.

Коллаборация режимінің екінші визуализациясы командалар арасындағы бірлескен жұмыстың сипаты толық дерлік болуы мүмкін екенін көрсетеді: бастапқыда әртүрлі дағдылары мен сараптамасы бар екі команда болса, енді іс жүзінде сараптама мен жауапкершілікті біріктіретін біртұтас команда бар. (Адамдар саны Данбардың он бес санынан аспауы үшін мұқият болу керек).

Екі жағдайда да — шағын анықталған сәйкестік болса да және назар мен жауапкершіліктің толық сәйкестігі болса да — екі команда өздерінің коллаборациясының жалпы нәтижелері үшін бірлескен жауапкершілікті алуы керек, өйткені коллаборация актісі жауапкершілік шекараларының бұлдырауын тудырады. Бірлескен жауапкершілік болмаса, бір нәрсе дұрыс болмай қалған жағдайда сенімнің жоғалу қаупі туындайды.

Сонымен қатар, Конвей заңы коллаборация режимінен туындайтын ізденіс пен жылдам оқу кезінде бағдарламалық жасақтаманың жауапкершіліктері мен архитектурасы бір-бірімен көбірек араласатынын айтады. Егер екі команда арасындағы қызметтердің немесе жүйелердің нақты, жақсы анықталған интерфейстері қажет болса, онда коллаборация режимін ұзақ уақыт пайдалану ең жақсы таңдау болмауы мүмкін. Интерфейстерді орнату немесе жетілдіру үшін қысқа мерзімді немесе жеңіл-желпі ара-тұра коллаборация жасау қалыпты жағдай, бірақ үздіксіз коллаборацияның қажеттілігі домен шекараларының және/немесе команда жауапкершіліктерінің дұрыс емес екенін немесе команда ішіндегі дағдылардың дұрыс үйлеспегенін көрсетеді.

X-қызмет ретінде (X-as-a-Service) командалық өзара әрекеттесу режимі бір немесе бірнеше командаға көп күш жұмсамай-ақ «жай ғана жұмыс істейтін» код кітапханасын, компонентті, API-ді немесе платформаны пайдалану қажет болған жағдайларға қолайлы, мұнда жүйенің компоненті немесе аспектісі бөлек команда немесе командалар тобымен «қызмет ретінде» тиімді қамтамасыз етіле алады.

<span data-term="true">X-қызмет ретінде</span>: минималды коллаборациямен бір нәрсені тұтыну немесе ұсыну

Жүйені әзірлеудің кейінгі кезеңдерінде және ізденістен гөрі болжамды жеткізу қажет болатын кезеңдерде X-қызмет ретінде моделі жақсы жұмыс істейді. Бұл модельде командалар өздерінің технологиялық ландшафтының белгілі бір аспектілері басқа командалармен (ішкі немесе сыртқы) қызмет ретінде ұсынылатынына сене алады, бұл командаға өз жұмысын жеткізуге назар аударуға мүмкіндік береді.

Қызметтің күрделі аспектілері тығыз коллаборацияны пайдаланатын алдыңғы «дивергентті» тәсілмен анықталып қойған болады, бұл ең тиімді шешімді қызмет ретінде іске қосуға мүмкіндік береді. Бір нәрсеге «қызмет ретінде» сену XaaS командасынан (командаларынан) тамаша жұмысты талап етеді — бұған қол жеткізу оңай емес — бірақ бұл жеткізу командасының өз жұмысының негізгі емес аспектілерін азырақ түсінуіне мүмкіндік береді, бұл оларға жылдам жеткізуге жағдай жасайды (бұл доктор Кюнг Хи Ким мен Роберт А. Пирстің «дивергентті ойлау» тәсілдеріне сәйкес келеді).

X-қызмет ретінде режимінде кімнің неге иелік ететіні туралы толық айқындық бар: бір команда екінші команда ұсынатын нәрсені тұтынады. Коллаборация режиміндегі жұмыспен салыстырғанда әр командаға азырақ контекст қажет, сондықтан әр тараптағы когнитивті жүктеме төменірек болуы мүмкін. Жоспар бойынша, шекара арқылы инновация коллаборацияға қарағанда баяуырақ жүреді, өйткені X-қызмет ретінде режимінде қызметті жақсы анықтаған жақсы, таза API бар. Біз бұл қарым-қатынасты 7. 4-суреттен көре аламыз.

Бұл жағдайда оң жақтағы команда сол жақтағы командаға бір нәрсені «қызмет ретінде» ұсынып отыр (мүмкін бұл API, әзірлеуші құралдары немесе тіпті бүтін бір платформа болуы мүмкін).

Компонентті немесе жүйенің аспектісін қызмет ретінде тиімді ұсыну үшін жауапкершілік шекарасы бизнес немесе технологиялық домен контекстінде мағыналы болуы ғана емес, сонымен қатар қызметті ұсынатын команда өз қызметін тұтынатын командалардың қажеттіліктерін түсінуге және жүйенің өз аспектісін қызметті басқару принциптерін (нұсқалауды пайдалану, өнім менеджменті және т. б. арқылы) қолдана отырып басқаруға шебер болуы керек.

Тіпті төменгі деңгейдегі XML түрлендірулеріне арналған қарапайым код кітапханасының өзі өнімді басқару және DevEx принциптерін қолданудан ұтады. XML кітапханасын жасайтын және қолдайтын команда нұсқалау (versioning) және кері үйлесімділік, кітапхананың ескі нұсқаларын қолданыстан шығарудың жарияланған жол картасы (roadmap), тұтынушыларға жаңа нұсқаларға өтуге көмектесу және т. б. туралы ойлануы керек. Код кітапханасынан үлкенірек кез келген нәрсе үшін X-as-a-Service тәсілдеріне деген қажеттілік бұдан да жоғары болады.

Артықшылықтары | Кемшіліктері --- | --- Жауапкершілік шекаралары нақты белгіленген иелік ету айқындылығы | Шекара немесе API тиімсіз болса, жұмыс ағынының баяулау қаупі Командалар арасында қажетті детальдар мен контекст азаяды, сондықтан когнитивтік жүктеме шектеледі | Шекара немесе API инновациясының баяулауы

Фасилитациялық (жәрдемдесу) командалық әрекеттесу режимі бір немесе бірнеше команда өз жұмысының қандай да бір аспектісінде басқа команданың белсенді көмегіне (немесе коучингіне) мұқтаж болған жағдайларға қолайлы. Фасилитациялық режим қолдаушы команданың (5-тарауды қараңыз) негізгі жұмыс режимі болып табылады және ол көптеген басқа командаларға қолдау көрсетіп, мүмкіндіктер бере отырып, осы командалардың өнімділігі мен тиімділігін арттыруға көмектеседі. Фасилитацияны жүзеге асыратын команданың міндеті — басқа команда(лар)ға тиімдірек болуға, тезірек үйренуге, жаңа технологияны жақсырақ түсінуге және командалар арасындағы ортақ мәселелер мен кедергілерді анықтап, жоюға мүмкіндік беру. Фасилитациялық команда сондай-ақ басқа командалар қолданатын қолданыстағы компоненттер мен қызметтердегі олқылықтарды немесе сәйкессіздіктерді анықтауға көмектесе алады.

Фасилитация режимін қолданатын командалар әдетте көптеген басқа командалармен жұмыс істейді, командааралық мәселелерді анықтап, азайтады және басқа командалар немесе ұйымдар қызмет ретінде ұсынатын код кітапханаларының, API-лердің және платформалардың бағыты мен мүмкіндіктерін қалыптастыруға көмектеседі.

Фасилитациялық міндеті бар команда негізгі бағдарламалық жүйелерді, қолдаушы компоненттерді немесе платформаны құруға қатыспайды, керісінше бағдарламалық жасақтаманы жасайтын және басқаратын басқа командалар арасындағы өзара әрекеттесу сапасына назар аударады. Мысалы, үш ағынға бағытталған команданың тиімділігіне жәрдемдесетін команда платформа ұсынатын лог жүргізу (logging) қызметін теңшеу өте қиын екенін анықтауы мүмкін: үш команда да оны пайдалануда қиындыққа тап болады. Сонда осы үш командаға көмектесетін команда платформа тарапынан лог жүргізу қызметін жақсартуға фасилитация жасай алады.

Фасилитациялық әрекеттесу кезінде екі команданың біреуі ғана негізгі бағдарламалық жүйелерді құратындықтан, <span data-term="true"> Конвей заңының </span> (ұйым құрылымы жүйе архитектурасына әсер етеді деген қағида) әсері алдын ала ескерілген: фасилитация жасайтын команда қажетті жүйе архитектурасына негізделе отырып, басқа командалар арасындағы байланысты анықтауға және нақтылауға көмектеседі.

Артықшылықтары | Кемшіліктері --- | --- Жұмыс ағынын арттыру үшін ағынға бағытталған командалардағы кедергілерді жою | «Құрастыру» немесе «басқару» жұмыстарымен айналыспайтын тәжірибелі мамандарды қажет етеді Компоненттер мен платформалардағы олқылықтарды және сәйкес келмейтін мүмкіндіктерді немесе функцияларды анықтау | Әрекеттесу фасилитацияға қатысатын бір немесе екі команда үшін де бейтаныс немесе біртүрлі көрінуі мүмкін

Әрбір командалық әрекеттесу режимі командалық мінез-құлықтардың тиісті жиынтығымен жақсы жұмыс істейді. Бұл командалық мінез-құлықтарды мінез-құлық «стильдері» деп қарастыруға болады, бұл концерттік топтың контекстке сәйкес музыкалық орындаудың әртүрлі стильдерін (джаз, свинг, оркестрлік фильм музыкасы және т. б. ) таңдауына ұқсайды. Топ (немесе команда) бір адамдардан тұрады, бірақ олардың топ ретінде қабылдайтын стилі қандай әсерге қол жеткізу керектігіне байланысты өзгереді. Бұл сондай-ақ топ (команда) квартет немесе хор сияқты басқа топпен бірге өнер көрсетуі керек жағдайларға да қатысты: екі топтың бірлескен өнері сәтті шығуы үшін топтың орындау стилі өзгереді.

Концерттік топ ойнап жатқан музыкасының қажеттіліктеріне және бірге өнер көрсетіп жатқан басқа топтарға сәйкес өзінің орындау стилін қалай өзгертсе, Team Topologies тәсілімен бағдарламалық жасақтаманы жеткізетін команда да басқа командалармен әрекеттесу түріне қарай командалық мінез-құлықтың әртүрлі «стильдерін» қабылдауы керек.

Белгілі технолог Джеймс Уркарт Конвей заңын ескере отырып, командааралық байланыс туралы былай деп жазады: «саясаттан, өткізу қабілетінің шектеулерінен және адамдар арасындағы байланыстың жай ғана тиімсіздігінен аулақ болатын байланыс арнасы қажет». Бұл дәл осы тараудағы нақты анықталған командалық әрекеттесулер қамтамасыз ететін нәтиже. Сонымен қатар, мінез-құлықты зерттеу нәтижелері адамдар басқалардың іс-әрекетін болжай алған кезде олармен жақсырақ жұмыс істейтінін көрсетеді. Адам ретінде біз ұйымдағы басқалар үшін тұрақты тәжірибе ұсына отырып, сенім ұялата аламыз. Нақты рөлдер мен жауапкершілік шекаралары күтілетін мінез-құлықты анықтауға көмектеседі және кейбіреулер «көрінбейтін электр қоршаулары» деп атайтын жағдайлардан аулақ болуға мүмкіндік береді.

Коллаборация (ынтымақтастық) режимін қолданатын командалар әріптес командамен жоғары деңгейдегі әрекеттесу мен өзара құрмет болуын күтуі керек. Бұл әдетте команда мүшелері іс-шаралардың олар күткеннен әлдеқайда ұзаққа созылуына дайын болуы керек дегенді білдіреді, өйткені коллаборацияның «шекараларды тоғыстырушы» аспектілері бұрын белгісіз болған мәселелерді анықтап, шешеді. Бір команданы екінші команданың жұмысы үшін марапаттау мінез-құлықты үйлестіруге көмектеседі — бұны Principles of Product Development Flow авторы Дон Райнертсен «Бір-бірін жабатын өлшеу принципі» деп атайды.

Жұптық бағдарламалау, моб-бағдарламалау (бүкіл команда бірге код жазу) және маркер тақтасында эскиз салу сияқты негізгі коллаборация дағдылары бойынша кейбір тренингтер немесе коучингтер, сондай-ақ шекараларды тоғыстыратын ынтымақтастық бойынша арнайы оқыту коллаборация режимін қолданатын командалар үшін өте пайдалы болуы мүмкін.

X-as-a-Service режимін қолданатын командалар қызмет ретінде ұсынылатын өнімнің пайдаланушы тәжірибесіне (UX) басымдық беруі керек. Мысалы, егер платформалық команда ағынға бағытталған команда үшін динамикалық бұлттық тестілеу орталарын ұсынса, екі команда да осы орталармен әрекеттесу тәжірибесіне назар аударуы керек: API қандай сезім тудырады, пайдаланылатын ресурстарды көру қаншалықты оңай, функциялар пайдалану үшін қаншалықты тартымды және т. б. Платформаның функционалдығы да маңызды екені анық, бірақ командалар арасындағы ең жақсы және нәтижелі әрекеттесуді қамтамасыз ету үшін платформаны пайдалану тәжірибесіне назар аудару өте маңызды.

Негізгі пайдаланушы тәжірибесі (UX) және әзірлеуші тәжірибесі (DevEx) практикалары бойынша кейбір тренингтер немесе коучингтер X-as-a-Service режимін қолданатын командалар үшін пайдалы болуы мүмкін.

Фасилитация режимін қолданатын командалар көмек беруге де, көмек алуға да дайын болуы керек. Айталық, қолдаушы команда ағынға бағытталған командаға жаңа практикаларды енгізуге көмектесіп жатыр. Ағынға бағытталған команданың адамдары қолдаушы команданың көмегін қабылдауға ашық болуы керек; олар жаңа тәсілдерге ниет білдіріп, қолдаушы команданың бұдан да жақсырақ тәсілдерді көрген болуы мүмкін екенін түсінуі қажет.

Басқа командаға қалай фасилитация жасау керек немесе одан қалай көмек алу керек деген мәселелер бойынша кейбір тренингтер немесе коучингтер фасилитация режимін қолданатын командалар үшін пайдалы болуы мүмкін.

Төрт негізгі командалық топологияның (ағынға бағытталған, қолдаушы, күрделі ішкі жүйе және платформалық) әрқайсысының ұйымдық контексте жақсы жұмыс істеуіне мүмкіндік беретін белгілі бір мінез-құлық сипаттамалары бар. Кейде нәтижелерді жақсарту үшін команда басқа командалармен әрекеттесудің басқа режимін қабылдауы қажет болуы мүмкін (уақытша немесе тұрақты негізде).

Әрбір негізгі командалық топология әртүрлі әрекеттесу режимдеріне тап болуы мүмкін. Командалық әрекеттесулерді осы үш режимге сәйкестендіру командалардың ағымдағы ұйымдық мақсаттары үшін барынша тиімді жұмыс істеуін қамтамасыз етуге көмектеседі. 7. 5-суретте (145-бетті қараңыз) төрт негізгі командалық топологияның әрқайсысы үшін негізгі әрекеттесу режимдері көрсетілген.

Ағынға бағытталған командалар X-as-a-Service немесе коллаборацияны пайдаланады; қолдаушы командалар фасилитацияны пайдаланады; күрделі ішкі жүйе командалары X-as-a-Service пайдаланады; платформалық командалар платформаны тұтынатын командалар үшін X-as-a-Service пайдаланады.

Негізгі командалық топологиялардың әдеттегі және кездейсоқ әрекеттесу режимдерін 7. 4-кестеде көрсетілгендей маңызды командалық әрекеттесу режимдерімен салыстыруға болады.

Топология | Коллаборация | X-as-a-Service | Фасилитация --- | --- | --- | --- Ағынға бағытталған | Әдеттегі | Әдеттегі | Кездейсоқ Қолдаушы | Кездейсоқ | — | Әдеттегі Күрделі ішкі жүйе | Кездейсоқ | Әдеттегі | — Платформалық | Кездейсоқ | Әдеттегі | —

Командалық әрекеттесу режимдерін түсіне отырып, біз қажетті бағдарламалық архитектураны құруға көмектесетін бастапқы ұйымдастыру дизайнын таңдай аламыз. Әріптестер арасында ұйым таңдалған шекаралардың шынымен де ең жақсы шекаралар екенін «сезінген» сайын, әрекеттесу режимдері мен командалық құрылымдардың аз да болса өзгеруі қажет болатыны туралы түсінік қалыптасуы тиіс.

Эрик Миник, Үздіксіз жеткізу (Continuous Delivery) бағдарламасының директоры, IBM

2013 жылдан бастап Эрик Миник бүкіл әлем бойынша IBM техникалық командаларында жаңа практикаларды енгізуге және таратуға жетекшілік етті.

2013 жылы мен IBM-ге қосылғанда, корпоративтік бағдарламалық жасақтама индустриясы бұлттық технологиялар мен жаппай автоматтандыру әкелген айтарлықтай өзгерістерді бастан кешіріп жатты. Менің ол кездегі рөлімнің бір бөлігі — ондаған жерде (алты континентте) жұмыс істейтін 40 000 әзірлеушіге сол кездегі жаңа DevOps және Agile практикаларын енгізуге көмектесу болды. Ол жерде командалық әрекеттесулердің көптеген түрлері болып жатты, сондықтан жаңа жұмыс тәсілдеріне көшуді ынталандыру үшін бізде «адвокаттар» командасы болды (7. 6-суретті қараңыз).

2014 жыл шамасындағы IBM-дегі командалық әрекеттесу режимдері: оқуды және командалық өзгерістерді үйлестіретін және фасилитациялайтын «DevOps адвокаттары» командасы.

Адвокаттар командасына бірнеше толық күндік қызметкерлер мен кейбір қосалқы жұмыс істейтін адамдар кірді. Ол идеялардың IBM ұйымына таралуына көмектесу үшін бүкіл әлем бойынша әртүрлі командалардан сәтті үлгілерді жинап, басқаларды ынталандырды және оқытты. Оның тәсілі командалар мен олардың басшылары үшін ресми оқытуды қамтыды. Сонымен қатар, мыңдаған технологтар аудиториясын жинайтын ішкі вебинарлар сияқты контенттер тұрақты түрде шығып тұрды.

Адвокаттар командасы командалық топологияға онша сәйкес келмеуі мүмкін, өйткені біз өзімізді бірнеше жылдан кейін қажет болмайтын уақытша команда ретінде қарастырдық, немесе мен ол кезде Twitter-де айтқандай: «DevOps командасының» мақсаты — ұйымның қалған бөлігіне мүмкіндік беру арқылы өзін-өзі жабу (қажетсіз ету) болуы керек.

Жаңа ұйымдық құрылымның жұмыс істеуіне көмектесу үшін — және жаңа жауапкершілік шекараларының шынымен дұрыс екенін сезіну үшін — кері Конвей маневрі бағдарламалық жасақтаманы жасайтын командалар арасындағы уақытша, бірақ нақты коллаборация режимдерімен, сондай-ақ фасилитациялық режимде әрекет ететін бір немесе бірнеше қолдаушы командалармен (және мүмкін басқа командалармен) бірге қолданылуы керек. Жаңа шекаралар арқылы уақытша, нақты коллаборацияны пайдалану және ағынға бағытталған және күрделі ішкі жүйе командалары үшін жоғары деңгейдегі фасилитацияны қолдану арқылы жаңа жауапкершілік шекараларындағы кез келген мәселелерді жылдам анықтауға болады, бұл командаға тым көп нәрсе құрылмай тұрып, дизайнды ертерек түзетуге мүмкіндік береді.

Коллаборация кезеңінде бағдарламалық ішкі жүйелер үшін командалық жауапкершіліктер басында «теріс» (back to front) болуы мүмкін, бұл команданың иелік етуі ұзақ мерзімді перспективада тиімді болуы үшін қажет. Мысалы, үлкен бағдарламалық монолитті жеке сегменттерге (ағындарға, компоненттерге немесе платформаның жаңа аспектілеріне сәйкестендірілген) бөлу керек делік. Жоғары деңгейдегі компонентке «логикалық» тұрғыдан иелік ететін командалар сол кодты бөліп алу үшін белгілі бір уақыт бойы төменгі деңгейдегі қабатта (платформада) жұмыс істеуі қажет болуы мүмкін, әсіресе егер олар басында тым тығыз байланысқан кодты өздері жазған болса. Коллаборация кезеңі ілгерілеген сайын, төменгі қабатқа логикалық түрде иелік ететін команда жаңа команда төменгі қабатқа толық иелік еткенге дейін бастапқы командадан көбірек жауапкершілікті ала алады.

5-тарауда көргеніміздей, арнайы архитектура командасы әдетте аулақ болу керек анти-үлгі (anti-pattern) болып табылады. Дегенмен, бағдарламалық жасақтама және жүйелік архитекторлардың шағын тобы ұйым ішінде өте тиімді болуы мүмкін, егер архитектураның міндеті командалар арасындағы әрекеттесулерді, демек, жүйенің архитектурасын анықтау, түзету және қайта қалыптастыру болса.

Себебі жүйе құратын ұйым ішінде Конвей заңы қолданыста болғандықтан, ұйымның архитектурасы — бұл жүйенің архитектурасы. Немесе Рут Малан айтқандай: «ұйымдық бөліністер жүйедегі нақты жіктерді (seams) анықтайды». Командаларды қалыптастыру үшін кері Конвей маневрін қолданудың бұрыннан келе жатқан жақтаушысы Аллан Келли былай дейді: «өзін Архитектормын деп санайтын адамға техникалық та, әлеуметтік те дағдылар қажет. . . Сондай-ақ оларға таза технологиядан кеңірек өкілеттік керек — олар бизнес стратегияларына, ұйымдық құрылымдарға және кадр мәселелеріне ықпал ете алуы тиіс, яғни олар менеджер де болуы керек».

Архитектор былай деп ойлануы тиіс: «Осы екі команда үшін қандай командалық әрекеттесу режимдері сәйкес келеді? Жүйенің осы екі бөлігі арасында, осы екі команда арасында бізге қандай байланыс қажет? » Сондықтан Team Topologies тәсілін ұстанатын ұйымдағы архитектор — бұл жоспарланған бағдарламалық архитектураны алдын ала ескеретін командалық API-лердің дизайнері.

Іс жүзінде, шекараларды тоғыстыруды орындау үшін командалар ішіндегі жеке адамдарға ғана сенудің орнына (бұл күйзеліске әкелуі мүмкін және жақсы әлеуметтік әрі техникалық дағдыларды қажет етеді), ұйым ішіндегі командалар арасындағы API-лерді жобалау үшін API дизайнында білікті адамдарды пайдаланыңыз.

Әртүрлі командалық әрекеттесу режимдерінің әртүрлі сипаттамалары бар, бұл оларды іс-әрекеттердің немесе мақсаттардың әртүрлі түрлеріне қолайлы етеді. Бұл бөлімде біз әртүрлі жағдайларда қай командалық әрекеттесу режимдерін қолдану керектігін анықтаймыз.

X-as-a-Service әрекеттесу режимі бағдарламалық жасақтаманы жеткізу командаларына жылдам ағынға қол жеткізуге көмектесуде өте тиімді болуы мүмкін. Дегенмен, кез келген қызмет сияқты, егер қызмет шекаралары дұрыс сызылмаса және қызмет жеткілікті икемділіксіз тым көп немесе тым аз нәрсені қамтамасыз етуге тырысса, X-as-a-Service әрекеттесуі тиімді болмайды; қызмет тұтынушы командалардың қажеттіліктерін қанағаттандырмайды.

Коллаборация режимі қолданбаның да, платформаның/инфрақұрылымның да инновация жылдамдығын арттыру үшін қолданылуы мүмкін, бұл әсіресе жаңа және дамып келе жатқан өнімдер немесе қызмет ұсыныстары үшін пайдалы.

Өзгерістердің қатысушы адамдардың толық келісімімен, түсіністігімен және құлшынысымен саналы түрде (және, бәлкім, уақытша) жасалуы өте маңызды. Хайди Хелфандтың «Dynamic Reteaming» кітабы командалық өзгерістерді мүмкіндігінше кедергісіз жасау үшін көптеген пайдалы ұсыныстар береді.

Командалық өзара әрекеттесу үлгілерін жүйе дизайнындағы мәселелерді анықтау және оларға жауап беру үшін қолдануға болады, бұл код өндіріске (production) жетпес бұрын бағдарламалық қамтамасыз ету мәселелерін болжауға мүмкіндік береді.

Екі мысалды қарастырайық:

Екінші мысалда платформалық команда stream-aligned командасымен белсенді байланысты күтеді, өйткені олар жаңа технологиялық шешімдерді бірге табу үшін коллаборация режимін пайдалануы керек. Бұл жағдайда командалар арасындағы байланыстың болмауы stream-aligned командасында бірдеңе дұрыс емес екенінің белгісі: Олар қазіргі кезеңде коллаборация режимін енгізудің маңыздылығын түсіне ме? Оларда бұл коллаборацияны жүзеге асыру үшін дағдылар жеткілікті ме, әлде басқа команда лайықтырақ па? Командалар қосқысы келетін шекара тым амбициялы ма?

Дон Рейнертсен айтқандай: «Біз рөлдер арасындағы ешкім жауапкершілік алмайтын "ақ дақтарға" (бос орындарға) сергек болуымыз керек». 12

Бұл тарауда біз командалық өзара әрекеттесудің үш негізгі режимі ұйымдағы барлық командалық қатынастар үшін қажетті айқындықты қалай қамтамасыз ететінін көрдік:

Нақты анықталған команда түрлері мен өзара әрекеттесу режимдерінің үйлесімі көптеген ұйымдар бастан кешіретін екіұштылық пен қақтығыстарды болдырмай, командаға негізделген ұйымдық тиімділікті арттырудың айқын әрі қуатты жолын ұсынады.

Бұл тарауда Конвей заңының нақты салдарын, «команда-бірінші кезекте» шешім қабылдауды және 5-тарауда сипатталған төрт негізгі командалық топологияны ескере отырып, заманауи, бағдарламалық қамтамасыз етуге негізделген ұйымдарға арналған дизайн ережелерінің жиынтығы қарастырылады.

Керісінше, X-as-a-Service режимінде қай команданың неге иелік ететіні туралы толық айқындық бар. Сондай-ақ әр команда үшін азырақ менталды контекст қажет, сондықтан қарым-қатынастың әр жағындағы когнитивтік жүктеме төменірек болады. Жалпы алғанда, командалар X-as-a-Service режимінде коллаборацияға қарағанда баяу инновация жасайтын сияқты, өйткені олардың өзара әрекеттесуі мүмкіндіктерді шектейтін таза API арқылы реттеледі және анықталады. X-as-a-Service болжамды жеткізу жылдам жаңалық ашудан маңыздырақ болатын жағдайлар үшін тиімді.

Бұл тәсіл «Accelerate» кітабында ұсынылған жоғары өнімді ұйымдарды зерттеудің соңғы нәтижелерімен расталады:

«Архитектуралық мүмкіндіктер бойынша жоғары ұпай жинайтын командаларда [бұл тікелей жоғары өнімділікке әкеледі], жеткізу командаларына өз жұмысын аяқтау үшін өзара байланыс аз қажет болады және жүйенің архитектурасы командаларға басқа командаларға тәуелді болмай-ақ өз жүйелерін сынауға, орналастыруға және өзгертуге мүмкіндік беретіндей етіп жасалған. Басқаша айтқанда, архитектура мен командалар "еркін байланысқан" (loosely coupled)». 1

Коллаборация қымбатқа түседі. Қажетсіз коллаборация, әсіресе негізгі платформалардағы немесе мүмкіндіктердегі кемшіліктерді жасыра алатындықтан, өте қымбат. Сондықтан кез келген тұрақты коллаборациялық қызмет құнды жаңалық ашу, құнды мүмкіндіктерді құру немесе құнды кемшіліктерді толтыру қызметі ретінде негізделуі тиіс.

Жоғары өнімді ұйым деңгейіне жету үшін әр командалық өзара әрекеттесуге қанша коллаборация сәйкес келетінін шешу маңызды. А командасы В командасының қызметтерін аз күш жұмсап тұтына алуы керек пе? Егер олар солай істеуі керек болса, бірақ әлі мүмкін болмаса, В командасының API-ын жақсырақ анықтау және А командасына оны «қызмет ретінде» тұтынуға мүмкіндік беру үшін А командасы В командасымен аз уақыт (Үш апта? Үш ай? ) бірге жұмыс істеуі керек пе? Коллаборация А және В командалары арасындағы жүйенің әр бөлігінің шекараларын бұлыңғырлататынын ескере отырып, командалар нақты не бойынша бірлесіп жұмыс істеуі керек?

Пол Инглс, uSwitch инженерия бөлімінің басшысы

Тұтынушылар рейтингі қызметі uSwitch-тегі Пол Инглс күрделілік біртіндеп артқан көптеген жылдардан кейін, әзірлеушілер (Dev) командалары тиімді болу үшін негізгі технологиялық стек туралы тым көп білуге мәжбүр болғанын қалай түсінгендерін сипаттайды.

Жеткізу мүмкіндігіндегі тиімді өзгерісті мәжбүрлеу үшін командалық өзара әрекеттесудегі өзгерісті осылайша саналы түрде пайдалану — күшті, стратегиялық технологиялық көшбасшылықтың мәні болып табылады.

Екі команданың өзара әрекеттесу режимін саналы түрде коллаборацияға өзгерту жаңа тәжірибелер мен тәсілдерді жылдам үйрену және енгізу үшін қуатты ұйымдық құрал бола алады. Егер бір команданың құнды тәжірибелер жиынтығында — мысалы, тестілеуді автоматтандыруда — үлкен тәжірибесі болса және бұл екінші командаға пайда әкелетін болса, онда екі команданы бірнеше айға коллаборация режимінде біріктіру командалар арасындағы API-ды жақсартуға және анықтауға көмектесіп қана қоймай, сонымен қатар екінші команданың мүмкіндіктерін сапалы жаңа деңгейге көтереді. Бұл «саналы коллаборация» әсіресе екі топтың өз технологияларына қатысты қалыптасқан тәжірибелерге байланысты бұрынғы тәжірибелері мүлдем басқаша болған жағдайда пайдалы.

Екі команда («бұлттық» және «ендірілген») тәжірибе алмасу және хабардарлықты арттыру үшін бірлесіп жұмыс істейді. Нәтижелер болашақ командалық өзара әрекеттесу нұсқалары туралы түсініктің артуын қамтиды: (1) бұлттық бағдарламалық қамтамасыз етуді ендірілген команда пайдаланатын платформа ретінде қарастыру, (2) ендірілген құрылғыларды бұлттық команда пайдаланатын платформа ретінде қарастыру немесе (3) тығыз коллаборацияны жалғастыру.

Бұлттық команда тестілеу орталарын өткінші және динамикалық ретінде қарастыратын шығар және ендірілген командаға тестілеуге икемді тәсіл қолдануға көмектесе алады. Өз кезегінде, ендірілген команда бұлттық командаға ендірілген IoT құрылғыларының жады мен өңдеу шектеулерін түсінуге және олардың кодын және протоколдарын шектеулі аппараттық құралдарға жақсырақ сәйкестендіруге көмектесе алады.

Бұл коллаборация кезеңі ұйымға бұлттық бағдарламалық қамтамасыз етуді немесе ендірілген құрылғыларды платформа ретінде (осы кітапта қолданылатын мағынада) қарастыруға болатын-болмайтынын және платформа жеткізуші команданың тиісті мінез-құлқын бағалауға көмектеседі. Балама нұсқа, әрине, командалардың коллаборацияны жалғастыруы болып табылады, бәлкім, көмекші (enabling) команданың үйлестіруімен. Коллаборация жалғасқан сайын, командалар өздерінің өзгерістер қарқыны біртіндеп сәйкес келетінін түсінуі мүмкін, бұл жағдайда олар екеуі де stream-aligned болатын «жұптасқан» командалар жиынтығын құруды шешуі мүмкін.

Дейв Хотчкисс, TransUnion платформа құрастыру менеджері

(4-тараудан жалғасы)

2014 жылы трансформациямыздың басында біз әзірлеу (Dev) және пайдалану (Ops) топтарының арасында үлкен алшақтық бар екенін түсіндік. Біз евангелистердің (насихаттаушылардың) жеке командасы Dev және Ops топтарын жақындастыруға көмектесетінін білдік; бірақ біздің жағдайда алшақтық өте үлкен болғандықтан, екі команданы пайдалануды шештік.

Dev тобынан біз жүйені құрастыру (SB) командасын, ал Ops тобынан платформаны құрастыру (PB) командасын құрдық. Содан кейін біз SB және PB командаларының тығыз коллаборациясына назар аудардық, бұл барлық Dev және Ops командаларын коллаборацияға тартудан гөрі басында шешілуі оңайырақ мәселе болды (158-беттегі 8. 2-суретті қараңыз).

Dev тобынан (SB) және Ops тобынан (PB) келген командалар тығыз өзара әрекеттесуді зерттеуде.

Біз DevOps командалық топологияларының үлгілерінен шабыт алып, команда эволюциясының хронологиясын сыздық. Біз басында Dev командаларының хабардарлығына немесе пайдалану мүмкіндігіне (operability) назар аударуды күттік, сондықтан біздің бастапқы командалық эволюциямызда SB командасы Dev командаларымен және PB командасымен тығыз коллаборация жасады. Бұл орналастыруды автоматтандыру, метрикалар, логтар және басқа да пайдалану аспектілері сияқты нәрселерді жақсартуға шынымен көмектесті (158-беттегі 8. 3-суретті қараңыз).

SB және PB екі командасы тығыз бірлесіп жұмыс істеуде.

2014 жылы біз SB және PB командаларын он екі айдың ішінде жақсы көмекші (enabling) командаға айналдырамыз деп күткен едік. Іс жүзінде бұл ауысу біз бастапқыда ойлағаннан әлдеқайда ұзаққа созылды (үш жылға ұзақ! ), өйткені біз қызметтерімізді Azure-ге көшіре бастадық; бірақ 2018 жылдың басына қарай біз бұған қол жеткіздік (158-беттегі 8. 4-суретті қараңыз). Бизнес үшін артықшылықтар өте анық болды: қауіпсіз, тұрақты өндірістік өзгерістер, орналастыру қателерінің азаюы және өзгерістердің жақсырақ қадағалануы (TransUnion жұмыс істейтін жоғары реттелетін қаржы секторында маңызды).

SB және PB командалары біріктіріліп, Dev және Ops-ты жақындастыруға көмектесті.

2018 жылдың соңына қарай біз одан да әрі кетіп, ақырында SB командасын Dev командаларына, ал PB командасын Ops командаларына қайта қостық, бұл пайдалану деңгейіндегі жауапкершілік пен хабардарлықты арттырды, ал Ops тобына Azure Cloud-та жұмыс істейтін кейбір стратегиялық инфрақұрылыммен негізгі платформаны басқаруды қалдырды (8. 5-суретті қараңыз).

SB және PB командалары Dev және Ops-қа қайта қосылып, Platform-as-a-Service (платформа қызмет ретінде) ұсынады.

Бұл командалардың эволюциясы болуы керек екенін ертерек түсінуіміз біздің жетістігіміз үшін өте маңызды болды. Адамдар бәріне уақыт керек екенін білді, ал нақты, бірақ өзгеретін жауапкершілік шекаралары адамдарға процестегі өз рөлін түсінуге көмектесті.

Коллаборация қымбат, бірақ жаңа тәсілдерді ашуға жақсы, ал X-as-a-Service болжамды жеткізуге жақсы; сондықтан командаларды бағдарламалық жүйенің әр аймағының және әр команданың қажеттіліктеріне сәйкес құруға болады. Бірақ талаптар немесе жұмыс контексті өзгергенде не болады?

Әртүрлі командалардың өзара әрекеттесу режимдері командалардың неге қол жеткізуі керек екеніне байланысты тұрақты түрде өзгереді деп күтілуі тиіс. Егер команда қазіргі уақытта басқа команда басқаратын технологиялық стектің немесе логикалық домендік модельдің бір бөлігін зерттеуі керек болса, онда олар белгілі бір уақыт кезеңінде коллаборация режимін пайдалануға келісуі керек. Егер команда басқа командамен жаңа тәсілдерді сәтті ашқаннан кейін жеткізу болжамдылығын арттыруы керек болса, онда ол командалар арасындағы API-ды анықтауға көмектесу үшін коллаборация режимінен X-as-a-Service режиміне ауысуы керек.

Осылайша, командалар неге қол жеткізуі керек екеніне байланысты белгілі бір уақыт аралығында әртүрлі өзара әрекеттесу режимдерін қабылдауы керек. Әрине, Конвей заңы бізге коллаборация режимінің бөлігі ретінде жүріп жатқан ізденістер мен жылдам оқу кезінде бағдарламалық жасақтаманың жауапкершіліктері мен архитектурасы командалар X-as-a-Service арқылы өзара әрекеттескен кезбен салыстырғанда көбірек «араласып» кететінін айтады. Осы бұлыңғырлықты алдын ала болжай отырып, команда X-as-a-Service режиміне ауысқан кезде API-ды қатайту арқылы кейбір қолайсыз командалық өзара әрекеттесулерден («API нашар жобаланған» және т. б. ) аулақ болуға болады.

Командалық топологиялардың тығыз коллаборациядан шектеулі коллаборацияға, содан кейін X-as-a-Service режиміне өтуін 8. 6-суреттен көруге болады (160-бетті қараңыз).

Командалық топологиялардың тығыз коллаборациядан шектеулі коллаборацияға (ізденіс), содан кейін қалыптасқан, болжамды жеткізу үшін X-as-a-Service режиміне дейінгі эволюциясы.

Бастапқы тығыз коллаборация технология мен өнім ізденіс арқылы жақсырақ түсінілген сайын азырақ нәрселер бойынша шектеулі коллаборацияға айналады және өнім немесе қызмет шекарасы көбірек қалыптасқаннан кейін X-as-a-Service режиміне ауысады.

Үлкенірек кәсіпорында бұл «ізденістен қалыптастыруға дейінгі» үлгі дамудың әртүрлі кезеңдеріндегі әртүрлі командалармен үнемі болып тұрады деп күтіледі. 8. 7-суретте көрсетілгендей, бір уақытта бірнеше ізденіс әрекеттері жүруі керек, ал басқа командалар нәрселерді қызмет ретінде тұтыну үшін нақты анықталған API-ларды пайдаланады (160-бетті қараңыз).

1-команда платформалық командамен коллаборацияны жалғастырып, жаңа технологияларды пайдаланудың жаңа үлгілері мен жолдарын ашады. Бұл ізденіс әрекеті ақырында 2-командаға платформалық командамен X-as-a-Service қарым-қатынасын орнатуға мүмкіндік береді. Кейінірек 3-команда және одан кейінгілер платформалық командамен тығыз коллаборация жасамай-ақ, оны қызмет ретінде пайдаланып, платформаның кейінгі нұсқасын қабылдайды.

Ақыр соңында, командалық әрекеттестіктің белгілі бір себептермен ынтымақтастық пен X-as-a-Service режимдері арасында ауысуын күту және ынталандыру арқылы ұйымдар <span data-term="true">ептілікке (agility)</span> (өзгерістерге жылдам бейімделу қабілеті) қол жеткізе алады.

Ұйымдағы командалар арасындағы өзара байланысты нақты анықталған және динамикалық күйде ұстау Джефф Суссна сыртқы және ішкі контексттер үшін «үздіксіз дизайн қабілеті» деп атайтын нәрсенің негізін қалайды. Бұл динамикалық қайта құру негізгі стратегиялық мүмкіндікті қамтамасыз етеді. Ұйымдық өзгерістер бойынша сарапшы Джон Коттер былай дейді: «Мен стратегияны «іздеу, орындау, үйрену және өзгертудің» үздіксіз процесі ретінде қарастырамын... Ұйым өзінің стратегиялық дағдыларын неғұрлым көп жаттықтырса, ол жоғары бәсекелестік ортаға соғұрлым бейімделе түседі».

Біз командалық өзара әрекеттестіктің уақыт өте келе олардың іс-әрекетіне байланысты айқын дамуы керектігін көрдік. Зерттеу кезеңінде белгілі бір деңгейдегі ынтымақтастық күтіледі, бірақ тығыз ынтымақтастық көбінесе бүкіл ұйым бойынша масштабталмайды. Мақсат — көптеген командалар жай ғана қызмет ретінде пайдалана алатын, нақты анықталған және қабілетті платформаны құру болуы керек.

Жаңа тауарлық қызметтер мен платформалар қолжетімді болған сайын, ұйымдар зерттеу қызметінен болжамды жеткізуге (delivery) көшуді мақсат етуі тиіс. Бұл ұйымдар үшін мынаны білдіреді: әртүрлі командалардағы адамдардың тәжірибесі сол уақытта немен айналысатынына байланысты әртүрлі болады. Барлық командалар басқа командалармен бірдей жолмен әрекеттеспейді және біздің қалайтынымыз да осы.

Ұйым ішіндегі командалық топологиялар күн сайын немесе апта сайын емес, бірнеше ай ішінде баяу өзгереді. Бірнеше ай ішінде командалық әрекеттестік режимдеріндегі өзгерістерді қолдау керек және соған сәйкес бағдарламалық жасақтама архитектурасында да өзгеріс күтілуі тиіс.

Платформаның дамуы шешуші нүктеге жетті және біз таңдау жасауымыз керек болды: не команданы таратып, қазіргі салыстырмалы түрде үлкен өнім командаларының әрқайсысын өздерінің конфигурациясын басқаруға жауапты етуіміз керек еді, не сол командаларды тиімдірек қолдаудың — оларға жоғары сапа мен сенімділікпен жеткізуді жеделдетуге мүмкіндік берудің жолын табуымыз керек еді.

Біз «Platform Evolution» командасы басқа командалар тұтынатын қызметтер ретінде өз жұмыстарын жобалау және ойластыру үшін қызметтері мен қолдау мүмкіндіктері бар өнім командасына айналуы керек деп шештік. Қысқасы, команда бизнеске құндылық әкелетін фичаларға (функцияларға) назар аударуы керек болды.

«Platform Evolution» командасы «Platform Services» болып өзгерді және мүлдем басқа дүниетаныммен жұмыс істей бастады. Олардың миссиясы — өз тұтынушыларының (басқа командалардың) қажеттіліктеріне негізделген функциялар мен мүмкіндіктер арқылы оларды қолдауға арналған қызметтерді ұсыну болды. Басқаша айтқанда, «Platform Services» өнімге бағытталған командаға айналды.

Осы кезеңде «Platform Evolution/Services» ішкі бағдарламалық жасақтама командаларымен тығыз байланыста болды. Жауапкершіліктің тиісті шекаралары туралы, әсіресе біздің инфрақұрылымдық команда мен «Platform Services» арасында жиі пікірталастар мен қақтығыстар болып тұратын. «Platform Services» файрвол және жүктеме теңестіргішін автоматтандыру, AWS-ті қолдануды қолдау құралдары, құпияларды басқару және PKI сияқты нәрселерді жасап жатты, бірақ көбінесе инфрақұрылымдық командамен арадағы ұйымдық шекараларға тап болатын. Инфрақұрылым «платформалық қабатта» не нәрсеге жауапты болуы керек? Және — сәл нәзік мәселе — олар өнімдерді қолдайтындай етіп ұйымдастырылған ба? деген сұрақ туындады.

Бұл әңгіме басталғаннан кейін, оның біздің инфрақұрылымдық команданың қалай ұйымдасуы керектігі туралы ішкі талқылауларымен ұштасатыны белгілі болды. Инфрақұрылым бизнестегі жеткізу (delivery) мен пайдалану (operations) арасында нақты бөлінісі бар соңғы маңызды функция болатын және жаңа нәрсені байқап көруге ниет білдірілді. Инфрақұрылым өнімдер мен қызметтер айналасында қайта ұйымдастырылды; шағын командалар бизнестегі тұтынушылары үшін оларды жақсартуға ұмтыла отырып, өзара байланысты нәрселердің толық өмірлік цикліне иелік етті. Бұл трансформацияның бөлігі ретінде «Platform Services»-тің қай жерге жақсы сәйкес келетіні де белгілі болды — ол инфрақұрылым мен технологияның қалған бөлігі арасындағы бір команда емес, инфрақұрылым функциясының бөлігі ретінде қарастырылды.

Жүктеме теңестіргіші және файрволды автоматтандыру сияқты кейбір қызметтер желіге қатысты жасақтарымыздың (squads) бірінен табиғи орын тапса, кейбіреулері екі «Platform Services» жасағында қалды: «Platform Engineering» және «Delivery Engineering». Біз бұрын мұндай мүмкіндігі болмаған инфрақұрылымдық жасақтарға автоматтандыру инженерлерін қостық және команданың кеңірек бизнеспен байланысын қолдау үшін инфрақұрылымдық өнім функциясын дамыттық.

Қазір бізде тұтынушыға бағытталған өнім фича-командалары сияқты инфрақұрылымдық-платформалық фича-командалар бар; бұл өзгеріс оңай немесе қиындықсыз болмаса да, қатысу деңгейінен, иелік ету сезімінен және бизнестің басқа салаларымен үйкелістің азаюынан бұл өзгерістің трансформациялық болғаны анық. Бизнестің басқа салалары үшін енді кіммен сөйлесу керектігі, ол команданың не істеп жатқаны және неге істеп жатқаны түсінікті, ал бұрын мұның бәрі жай ғана «инфрақұрылым» болатын.

Кез келген уақытта ұйым ішіндегі әртүрлі командалардың әртүрлі әрекеттестік пен ынтымақтастық қажеттіліктері болады. Командалық топологиялардың әртүрлі түрлері бір мезгілде болады деп күтілуі керек. Командалар арасында белгілі бір дәрежеде ынтымақтастық күтіледі, бірақ ынтымақтастық көбінесе бүкіл ұйым бойынша масштабталмайды; ал командалар саны артқан сайын нәрселерді қызмет ретінде тұтыну тиімдірек болады.

Бұл мысалда бір мезгілде командалық әрекеттестіктің үш түрі орын алуда: ағынға бағытталған командалар көмекші командамен жеңілдетуші (facilitating) әрекеттестікті бастан кешуде, ал төрт ағынға бағытталған команданың үшеуі платформамен X-as-a-Service әрекеттестігін күтеді, ал бір ағынға бағытталған команда платформалық командамен ынтымақтастық әрекеттестігі арқылы зерттеу жұмыстарын жүргізеді.

Өзара әрекеттесу режимдері анық және айқын болғандықтан және олар нақты мақсаттарға сәйкестендірілгендіктен, ұйымдағы әртүрлі командалардағы адамдар басқа командалармен неге әртүрлі тәсілдермен әрекеттесетінін түсінеді. Бұл командалар ішіндегі белсенділікті арттыруға және командаларға өзара әрекеттесуден туындаған кез келген үйкелісті (friction) бірқатар мәселелерді анықтауға арналған сигнал ретінде пайдалануға мүмкіндік береді. Біз осы сигналдардың кейбірін келесі бөлімде қарастырамыз.

5-тараудағы кеңестерді пайдалана отырып, ұйымның құрылымын белгілі бір уақыттағы төрт негізгі командалық топологияға сәйкестендіру өте оңай, бірақ команда құрылымын дамыту уақыты келгенін анықтау үшін қажетті ұйымдық сана-сезімге ие болу жиі қиынға соғады. Ұйым ішіндегі командалық топологияларды қайта жобалауға түрткі болатын кейбір жағдайлар бар. Оларды тануды үйрену ұйымға өз қажеттіліктеріне қарай бейімделуді және дамуды жалғастыруға көмектеседі.

Сәтті бағдарламалық өнімдер көбірек функциялар қосылып, көбірек тұтынушылар өнімді қабылдаған сайын үлкейе береді. Бастапқыда өнім командасындағы әрбір адамның код базасы туралы кең түсінігі болуы мүмкін болса да, уақыт өте келе бұл қиындай түседі.

Бұл команда ішінде жүйенің әртүрлі компоненттеріне қатысты (көбінесе айтылмаған) мамандануға әкелуі мүмкін. Белгілі бір компонентке немесе жұмыс процесіне өзгерістерді қажет ететін сұраныстар үнемі сол команда мүшесіне (мүшелеріне) жүктеледі, өйткені олар басқа команда мүшелеріне қарағанда жылдамырақ жеткізе алады.

Бұл маманданудың күшею циклі — жергілікті оңтайландыру («осы сұранысты тез орындау»), ол жоспарлау «қазір істеуіміз керек ең басым жұмыс қандай» емес, «кім нені біледі» деген ұстаныммен жасалғанда, команданың жалпы жұмыс ағынына теріс әсер етуі мүмкін. Маманданудың бұл деңгейі жеткізудегі кедергілерді тудырады («The Phoenix Project» кітабында баяндалғандай және «The DevOps Handbook» кітабында түсіндірілгендей). Тұрақты қайталанатын аспект жеке мотивацияға да теріс әсер етуі мүмкін.

Ұзақ өмір сүретін, жоғары өнімді өнім командасы бірлесіп тиімдірек жұмыс істеу жолдарын тауып, жеткізудегі кедергілерді жойған сайын өздерінің жеткізу қарқынын тұрақты түрде жақсарта алуы керек. Дегенмен, бұл командалардың өркендеуінің алғышарты — оларға өнімнің бүкіл өмірлік цикліне автономия беру. Бұл басқа команданың жаңа инфрақұрылым құруын күту сияқты сыртқы командаларға қатаң тәуелділіктің болмауын білдіреді. Ішкі платформа арқылы жаңа инфрақұрылымды өзіне-өзі қызмет көрсету (self-serve) мүмкіндігі — жұмсақ тәуелділік (егер өзіне-өзі қызмет көрсетуді платформалық команда қамтамасыз етсе).

Автономияның бұл деңгейіне көптеген ұйымдарда қол жеткізу қиын. Шын мәнінде, керісінше жағдайды жиі көруге болады: командалар арасында жаңа қатаң тәуелділіктерді енгізу арқылы автономияны азайту. Бұл барлық өнімдерді тестілеуді орталықтандыру және теориялық тұрғыдан тестілеушілерге жұмысты тиімдірек бөлу үшін сапаны қамтамасыз ету (QA) командасын құру арқылы тестілеу аясын арттыру әрекеті болуы мүмкін. Мұндай мақсат мақтауға тұрарлық болса да, бұл командалық дизайн «функционалдық силосты» (QA) тудырады, бұдан былай бағдарламалық жасақтаманы жеткізетін барлық командалар QA командасының олардың жаңартуларын тексеруге бос болуын күтуі керек болады.

DevOps-тың пайда болуы 2010 жылдары әзірлеу (development) және пайдалану (operations) командалары арасындағы бөліністі көрсетті, бірақ бұл — өнімді жеткізудің өмірлік цикліне араласатын барлық басқа силостар үшін де бірдей мәселе.

Жеткізу қарқыны жинақталған техникалық қарыздың кесірінен де баяулауы мүмкін екенін ескеріңіз. Бұл сценарийде код базасының күрделілігі сондай деңгейге жетуі мүмкін, тіпті шағын өзгерістер де қымбатқа түседі және жиі регрессияларды (жаңа қателерді) тудырады. Бұл жеткізілімдерді әзірлеу және тұрақтандыру код базасы алғаш жасалған кезге қарағанда әлдеқайда ұзақ уақыт алатынын білдіреді.

Қаржы, сақтандыру, заң және мемлекеттік сектор сияқты кейбір жоғары реттелетін салаларда бірнеше түрлі жоғары деңгейлі бизнес-қызметтер бөлек негізгі қызметтердің, API-лердің немесе ішкі жүйелердің үлкен жиынтығына сүйенуі мүмкін. Мысалы, сақтандыру компаниясына жаңартылған сақтандыру бағасын ұсыну үшін зауыт машиналарына ұзақ мерзімді физикалық тексерулер жүргізу қажет болуы мүмкін; немесе банкке жаңа банк шотын ашпас бұрын мекенжайды растайтын құжаттардың жеткізілуін күту қажет болуы мүмкін. Бұл жоғары деңгейлі бизнес-қызметтер негізделетін төменгі деңгейлі жүйелер арнайы төлем механизмдерін, деректерді тазалауды, жеке басын куәландыруды, заңды тексерулерді және т. б. қамтамасыз етуі мүмкін, олардың әрқайсысы қызметті дамыту және қолдау үшін жұмыс істейтін бірнеше команданы қажет етеді. Бизнес-процестерді басқару (BPM) — бәлкім, машиналық оқытумен (ML) толықтырылған — бұл жағдайларда кейбір жұмыстарды автоматтандыруға көмектеседі; бірақ белсенді, саналы командалар әлі де BPM жұмыс процесінің сценарийлерін конфигурациялауы және тексеруі керек. Бұл қызметтер мен ішкі жүйелердің кейбірі ішкі ресурстармен құрылуы мүмкін, бірақ басқаларын сыртқы жеткізушілер ұсынуы мүмкін.

Пайдалы бизнес құндылығын жеткізу үшін жоғары деңгейлі ағындар көптеген төменгі деңгейлі қызметтермен интеграциялануы керек (бұл — кәсіпорын қызметтерін басқару саласы). Егер ағындар әрбір негізгі қызметпен бөлек интеграциялануы керек болса, ағынның тиімділігін бағалау және адам шешімін қажет ететін ұзақ уақытқа созылатын процестердегі қателерді анықтау қиын болуы мүмкін. Мысалы, негізгі қызметтер бақылау механизмдерін көрсетпеуі мүмкін немесе транзакцияларды анықтаудың әрқайсысында бөлек жолы болуы мүмкін.

Төменгі деңгейлі қызметтер мен API-лерді «платформаландыру» үшін «платформалық қаптаманы» пайдалану арқылы жоғары деңгейлі бизнес-қызметтердегі (ағындардағы) ағынның болжамдылығын арттырыңыз. Бұл ағындарға барлық тәуелділіктерді біртұтас жол картасы мен бірізді DevEx бар бірыңғай платформа ретінде қарастыруға мүмкіндік береді. Ағындарда платформаның ағынын және ресурстарды пайдалануын бақылау үшін бай телеметрия бар.

Әрбір жоғары деңгейлі бизнес-қызмет төңірегіндегі бай телеметрияның бөлігі ретінде ағынға бағытталған команда мыналарды құрады және иеленеді: (1) Платформадағы әртүрлі негізгі қызметтер мен API-лерді шақырған кезде бірізді логтау уақыт белгілерін, корреляциялық ID-лердегі бірізділікті, сұраныс/жауапты сәйкестендіруді және логтауды және т. б. қамтамасыз ететін жеңіл сандық-қызметтік «қаптама»; (2) Барлық «ағын жағындағы» үйлестіруді қадағалауға және бақылауға мүмкіндік беретін сандық-қызметтік қаптамаға арналған логтау, метрикалар және бақылау панельдері (тіпті «платформа жағындағы» аспектілердің көрінуі бастапқыда өзгермелі болса да).

Жоғары деңгейлі бизнес-қызметтерде тұрақты және болжамды ағынды қолдау үшін платформалық қаптама платформалық қызметтердің айналасындағы DevEx-ті жақсартуы тиіс — логтау, метрикалар, бақылау панельдері, корреляциялық ID-лер және т. б. бойынша бірізділік пен стандарттар — осылайша ағынға бағытталған командалар құрған сандық-қызметтік қаптама ішінен үлкенірек бақылау мүмкіндігі болады.

Тарихи тұрғыдан алғанда, көптеген ұйымдар «әзірлеуді» (develop) және «пайдалануды» (operate) бағдарламалық жасақтаманы жеткізудің екі бөлек кезеңі ретінде қарастырды, олардың арасында өзара әрекеттесу өте аз болды және пайдаланудан әзірлеуге кері байланыс мүлдем болмады десе де болады. Қазіргі заманғы бағдарламалық жасақтаманы жеткізу мүлдем басқа тәсілді қолдануы керек: бағдарламалық жасақтаманы пайдалану әзірлеу әрекеттері үшін бағалы сигналдар ретінде әрекет етіп, соларды қамтамасыз етуі керек. Пайдалануды әзірлеуге арналған бай сенсорлық кіріс ретінде қарастыру арқылы ұйымға өзін-өзі басқаруға мүмкіндік беретін кибернетикалық кері байланыс жүйесі орнатылады.

Бағдарламалық жүйелердің әртүрлі бөліктеріне тиімді иелік ететін және нақты анықталған коммуникациялық үлгілерді пайдалана отырып әрекеттесетін тұрақты командалардың көмегімен ұйымдар қуатты стратегиялық мүмкіндікті іске қоса алады: ұйымдық сезіну (sensing).

«Жаңа дүниелер» мен BAU үшін бөлек командалардың болуы білім алуға, жақсартуға және өзін-өзі басқару қабілетіне кедергі келтіреді. Бұл — кибернетикалық емес тәсіл.

Ескі жүйелерді қолдаудың кибернетикалық тәсілінде бір ағынға бағытталған команда (немесе командалар жұбы) жаңа сервисті де, ескі жүйелерді де әзірлеп, іске қосады, бұл командаға ескі жүйеге жаңа телеметрияны орнатуға және екі жүйеден де келетін сезіну дәлдігін арттыруға мүмкіндік береді.

Төрт негізгі команда топологиясы:

Ұйымдар команда құрылымын тек белгілі бір уақыт сәтінде ғана қарастырып қоймай, технологиялық және ұйымдық жетілу деңгейіне қарай команда құрылымдары мен коммуникация жолдарын үнемі дамытып отыруы қажет. Техникалық және өнімді зерттеу (discovery) кезеңдері әдетте табысқа жету үшін жоғары деңгейдегі ынтымақтастықты (командалар арасындағы шекаралардың жойылуымен) талап етеді. Бірақ зерттеу аяқталғанда (технологиялар мен өнім қалыптасқан соң) сол құрылымдарды сақтап қалу күш-жігердің босқа жұмсалуына және түсініспеушіліктерге әкелуі мүмкін. Атап айтқанда, ұйымдар командалардан жаңа үлгілер мен орындау модельдерін табу үшін бірлесіп жұмыс істеуін, содан кейін бұларды платформаға және қолдаушы құралдарға енгізуін күтуі керек.

Бағдарламалық жүйелерге арналған Team Topologies тәсілі бүкіл әлемдегі көптеген ұйымдар үшін алға жасалған үлкен қадам болып табылады. Ол командалардың әртүрлі комбинациялары мен өзара әрекеттесуінің қалай және неліктен жұмыс істейтінін түсінуге көмектеседі, сондай-ақ нақты жағдайларда қолданылатын практикалық кеңестер мен үлгілерді ұсынады.

Дегенмен, Team Topologies-тің өзі ғана бағдарламалық қамтамасыз етуді жеткізу және пайдалану бойынша тиімді ұйым құра алмайды. Осы кітапта ұсынылған құрылымдар мен динамикадан басқа, табысқа жетудің маңызды қосымша компоненттеріне мыналар жатады:

IT Revolution Press командасы, әсіресе Анна Ноак, Лин Браун және басқа да редакторлар мен дизайнерлер таңқаларлық жұмыс атқарды — біз олардың кеңестерін, қолдауын және жұғысты құлшынысын жоғары бағалаймыз. Бізді 2017 жылы Лондонда өткен DevOps Enterprise Summit-те сөз сөйлеуге шақырып, Team Topologies идеяларының құндылығын түсінуге көмектескені үшін Джин Кимге ризашылығымызды білдіреміз.

Соңында, бізді командалар мен бағдарламалық жасақтама арасындағы қызықты байланысқа қызығушылық танытуға шабыттандырған және осы кітаптың шындыққа айналуына көмектескен идеялардың, баяндамалардың және жазбалардың авторларына: Аллан Келлиге, Энди Лонгшоуға, Чарльз Т. Бетцке, Донелла Медоузға, Джеймс Льюиске, Джин Кимге, Мел Конвейге, Мирко Херингке, Рэйчел Лейкокқа, Рут Маланға және Рэнди Шоупқа алғыс айтамыз.