[08] პროგრამული უზრუნველყოფის...

გუნდის ორგანიზება

პროგრამული უზრუნველყოფისინჟინერია, ლექცია 8

მიხეილ კაპანაძე

პასუხისმგებლობათა გამიჯვნა

n პროექტზე მომუშავე გუნდში ხალხს სხვადასხვა როლიდა პასუხისმგებლობა აქვს. მენეჯერები, ტესტერები, დიზაინერები, პროგრამისტები და ა.შ.

n ზოგჯერ ერთიდაიგივე ადამიანმა შეიძლებარამდენიმე როლი იტვირთოს

n თუმცა ხანდახან ეს მიუღებელია. ის, ვინც პროგრამასწერს, არ შეიძლება იყოს ტესტერიც (და პირიქით)

გუნდების ორგანიზება

n დიდი გუნდი შეიძლება დანაწილდეს, მართვისგაადვილების მიზნით.

n თუკი ამ მცირე გუნდებს ნათლად ექნებათ დასახულიამოცანა, კომუნიკაცია ძირითადად მათ შიგნით იქნებამოქცეული

n პერსონალს შორის კომუნიკაციის ღირებულებისშეფასებამ შეიძლება მოგვცეს წარმოდგენა გუნდისზომისა და პროდუქტიულობის თანაფარდობაზე

იერარქიული ორგანიზაცია

n იერარქიული ორგანიზაცია ხშირად გვხვდება ისეთკომპანიებში, რომლებიც პროგრამულიუზრუნველყოფის შექმნით არიან დაკავებული

n ხშირად იერარქია იმეორებს იმ სისტემისსტრუქტურას, რომლის აგებაც ხდება.

n თუ სისტემას 3 ძირითადი ქვესისტემა აქვს, შესაძლოათითოეულზე ცალკე გუნდი მუშაობდეს, მათ ცალკემენეჯერები აკონტროლებდნენ, სათავეში კიხდებოდეს საერთო კოორდინაცია

იერარქიული ორგანიზაცია –გაგრძელებაn გარდა ქვესისტემებზე მომუშავე ჯგუფებისა, ასევე

შეიძლება არსებობდეს ცალკე ფუნქციონალურიგანყოფილებები. მაგალითად – ტესტირების.

n იერარქიულ ორგანიზებას როგორც წესი თან ახლავსსხვადასხვაგვარი რისკებიq სხვადასხვა გუნდების მართვის სტილი შეიძლება

განსხვავდებოდესq ინფორმაცია, რომელიც ქვემოდან ზემოთ მიდის, შეიძლება

შელამაზდეს

კარიერული ზრდ იერარქიულორგანიზაციაშიn იერარქიულ ორგანიზაციებში თანამდებობა

განსაზღვრავს სტატუსს და ფინანსურ მდგომარეობას

n აქედან გამომდინარე, ყველა ზემოთ მიისწრაფის

n პეტერის პრინციპი (Peter Principle) :“იერარქიაში ყველა თანამშრომელი მიისწრაფვის რომგაიზარდოს საკუთარი არაკომპეტენტურობისდონემდე”

მატრიცული ორგანიზაცია

n მატრიცულ ორგანიზაციაში ადამიანები სხვადასხვაგანყოფილებებიდან ერთვებიან პროგრამულიუზრუნველყოფის შემუშავებაში. ხშირად – არასრულიდატვირთვით.

n ასეთ ორგანიზაციაში ადამიანი ხშირად ექვემდებარებარამდენიმე ხელმძღვანელს ერთდროულად დაშესაძლოა სცადოს ამ სიტუაციით მანიპულირება.

მატრიცული ორგანიზაცია –გაგრძელებაn შესაძლებელია არსებობდეს რამდენიმე ქვეყანაყოფი

ერთიდაიგივე სპეციალიზაციით: ინტერფეისი, მონაცემთა ბაზები, ხარისხის კონტროლი და ა.შ.

