🥇Infrastructure as Code: si të kapërcejmë problemet me ndihmën e XP

Përshëndetje, Habr! Më parë ankoja mbi jetën në paradigmen e Infrastrukturës si Kod dhe nuk ofroja asnjë zgjidhje për situatën e krijuar. Sot kam rikthyer për t'ju treguar se cilat qasje dhe praktika mund t'i bëjnë të largoheni nga humbja e shpresës dhe të rregulloni situatën drejt rrugës së duhur.

Në artikullin e mëparshëm «Infrastruktura si kod: njohje e parë» ndaja përshtypjet e mia për këtë fushë, përpiqesha të reflektoja mbi situatën aktuale në këtë fushë dhe madje të supozova se praktikat e njohura, të njohura për të gjithë zhvilluesit, mund të ndihmojnë. Mund të ketë dukur se kishte shumë ankesa për jetën, por nuk kishte propozime për zgjidhjen e situatës.

Kush jemi, ku jemi dhe cilat janë problemet tona

Tani jemi në Sre Onboarding Team, që përbëhet nga gjashtë programues dhe tre inxhinierë infrastrukture. Të gjithë ne përpiqemi të shkruajmë Infrastrukturë si Kod (IaC). E bëjmë këtë sepse, në thelb, dimë të shkruajmë kod dhe kemi një histori si zhvillues më të avancuar.

Kemi një grup përparësish: një përvojë të caktuar, njohuri praktike, aftësi në kodim, dëshirë për të mësuar të reja.
Dhe kemi një pjesë që tërhiqet mbrapa, që është një minus: mungesa e njohurive për materien e infrastrukturës.

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

Terraform për të krijuar burime.
Packer për ndërtimin e imazheve. Këto janë imazhe Windows dhe CentOS 7.
Jsonnet, për të krijuar një ndërtim të fuqishëm në drone.io, si dhe për gjenerimin e packer json dhe moduleve të terraformit tanë.
Azure.
Ansible gjatë përgatitjes së imazheve.
Python për shërbime ndihmëse dhe gjithashtu për skriptet e provisioning.
Dhe gjithçka kjo në VSCode me shtesa të ndara midis pjesëtarëve të ekipit.

Përfundimi nga artikulli im të mëparshëm ishte ky: kam përpiquar të transmetoj (së pari në veten time) optimizëm, doja të thosha se do të provojmë qasjet dhe praktikat që na janë të njohura për të luftuar me vështirësitë dhe sfidat që ekzistojnë në këtë fushë.

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

Përkryerja e veglave, mjeteve për zhvillimin e kodit.
Ndërtime të ngadalta. Infrastruktura është një pjesë e botës reale, dhe ajo mund të jetë e ngadaltë.
Mungesa e qasjeve dhe praktikave.
Jemi të rinj dhe nuk dimë shumë.

Programimi ekstrem (XP) nxiton për ndihmë

Të gjithë zhvilluesit e njohin mirë programimin ekstreme (XP) dhe praktikat që e mbështesin atë. Shumë prej nesh kanë punuar sipas këtij qasjeje, dhe ka qenë e suksesshme. Pse mos të shfrytëzojmë parimet dhe praktikat e vendosura aty për të përballuar vështirësitë e infrastrukturës? Ne vendosëm të zbatonim këtë qasje dhe të shohim se çfarë do të dalë prej saj.

Kontrolli i aplikueshmërisë së qasjes XP në fushën tuajJa përshkrimi i mjedisit për të cilin XP përshtatet mirë dhe si lidhet kjo me ne:

1. Kërkesat e softuerit që ndryshojnë dinamikisht. Na ishte e qartë se cila ishte qëllimi përfundimtar. Por në detaje mund të kemi variacione. Ne vetë vendosim se ku duam të shkojmë, prandaj kërkesat ndryshojnë herë pas here (kryesisht nga ne vetë). Nëse marrim ekipin SRE, i cili automatikisht bën automatizimin dhe vetë kufizon kërkesat dhe përmbajtjen e punëve, ky pikë është i përshtatshëm.

