🥇Infrastruktura si Kod: si të përballojmë problemet me ndihmën e XP

Përshëndetje, Habr! Më parë kisha ankuar për jetën në paradigmën e Infrastrukturës si Kod dhe nuk ofrova asnjë zgjidhje për situatën e krijuar. Sot u ktheva për të treguar se cilat qasje dhe praktika mund të ndihmojnë për t'u çliruar nga gremina e ngashmërimit dhe për të drejtuar situatën në një drejtim të duhur.

Në artikullin e mëparshëm «Infrastruktura si Kod: një takim i parë» ndaja përshtypjet e mia nga ky fushë, përpiqesha të reflektoja mbi situatën aktuale në këtë fushë dhe madje sugjeroja se praktikat standarde, të njohura për të gjithë zhvilluesit, mund të ndihmojnë. Mund të dukej se kishte shumë ankesa për jetën, por nuk kishte propozime për daljen nga situata e krijuar.

Kush jemi, ku jemi dhe cilat janë problemet tona

Tani jemi në Ekipin e Sre Onboarding, i cili përbëhet nga gjashtë programues dhe tre inxhinierë të infrastrukturës. Të gjithë ne përpiqemi të shkruajmë Infrastrukturë si Kod (IaC). E bëjmë këtë sepse në parim dimë të shkruajmë kod dhe në histori jemi zhvillues të nivelit 'mbi mesatar'.

Kemi një grup përfitimesh: një sfond të caktuar, njohuri të praktikave, aftësi në programim dhe dëshirë për të mësuar diçka të re.
Dhe ka një pjesë të varur, e njohur gjithashtu si minus: mungesa e njohurive në materialin e infrastrukturës.

Grupi i teknologjive që përdorim në IaC tonë.

Terraform për krijimin e burimeve.
Packer për ndërtimin e imazheve. Këto janë imazhe të Windows dhe CentOS 7.
Jsonnet, për të bërë një ndërtim të fuqishëm në drone.io, si dhe për të gjeneruar packer json dhe modulet tona të terraform.
Azure.
Ansible gjatë përgatitjes së imazheve.
Python për shërbimet ndihmëse, si dhe për skriptet e provizionimit.
Dhe gjithçka kjo brenda VSCode me pluginët e ndara midis anëtarëve të ekipit.

Përfundimi nga artikulli im të kaluar ishte ky: përpiqesha të jepja (para së gjithash për veten time) optimizëm, doja të thosha se do të përpiqeshim për të provuar qasjet dhe praktikat që njohim për të luftuar vështirësitë dhe sfidat që ekzistojnë në këtë fushë.

Tani po luftojmë me këto probleme të IaC:

Përkryerja e mjeteve, burimeve për zhvillimin e kodit.
Zhvillimi i ngadalshëm. Infrastruktura është një pjesë e botës reale, dhe ajo mund të mos jetë e shpejtë.
Mungesa e qasjeve dhe praktikave.
Jemi të rinj dhe nuk dimë shumë.

Programimi ekstrem (XP) vjen për ndihmë.

Të gjithë zhvilluesit e njohin mirë programimin ekstrem (XP) dhe praktikat që e mbështesin atë. Shumica prej nesh kemi punuar në këtë qasje, dhe ajo ka qenë e suksesshme. Pse të mos e shfrytëzojmë parimet dhe praktikat e vendosura aty për të përballuar vështirësitë e infrastrukturës? Ne vendosëm të aplikojmë këtë qasje dhe të shohim se çfarë rezultati do të sjellë.

Kontrolli i aplikueshmërisë së qasjes XP në fushën tuajPo paraqes përshkrimin e mjedisit, për të cilin XP është i përshtatshëm, dhe si lidhet kjo me ne:

1. Kërkesat e softuerit që ndryshojnë dinamikisht. Na ishte e qartë cila ishte qëllimi përfundimtar. Por në detaje është e mundur të ndryshohet. Ne vetë vendosim se ku duam të orientohemi, kështu që kërkesat ndryshojnë periodikisht (kryesisht nga ne vetë). Nëse merrni ekipin SRE, i cili bën automatizimin vetë dhe gjithashtu e kufizon vetë kërkesat dhe përmbajtjen e punës, atëherë ky pikë është shumë i përshtatshëm.

