Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Foto: Unsplash

Pershendetje te gjitheve! Ne jemi inxhinierë automatizimi nga kompania Teknologjitë pozitive dhe ne ofrojmë mbështetje për zhvillimin e produkteve të kompanisë: ne mbështesim të gjithë tubacionin e montimit nga marrja e një linje kodi nga zhvilluesit deri te publikimi i produkteve të gatshme dhe licencave në serverët e përditësimit. Joformalisht, ne quhemi inxhinierë DevOps. Në këtë artikull duam të flasim për fazat teknologjike të procesit të prodhimit të softuerit, si i shohim dhe si i klasifikojmë.

Nga materiali do të mësoni për kompleksitetin e koordinimit të zhvillimit të shumë produkteve, për atë që është një hartë teknologjike dhe si ndihmon për të përmirësuar dhe përsëritur zgjidhjet, cilat janë fazat dhe hapat kryesore të procesit të zhvillimit, si janë fushat e përgjegjësisë midis DevOps dhe ekipeve në kompaninë tonë.

Rreth Kaosit dhe DevOps

Shkurtimisht, koncepti i DevOps përfshin mjetet dhe shërbimet e zhvillimit, si dhe metodologjitë dhe praktikat më të mira për përdorimin e tyre. Le të veçojmë globalen qëllimi nga zbatimi i ideve të DevOps në kompaninë tonë: ky është një ulje e vazhdueshme e kostos së prodhimit dhe mirëmbajtjes së produkteve në terma sasiorë (orë punë ose orë makinerie, CPU, RAM, Disk etj.). Mënyra më e thjeshtë dhe më e dukshme për të reduktuar koston e përgjithshme të zhvillimit në nivel kompanie është duke minimizuar koston e kryerjes së detyrave tipike serike në të gjitha fazat e prodhimit. Por cilat janë këto faza, si mund të dallohen nga procesi i përgjithshëm, në çfarë hapash përbëhen ato?

Kur një kompani po zhvillon një produkt, gjithçka është pak a shumë e qartë: zakonisht ekziston një udhërrëfyes i përgjithshëm dhe një skemë zhvillimi. Por çfarë të bëni kur linja e produkteve zgjerohet dhe ka më shumë produkte? Në pamje të parë, ata kanë procese dhe linja montimi të ngjashme dhe fillon loja e "gjeni dallimet X" në regjistrat dhe skriptet. Po sikur tashmë ka mbi 5 projekte në zhvillim aktiv dhe kërkohet mbështetje për disa versione të zhvilluara gjatë disa viteve? A duam të ripërdorim sa më shumë zgjidhje të jetë e mundur në tubacionet e produkteve apo jemi gati të shpenzojmë para për zhvillimin unik për secilën?

Si të gjeni një ekuilibër midis unike dhe zgjidhjeve serike?

Këto pyetje filluan të ngrihen para nesh gjithnjë e më shpesh që nga viti 2015. Numri i produkteve u rrit dhe ne u përpoqëm të zgjeronim departamentin tonë të automatizimit (DevOps), i cili mbështeti linjat e montimit të këtyre produkteve, në minimum. Në të njëjtën kohë, ne donim të përsëritnim sa më shumë zgjidhje të jetë e mundur midis produkteve. Në fund të fundit, pse të bëjmë të njëjtën gjë në dhjetë produkte në mënyra të ndryshme?

Drejtori i Zhvillimit: "Djema, a mund të vlerësojmë disi se çfarë bën DevOps për produktet?"

Ne: "Nuk e dimë, nuk kemi bërë një pyetje të tillë, por cilët tregues duhet të merren parasysh?"

Drejtori i Zhvillimit: "Kush e di! Mendo..."

Si në atë filmin e famshëm: "Unë jam në një hotel! .." - "Uh ... Mund të më tregosh rrugën?" Me reflektim, arritëm në përfundimin se fillimisht duhet të vendosim për gjendjen përfundimtare të produkteve; ky u bë qëllimi ynë i parë.

Pra, si mund të analizoni një duzinë produktesh me ekipe mjaft të mëdha nga 10 deri në 200 persona dhe të përcaktoni metrika të matshme kur përsëritni zgjidhje?

1:0 në favor të Chaos, ose DevOps në tehët e shpatullave