2. Rreziqet e shkaktuara nga projektet me kohë të fixuar duke përdorur teknologji të reja. Ne mund të hasim rreziqe kur përdorim gjëra që nuk i njohim. Dhe ky është rasti ynë 100%. Të gjithë projekti ynë është përdorimi i teknologjive me të cilat nuk ishim plotësisht të njohur. Për më tepër, kjo është një problem në vazhdimësi, sepse në fushën e infrastrukturës vazhdimisht po shfaqen teknologji të reja.

3,4. Ekip i vogël, i vendosur së bashku. Teknologjia që po përdorni lejon teste automatike unitare dhe funksionale. Këta dy pikë nuk na përshtaten plotësisht. Së pari, ne nuk jemi një ekip i vendosur, së dyti, kemi nëntë persona, që mund të konsiderohet një ekip i madh. Megjithatë, sipas disa definicionëve të ekipit "të madh", shumë do të ishte 14+ persona.

Le të shqyrtojmë disa praktika nga XP dhe si ato ndikojnë në shbrirjen dhe cilësinë e feedback-ut.

Parimi i ciklit të feedback-ut në XP

Në mendimin tim, feedback-u është përgjigja ndaj pyetjes, a po e bëj drejt, a po shkojmë drejt? Në XP ka një diagram hyjnor për këtë: cikli i feedback-ut në kohë. Interesant është se sa më poshtë jemi, aq më shpejt kemi mundësi të marrim OS, për të përgjigjur pyetjeve të nevojshme.

Kjo është një temë mjaft interesante për t'u diskutuar, se në industri dhe IT është e mundur të merrni shpejt OS. Imagjinoni sa e vështirë është të realizoni një projekt për gjashtë muaj dhe pastaj të kuptoni se në fillim është bërë një gabim. Kjo ndodh jo vetëm në projektim, por në çdo ndërtim të 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 është një cikël mujor, por ndodh disa herë në ditë. Në këtë cikël, OS ka lidhje me disa praktika, të cilat do i shqyrtojmë më në detaje.

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

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

Testet

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

Supozoheni se keni teste Unit dhe Acceptance. Disa ju japin feedback brenda disa minutash, të tjerat brenda disa ditësh, prandaj ato shkruhen më gjatë, por ekzekutohen më rrallë.

Ekziston një piramidë klasike testimi, e cila tregon se disa teste duhet të jenë më shumë.

Si aplikohet kjo skemë në projektin tonë IaC? Në të vërtetë… aspak.

Testet Unit, megjithëse duhet të jenë shumë, nuk mund të jenë tejet të shumta. Ose ato testojnë diçka shumë indirekt. Në të vërtetë, mund të themi se ne nuk i shkruajmë fare. Megjithatë, këtu janë disa aplikime për teste të tilla që çdo të paktën mundëm t'i realizojmë:
1. Testimi i kodit në jsonnet. Ky është, për shembull, pipeline ynë i ndërtimit në drone, i cili është mjaft kompleks. Kodi në jsonnet mbulohet mirë me teste.
  Ne përdorim këtë Unit testing framework for Jsonnet.
2. Testet për skriptet, të cilat ekzekutohen gjatë nisjes së burimeve. Skriptet në Python, dhe për rrjedhojë testet për to mund të shkruheshin.
Potencialisht është e mundur të kontrollojmë konfigurimin në teste, por ne nuk e bëjmë kështu. Ka gjithashtu mundësinë e konfigurimit të rregullave të kontrollit të burimeve përmes tflint. Megjithatë, thjesht për Terraform është kryer një kontroll shumë bazik, por ka shumë skenarë testuese të shkruar për AWS. Dhe ne jemi në Azure, kështu që kjo sërish nuk i përshtatet.
Testet e integrimit të komponentëve: këtu varet nga mënyra se si i klasifikoni dhe ku i vendosni. Por ato në parim funksionojnë.
Këtu janë të tilla integrimet e testeve.