2. Rreziqet e shkaktuara nga projektet me kohë të fiksuar duke përdorur teknologji të reja. Ka mundësi që të hasim rreziqe kur përdorim gjëra që nuk i njohim. Kjo është 100% situata jonë. I gjithë projekti ynë përfshin përdorimin e teknologjive me të cilat nuk jemi njohur plotësisht. Në fakt, kjo është një problem i vazhdueshëm, pasi në fushën e infrastrukturës vazhdimisht shfaqen shumë teknologji të reja.

3,4. Ekip i vogël, i vendosur së bashku për zhvillim të zgjeruar. Teknologjia që po përdorni lejon teste automatike njësi dhe funksionale. Këto dy pika nuk janë krejtësisht të përshtatshme për ne. Së pari, ne nuk jemi një ekip i vendosur së bashku, së dyti, jemi nëntë persona, që mund të konsiderohet si një ekip i madh. Megjithatë, sipas disa definicionesh, një " ekip i madh" është ai që përfshin 14+ persona.

Le të shqyrtojmë disa praktika nga XP dhe si ato ndikojnë në shpejtësinë dhe cilësinë e përgjigjeve.

Parimi i ciklit të përgjigjes në XP

Në kuptimin tim, përgjigjja është një përgjigje ndaj pyetjes, a e bëj saktë, a po shkojmë në drejtimin e duhur? Në XP ka një grafik të mrekullueshëm për këtë: cikli i përgjigjes me kohë. Interesant është se sa më poshtë të jemi, aq më shpejt kemi mundësi të marrim informacione për të përgjigjur pyetjeve të nevojshme.

Kjo është një temë mjaft interesante për t'u diskutuar, për sa i përket industrisë së TI-së, ku është e mundur të fitosh një OS shpejt. Imagjinoni sesi është shumë e vështirë të punoni në një projekt për gjashtë muaj dhe pastaj të kuptoni se në fillim është bërë një gabim. Kjo ndodh ndonjëherë në projektim dhe në ndërtimin e sistemeve të komplikuara.

Në rastin tonë, IaC na ndihmon me feedback-un. Menjëherë bëj një rregullim të vogël në skemën e mësipërme: plani i lëshimit nuk ndodh çdo muaj, por disa herë në ditë. Në këtë cikël, OS është e lidhur me disa praktika që do t'i shqyrtojmë më në detaje.

Është e rëndësishme: feedback-u mund të bëhet zgjidhja për të gjitha problemet e shpallura më sipër. Në bashkëpunim me praktikat XP, ai mund ta nxjerrë nga humbja e shpresës.

Si të nxjerrësh veten nga humbja e shpresës: tri praktika

Testet

Testet përmenden dy herë gjatë ciklit të feedback-ut XP. Kjo nuk është rastësi. Ato janë jashtëzakonisht të rëndësishme për të gjithë teknikën e programimit ekstrem.

Supozimi është se ti ke Testet e Njësisë dhe Testet e Pranimit. Njëra të jep feedback për disa minuta, tjetra për disa ditë, ndaj ato shkruhen më gjatë, por ekzekutohen më rrallë.

Ekziston një piramidë klasike testimi që tregon se duhet të ketë më shumë testime të caktuara.

Si është kjo skemë e aplikueshme për ne në projektin IaC? Në të vërtetë… askund.

Testet unit, pavarësisht se sa shumë duhet të jenë, nuk mund të jenë shumë. Ose ato testojnë diçka në mënyrë shumë indirekte. Në fakt, mund të themi se ne nuk i shkruajmë fare. Por ja disa aplikacione për këto teste që megjithatë kemi arritur t'i bëjmë:
1. Testimi i kodit në jsonnet. Kjo është, për shembull, pipeline ynë i ndërtimit në drone, i cili është mjaft i komplikuar. Kodi në jsonnet mbulohet mirë me teste.
  Ne përdorim këtë Unit testing framework for Jsonnet.
2. Testet për skriptet që ekzekutohen në fillim të burimit. Skriptet në Python, dhe prandaj mund të shkruhen teste për to.
Potencialisht mund të bëhet verifikimi i konfigurimit në teste, por ne nuk e bëjmë këtë. Ka gjithashtu mundësinë e konfigurimit të verifikimit të rregullave të konfigurimit të burimeve përmes tflint. Megjithatë, thjesht për Terraform aty ka kontrollime shumë të bazuara, por shumë skenarë verifikimi janë shkruar për AWS. Dhe ne jemi në Azure, kështu që përsëri nuk përshtatet.
Testet e integrimit komponent: kjo varet nga mënyra se si i klasifikoni dhe ku i vendosni. Por, në parim, ato funksionojnë.
Këto janë testet e integrimit.