Filluam duke u përpjekur të aplikojmë diagrame IDEF0 dhe diagrame të ndryshme të proceseve të biznesit nga seria BPwin. Konfuzioni filloi pas katrorit të pestë të fazës tjetër të projektit të ardhshëm, dhe këto sheshe për çdo projekt mund të tërhiqen në bishtin e një pitoni të gjatë në 50+ hapa. U ndjeva i trishtuar dhe doja të ulërija në hënë - nuk përshtatej fare.

Detyrat tipike të prodhimit

Modelimi i proceseve të prodhimit është një punë shumë komplekse dhe e mundimshme: ju duhet të grumbulloni, përpunoni dhe analizoni shumë të dhëna nga departamente dhe zinxhirë të ndryshëm prodhimi. Mund të lexoni më shumë rreth kësaj në artikullin "Modelimi i proceseve të prodhimit në një kompani IT'.

Kur filluam të modelonim procesin tonë të prodhimit, kishim një qëllim specifik - t'i përcillnim çdo punonjësi të përfshirë në zhvillimin e produkteve të kompanisë sonë dhe menaxherëve të projektit:

  • si produktet dhe përbërësit e tyre, duke filluar nga marrja e një linje kodi, arrijnë te klienti në formën e instaluesve dhe përditësimeve,
  • çfarë burimesh sigurohen për secilën fazë të prodhimit të produkteve,
  • cilat shërbime përfshihen në çdo fazë,
  • si përcaktohen fushat e përgjegjësisë për çdo fazë,
  • çfarë kontratash ekzistojnë në hyrje dhe dalje të çdo faze.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Duke klikuar mbi imazhin do ta hapni atë në madhësi të plotë.

Puna jonë në kompani është e ndarë në disa fusha funksionale. Departamenti i infrastrukturës është i angazhuar në optimizimin e funksionimit të të gjitha burimeve harduerike të departamentit, si dhe automatizimin e vendosjes së makinave virtuale dhe mjedisit mbi to. Drejtimi i monitorimit ofron kontroll mbi kryerjen e shërbimeve 24/7; Ne gjithashtu ofrojmë monitorim si një shërbim për zhvilluesit. Drejtimi i rrjedhës së punës u siguron ekipeve mjete për menaxhimin e proceseve të zhvillimit dhe testimit, analizimin e statusit të kodit dhe marrjen e analitikëve në projekte. Dhe së fundi, drejtimi i webdev siguron publikimin e publikimeve në serverët e përditësimit GUS dhe FLUS, si dhe licencimin e produkteve duke përdorur shërbimin LicenseLab. Për të mbështetur tubacionin e prodhimit, ne kemi ngritur dhe mirëmbajtur shumë shërbime të ndryshme mbështetëse për zhvilluesit (mund të dëgjoni histori për disa prej tyre në takimet e vjetra: Op!DevOps! 2016 и Op!DevOps! 2017). Ne gjithashtu zhvillojmë mjete të automatizimit të brendshëm, duke përfshirë zgjidhje me burim të hapur.

Gjatë pesë viteve të fundit, puna jonë ka grumbulluar shumë operacione të të njëjtit lloj dhe rutinë, dhe zhvilluesit tanë nga departamentet e tjera vijnë kryesisht nga të ashtuquajturat detyra tipike, zgjidhja e të cilave është plotësisht ose pjesërisht e automatizuar, nuk shkakton vështirësi për interpretuesit dhe nuk kërkon sasi të konsiderueshme pune. Së bashku me fushat kryesore, ne analizuam detyra të tilla dhe ishim në gjendje të identifikonim kategoritë individuale të punës, ose fazat e prodhimit, fazat u ndanë në hapa të pandashëm dhe mblidhen disa faza zinxhiri i procesit të prodhimit.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Shembulli më i thjeshtë i një zinxhiri teknologjik janë fazat e montimit, vendosjes dhe testimit të secilit prej produkteve tona brenda kompanisë. Nga ana tjetër, për shembull, faza e ndërtimit përbëhet nga shumë hapa të veçantë tipikë: shkarkimi i burimeve nga GitLab, përgatitja e varësive dhe bibliotekave të palëve të treta, testimi i njësive dhe analiza statike e kodit, ekzekutimi i një skripti ndërtimi në GitLab CI, publikimi i objekteve në depo në Artifaktori dhe gjenerimi i shënimeve të lëshimit përmes mjetit tonë të brendshëm ChangelogBuilder.