Ky është një shembull gjatë ndërtimit të imazheve në Drone CI. Për të arritur atje, duhet të presësh 30 minuta për të pritur që imazhi Packer të grumbullohet, pastaj 15 minuta për të kaluar. Por ato ekzistojnë!
Algoritmi i kontrollit të imazheve
1. Fillimisht, Packer duhet të përgatisë plotësisht imazhin.
2. Përkrah testit ka terraform me gjendje lokale, me të cilin e zhvillojmë këtë imazh.
3. Gjatë zhvillimit përdoret një modul i vogël, i cili ndodhet afër, për ta bërë më të lehtë punën me imazhin.
4. Kur një VM është zhvilluar nga imazhi, mund të fillojmë verifikimet. Kryesisht, verifikimet bëhen në makinë. Këtu kontrollohet si kanë funksionuar skritpat gjatë startit dhe si funksionojnë demonët. Për këtë, përmes ssh ose winrm ne hyjmë në makinën e sapolindur dhe kontrollojmë gjendjen e konfigurimit ose nëse shërbimet janë aktivizuar.
Situatë e ngjashme ka me testet integruese dhe në modulët për terraform. Ja një tabelë e shkurtër që shpjegon veçoritë e këtyre testeve.

Kthimi i informacionit në pipeline është rreth 40 minuta. Gjithçka ndodh shumë ngadalë. Mund të përdoret për regresinë, por për zhvillim të ri është krejtësisht e pamundur. Nëse përgatitemi shumë, përgatitim running, skritpat, atëherë mund ta zvogëlojmë në 10 minuta. Por kjo gjithsesi nuk është test Unit, që bën 100 teste për 5 sekonda.

Mungesa e testeve Unit gjatë ndërtimit të imazheve ose modulëve të terraformit na detyron të hedhim punën në shërbime të veçanta, të cilat thjesht mund të thirren përmes REST, ose në skritpa Python.

Për shembull, na nevojitej të bënim që, gjatë startit të makinës virtuale, ajo të regjistrohej në shërbimin ScaleFT, dhe gjatë shkatërrimit të VM-së të hiqte veten.

Deri sa ScaleFT është një shërbim, ne detyrohemi të punojmë me të përmes API-së. Atje ishte shkruar një mbështetje, që mund të thirret dhe të thuhet: "Hy dhe hiqe këtë, atë". Ajo mban të gjitha konfigurimet dhe qasjen e nevojshme.

Tani mund të shkruajmë teste normale, pasi kjo nuk ka asnjë ndryshim nga softi i zakonshëm: mock-ojmë ndonjë API, e thirremi dhe shohim çfarë ndodh.

Përfundimet nga testet: Testimi Unit, që duhet të japë OS për një minutë, nuk e bën atë. Ndërsa llojet më të larta të testimit në piramidë japin efekt, por mbulojnë vetëm një pjesë të problemeve.

Programimi i çiftave

Testet janë, sigurisht, të mira. Mund të shkruhen shumë prej tyre, mund të jenë të llojeve të ndryshme. Ato do të punojnë në nivelet e tyre dhe do të na japin feedback. Por problemi me testet e dobëta që ofrojnë sistemin më të shpejtë vazhdon të ekzistojë. Megjithatë, vazhdojmë të duam një sistem të shpejtë, me të cilin është lehtë dhe këndshëm të punosh. Pa folur për cilësinë e zgjidhjes që marrim. Me fat, ka teknika që lejojnë të ofrojnë një feedback edhe më të shpejtë se testet modulare. Kjo është programimi i çiftit.

Kur shkruajmë kod, duam të marrim feedback mbi cilësinë e tij sa më shpejt të jetë e mundur. Po, mund të shkruani gjithçka në një degë funksionale (për të mos prishur asgjë për askënd), të krijoni një pull request në GitHub, të caktoni dikë, mendimi i të cilit ka peshë, dhe të prisni përgjigjen.

Por mund të presim gjatë. Njerëzit janë të gjithë të zënë, dhe përgjigja, edhe nëse vjen, mund të mos jetë e cilësisë më të lartë. Supozojmë se përgjigja erdhi menjëherë, rishikuesi e kuptoi menjëherë gjithë qëllimin, por përgjigja gjithsesi vjen me vonesë, pas faktit. Dhe ne duam ta marim atë më të shpejtë. Këtu synon programimi i çiftit – që të ketë feedback menjëherë, në momentin e shkruar.

Më poshtë po sjell stilet e programimit të çiftit dhe aplikueshmërinë e tyre në punën mbi IaC:

1. Klasik, Ekspert+ekspert, ndërrim sipas një kohezgjatjeje të caktuar. Dy role – shofer dhe navigator. Dy persona. Ata punojnë mbi një kod dhe ndërrimin e roleve e bëjnë pas një periudhe të caktuar kohore.

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

Problemi: përsosmëritë e mjeteve, mjeteve për zhvillimin e kodit.
Ndikimi negativ: zhvillimi zgjat më gjatë, ne ngadalësohemi, humbasim ritmin.
Si luftojmë: aplikojmë mjete të tjera, IDE për të gjithë dhe mësojmë shkurtesat.
Problemi: shpërndarja e ngadaltë.
Ndikimi negativ: rrit kohën për të krijuar një copë funksionale të kodit. Bëhemi të mërzitur gjatë pritjes, duar tërhiqen për të bërë diçka tjetër, derisa presim.
Si luftojmë: nuk e kemi përballuar.
Problemi: mungesa e qasjeve dhe praktikave.
Ndikimi negativ: nuk ka njohuri se si të bëhet mirë dhe si keq. Zgjat marrjen e feedbackut.
Si luftojmë: shkëmbimi i mendimeve dhe praktikave në punën e çiftit pothuajse zgjidh problemin.

Problemi kryesor i përdorimit të këtij stili në IaC është ritmi i papërshtatshëm i punës. Në zhvillimin tradicional të softuerit, ke një lëvizje shumë uniforme. Mund të harxhosh pesë minuta dhe të shkruash N. Të harxhosh 10 minuta dhe të shkruash 2N, 15 minuta – 3N. Këtu, mund të harxhosh pesë minuta dhe të shkruash N, pastaj të harxhosh akoma 30 minuta dhe të shkruash një të dhjetën e N. Këtu nuk di asgjë, ndihesh i bllokuar. Zgjidhja merr kohë dhe të shpërqendron nga programimi vetë.

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

2. Ping-pong. Ky qasje supozon që një pjesëmarrës shkruan testin, ndërsa tjetri e bën realizimin e tij. Duke marrë parasysh se me testet e njësive gjithçka është e komplikuar, dhe është e nevojshme të shkruash një test integrues që kërkon shumë kohë, e gjithë lehtësia e ping-pong-ut largohet.

Mund të them se kemi provuar ndarjen e detyrave për projektimin e skenarit të testit dhe realizimin e kodit për të. Një pjesëmarrës shpik skenarin, në këtë pjesë të punës ai është përgjegjës, atij i përket fjala përfundimtare. Ndërsa tjetri është përgjegjës për realizimin. Kjo rezultoi mirë. Cilësia e skenarit në këtë qasje rritet.

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

3. Strong Style. Praktikë e komplikuar.. Ideja është që një pjesëmarrës bëhet një navigues direktiv, ndërsa tjetri merr rolin e shoferit ekzekutues. Në këtë rast, e drejta për të marrë vendime është ekskluzivisht e naviguesit. Shoferi thjesht shtyp dhe me fjalë mund të ndikojë në ngjarjet. Roli nuk ndryshon për një kohë të gjatë.

Shkon mirë për mësim, por kërkon aftësi të forta sociale. Këtu u bllokuam. Teknikat ishin të komplikuara. Dhe kjo ndodhi jo për shkak të infrastrukturës.

Përfundimi: potencialisht mund të aplikohet, ne nuk e lëmë mundësinë.

4. Mobbing, swarming, dhe të gjithë stilët e njohur, por jo të përmendur këtu, nuk shqyrtohen, pasi nuk i kemi provuar dhe nuk mund të themi për këtë në kontekstin e punës tonë.

Përmbledhje e përgjithshme mbi përdorimin e programimit në çift:

Kemi një ritëm pune të pauniformuar, që na pengon.

Ne kemi hasur në aftësi të pamjaftueshme sociale. Dhe fusha tematike nuk ndihmon në tejkalimin e këtyre mangësive tona.

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

5. Megjithatë, kishim edhe suksese. Ne krijuam metodën tonë "Konvergjencë - Divergjencë". Përmbledhtas, do ta përshkruaj si funksionon.