Ky është një shembull gjatë ndërtimit të imazheve në Drone CI. Për t'u arritur atyre, duhen 30 minuta për të pritur që imazhi Packer të ndërtohet, pastaj edhe 15 minuta për të kaluar. Por ato ekzistojnë!
Algoritmi i kontrollit të imazheve
1. Së pari, Packer duhet të përgatisë imazhin plotësisht.
2. Pranë testit, ka Terraform me gjendje lokale, me të cilin ne e zhvillojmë këtë imazh.
3. Gjatë zhvillimit përdoret një modul i vogël pranë, për ta bërë më të thjeshtë punën me imazhin.
4. Kur një VM është zhvilluar nga imazhi, mund të filloni kontrollimet. Në përgjithësi, kontrollimet kryhen në makinë. Kontrollohet se si kanë punuar skriptet gjatë nisjes, si funksionojnë demonët. Për këtë, ne hyjmë në makinën e sapo ngritur përmes SSH ose WinRM dhe kontrollojmë gjendjen e konfigurimit apo a janë ngritur shërbimet.
Një situatë e ngjashme është edhe me testet e integrimit në modulet për Terraform. Këtu është një tabelë e shkurtër që shpjegon veçoritë e këtyre testeve.

Përgjigjia në pipeline është rreth 40 minuta. Gjithçka ndodh shumë ngadalë. Mund të përdoret për regresion, por për zhvillim të ri është krejtësisht e pamundur. Nëse përgatiteni shumë, duke përgatitur running dhe skriptet, atëherë mund ta shkurtoni deri në 10 minuta. Por kjo akoma nuk është një testim unitar, i cili bëhet për 5 sekonda 100 herë.

Mungesa e testeve unitare gjatë ndërtimit të imazheve ose moduleve të Terraform nxit të menjani punën në shërbime të veçanta, të cilat mund t'i thërrasësh thjesht përmes REST, ose me skripte Python.

Për shembull, na duhej që kur makina virtuale të nisë, ajo të regjistrohet në shërbimin ScaleFT, dhe kur virtualja të shkatërrohet, të fshihet vetë.

Duke qenë se ScaleFT është një shërbim në vetvete, ne jemi të detyruar të punojmë me të përmes API-së. Atje është shkruar një mbështjellës, të cilin mund ta thërrasësh dhe të thuash: "Shko dhe fshi këtë, atë". Ai ruan të gjitha konfigurimet dhe akseset e nevojshme.

Tani mund të shkruajmë teste normale për këtë, pasi nuk ndryshon nga softi i zakonshëm: moku një API, e thërris, dhe shohim çfarë ndodh.

Përfundimet nga testet: Testimi i njësive, i cili duhet të jepet nga OS për minuta, nuk e bën atë. Ndërsa llojet më të larta të testimeve në piramidë japin efekt, ato zgjidhin vetëm disa probleme.

Programimi në çift

Testet janë, sigurisht, të mira. Mund të shkruhen shumë, ato mund të jenë të llojeve të ndryshme. Ato do të funksionojnë në nivelet e tyre dhe do të na japin feedback. Por problemi me testet e dobëta të njësive, të cilat japin sistemin më të shpejtë operativ, mbetet. Megjithatë, vazhdon të dëshirohet një sistem operativ i shpejtë, me të cilin është lehtë dhe këndshëm të punosh. Pa përmendur cilësinë e zgjidhjes së marrë. Fatmirësisht, ekzistojnë teknika që mund të ofrojnë feedback edhe më të shpejtë se testet modulare. Kjo është programimi në çift.

Kur shkruajmë kod, dëshirojmë të marrim feedback për cilësinë e tij sa më shpejt të jetë e mundur. Po, mund të shkruajmë gjithçka në një degë funksionimi (në mënyrë që të mos prishim asgjë për askënd), të bëjmë një kërkesë për bashkim në GitHub, të emërojmë dikë, opinioni i të cilit ka rëndësi, dhe të presim përgjigje.

Por benë mund të presim gjatë. Njerëzit janë të zënë, dhe përgjigja, madje edhe nëse vjen, mund të mos jetë e niveli më i lartë. Supozoni se përgjigja ka ardhur menjëherë, rishikuesi ka kuptuar menjëherë të gjithë qëllimin, por përgjigja akoma vjen me vonesë, pas faktit. Por dëshirojmë ta kemi më herët. Kjo është ajo që programimi në çift synon - që të ndodhë menjëherë, në momentin e shkruajtjes.

