[08] პროგრამული უზრუნველყოფის...
TRANSCRIPT
![Page 1: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/1.jpg)
გუნდის ორგანიზება
პროგრამული უზრუნველყოფისინჟინერია, ლექცია 8
მიხეილ კაპანაძე
![Page 2: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/2.jpg)
პასუხისმგებლობათა გამიჯვნა
n პროექტზე მომუშავე გუნდში ხალხს სხვადასხვა როლიდა პასუხისმგებლობა აქვს. მენეჯერები, ტესტერები, დიზაინერები, პროგრამისტები და ა.შ.
n ზოგჯერ ერთიდაიგივე ადამიანმა შეიძლებარამდენიმე როლი იტვირთოს
n თუმცა ხანდახან ეს მიუღებელია. ის, ვინც პროგრამასწერს, არ შეიძლება იყოს ტესტერიც (და პირიქით)
![Page 3: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/3.jpg)
გუნდების ორგანიზება
n დიდი გუნდი შეიძლება დანაწილდეს, მართვისგაადვილების მიზნით.
n თუკი ამ მცირე გუნდებს ნათლად ექნებათ დასახულიამოცანა, კომუნიკაცია ძირითადად მათ შიგნით იქნებამოქცეული
n პერსონალს შორის კომუნიკაციის ღირებულებისშეფასებამ შეიძლება მოგვცეს წარმოდგენა გუნდისზომისა და პროდუქტიულობის თანაფარდობაზე
![Page 4: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/4.jpg)
იერარქიული ორგანიზაცია
n იერარქიული ორგანიზაცია ხშირად გვხვდება ისეთკომპანიებში, რომლებიც პროგრამულიუზრუნველყოფის შექმნით არიან დაკავებული
n ხშირად იერარქია იმეორებს იმ სისტემისსტრუქტურას, რომლის აგებაც ხდება.
n თუ სისტემას 3 ძირითადი ქვესისტემა აქვს, შესაძლოათითოეულზე ცალკე გუნდი მუშაობდეს, მათ ცალკემენეჯერები აკონტროლებდნენ, სათავეში კიხდებოდეს საერთო კოორდინაცია
![Page 5: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/5.jpg)
იერარქიული ორგანიზაცია –გაგრძელებაn გარდა ქვესისტემებზე მომუშავე ჯგუფებისა, ასევე
შეიძლება არსებობდეს ცალკე ფუნქციონალურიგანყოფილებები. მაგალითად – ტესტირების.
n იერარქიულ ორგანიზებას როგორც წესი თან ახლავსსხვადასხვაგვარი რისკებიq სხვადასხვა გუნდების მართვის სტილი შეიძლება
განსხვავდებოდესq ინფორმაცია, რომელიც ქვემოდან ზემოთ მიდის, შეიძლება
შელამაზდეს
![Page 6: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/6.jpg)
კარიერული ზრდ იერარქიულორგანიზაციაშიn იერარქიულ ორგანიზაციებში თანამდებობა
განსაზღვრავს სტატუსს და ფინანსურ მდგომარეობას
n აქედან გამომდინარე, ყველა ზემოთ მიისწრაფის
n პეტერის პრინციპი (Peter Principle) :“იერარქიაში ყველა თანამშრომელი მიისწრაფვის რომგაიზარდოს საკუთარი არაკომპეტენტურობისდონემდე”
![Page 7: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/7.jpg)
მატრიცული ორგანიზაცია
n მატრიცულ ორგანიზაციაში ადამიანები სხვადასხვაგანყოფილებებიდან ერთვებიან პროგრამულიუზრუნველყოფის შემუშავებაში. ხშირად – არასრულიდატვირთვით.
n ასეთ ორგანიზაციაში ადამიანი ხშირად ექვემდებარებარამდენიმე ხელმძღვანელს ერთდროულად დაშესაძლოა სცადოს ამ სიტუაციით მანიპულირება.
![Page 8: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/8.jpg)
მატრიცული ორგანიზაცია –გაგრძელებაn შესაძლებელია არსებობდეს რამდენიმე ქვეყანაყოფი
ერთიდაიგივე სპეციალიზაციით: ინტერფეისი, მონაცემთა ბაზები, ხარისხის კონტროლი და ა.შ.
n პროექტი საჭიროებს სხვადასხვა კომპეტენციებს
n შესაბამისად, ადამიანები 2 ღერძის მიხედვით არიანგანლაგებული: ერთი მხრივ ქვეგანაყოფებში(სპეციალიზაციის მიხედვით), მეორე მხრივ –პროექტებში.
![Page 9: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/9.jpg)
მენეჯერები მატრიცულიორგანიზებისასn როგორც აღინიშნა, მომხმარებლები ექვემდებარებიან
რამდენიმე მენეჯერს
n პროექტ მენეჯერი პასუხისმგებელია პროექტისწარმატებულ დასრულებაზე. განყოფილების მენეჯერსკი გრძელვადიანი ამოცანები აქვს. მაგალითად, გუნდის პროფესიონალიზმის ამაღლება
n შეიძლება ითქვას რომ პროექტ მენეჯერი სამუშაოზემიმართულ სტილს უნდა მისდევდეს. განყოფილებისმენეჯერი კი – ურთიერთობაზე მიმართულს
![Page 10: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/10.jpg)
უფროსი პროგრამისტის გუნდი
n ასეთ გუნდის ბირთვს 3 ძირითადი თანამშრომელიწარმოადგენს:q უფროსი პროგრამისტი – გუნდის ლიდერი, რომელიც თავის
თავზე იღებს სისტემის საკვანძო ნაწილების დიზაინს დაგადაწყვეტას
q უფროსი პროგრამისტის ასისტენტი – მას შეუძლია შეცვალოსუფროსი პროგრამისტი, თუ ეს საჭირო გახდება
q ბიბლიოთეკარი – თავის თავზე იღებს ადმინისტრაციულსაქმეებს და დოკუმენტაციას
n გარდა ამისა, შეიძლება გუნდში მცირე რაოდენობისექსპერტების დამატება
![Page 11: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/11.jpg)
უფროსი პროგრამისტი
n უფროსი პროგრამისტი აუცილებლად უნდა იყოსკომპეტენტური ტექნიკურ სფეროში
n მას ასევე უნდა გააჩნდეს საკმარისი მენეჯერულიუნარები
n ასეთი ადამიანები, რომლებიც ამავდროულადშეიძლება ქარიზმატული ლიდერები იყონ, როგორცწესი იშვიათია.
![Page 12: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/12.jpg)
უფროსი პროგრამისტის გუნდისმოდიფიცირებული ვარიანტიn ნაცვლად კლასიკური “ელიტარული” უფროსი
პროგრამისტის გუნდისა, შეიძლება ავიღოთმცირერიცხოვანი გუნდი, ამოცანაზე კოლექტიურიპასუხისმგებლობით
n გუნდში შეიძლება არ იყოს ფიქსირებულიანალიტიკოსის, დიზაინერის, პროგრამისტის და ა.შ. პოზიციები (თუმცა ტესტერისა შეიძლება იყოს)
n ყველაზე გამოცდილი ორი ადამიანი იქნება უფროსიპროგრამისტი და მისი მოადგილე
![Page 13: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/13.jpg)
SWAT გუნდი
n ევოლუციურ ან იტერაციულ პროცესებში (მაგ. RAD)პროექტზე მუშაობს “გამოცდილი და საუკეთესოხელსაწყოებით აღჭურვილი” გუნდი.
n შეგვიძლია ვთქვათ, რომ ასეთ გუნდებში ორიენტაციამიმართულია როგორც სამუშაოზე, ისეურთიერთობაზე.
n გუნდები მცირერიცხოვანია (4–5 კაცი). კომუნიკაციახანმოკლეა და ნაკლებად ფორმალური.
![Page 14: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/14.jpg)
SWAT გუნდი და კომპეტენცია
n SWAT გუნდის წევრებს ვიწრო სპეციალობასთანერთად ზოგადი ცოდნაც მოეთხოვებათ
n მათი ლიდერი გამორჩეული ფიგურაა. ის მენეჯერთანერთად თანამშრომელიცაა
n გუნდის წევრებს ევალებათ არამარტო სისტემებისაგება არამედ მომხმარებლებთან ურთიერთობაც
n გუნდის მოტივაცია ძალიან მნიშვნელოვანია. ხშირადასეთ გუნდებს რიხიანი სახელები ჰქვიათ, ან ლოგოაქვთ და ა.შ.
![Page 15: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/15.jpg)
Agile გუნდი
n იქიდან გამომდინარე, რომ მარდი (Agile) მეთოდებიიტერაციული მეთოდებისაგან წარმოიშვნენ, Agileგუნდები (შეიძლება ვთქვათ, ჩაუქი გუნდი) გარკვეულწილად წააგავს SWAT გუნდს:q ისინიც ერთ ოთახში სხედანq კომუნიკაცია მოკლეა და არაფორმალური
n პროცესები ნაკლებად იმართება გარედან, აქედანგამომდინარე გუნდს აუცილებლად ესაჭიროებათვითორგანიზება
![Page 16: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/16.jpg)
გათვიცნობიერების დონე
n როგორც წესი, პროექტის მონაწილეებისხვადასხვაგვარად ერკვევიან დეტალებში:q თავისუფალი (დონე 3)
ადამიანებს შეუძლიათ გამოიყენონ სხვადასხვა მიდგომა. დეველოპერებს შეუძლიათ შეცვალონ მეთოდები და მოარგონისინი ახალ გარემოებებს
q მოშორებული (დონე 2)ასეთ ადამიანებს მხოლოდ კონკრეტული მიდგომები ესმითთუმცა შეუძლიათ შეისწავლონ ალტერნატივები
q მიმყოლი (დონე 1)ასეთმა ადამიანებმა მარტო ერთი მიდგომა იციან დასიახლეებს ეჭვით და მტრულად აღიქვამენ
![Page 17: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/17.jpg)
Agile გუნდი და გათვიცნობიერებისდონეებიn წარმატებისათვის აუწილებელია რომ Agile გუნდში
გამოცდილი ადამიანები მუშაობდნენ
n გეგმაზე ორიენტირებულ მიდგომებში გეგმაგარკვეულწილად მაშველი რგოლია. ამიტომშესაძლებელია რომ მე–2 და მე–3 დონის მოთამაშეებიდაგეგმვის ფაზაში ვიყოლიოთ
n Agile გუნდში მხოლოდ მე–3 და მე–2 დონეებიდაიშვება. 1–ლი დონე რისკებს მნიშვნელოვნადზრდის
![Page 18: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/18.jpg)
Open Source გუნდი
n არსებობს შეხედულება იმის თაობაზე რომ Open Source პროექტებზე მომუშავე გუნდი ბაზარსმოგვაგონებს, სადაც ანარქისტი დეველოპერებისმრავალრიცხოვანი ურდოები ერთ, ვირტუალურორგანიზაციად არიან წარმოდგენილი
n წარმატებულ Open Source პროექტებში გუნდს უფროგადაჭრილი ხახვის სტრუქტურა აქვთ
![Page 19: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/19.jpg)
Open Source გუნდი (სქემა)ძირითადი გუნდი
დამხმარე დევლოპერები
აქტიური მომხმარებლები
პასიური მომხმარებლები
![Page 20: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/20.jpg)
Open Source გუნდის წევრები
n Open Source პროექტებში მერიტოკრატიაა. ძირითადიგუნდი 5–15 წევრისაგან შედგება, რომელთაგანნაწილი შეიძლება სხვა ფენებიდან აღზევდნენ
n ნებაყოფლობითი მონაწილეობა გულისხმობსსხვადასხვა გამოწვევებს:q წევრების მოტივაციას რომ განაგრძონ აქტიურობაq უთანხმოებას დეველოპერებს შორისq კომუნიკაციას დეველოეპრებს შორის
![Page 21: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/21.jpg)
ლიტერატურა
Software Engineering: Principles and Practiceავტორი: Hans van Vlietგამომცემლობა: John Wiley & Sonsგამოცემულია: June 30, 2008ISBN: 978-0-470-03146-9Web ISBN: 0-47-003146-8
![Page 22: [08] პროგრამული უზრუნველყოფის ინჟინერია – გუნდის ორგანიზება](https://reader030.vdocuments.net/reader030/viewer/2022013115/55720c80497959fc0b8c43c4/html5/thumbnails/22.jpg)
გმადლობთყურადღებისათვის!
მომავალ შეხვედრამდე!