Kemi partnerë të përhershëm për disa ditë (pak më pak se një javë). Bëjmë një detyrë së bashku. Njëfarë kohe qëndrojmë së bashku: një shkruan, tjetri qëndron dhe vështron si një ekip mbështetës. Pastaj shpërndajmë për një kohë, secili bën diçka të pavarur, pastaj prapë takohemi, shpejtëkoordinim, bëjmë diçka së bashku dhe përsëri shpërndajmë.

Planifikimi dhe komunikimi

Blloku i fundit i praktikave, përmes të cilave zgjidhen problemet e OS – është organizimi i punës me detyrat vetë. Këtu hyjnë edhe shkëmbimi i përvojës, i cili është jashtë punës në çift. Le të shqyrtojmë tre praktika:

1. Detyrat përmes strukturës së qëllimeve. Menaxhimi i përgjithshëm i projektit e kemi organizuar përmes një strukture, që shkon pafundësisht në të ardhmen. Teknikisht, mbajtja e vështirësohet në Miro. Ka një detyrë – ajo është një qëllim ndërmjetës. Prej saj dalin ose qëllime më të vogla, ose grupe detyrash. Prej tyre janë pa dyshim detyrat. Të gjitha detyrat krijohen dhe menaxhohen në këtë tabelë.

Ky skemë gjithashtu ofron reagim, i cili ndodh një herë në ditë, kur ne koordinatohemi në mbledhje. Prania e një plani të përbashkët për të gjithë, i strukturuar dhe plotësisht i hapur, lejon çdo kush të jetë në dijeni të asaj që po ndodh dhe se sa përpara kemi avancuar në progres.

Përparësitë e shikimit vizual të detyrave:

Kauzaliteti. Çdo detyrë çon në një qëllim global. Detyrat grupohen sipas qëllimeve më të vogla. Domeni i infrastrukturës vetë është mjaft teknik. Nuk është gjithmonë e qartë menjëherë se cilat ndikim konkret ka në biznes, për shembull, shkruani një dokument rregullash për migrimin në një nginx tjetër. Prania e një kartë qëllimike pranë e bën më të kuptueshëm.

Kauzaliteti – është një pronë e rëndësishme e detyrave. Ai përgjigjet drejtpërdrejt në pyetjen: "A po bëj atë që duhet?"
Paraleliteti. Ne jemi nëntë njerëz, dhe është fizikisht e pamundur që të sulmojmë të gjithë një detyrë. Detyrat nga një fushë gjithashtu nuk janë gjithmonë të mjaftueshme. Ne jemi të detyruar të ndahet punën në grupe të vogla punuese. Gjatë kësaj, grupet kalojnë një kohë të caktuar me detyrën e tyre dhe mund të forcohen nga dikush tjetër. Ndonjëherë ndodhin ndryshime në këtë grup pune. Disa largohen në pushim, disa përgatisin një referim për konferencën DevOps conf, disa shkruajnë një artikull për Habr. Të dish se cilat qëllime dhe detyra mund të bëhen paralelisht bëhet shumë e rëndësishme.

2. Ndryshimi i liderëve në takimet e mëngjesit. Në standup, u shfaq një problem - shumë detyra njerëzit i bëjnë paralelisht. Ndonjëherë detyrat janë pak të lidhura dhe nuk ka kuptim se kush bën çfarë. Opinioni i një anëtari tjetër të ekipit është shumë i rëndësishëm. Ky është informacion shtesë, i cili mund të ndryshojë kursin e zgjidhjes së detyrës. Sigurisht, zakonisht je me dikë, por konsultimi dhe ndihmat janë gjithmonë të dobishme.

Për të përmirësuar këtë situatë, ne aplikuam teknikën "Ndryshimi i liderit të standup-it". Tani ato rotullohen sipas një liste të caktuar, dhe ky ka efektin e tij. Kur arrin radha jote, je i detyruar të thellohesh dhe të kuptosh çfarë po ndodh, për të drejtuar mirë takimin e skram.