Më poshtë sjell stilët e programimit në çift dhe aplikueshmërinë e tyre në punën me IaC:

1. Klasik, Ekspert + ekspert, ndërrimi sipas një timeri. Dy role – driver dhe navigator. Dy njerëz. Ata punojnë mbi një kod dhe ndërronin rolet pas një periudhe të caktuar të parapërcaktuar.

Le të shqyrtojmë përputhshmërinë e problemeve tona me stilin:

Problemi: imperfeksionet e mjeteve, të burimeve për zhvillimin e kodit.
Ndikimi negativ: zhvillimi merr më gjatë, ne ngadalssohemi, humbasim ritmin e punës.
Si luftojmë: përdorim mjete të tjera, IDE të përbashkëta dhe mësojmë shkurtesa.
Problemi: zbatuar ngadalë.
Ndikimi negativ: rrit kohën për të krijuar një copë funksionuese të kodit. Ne mërzitemi gjatë pritjes, duar të tjera kërkojnë të merremi me diçka tjetër, derisa presim.
Si luftojmë: nuk kemi arritur ta përballojmë.
Problemi: mungesa e qasjeve dhe praktikave.
Ndikimi negativ: nuk ka njohuri se si të bësh mirë dhe si të bësh keq. E zgjat marrjen e feedback-ut.
Si luftojmë: shkëmbimi i mendimeve dhe praktikave në punën në çift zgjidh pothuajse problemin.

Problemi kryesor në aplikimin e këtij stili në IaC është ritmi i paqëndrueshëm i punës. Në zhvillimin tradicional të softuerit ke një lëvizje shumë të rregullt. Mund të shkosh për pesë minuta dhe të shkruash N. Të kalosh 10 minuta dhe të shkruash 2N, 15 minuta - 3N. Këtu mund të kalosh pesë minuta dhe të shkruash N, dhe pastaj të kalosh 30 minuta e të shkruash një pjesë të dhjetë të N. Këtu nuk di asgjë, ke një bllokim. Hulumtimi merr kohë dhe të shpërqendron nga programimi i drejtpërdrejtë.

Përfundimi: në formën e pastër nuk na përshtatet.

2. Ping-pong. Ky qasje parashikon se një pjesëmarrës shkruan testin, ndërsa tjetri bën realizimin për të. Duke marrë parasysh që me testet Unike është e komplikuar, dhe duhet të shkruhet një test integrimi që zgjat, gjithë lehtësia e ping-pongut zhduket.

Mund të them se kemi provuar ndarjen e detyrave në projektimin e skenarit të testit dhe implementimin e kodit për të. Një pjesëmarrës krijoi skenarin, dhe në këtë pjesë të punës ai ishte përgjegjës, ai kishte fjalën e fundit. Një tjetër ishte përgjegjës për implementimin. Kjo funksionoi mirë. Cilësia e skenarit rritej me këtë qasje.

Përfundimi: fatkeqësisht, ritmi i punës nuk lejon përdorimin e ping-pong, si një praktikë programimi të çiftuar në IaC.

3. Stili i fortë. Praktika komplekse.Ideja është që një pjesëmarrës të bëhet një udhëheqës direktiv, ndërsa tjetri merr rolin e shoferit ekzekutiv. Në këtë rast, e drejta për vendime i takon ekskluzivisht udhëheqësit. Shoferi vetëm shkruan dhe me fjalë mund të ndikojë në atë që po ndodh. Roli nuk ndryshon për një kohë të gjatë.

Përshtatet mirë për mësimin, por kërkon aftësi të forta sociale. Këtu u përballëm. Teknikat ishin të komplikuara. Dhe problemi nuk është as në infrastrukturë.

Përfundimi: potencialisht mund të përdoret, ne nuk po e lëmë këtë përpjekje.

4. Mobbing, swarming dhe të gjitha stilet e njohura, por që nuk janë përmendur këtu. nuk shqyrtojmë, pasi nuk i kemi provuar dhe nuk mund të flasim për të në kontekstin e punës tonë.

Përmbledhja e përgjithshme e përdorimit të programimit në çift:

Kemi një ritëm pune të paekuilibruar, i cili shkakton pengesa.

Ndeshim mungesë të aftësive të mira për të komunikuar. Dhe fusha e temave nuk ndihmon për të kapërcyer këto mangësi.