n პროექტი საჭიროებს სხვადასხვა კომპეტენციებს

n შესაბამისად, ადამიანები 2 ღერძის მიხედვით არიანგანლაგებული: ერთი მხრივ ქვეგანაყოფებში(სპეციალიზაციის მიხედვით), მეორე მხრივ –პროექტებში.

მენეჯერები მატრიცულიორგანიზებისასn როგორც აღინიშნა, მომხმარებლები ექვემდებარებიან

რამდენიმე მენეჯერს

n პროექტ მენეჯერი პასუხისმგებელია პროექტისწარმატებულ დასრულებაზე. განყოფილების მენეჯერსკი გრძელვადიანი ამოცანები აქვს. მაგალითად, გუნდის პროფესიონალიზმის ამაღლება

n შეიძლება ითქვას რომ პროექტ მენეჯერი სამუშაოზემიმართულ სტილს უნდა მისდევდეს. განყოფილებისმენეჯერი კი – ურთიერთობაზე მიმართულს

უფროსი პროგრამისტის გუნდი

n ასეთ გუნდის ბირთვს 3 ძირითადი თანამშრომელიწარმოადგენს:q უფროსი პროგრამისტი – გუნდის ლიდერი, რომელიც თავის

თავზე იღებს სისტემის საკვანძო ნაწილების დიზაინს დაგადაწყვეტას

q უფროსი პროგრამისტის ასისტენტი – მას შეუძლია შეცვალოსუფროსი პროგრამისტი, თუ ეს საჭირო გახდება

q ბიბლიოთეკარი – თავის თავზე იღებს ადმინისტრაციულსაქმეებს და დოკუმენტაციას

n გარდა ამისა, შეიძლება გუნდში მცირე რაოდენობისექსპერტების დამატება

უფროსი პროგრამისტი

n უფროსი პროგრამისტი აუცილებლად უნდა იყოსკომპეტენტური ტექნიკურ სფეროში

n მას ასევე უნდა გააჩნდეს საკმარისი მენეჯერულიუნარები

n ასეთი ადამიანები, რომლებიც ამავდროულადშეიძლება ქარიზმატული ლიდერები იყონ, როგორცწესი იშვიათია.

უფროსი პროგრამისტის გუნდისმოდიფიცირებული ვარიანტიn ნაცვლად კლასიკური “ელიტარული” უფროსი

პროგრამისტის გუნდისა, შეიძლება ავიღოთმცირერიცხოვანი გუნდი, ამოცანაზე კოლექტიურიპასუხისმგებლობით

n გუნდში შეიძლება არ იყოს ფიქსირებულიანალიტიკოსის, დიზაინერის, პროგრამისტის და ა.შ. პოზიციები (თუმცა ტესტერისა შეიძლება იყოს)

n ყველაზე გამოცდილი ორი ადამიანი იქნება უფროსიპროგრამისტი და მისი მოადგილე

SWAT გუნდი

n ევოლუციურ ან იტერაციულ პროცესებში (მაგ. RAD)პროექტზე მუშაობს “გამოცდილი და საუკეთესოხელსაწყოებით აღჭურვილი” გუნდი.

n შეგვიძლია ვთქვათ, რომ ასეთ გუნდებში ორიენტაციამიმართულია როგორც სამუშაოზე, ისეურთიერთობაზე.

n გუნდები მცირერიცხოვანია (4–5 კაცი). კომუნიკაციახანმოკლეა და ნაკლებად ფორმალური.

SWAT გუნდი და კომპეტენცია

n SWAT გუნდის წევრებს ვიწრო სპეციალობასთანერთად ზოგადი ცოდნაც მოეთხოვებათ

n მათი ლიდერი გამორჩეული ფიგურაა. ის მენეჯერთანერთად თანამშრომელიცაა

n გუნდის წევრებს ევალებათ არამარტო სისტემებისაგება არამედ მომხმარებლებთან ურთიერთობაც