Ju mund të lexoni për detyrat tipike DevOps në artikujt tanë të tjerë në Habré: "Përvoja personale: si duket sistemi ynë i Integrimit të Vazhdueshëm"Dhe"Automatizimi i proceseve të zhvillimit: si i zbatuam idetë e DevOps në Positive Technologies'.

Formohen shumë zinxhirë tipikë prodhimi procesi i prodhimit. Qasja standarde për përshkrimin e proceseve është përdorimi i modeleve funksionale IDEF0.

Një shembull i modelimit të një procesi CI prodhimi

Ne i kushtuam vëmendje të veçantë zhvillimit të projekteve standarde për një sistem integrimi të vazhdueshëm. Kjo bëri të mundur arritjen e unifikimit të projekteve, duke evidentuar të ashtuquajturat lëshimi i skemës së ndërtimit me promovime.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Ja si funksionon. Të gjitha projektet duken tipike: ato përfshijnë konfigurimin e asambleve që shkojnë në depon e fotografive në Artifactory, pas së cilës ato vendosen dhe testohen në stolat e testimit, dhe më pas promovohen në depon e lëshimit. Shërbimi Artifactory është një pikë e vetme për shpërndarjen e të gjitha objekteve të ndërtimit midis ekipeve dhe shërbimeve të tjera.

Nëse e thjeshtojmë dhe përgjithësojmë shumë skemën tonë të lëshimit, ajo përfshin fazat e mëposhtme:

  • montimi i produktit ndër-platformë,
  • vendosen në stolat e testimit,
  • nisja e testeve funksionale dhe të tjera,
  • promovimi i ndërtimeve të testuara për lëshimin e depove në Artifactory,
  • publikimi i versioneve të lëshimit për të përditësuar serverët,
  • dërgimi i asambleve dhe përditësimet në prodhim,
  • nisja e instalimit dhe përditësimit të produktit.

Le të shqyrtojmë, si shembull, modelin teknologjik të kësaj skeme tipike lëshimi (më tej i referuar thjesht si Modeli) në formën e një modeli funksional IDEF0. Ai pasqyron fazat kryesore të procesit tonë CI. Modelet IDEF0 përdorin të ashtuquajturat Shënimi ICOM (Input-Control-Output-Mechanism) për të përshkruar se çfarë burimesh përdoren në çdo fazë, në bazë të rregullave dhe kërkesave që kryhet puna, cili është rezultati dhe cilat mekanizma, shërbime ose njerëz zbatojnë një fazë të caktuar.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Duke klikuar mbi imazhin do ta hapni atë në madhësi të plotë.

Si rregull, është më e lehtë të zbërthehet dhe të detajohet përshkrimi i proceseve në modelet funksionale. Por ndërsa numri i elementeve rritet, bëhet gjithnjë e më e vështirë të kuptosh diçka në to. Por në zhvillimin real ka edhe faza ndihmëse: monitorimi, certifikimi i produkteve, automatizimi i proceseve të punës dhe të tjera. Është për shkak të problemit të shkallëzimit që ne e braktisëm këtë përshkrim.

Lindja e Shpresës

Në një libër, ne hasëm në harta të vjetra sovjetike që përshkruajnë proceset teknologjike (të cilat, meqë ra fjala, përdoren ende sot në shumë ndërmarrje dhe universitete shtetërore). Prisni, prisni, sepse edhe ne kemi një fluks pune!.. Ka faza, rezultate, metrikë, kërkesa, tregues, e kështu me radhë e kështu me radhë… Pse të mos përpiqeni të aplikoni fletë rrjedhëse edhe në tubacionet e produkteve tona? Kishte një ndjenjë: "Kjo është ajo! Ne kemi gjetur fillin e duhur, është koha ta tërheqim mirë!

Në një tabelë të thjeshtë, ne vendosëm të regjistrojmë produktet sipas kolonave, dhe fazat teknologjike dhe hapat e tubacionit të produktit sipas rreshtave. Pikat kryesore janë diçka e madhe, siç është një hap i ndërtimit të produktit. Dhe hapat janë diçka më e vogël dhe më e detajuar, siç është hapi i shkarkimit të kodit burim në serverin e ndërtimit ose hapi i përpilimit të kodit.