Testime të gjata, probleme me mjetet e punës e bëjnë zhvillimin në çift të ngadaltë.

5. Megjithatë, kishim edhe suksese. Krijuam metodën tonë "Konvergjenca - Divergjenca". Do ta përshkruaj shkurtimisht se si funksionon.

Ne kemi partnerë të rregullt për disa ditë (më pak se një javë). Bëjmë një detyrë së bashku. Për një kohë, jemi së bashku: njëri shkruan, tjetri ulur dhe vëzhgon, si një ekip mbështetje. Pastaj shkëputemi për një kohë, secili bën disa gjëra të pavarura, pastaj e rikthejmë veten, sinkronizohemi shumë shpejt, bëjmë diçka së bashku dhe përsëri shkëputemi.

Planifikimi dhe komunikimi

Blloku i fundit i praktikave, përmes të cilave zgjidhen problemet e OS, është organizimi i punës me detyrat vetë. Ky informacion gjithashtu përfshin shkëmbimin e përvojës që është jashtë punës në çift. Le të shqyrtojmë tre praktika:

1. Detyrat përmes pemës së qëllimeve. Menaxhimi i përgjithshëm i projektit e kemi organizuar përmes një strukture, e cila shkon pafundësisht në të ardhmen. Teknikisht, menaxhimi bëhet në Miro. Ka një detyrë - ajo është një objektiv përfundimtar. Nga ajo burojnë ose objektiva më të vogla, ose grupe detyrash. Prej tyre dalin detyrat vetë. Të gjitha detyrat krijohen dhe menaxhohen në këtë table.

Kjo skemë gjithashtu ofron një feedback që ndodh një herë në ditë, kur ne sinkronizohemi në takime. Prania e një plani të përbashkët përpara të gjithëve, duke qenë kështu e strukturuar dhe plotësisht e hapur, i lejon secilit të jetë në dijeni të asaj që po ndodh dhe se sa larg kemi avancuar në progres.

Avantazhet e vizionit vizual të detyrave:

Kausaliteti. Çdo detyrë çon në një objektiv global. Detyrat grupohen sipas objektivave më të vogla. Domeni i infrastrukturës vetë është mjaft teknik. Nuk është gjithmonë e qartë se çfarë ndikimi të drejtpërdrejtë në biznes ka, për shembull, përgatitja e një manuali migrimi në një nginx tjetër. Prania e një kartice qëllimi përkrah e bën atë më të kuptueshëm.

Kausaliteti është një veçori e rëndësishme e detyrave. Ai përgjigjet drejtpërdrejt pyetjes: "Po bëj atë që duhet?"
Paralelizmi. Jemi nëntë veta dhe nuk është fizikisht e mundur që të gjithë të angazhohemi në një detyrë të vetme. Nuk është gjithmonë e mjaftueshme të kemi detyra nga një fushë. Jemi të detyruar të ndajmë punën në grupe të vogla. Gjatë kësaj kohe, grupet punojnë në detyrat e tyre dhe mund të forcohen nga ndonjë person tjetër. Disa herë, njerëz nga këto grupe e lëshojnë punën. Disa shkojnë në pushim, disa bëjnë një prezantim për konferencën DevOps conf, disa shkruajnë një artikull për Habr. Të dini cilat janë objektivat dhe detyrat që mund të bëhen paralelisht bëhet shumë e rëndësishme.

2. Ndërrimi i udhëheqësve të takimeve të mëngjesit. Në stand-up na doli një problem – shumë njerëz punojnë në detyra paralelisht. N sometimes detyrat janë të lidhura dobët dhe nuk kemi një kuptim të qartë se kush po bën çfarë. Mendimi i një anëtari të ekipit është shumë i rëndësishëm. Kjo është informacion shtesë që mund të ndryshojë rrjedhën e zgjidhjes së detyrës. Sigurisht, zakonisht ke dikë pranë, por konsultimi dhe këshillat gjithmonë janë të dobishme.

Përmirësimi i kësaj situate përfshin përdorimin e teknikës "Ndërrimi i udhëheqësit të takimit". Tani ata rotullohen sipas një liste të caktuar, dhe kjo ka efektin e vet. Kur të vijë radha jote, je i detyruar të thellohesh dhe të kuptosh se çfarë po ndodh, për të realizuar mirë takimin e skramit.