3. Demo e brendshme. Ndihma në zgjidhjen e detyrës nga programimi i përbashkët, vizualizimi në pemën e detyrave dhe ndihma në takimet e skramit në mëngjes është e mirë, por jo perfekte. Në çift je i kufizuar vetëm nga njohuritë tuaja. Pema e detyrave ndihmon për të kuptuar globalisht se kush dhe çfarë po bën. Ndërsa udhëheqësi dhe kolegët në takimin e mëngjesit nuk do të thellohen shumë në problemet tua. Ata sigurisht mund të lënë diçka pa qënë vënë re.

Zgjidhja u gjet në demontrimin e punimeve të bëra ndaj njëri-tjetrit dhe diskutimit të mëpasshëm të tyre. Ne mblidhemi një herë në javë për një orë dhe tregojmë detajet e zgjidhjeve për detyrat që kemi bërë javën e kaluar.

Në procesin e demontrimit, duhet të zbulojmë detajet e detyrës dhe patjetër të demonstrojmë funksionimin e saj.

Raporti mund të udhëhiqet sipas një liste kontrolli.1. Fut në kontekst. Nga erdhi detyra, përse ishte e nevojshme kjo në të vërtetë?

2. Si është zgjidhur detyra deri tani? Për shembull, ishte e nevojshme të klikosh shumë me miun, ose ishte krejtësisht e pamundur të bëhej diçka.

3. Si e përmirësojmë këtë. Për shembull: "Shikoni, tani ka një skrip, ja README."

4. Trego se si funksionon. Preferohet të realizoni një skenar të përdoruesit. Dua X, bëj Y, shoh Z (ose Z'). Për shembull, deploy NGINX, shikoj url, merr 200 OK. Nëse veprimi zgjat, përgatiteni më parë për ta treguar më vonë. Preferohet të mos ndërpritet shumë para demos, veçanërisht nëse është delikat.

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

Preferohet që çdo folës të përfshihet brenda 5-10 minutash. Nëse fjalimi juaj është me rëndësi të madhe dhe do të zgjasë më shumë, dakordoni këtë paraprakisht në kanalin sre-takeover.

Pas pjesës me prezencë fizike, përcjellja e diskutimeve në thread është e domosdoshme. Këtu do të dalë e nevojshmja për ne një informacion të kthyer për detyrat tona.

Në përfundim, organizohet një anketë për të vlerësuar përdorshmërinë e zhvillimeve. Kjo është tashmë një informacion i kthyer në lidhje me përmbajtjen e fjalimit dhe rëndësinë e detyrës.

Përfundime të gjata dhe çfarë do të ndodhë më pas

Mund të duket se qëndrimi i artikullit është disi pesimist. Kjo nuk është e saktë. Dy nivelet e ulëta të marrjes së informacionit të kthyer, domethënë testet dhe programimi në çift, funksionojnë. Nuk është aq perfekt sa në zhvillimin tradicional, por ka një efekt pozitiv nga kjo.

Testet, në formën e tyre aktuale, ofrojnë vetëm mbulim të pjesshëm të kodit. Shumë funksione konfigurimi nuk janë testuar. Ndikimi i tyre në punën e menjëhershme gjatë shkruarjes së kodit është i ulët. Megjithatë, ka një efekt nga testet integruese, dhe ato lejojnë që të kryhen pa frikë refaktorizime. Kjo është një arritje e madhe. Gjithashtu, me kalimin në zhvillimin në gjuhë të nivelit të lartë (ne kemi python, go) problemi zhduket. Dhe për "ndihmën" ka shumë prova dhe nuk është e nevojshme, mjafton teste të përgjithshme integruese.

Puna në çift varet më shumë nga njerëzit specifikë. Ka një faktor të detyrës dhe aftësive tona të buta. Me dikë funksionon shumë mirë, me dikë më keq. Patjetër ka dobi nga kjo. E qartë është se edhe kur rregullat e punës në çift nuk respektohen, vetë fakti i realizimit të detyrave së bashku ndikon pozitivisht në cilësinë e rezultatit. Për mua, është më e lehtë dhe më e këndshme të punosh në çift.

Metoda më të nivelit të lartë për të ndikuar në OS - planifikimi dhe puna me detyrat sigurisht që japin efekte: shkëmbimi i njohurive dhe përmirësimi i cilësisë së zhvillimit.