Në kryqëzimet e rreshtave dhe kolonave të hartës, ne vendosim statuset për një fazë dhe produkt specifik. Për statuset, u përcaktua një grup gjendjesh:

  1. Nuk ka të dhëna - ose të papërshtatshme. Është e nevojshme të analizohet kërkesa për një fazë në produkt. Ose analiza është kryer tashmë, por faza aktualisht nuk nevojitet ose nuk justifikohet ekonomikisht.
  2. Shtyhet - ose jo relevante për momentin. Duhet një fazë në tubacion, por nuk ka forca për zbatim këtë vit.
  3. Të planifikuara. Faza është planifikuar të zbatohet këtë vit.
  4. Zbatuar. Faza në tubacion zbatohet në vëllimin e kërkuar.

Plotësimi i tabelës filloi projekt për projekt. Fillimisht u klasifikuan fazat dhe hapat e një projekti dhe u regjistruan statuset e tyre. Më pas morën projektin e radhës, rregulluan statuset në të dhe shtuan fazat dhe hapat që mungonin në projektet e mëparshme. Si rezultat, ne morëm fazat dhe hapat e të gjithë tubacionit tonë të prodhimit dhe statuset e tyre në një projekt specifik. Doli diçka e ngjashme me matricën e kompetencës së tubacionit të produktit. Ne e quajtëm një matricë të tillë një hartë teknologjike.

Me ndihmën e hartës teknologjike, ne koordinojmë në mënyrë të arsyeshme metrologjike me ekipet planet e punës për vitin dhe objektivat që duam të arrijmë së bashku: cilat faza i shtojmë projektit këtë vit dhe cilat i lëmë për më vonë. Gjithashtu gjatë punës mund të kemi përmirësime në fazat që kemi përfunduar vetëm për një produkt. Më pas ne zgjerojmë hartën tonë dhe e prezantojmë këtë përmirësim si një fazë ose një hap të ri, më pas analizojmë për secilin produkt dhe zbulojmë mundësinë e përsëritjes së përmirësimit.

Ata mund të na kundërshtojnë: “Kjo është e gjitha, natyrisht, e mirë, vetëm me kalimin e kohës numri i hapave dhe fazave do të bëhet jashtëzakonisht i madh. Si të jesh?

Ne kemi prezantuar përshkrime standarde dhe mjaft të plota të kërkesave për çdo fazë dhe hap, në mënyrë që ato të kuptohen nga të gjithë brenda kompanisë në të njëjtën mënyrë. Me kalimin e kohës, ndërsa përmirësimet futen, një hap mund të përthithet në një fazë ose hap tjetër, dhe më pas ato do të "shemben". Në të njëjtën kohë, të gjitha kërkesat dhe nuancat teknologjike përshtaten në kërkesat e fazës ose hapit përgjithësues.

Si të vlerësohet efekti i përsëritjes së zgjidhjeve? Ne përdorim një qasje jashtëzakonisht të thjeshtë: ia atribuojmë kostot kapitale fillestare për zbatimin e një faze të re kostove të përgjithshme vjetore të produktit, dhe më pas i ndajmë me të gjitha kur përsërisim.

Pjesë të zhvillimit janë pasqyruar tashmë si faza dhe hapa në hartë. Ne mund të ndikojmë në uljen e kostove të produktit nëpërmjet futjes së automatizimit për fazat tipike. Pas kësaj, ne llogarisim ndryshimet në karakteristikat cilësore, metrikat sasiore dhe fitimin e marrë nga ekipet (në orë pune ose orë makinerie të kursyera).

Harta teknologjike e procesit të prodhimit

Nëse marrim të gjitha fazat dhe hapat tanë, i kodojmë me etiketa dhe i zgjerojmë në një zinxhir, atëherë do të rezultojë shumë i gjatë dhe i pakuptueshëm (vetëm "bishti i pitonit" për të cilin folëm në fillim të artikullit) :

[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]