n გუნდის მოტივაცია ძალიან მნიშვნელოვანია. ხშირადასეთ გუნდებს რიხიანი სახელები ჰქვიათ, ან ლოგოაქვთ და ა.შ.

Agile გუნდი

n იქიდან გამომდინარე, რომ მარდი (Agile) მეთოდებიიტერაციული მეთოდებისაგან წარმოიშვნენ, Agileგუნდები (შეიძლება ვთქვათ, ჩაუქი გუნდი) გარკვეულწილად წააგავს SWAT გუნდს:q ისინიც ერთ ოთახში სხედანq კომუნიკაცია მოკლეა და არაფორმალური

n პროცესები ნაკლებად იმართება გარედან, აქედანგამომდინარე გუნდს აუცილებლად ესაჭიროებათვითორგანიზება

გათვიცნობიერების დონე

n როგორც წესი, პროექტის მონაწილეებისხვადასხვაგვარად ერკვევიან დეტალებში:q თავისუფალი (დონე 3)

ადამიანებს შეუძლიათ გამოიყენონ სხვადასხვა მიდგომა. დეველოპერებს შეუძლიათ შეცვალონ მეთოდები და მოარგონისინი ახალ გარემოებებს

q მოშორებული (დონე 2)ასეთ ადამიანებს მხოლოდ კონკრეტული მიდგომები ესმითთუმცა შეუძლიათ შეისწავლონ ალტერნატივები

q მიმყოლი (დონე 1)ასეთმა ადამიანებმა მარტო ერთი მიდგომა იციან დასიახლეებს ეჭვით და მტრულად აღიქვამენ

Agile გუნდი და გათვიცნობიერებისდონეებიn წარმატებისათვის აუწილებელია რომ Agile გუნდში

გამოცდილი ადამიანები მუშაობდნენ

n გეგმაზე ორიენტირებულ მიდგომებში გეგმაგარკვეულწილად მაშველი რგოლია. ამიტომშესაძლებელია რომ მე–2 და მე–3 დონის მოთამაშეებიდაგეგმვის ფაზაში ვიყოლიოთ

n Agile გუნდში მხოლოდ მე–3 და მე–2 დონეებიდაიშვება. 1–ლი დონე რისკებს მნიშვნელოვნადზრდის

Open Source გუნდი

n არსებობს შეხედულება იმის თაობაზე რომ Open Source პროექტებზე მომუშავე გუნდი ბაზარსმოგვაგონებს, სადაც ანარქისტი დეველოპერებისმრავალრიცხოვანი ურდოები ერთ, ვირტუალურორგანიზაციად არიან წარმოდგენილი

n წარმატებულ Open Source პროექტებში გუნდს უფროგადაჭრილი ხახვის სტრუქტურა აქვთ

Open Source გუნდი (სქემა)ძირითადი გუნდი

დამხმარე დევლოპერები

აქტიური მომხმარებლები

პასიური მომხმარებლები

Open Source გუნდის წევრები

n Open Source პროექტებში მერიტოკრატიაა. ძირითადიგუნდი 5–15 წევრისაგან შედგება, რომელთაგანნაწილი შეიძლება სხვა ფენებიდან აღზევდნენ

n ნებაყოფლობითი მონაწილეობა გულისხმობსსხვადასხვა გამოწვევებს:q წევრების მოტივაციას რომ განაგრძონ აქტიურობაq უთანხმოებას დეველოპერებს შორისq კომუნიკაციას დეველოეპრებს შორის

ლიტერატურა

Software Engineering: Principles and Practiceავტორი: Hans van Vlietგამომცემლობა: John Wiley & Sonsგამოცემულია: June 30, 2008ISBN: 978-0-470-03146-9Web ISBN: 0-47-003146-8

გმადლობთყურადღებისათვის!

მომავალ შეხვედრამდე!