3. Demonstrimi i brendshëm. Ndihma në zgjidhjen e problemeve nga programimi në çift, vizualizimi në pemën e detyrave dhe ndihma në takimet e skramit në mëngjes – është mirë, por jo ideale. Në çift, je i kufizuar vetëm me njohuritë tuaja. Pema e detyrave ndihmon për të kuptuar globalisht se kush bën çfarë. Ndërsa udhëheqësi dhe kolegët në takimin e mëngjesit nuk do të thellohen në problemet e tua. Sigurisht, ata mund të humbasin diçka.

Zgjidhja u gjet në demonstrimin e punimeve të kryera njëri për tjetrin dhe diskutimin e tyre pas kësaj. Ne mblidhemi një herë në javë për një orë dhe tregojmë detajet e zgjidhjeve për detyrat që kemi bërë gjatë javës së kaluar.

Gjatë demonstrimit duhet të sqarosh detajet e detyrës dhe patjetër të demonstrosh funksionimin e saj.

Raporti mund të ndiqet sipas një liste kontrolli.1. Futni në kontekst. Nga ka ardhur detyra, përse ishte e nevojshme?

2. Si si zgjidhte problemi deri më tani? Për shembull, kërkohej klikim masiv ose ishte e pamundur të bëhej diçka krejtësisht.

3. Si e përmirësojmë këtë. Për shembull: «Shikoni, tani ka një skript, ja ridhmi».

4. Tregoni si funksionon. Preferohet të realizoni një skenar të caktuar të përdoruesit. Dua X, bëj Y, shoh Z (ose Y). Për shembull, deploji NGINX, kontrolloj url, marr 200 OK. Nëse veprimi zgjat, përgatitni më parë për ta treguar më pas. Preferohet që një orë para demonstrimit të mos prishet në mënyrë të veçantë, nëse është e brishtë.

5. Shpjegoni se sa mirë është zgjidhur problemi, cilat vështirësi kanë mbetur, çfarë nuk është përfunduar, cilat përmirësime janë të mundshme në të ardhmen. Për shembull, tani cli, pastaj do të ketë automatizim të plotë në CI.

Preferohet që çdo folës të përfundojë brenda 5-10 minutash. Nëse paraqitja juaj është natyrshëm e rëndësishme dhe do të zgjasë më shumë, miratoni këtë paraprakisht në kanal.

Pas pjesës në jetër, është e nevojshme të diskutohet në thirrje. Këtu është ku shfaqet përmbledhja e nevojshme për detyrat tona.

Në përfundim, bëhet një anketë për të identifikuar dobishmërinë e asaj që po ndodh. Kjo është një përgjigje e ndjerë për thelbin e paraqitjes dhe rëndësinë e detyrës.

Përfundimet e gjata dhe çfarë do të ndodhë më pas

Mund të duket se tonin e artikullit është disi pesimist. Kjo nuk është e vërtetë. Dy nivelet e poshtme të marrjes së feedback-ut, pikërisht testet dhe programimi në çift, funksionojnë. Jo aq siç duhet në zhvillimin tradicional, por ka një efekt pozitiv nga kjo.

Testet, në formën e tyre aktuale, ofrojnë vetëm mbulimin e pjesshëm të kodit. Shumë funksione konfiguruese mbesin të patestuar. Ndikimi i tyre në punën e menjëhershme gjatë kodimit është i ulët. Megjithatë, ka një efekt nga testet integruese, dhe pikërisht ato e lejojnë të bëhen refaktorizime pa frikë. Kjo është një arritje e madhe. Po ashtu, me transferimin e fokusit në zhvillimin në gjuhët e nivelit të lartë (ne përdorim python, go), problemi zhduket. Ndërsa për 'ngjitësin', ka shumë kontrollime dhe nuk është e nevojshme, mjafton integrimi i përgjithshëm.

Punimi në çift varet më shumë nga njerëzit e caktuar. Ka faktorë të detyrave dhe aftësi tona të buta. Disa e ndjekin shumë mirë, të tjerë më keq. Pavaresisht kësaj, përfitimi është i sigurt. E qartë është se, edhe në rastin e mosrespektimit të rregullave të punës në çift, vetë fakti i përfundimit të detyrave së bashku ndikon pozitivisht në cilësinë e rezultateve. Personalist, më është më lehtë dhe më këndshëm të punoj në çift.

Mënyrat më të avancuara për të ndikuar në OS – planifikimi dhe puna me detyrat me siguri japin efekte: shkëmbimi cilësor i njohurive dhe përmirësimi i cilësisë së zhvillimit.