Këto janë fazat e ndërtimit të produkteve [Build], vendosja e tyre në serverët e testimit [Deploy], testimi [Test], promovimi i ndërtimeve për lëshimin e depove bazuar në rezultatet e testimit [Promote], gjenerimi dhe publikimi i licencave [License], publikimi [ Publikimi] në serverin e përditësimit GUS dhe dërgimi në serverët e përditësimit FLUS, instalimi dhe përditësimi i komponentëve të produktit në infrastrukturën e klientit duke përdorur Menaxhimin e konfigurimit të produktit [Install], si dhe mbledhjen e telemetrisë [Telemetry] nga produktet e instaluara.

Përveç tyre, mund të dallojmë faza të veçanta: monitorimi i gjendjes së infrastrukturës [InfMonitoring], menaxhimi i versioneve të kodit burimor [SourceCodeControl], përgatitja e mjedisit të montimit [Përgatitja], menaxhimi i projektit [Rrjedha e punës], sigurimi i ekipeve me mjete komunikimi [ Komunikimi], certifikimi i produktit [Certifikimi] dhe sigurimi i vetë-mjaftueshmërisë së proceseve CI [CISelfSufficiency] (për shembull, pavarësia e asambleve nga Interneti). Ne as nuk do të marrim parasysh dhjetëra hapa në proceset tona, sepse ato janë shumë specifike.

Do të jetë shumë më e lehtë për të kuptuar dhe parë të gjithë procesin e prodhimit nëse paraqitet në formë harta teknologjike; Kjo është një tabelë në të cilën fazat individuale të prodhimit dhe hapat e zbërthyer të Modelit regjistrohen në rreshta dhe në kolona një përshkrim i asaj që bëhet në çdo fazë ose hap. Theksi kryesor është në burimet që ofrojnë çdo fazë dhe përcaktimin e fushave të përgjegjësisë.

Harta për ne është një lloj klasifikuesi. Ai pasqyron pjesët e mëdha teknologjike të prodhimit të produkteve. Falë tij, u bë më e lehtë për ekipin tonë të automatizimit të ndërveprojë me zhvilluesit dhe të planifikojë bashkërisht zbatimin e fazave të automatizimit, si dhe të kuptojë se cilat kosto dhe burime të punës (njerëzore dhe pajisje) do të kërkohen për këtë.

Brenda kompanisë sonë, harta gjenerohet automatikisht nga një shabllon jinja si një skedar i rregullt HTML, dhe më pas ngarkohet në serverin GitLab Pages. Mund të shihet një pamje e ekranit me një shembull të një harte të krijuar plotësisht по ссылке.

Menaxhimi i kaosit: Vendosja e gjërave në rregull me ndihmën e një harte teknologjike

Duke klikuar mbi imazhin do ta hapni atë në madhësi të plotë.

Me pak fjalë, një hartë teknologjike është një pamje e përgjithësuar e procesit të prodhimit, e cila pasqyron blloqe të klasifikuara qartë me funksionalitet standard.

Struktura e hartës sonë teknologjike

Harta përbëhet nga disa pjesë:

  1. Zona e titullit - këtu është një përshkrim i përgjithshëm i hartës, futen konceptet bazë, përcaktohen burimet kryesore dhe rezultatet e procesit të prodhimit.
  2. Paneli - këtu mund të kontrolloni shfaqjen e të dhënave për produkte individuale, jepet një përmbledhje e fazave të zbatuara dhe hapave në përgjithësi për të gjitha produktet.
  3. Harta teknologjike - një përshkrim tabelor i procesit teknologjik. Në hartë:
    • jepen të gjitha fazat, hapat dhe kodet e tyre;
    • jepen përshkrime të shkurtra dhe të plota të fazave;
    • tregohen burimet hyrëse dhe shërbimet e përdorura në çdo fazë;
    • tregohen rezultatet e secilës fazë dhe një hap i veçantë;
    • tregohet fusha e përgjegjësisë për çdo fazë dhe hap;
    • janë përcaktuar burimet teknike, për shembull HDD (SSD), RAM, vCPU dhe orët e punës të nevojshme për të mbështetur punën në këtë fazë, si në planin aktual, ashtu edhe në të ardhmen;
    • për çdo produkt tregohet se cilat faza ose hapa teknologjikë për të janë zbatuar, janë planifikuar për zbatim, janë të parëndësishme ose nuk janë zbatuar.

Vendimmarrja e bazuar në hartën teknologjike

Pas ekzaminimit të hartës, është e mundur të ndërmerren disa veprime - në varësi të rolit të punonjësit në kompani (menaxheri i zhvillimit, menaxheri i produktit, zhvilluesi ose testuesi):

  • të kuptojnë se cilat faza mungojnë në një produkt ose projekt real dhe të vlerësojnë nevojën për zbatimin e tyre;
  • Kufizoni fushat e përgjegjësisë ndërmjet disa departamenteve nëse ata punojnë në faza të ndryshme;
  • të negociojë kontrata për inputet dhe outputet e fazave;
  • integroni fazën tuaj të punës në procesin e përgjithshëm të zhvillimit;
  • të vlerësojë më saktë nevojën për burime që ofrojnë secilën nga fazat.

Duke përmbledhur të gjitha sa më sipër

Drejtimi është i gjithanshëm, i shtrirë dhe i lehtë për t'u mirëmbajtur. Është shumë më e lehtë për të zhvilluar dhe mbajtur një përshkrim të proceseve në këtë formë sesa në një model të rreptë akademik IDEF0. Përveç kësaj, një përshkrim tabelor është më i thjeshtë, më i njohur dhe më i strukturuar sesa një model funksional.

Për zbatimin teknik të hapave, ne kemi një mjet të veçantë të brendshëm CrossBuilder - një mjet shtresash midis sistemeve CI, shërbimeve dhe infrastrukturës. Zhvilluesi nuk ka nevojë të presë biçikletën e tij: në sistemin tonë CI, mjafton të ekzekutoni një nga skriptet (e ashtuquajtura detyrë) e mjetit CrossBuilder, i cili do ta ekzekutojë saktë atë, duke marrë parasysh veçoritë e infrastrukturës sonë. .

Rezultatet e

Artikulli doli të ishte mjaft i gjatë, por kjo është e pashmangshme kur përshkruhet modelimi i proceseve komplekse. Në fund, do të doja të rregulloja shkurtimisht idetë tona kryesore:

  • Qëllimi i zbatimit të ideve të DevOps në kompaninë tonë është të zvogëlojë vazhdimisht koston e prodhimit dhe mirëmbajtjes së produkteve të kompanisë në terma sasiorë (orë punë ose orë makinerie, vCPU, RAM, Disk).
  • Mënyra për të ulur koston e përgjithshme të zhvillimit është të minimizoni koston e kryerjes së detyrave tipike serike: fazat dhe hapat e procesit teknologjik.
  • Një detyrë tipike është një detyrë, zgjidhja e së cilës është plotësisht ose pjesërisht e automatizuar, nuk shkakton vështirësi për interpretuesit dhe nuk kërkon kosto të konsiderueshme të punës.
  • Procesi i prodhimit përbëhet nga faza, fazat ndahen në hapa të pandashëm, të cilët përfaqësojnë detyra tipike të shkallëve dhe vëllimeve të ndryshme.
  • Nga detyrat standarde të izoluara kemi ardhur në zinxhirë teknologjikë komplekse dhe modele me shumë nivele të procesit të prodhimit, të cilat mund të përshkruhen nga një model funksional IDEF0 ose një hartë teknologjike më e thjeshtë.
  • Harta teknologjike është një paraqitje tabelore e fazave dhe hapave të procesit të prodhimit. Gjëja më e rëndësishme: harta ju lejon të shihni të gjithë procesin në tërësi, në copa të mëdha me mundësinë e detajimit të tyre.
  • Bazuar në hartën teknologjike, ju mund të vlerësoni nevojën për të zbatuar fazat në një produkt të caktuar, të kufizoni fushat e përgjegjësisë, të bini dakord për kontratat për hyrjet dhe rezultatet e fazave dhe të vlerësoni më saktë nevojën për burime.

Në artikujt e mëposhtëm, ne do të përshkruajmë më në detaje se cilat mjete teknike përdoren për të zbatuar faza të caktuara teknologjike në hartën tonë.

Autorët e artikullit:

  • Aleksandër Pazdnikov — Shef i Departamentit të Automatizimit (DevOps) në Positive Technologies
  • Timur Gilmullin - Zv Shef i Departamentit të Automatizimit (DevOps) në Positive Technologies

Burimi: www.habr.com

Shto një koment