განსაზღვრული გიდი SCRUM-ისთვის: თამაშის წესები
ჩამოყალიბებული და მხარდაჭერილია:KEN SCHWABER-ის და Jeff Sutherland-ის მიერ
- Scrum-ის სახელმძღვანელოს დანიშნულება
- Scrum-ის განსაზღვრება
- SCRUM-ის გამოყენება
- SCRUM-ის თეორია
- SCRUM-ის ღირებულებები
- SCRUM-ის გუნდი
- პროდუქტის მფლობელი
- დეველოპერების გუნდი
- SCRUM-ის ოსტატი
- SCRUM-ის ღონისძიებები
- სპრინტის დაგეგმვა
- დღიური SCRUM-ი
- სპრინტის განხილვა
- სპრინტის რეტროსპექტივა
- SCRUM-ის არტეფაქტები
- პროდუქტის ბექლოგი
- სპრინტის ბექლოგი
- ინკრემენტი
- არტეფაქტების გამჭვრირვალეობა
- „გაკეთებულია“-ს განსაზღვრება
Scrum-ის სახელმძღვანელოს დანიშნულება
Scrum-ი არის ფრეიმვორკი რომლის დანიშნულებაა კომპლექსური პროდუქტების დეველოპმენტი, ჩაბარება და შენარჩუნება. ეს სახელმძღვანელო შეიცავს scrum-ის განსაზღვრებას. ეს განსაზღვრება შედგება SCRUM-ის როლების, ღონისძიებების, არტეფაქტებისა და წესებისგან რომელიც კრავს ამ ყველაფერს ერთად. Ken Schwaber და Jeff Sutherland-მა შექმნეს Scrum-ი; Scrum-ის სახელმძღვანელო დაწერილია და წარმოდგენილია მათ მიერ. ერთად ისინი დგანან Scrum-ის სახელმძღვანელოს უკან.
Scrum-ის განსაზღვრება
Scrum-ი(n): ფრეიმვორკი რომლის შიგნითაც ადამიანებს შეუძლიათ შეეჭიდონ კომპლექსურ ადაპტირებად პრობლემებს, რომლის დროსაც კრეატიულად ჩააბარებენ პროდუქტებს, მაქსიმალური შესაძლებელი ღირებულებით.
Scrum-ი არის:
- მსუბუქი
- მარტივად გასაგები
- რთულად დასაოსტატებელი
Scrum-ი არის პროცესის ფრეიმვორკი რომელიც გამოიყენება კომპლექსური პროდუქტებზე სამუშაოს მართვისთვის 1990-ი წლიდან მოყოლებული. Scrum-ი არ არის პროცესი, ტექნიკა ან განსაზღვრული მეთოდი. ის უფრო ფრეიმვორკია რომლის შიგნითაც თქვენ შეგიძლიათ გამოიყენოთ სხვადასხვა პროცესები და ტექნიკები. Scrum-ი უზრუნველყოფს გამჭვირვალეობას თქვენი პროდუქტის მენეჯმენტის ფარდობითი ეფექტიანობისა და სამუშაოს ტექნიკებისა, ისე რომ თქვენ შეგიძლიათ განგრძობითად გააუმჯობესოთ პროდუქტი , გუნდი და სამუშაო გარემო.
Scrum-ის ფრეიმვორკი შედგება Scrum-ის გუნდისგან და მასთან ასოცირებული როლებისგან, ღონისძიებებისგან , არტეფაქტებისგან და წესებისგან. ყოველი კომპონენტი ფრეიმვორკის შიგნით, ემსახურება სპეცოფიურ დანიშნულებას და არის არსებითი Scrum-ის გამოყენებისა და წარმატებისთვის.
Scrum-ის წესები აკავშირებს როლებს, ღონისძიებებს და არტიფაქტებს, ხელმძღვანელობას უწევს მათ შორის კავშირს და ინტერაქციას. SCRUM-ის წესები არის აღწერილი ამ დოკუმენტის შიგთავსში.
Scrum-ის ფრეიმვორკის გამოყენების სპეციფიური ტაქტიკები ცვალებადია და აღწერილია სხვა ადგილას.
SCRUM_ის გამოყენება
Scrum თავდაპირველად განვითარდა პროდუქტების მართვის და განვითარებისთვის. 1990 წლიდან მოყოლებული Scrum-ი გამოიყენება მსოფლიოს მასშტაბით, რომ:
- გამოიკვლიოს და განსაზღვროს სისოცხლისუნარიანი ბაზრები, ტექნოლოგიები და პროდუქტის შესაძლებლობები.
- განავითაროს პროდუქტები და გაუმჯობესებები.
- გამოუშვას პროდუქტები და გაუმჯობესებები, ისე ხშირად როგორც რამოდენიმეჯერ დღის განმავლობაში.
- განავითაროს და მხარი დაუჭიროს ქლაუდ (ონლაინ, დაცულ, მოთხოვნისამებრ) და სხვა ოპერაციულ გარემოს პროდუქტის გამოყენებისთვის და
- მხარი დაუჭიროს და განაახლოს პროდუქტები
Scrum-ი გამოიყენება შემდეგი ჩამონათვალის განვითარებისთვის: პროგრამული უზრუნველყოფის, აპარატურის, ჩაშენებული პროგრამული უზრუნველყოფის, ქსელების და დაკავშირებული ფუნქციების, ავტონომიური მანქანების, სკოლების, სახელმწიფო სტრუქტურების, მარკეტინგის, ორგანიზაციის ოპერაციების მართვისთვის და თითქმის ყველაფრისთვის რასაც ჩვენ ვიყენებთ ყოველდღიურ ცხოვრებაში, როგორც ინდივიდები და საზოგადოებები.
რაც ტექნოლოგია, ბაზარი და ეკოლოგიური სირთულეები და მათი ურთიერთქმედება მნიშვნელოვნად გაიზარდა, SCRUM-ის სარგებლობა კომპლექსურობასთან ბრძოლაში ყოველდღე მტკიცდება.
Scrum- ი განსაკუთრებით ეფექტური აღმოჩნდა იტერაციული და მზარდი ცოდნის ტრანსფერისთვის. Scrum-ი დღეს ფართოდ გამოიყენება პროდუქტების, სერვისების და მშობელი ორგანიზაციის მენეჯმენტში.
Scrum-ის არსი არის ადამიანების მცირე გუნდში. ინდივიდუალური გუნდი არის ძალზედ მოქნილი და ადაპტირებადი. ეს სიძლიერეები აგრძელებენ არსებობას ინდივიდუალური, რამოდენიმე, ბევრი და ქსელური გუნდებისთვის, რომლებიც ავითარებენ, უშვებენ, ოპერირებენ და მხარს უჭერენ მუშაობას და მუშა პროდუქტებს ათასობით ადამიანისთვის. ისინი ურთიერთქმედებენ და თანამშრომლობენ განხორციელების რთული არქიტექტურის პირობებში და განსაზღვრულია გამომშვები(რელიზური) გარემოსთვის.
როდესაც გამოყენებულია სიტყვები „განვითარება“ და „შექმნა“ Scrum-ის სახელმძღვანელოში, ისინი ეხება კომპლექსურ სამუშაოებს, ისეთს როგორც ზემოთ ჩამოთვლილი სახეები.
Scrum-ის თეორია
Scrum-ი დაფუძნებულია ემპირიული პროცესის კონტროლის თეორიაზე, ან ემპირიციზმზე. ემპირიციზმი ამტკიცებს რომ ცოდნა მოდის გამოცდილებიდან და გადაწყვეტილებები მიიღება იმაზე დაყრდნობით რაც ვიცით. Scrum მუშაობს იტერაციულ, ინკრემენტულ მიდგომაზე რომ მოახდინოს პროგნოზირებადობის ოპტიმიზირება და აკონტროლოს რისკები.
სამი სვეტი ემპირიული პროცესის ყველა იმპლემენტაციას უზრუნველყოფს, ესენია:
- გამჭვირვალეობა
- შემოწმება(ინსპექტირება) და
- ადაპტაცია.
გამჭვირვალეობა
პროცესის მნიშვნელოვანი ასპექტები უნდა იყოს ნათელი(ჩვენებადი) იმათთვის ვინც შედეგზეა პასუხისგებელი. გამჭვირვალეობა მოითხოვს ამ ასპექტების განსაზღვრას ერთიანი სტანდარტით და ამ სახით დამკვირვებლები იზიარებენ საერთო გაგებას იმისა თუ რასაც ხედავენ.
მაგალითად :
- საერთო ენა, რომელიც დაკავშირებულია პროცესთან უნდა იყოს გაზიარებული ყველა მონაწილის მიერ; და
- განმახორციელებლები და ინკრემენტის შემმოწმებლები უნდა იზიარებდნენ საერთო განსაზღვრებას სიტყვის „დასრულებულია“
შემოწმება
SCRUM-ის მომხმარებლები ხშირად უნდა ამოწმებდნენ SCRUM_ის არტეფაქტებს და პროგრესს სპრინტის მიზანთან მიმართებაში, რათა დაადგინონ არასასურველი გადახრები. მათი ინსპექტირება არ უნდა იყოს ისეთი ხშირი რომ ინსპექტირებამ ხელი შეუშალოს მუშაობას. ინსპექტირებები არის ყველაზე მარგებელი როცა გულდასმით არის შესრულებული გამოცდილი ინსპექტორების მიერ სამუშაო ადგილზე.
ადაპტაცია
თუ ინსპექტორი აღმოაჩენს რომ ერთი ან მეტი ასპექტები პროცესისა გადაცდენილია დაშვებულ ლიმიტებს, და რეზულტატში პროდუქტი არ იქნება მისაღები, პროცესი ან მატერიალი რომელიც გატარებულია პროცესში საჭიროებს დაზუსტებას. დაზუსტება უნდა განხორციელდეს რაც შეიძლება სწრაფად რომ მინიმიზება მოახდინოს მომავალი გადაცდენის.
SCRUM-ი აღწერს ოთხ ფორმალურ ღონისძიებას ინსპექტირბისა და ადაპტაციისა, როგორც აღწერიალია SCRUM-ის ღონისძიებების სექციაში ამ დოკუმენტში:
- სპრინდის დაგეგმვა
- დღური SCRUM
- სპრინტის განხილვა
- სპრინტის რეტროსპექტივა
SCRUM-ი ღირებულებები
როცა ისეთი ღირებულებები როგორიცაა ვალდებულება(პასუხისმგებლობა), გამბედაობა, ფოკუსირება, გახსნილობა და პატივისცემა არის შესისხლხორცებული და SCRUM-ის გუნდის მიერ მხარდაჭერილია, SCRUM-ის სვეტები, როგორიცაა : გამჭვირვალეობა, ინსპექცია და ადაპტაცია ცოცხლობს და აშენებს ნდობას ყველასთვის. SCRUM_ის გუნდის წევრები სწავლობენ და აღმოაჩენენ ამ ღირებულებებს მაშინ როცა ისინი იმუშავებენ SCRUM_ის როლებში, ღონისძიებებში და არტიფაქტებში.
SCRUM-ის წარმატებული გამოყენება დამოკიდებულია იმაზე, რომ ადამიანები გახდებიან უფრო გამოცდილები ამ ხუთი ფასეულობებით ცხოვრებით. ადამიანები პირადად იღებენ მონაწილეობას SCRUM ის გუნდის მიზნების მიღწევაში. SCRUM-ის გუნდის წევრებს აქვთ გამბედაობა რომ აკეთონ სწორად საქმეები და იმუშაონ რთულ პრობლემებზე. ყველა ფოკუსირდება სპრინტის სამუშაოზე და SCRUM-ის გუნდის მიზნებზე. SCRUM_ის გუნდი და მისი მეწილეები თანხმდებიან რომ იქნებიან გახსნილები ყველა სახის სამუშაოზე და სამუშაოს შესრულების გამოწვევებზე. SCRUM_ის გუნდის წევრები აფასებენ ერთმანეთს როგორც უნარიან, საქმის გამკეთებელ, დამოუკიდებელ ადამიანებს.
SCRUM_ის გუნდი
SCRUM_ის გუნდი შედგება პროდუქტის მფლობელისგან, დეველოპერების გუნდისგან და SCRUM_ის ოსტატისგან. SCRUM-ის გუნდი არის თვითორგანიზებადი და კროს-ფუნქციური. თვითორგანიზებადი გუნდები ირჩევენ თუ როგორ შეასრულონ საუკეთესო გზით საკუთარი სამუშაო, ვიდრე გუნდის გარედან სხვების მხრიდან მიიღონ დირექტივები. კროს-ფუნქციურ გუნდებს აქვთ ყველა კომპეტენციები რაც საჭიროა რომ შეასრულონ საქმე, და არ იყვნენ დამოკიდებულები ისეთ ადამიანებზე რომლებიც გუნდის წევრები არ არიან. გუნდის მოდელი SCRUM_ში განკუთვნილია იმისათვის რომ ოპტიმიზირება მოახდინონ მოქნილობის, კრეატიულობის და პროდუქტიულობის. SCRUM_ის გუნდმა თავის მხრივ დაამტკიცა რომ განვითარებადად ეფექტურები ყველა ადრეული განსაზღვრული გამოყენებისთვის და ნებისმიერი კომპლექსური სამუშაოსთვის.
SCRUM-ის გუნდი აბარებს პროდუქტებს იტერაციულად და ინკრემენტალურად, მაქსიმიზირებას უკეთებს რა შესაძლებლობებს შეფასებისთვის. ინკრემენტალური ჩაბარებები „დასრულებული“ პროდუქტებისა უზრუნველყოფს იმას, რომ პოტენციურად გამოყენებად ვერსია მუშა პროდუქტისა არის ყოველთვის ხელმისაწვდომი.
პროდუქტის მფლობელი
პროდუქტის მფლობელი არის პასუხისმგებელი პროდუქტის ღირებულების მაქსიმიზირებაზე დეველოპერების გუნდის მხრიდან შესრულებულ სამუშაოზე. როგორ შეიძლება ეს იყოს მიღწეული ფართოდ ვარირებს ორგანიზაციების, SCRUM გუნდების და ინდივიდების მიხედვით.
პროდუქტის მფლობელი არის პირი რომელიც პასუხისმგებელია პროდუქტის ბექლოგის მართვაზე. პროდუქტის ბექლოგის მართვა შეიცავს:
- ნათლად გამოხატოს პროდუქტის ბექლოგის ელემენტები.
- ალაგებს ელემენტებს პროდუქტის ბექლოგში რომ საუკეთესოდ მიაღწიოს მიზნებს და მისიას.
- ოპტიმიზებას უკეთებს დეველოპერების გუნდის მიერ შესრულებული სამუშაოს ღირებულებას.
- უზრუნველყოფს რომ პროდუქტის ბექლოგი ჩანდეს, იყოს გამჭვირვალე და გასაგები ყველასთვის, და აჩვენებს რაზეც იმუშავებს SCRUM_ის გუნდი შემდეგში და
- უზრუნველყოფს რომ დეველოპერების გუნდმა გაიგოს ელემენტები პროდუქტის ბექლოგში იმ დონეზე რაც საჭიროა.
პროდუქტის მფლობელს შეუძლია შეასრულოს ზემოთხსენებული სამუშაო, ან ჰყავს დეველოპერების გუნდი ამისათვის. ერთი სიტყვით პროდუქტის მფლობელი რჩება ანგარიშვალდებული.
პროდუქტის მფლობელი არის ერთი ადამიანი, არა კომიტეტი. პროდუქტის მფლობელს შეუძლია წარმოადგინოს კომიტეტის სურვილები პროდუქტის ბექლოგში, მაგრამ მათ თუ უნდათ რომ შეცვალონ პროდუქტის ბექლოგის ელემენტების პრიორიტეტი, მათ უნდა მიმართონ პროდუქტის მფლობელს.
იმისათვის რომ პროდუქტის მფლობელი იყოს წარმატებული, მთელი ორგანიზაცია უნდა აფასებდეს მის გადაწყვეტილებებს. პროდუქტის მფლობელის გადაწყვეტილებები ჩანს კონტენტში და პროდუქტის ბექლოგის დალაგებაში. არავის შეუძლია ძალა დაატანოს დეველოპერების გუნდს რომ იმუშაოს მოთხოვნების სხვა წყებაზე.
დეველოპერების გუნდი
დეველოპერების გუნდი შედგება პროფესიონალებისგან, რომლებიც მუშაობენ სამუშაოზე, კერძოდ პროდუქტის პოტენციურად გაშვებად „დასრულებულ“ ინკრემენტზე ყოველი სპრინტის ბოლოს. ინკრემენტი „დასრულებულია“ არის მოთხოვნილი სპრინტის განხილვისას. მხოლოდ დეველოპერების გუნდის წევრები ქმნიან ამ ინკრემენტს.
დეველოპერების გუნდი არის სტრუქტურიებული და უფლებამოსული ორგანიზაციის მხრიდან რომ ორგანიზება და მართვა გაუწიოს საკუთარ სამუშაოს. რეზულტატში დამდგარი სინერგია დეველოპერების გუნდის საერთო ეფექტიანობის და ეფექტურობის ოპტიმიზებას ახდენს.
დეველოპერების გუნდს აქვს შემდეგი თვისებები:
- ისინი არიან თვით ორგანიზებადი. არავინ (თავად SCRUM-ის ოსტატიც კი) ეუბნება დეველოპერების გუნდს თუ როგორ უნდა გადააქციონ პროდუქტის ბექლოგი პოტენციურად გაშვებადი ფუნციონალის ინკრემენტად.
- დეველოპერების გუნდი არის კროს-ფუნქციური, ყველა საჭირო უნარებით აღჭურვილი რაც გუნდს სჭირდება იმისათვის რომ შექმნას პროდუქტის ინკრემენტი.
- SCRUM-ში არ შეიმჩნევა რაიმე ტიპის სახელწოდებები დეველოპერები გუნდის წევრებისთვის, მიუხედავად სამუშაოსი, რომელსაც პიროვნებები ასრულებენ.
- SCRUM-ში არ შეიმჩნევა ქვე გუნდები დეველოპერების გუნდის შიგნით, მიუხედავად ისეთი სახელწოდების სამუშაოებისა როგორიცაა ტესტირება, არქიტექტურა, ოპერაციები ან ბიზნეს ანალიზი და
- ინდივიდუალური დეველოპერების გუნდის წევრებს შეუძლიათ იყვნენ სპეციალიზებული უნარების მქონე და ფოკუსირებული რაიმე კონკრეტულზე, მაგრამ პასუხისმგებლობა მთლიანად დეველოპერების გუნდს ეკისრება როგორც მთლიანს.
დეველოპერების გუნდის ზომა
დეველოპერების გუნდის ოპტიმალური ზომა საკმარისად პატარაა იმისათვის, რომ იყოს მოხერხებული და საკმარისად დიდი იმისათვის რომ დაასრულოს მნიშვნელოვანი საქმე სპრინტის ფარგლებში. 3-ზე ნაკლები ზომე დეველოპერების გუნდში ამცირებს ინტერაქციას და რეზულტატში პატარა პროდუქტიულობას აღწევს. პატარა დეველოპერების გუნდები შეიძლება დაეჯახონ უნარების სიმცირეს სპრინტის დროს, რაც შედეგში გამოიწვევს იმას რომ დეველოპერების გუნდი იქნება უუნარო რომ ჩააბაროს პოტენციურად გასაშვები ინკრემენტი. 9-ზე მეტი ადამიანი საჭიროებს ძალიან ბევრ კოორდინაციას. დიდი დეველოპერების გუნდი აგენერირებს ძალიან ბევრ კომპლექსურობას ემპირიული პროცესის სარგებლიანობისთვის. პროდუქტის მფლობელი და SCRUM_ის ოსტატის როლები არ გაითვალისწინება ამ რიცხვში , თუ ისინი ასევე არ ასრულებენ სამუშაოს სპრინტის ბექლოგიდან.
SCRUM-ის ოსტატი
SCRUM-ის ოსტატი არის პასუხისმგებელი რომ ხელი შეუწყოს და დაეხმაროს SCRUM-ს როგორც აღწერიალია SCRUM-ის სახელმძღვანელოში. SCRUM_ის ოსტატები აკეთებენ ამას, ეხმარებიან რა ყველას რომ გაიგონ SCRUM_ის თეორია, პრაქტიკები, წესები და ღირებულებები.
SCRUM_ის ოსტატი არის მომსახურე-ლიდერი scrum_ის გუნდისთვის. SCRUM-ის ოსტატი ეხმარება SCRUM_ის გუნდის გარეთ მყოფებს რომ გაიგონ, თუ რა ტიპის ინტერაქციები იქნება სასარგებლო SCRUM_ის გუნდთან და რომელი არა. SCRUM_ის ოსტატი ეხმარება ყველას რომ შეცვალონ ეს ინტერაქციები იმისათვის რომ მაქსიმიზირება გაუკეთოს ღირებულება რომელიც შექმნილია SCRUM_ის გუნდის მიერ.
SCRUM-ის ოსტატის მომსახურება პროდუქტის მფლობელისთვის
SCRUM-ის ოსტატი ემსახურება პროდუქტის მფლობელს რამოდენიმე გზით, მათ შორის:
- უზრუნველყოს რომ მიზნები, ზომა და პროდუქტის დომენი მაქსიმალური შესაძლო გზით არის გაგებული ყველას მიერ SCRUM_ის გუნდში.
- იპოვოს ტექნიკები პროდუქტის ბექლოგის ეფექტური მენეჯმენტისთვის
- დაეხმაროს SCRUM_ის გუნდს რომ გაიგოს პროდუქტის ბექლოგის ელემენტებს ნათლად და მოკლედ წადმოდგენის საჭიროება.
- გაიგოს პროდუქტის დაგეგმვა ემპირიულ გარემოში.
- უზრუნველყოს რომ პროდუქტის მფლობელმა იცის როგორ დაალაგოს პროდუქტის ბექლოგი, მაქსიმალური ღირებულების მისაღწევად.
- გაიგოს და გამოსცადოს მოქნილობა და
- ხელი შეუწყოს SCRUM-ის ღონისძიებებს ჩატარებას როგორც მოითხოვება და საჭიროა.
SCRUM-ის ოსტატის სამსახური დეველოპერების გუნდის მიმართ
SCRUM-ის ოსტატი ემსახურება დეველოპერების გუნდს რამოდენიმე გზით, მათ შორის:
- წვრთნის დეველოპერების გუნდს თვით-ორგანიზებაში და კროს ფუნქციონალურობაში
- ეხმარება დეველოპერების გუნდს რომ შექმნას მაღალი ღირებულების პროდუქტები
- აშორებს ხელის შემშლელ ფაქტორებს დეველოპერების გუნდის პროგრესის გზაზე
- ამარტივებს SCRUM-ის ღონისძიებებს მოთხოვნის და საჭიროების შემთხვევაში; და
- წვრთნის დეველოპერების გუნდს ორგანიზაციულ გარემოში რომელშიც SCRUM-ი ჯერ არ არის ბოლომდე გააზრებული და შეთვისებული
SCRUM_ის ოსტატის მომსახურება ორგანიზაციის მიმართ
SCRUM_ის ოსტატი ემსახურება ორგანიზაციას რამოდენიმე გზით, მათ შორის:
- უძღვება და წვრთნის ორგანიზაციას SCRUM_ის შეთვისების კუთხით
- გეგმავს SCRUM-ის იმპლემენტაციებს ორგანიზაციის შიგნით.
- ეხმარება დაქირავებულებს და მეწილეებს გაიგონ და აამოგმედონ SCRUM_ი და პროდუქტის განვითარების ემპირიულობა.
- იწვევს ცვლილებას, რაც ზრდის SCRUM_ის გუნდის პროდუქტიულობას; და
- მუშაობს სხვა SCRUM_ის ოსტატებთან რომ გაზარდოს SCRUM_ის გამოყენების ეფექტურობა ორგანიზაციის შიგნით.
SCRUM_ის ღონისძიებები
განსაზღვრული ღონისძიებები არის გამოყენებული SCRUM_ში რომ უზრუნველყოს რეგულარულობა და მინიმიზირება მოახდინოს შეხვედრებისა, რომელიც არ არის აღწერილი SCRUM_ში. ყველა ღონისძიება არის დროში შეზღუდული ღონისძიება, ისე რომ ყოველ ღონისძიებას გააჩნია ხანგრძლივობის მაქსიმუმი. მას შემდეგ რაც სპრინტი დაიწყება, მისი ხანგრძლივობა არის ფიქსირებული და არ შეიძლება შემოკლდეს ან შეიცვალოს ზომაში. დარჩენილი ღონისძიებები შეიძლება დამთავრდეს მას შემდეგ რაც ღონისძიების მიზანი მიღწეული იქნება, იმის უზრუნველსაყობად რომ საჭირო დრო არის დახარჯული, და დროის ტყუილი ხარჯვას არ ჰქონდეს ადგილი.
გარდა თავად სპრინტისა, რომელიც არის ყველა ღონისძიების კონტეინერი, ყველა ივენთი SCRUM_ში არის ფორმალური შესაძლებლობა რომ ინსპექტირება და ადაპტირება მოხდეს რამისა. ეს ღონისძიებები არის სპეციფიურად შექმნილი იმისათვის, რომ შესაძლებელი გახადოს კრიტიკული გამჭვირვალეობა და ინსპექცია. რომელიმე ამ ღონისძიების განუხორციელებლობა გამოიწვევს გამჭვირვალეობის შემცირებას და არის დაკარგული შესაძლებლობა ინსპექტირებისა და ადაპტაციისთვის.
სპრინტი
SCRUM_ის გული არის სპრინტი, დროში ზემოდან შეზღუდული ერთი თვით ან ნაკლებით, რომლის ფარგლებშიც „დასრულებული“, გამოყენებადი და პოტენციურად გაშვებადი პროდუქტის ინკრემენტი იქმნება. სპრინტებს აქვთ მყარი ხანგრძლივობა განვითარების პროცესში. ახალი სპრინტი იწყება ეგრევე, რაც მოხდება წინა სპრინტზე დასკვნის გამოტანა.
სპრინტი შეიცავს და შედგება სპრინტის დაგეგმვისგან, დღიური SCRUM-ისგან, დეველოპმენტის სამუშაოსგან, სპრინტის განხილვისგან და სპრინტის რეტროსპექტივისგან.
სპრინტის დროს:
- არანაირი ცვლილებები არ უნდა განხორციელდეს რაც შეიძლება საფრთხის შემცველი იყოს სპრინტის მიზნისთვის
- ხარისხის მიზნები არ მცირდება ; და
- შეიძლება დაზუსტდეს და გადახედილ იქნეს მოცულობა პროდუქტის მფლობელის და დეველოპერების გუნდის მიერ, ვინაიდან მეტი ცოდნაა მიღებული.
ყოველი სპრინტი შეიძლება განხილული იქნეს როგორც პროექტი რომელიც არის მაქსიმუმ 1 თვიანი ხანგრძლივობის. როგორც პროექტები, სპრინტები გამოიყენება რომ მიიღწეს რაიმე. ყოველ სპრინტს აქვს მიზანი თუ რა უნდა აშენდეს, პროექტი და მოქნილი გეგმა რაც უხელმძღვანელებს მის აშენებას, სამუშაოს, და რეზულტატში მიიღწევა პროდუქტის ინკრემენტი.
სპრინტები არის შეზღუდული ერთი კალენდარული თვით. როცა სპრინტის ჰორიზონტი არის ძალიან გრძელი, განსაზღვრება იმისა თუ რა კეთდება შეიძლება შეიცვალოს, კომპლექსურობა შეიძლება წამოვიდეს წინა პლანზე და რისკი გაიზარდოს. სპრინტები საშუალებას იძლევა პროგნოზირებადობადობის, უზრუნველყოფს რა ინსპექციას და პროგრესის ადაპტაციას სპრინტის მიზნის მიმართ მაქსიმუმ ერთი კალენდარული თვის განმავლობაში. სპრინტები ასევე ამცირებს ღირებულებას ერთი კალენდარული თვის ფარგლებში.
სპრინტის გაუქმება
სპრინტი შეიძლება გაუქმნდეს სანამ სპრინტის თაიმ ბოქსი მორჩება. მხოლოდ პროდუქტის მფლობელს აქვს სპრინტის გაუქმების უფლება, ამასთან მან ეს შეიძლება გააკეთოს ბიზნესის მფლობელების, დეველოპერების გუნდის ან SCRUM-ის ოსტატის გავლენის საფუძველზე.
სპრინტი შეიძლება გაუქმნდეს თუ სპრინტის მიზანი გახდება მოძველებული(ანუ არააქტუალური). ეს შეიძლება მოხდეს თუ კომპანია ცვლის მიმართლებას ან ბაზრის და ტექნოლოგიის მდგომარეობა შეიცვლება. ზოგადად , სპრინტი შეიძლება გაუქმდეს თუ ის აღარ არის აქტუალური მოცემულ მდგომარეობაში. მაგრამ, სპრინტის მოკლე ხანგრძლივობის გამო, გაუქმება თითქმის არ ცვლის მდგომარეობას.
როცა სპრინტი გაუქმებულია, ნებისმიერი მორჩენილი და „დასრულებული“ პროდუქტის ბექლოგის ელემენტები არის გადახედილი. თუ საქმის ნაწილი არის პოტენციურად გაშვებადი, პროდუქტის მფლობელი როგორც წესი ადასტურებს მათ. ყველა მოურჩენელი პროდუქტის ბექლოგის ელემენტები არის თავიდან შეფასებული(გადახედილი) და უკან დაბრუნებული პროდუქტის ბექლოგში. სამუშაო რომელიც განხორციელდა მათზე, განიცდის ცვეთას სწრაფად და უნდა იყოს ხშირად თავიდან შეფასებული.
სპრინტის გაუქმება მოითხოვს რესურსებს, რადგან ყველა გადაჯგუფდება სხვა სპრინტის დაგეგმის პირობებში რომ დაიწყოს ახალი სპრინტი. სპრინტის გაუქმება ხშირდა არის ტრავმული მოქმედება სქრამის გუნდისთვის, და არის ძალიან იშვიათი.
სპრინტის დაგეგმვა
სპრინტის ფარგლებში შესასრულებელი სამუშაო უნდა დაიგეგმოს სპრინტის დაგეგმვის ღონისძიების დროს. ეს გეგმა დგება მთლიანი სქრამის გუნდის მიერ ერთობლივი მუშაობის დროს.
სპრინტის დაგეგმვა არის დროში შეზღუდული და შეადგენს 8 საათს ერთ თვიანი სპრინტის პირობებში. უფრო ნაკლები დროის სპრინტის დროს, ღონისძიება როგორც წესი არის ნაკლები დროის. სქრამის ოსტატი უზრუნველყოფს რომ ეს ღონისძიება ჩატარდეს და დამსწრეებმა გაიგონ მისი მიზანი. სქრამის ოსტატი ასწავლის SCRUM-ის გუნდს რომ იმ დროში ჩაეტიონ რაც დაწესებულია ამ ღონისძიებისთვის.
სპრინტის დაგეგმვა პასუხობს შემდეგ კითხვებს:
- რა უნდა ჩაბარდეს რომ რეზულტატში ინკრემენტის რეზულტატი მივიღოთ მიმდინარე სპრინტის ფარგლებში?
- როგორ უნდა ჩატარედეს სამუშაოები რომ ინკრემენტის ჩაბარება მოხდეს?
ნაწილი პირველი: რა შეიძლება გაკეთდეს ამ სპრინტის როს?
დეველოპერების გუნდი მუშაობს რომ შეაფასოს ფუნქციონალი, რომელიც სპრინტის დროს უნდა გაკეთდეს. პროდუქტის მფლობელი განიხილავს მიზანს რაც სპრინტის დროს უნდა იყოს მიღწეული და პროდუქტის ბექლოგის ელემენტებს რაც, თუ შესრულდება სპრინტის შიგნით, დაეხმარება სპრინტის მიზნის მიღწევაში. მთელი SCRUM_ის გუნდი თანამშრომლობს ერთმანეთში და გაიგებს სპრინტის სამუშაოს.
ამ შეხვედრის ამოსავალი წერტილები არის პროდუქტის ბექლოგი, პროდუქტის ბოლო ინკრემენტი, დეველოპერების გუნდის მიერ დაგეგმილი მოცულობა სპრინტის ფარგლებში და დეველოპერების გუნდის წარსული პროდუქტიულობა. ელემენტების რაოდენობა რომელიც არჩეულია პროდუქტის ბექლოგიდან სპრინტისათვის არის ბოლომდე დეველოპერების გუნდის გასაკეთებელი. მხოლოდ დეველოპერების გუნდს შეუძლია თქვას რა შეიძლება იყოს გაკეთებული მოსალოდნელი სპრინტის დროს.
სპრინტის დაგეგმვის დროს SCRUM_ის გუნდი ახელოვნებს სპრინტის მიზანს. სპრინტის მიზანი არის ამოცანა რომელიც უნდა მიიღწეს სპრინტის პირობებეში, პროდუქტის ბექლოგის იმპლემენტაციის გზით და იგი წარმოადგენს სახელმძღვანელოს დეველოპერების გუნდისათვის იმის გასარკვევად თუ რატომ აშენებენ ისინი ინკრემენტს.
ნაწილი მეორე: როგორ უნდა გაკეთდეს არჩეული სამუშაო?
განსაზღვრავენ რა სპრინტის მიზანს და აირჩევენ რა პროდუქტის ბექლოგის ელემენტებს სპრინტისათვის, დეველოპერების გუნდი წყვეტს როგორ უნდა გააკეთონ აღნიშნული ფუნქციონალი ისე რომ „გაკეთებული“ პროდუქტის ინკრემენტი მიიღონ სპრინტის ფარგლებში. სპრინტის პირობებში არჩეულ პროდუქტის ბექლოგის ელემენტებს დამატებული გეგმა რომლითაც უნდა ჩაბარდეს აღნიშნული ელემენტები ეწოდება სპრინტის ბექლოგი.
დეველოპერების გუნდი როგორც წესი იწყებს სისტემის და სამუშაოს პროექტირებას რომ გადააქციონ პროდუქტის ბექლოგის ელემენტები მუშა პროდუქტის ინკრემენტად. სამუშაო შეიძლება იცვლებოდეს ზომაში, ან განხორციელებულ ძალისხმევაში. ერთი სიტყვით, საკმარისი სამუშაოები უნდა ჩატარდეს სპრინტის დაგეგმვის დროს დეველოპერების გუნდის მხრიდან რომ შეაფასონ ის ძალისხმევა რომელიც მათი აზრით უნდა განხორციელდეს მომავალი სპრინტის დროს.სამუშაო რომელიც დაგეგმილია სპრინტის პირველი დღეების დროს, აღნიშნული შეხვედრის ბოლოსკენ უნდა დაიყოს ისეთ სამუშაოებზე რომელსაც გასაკეთებლად ესაჭიროება დღე ან ნაკლები. ორივე შემთხვევაში, სპრინტის დეგეგმვისას და საჭიროების შემთხვევაში სპრინტის დროსაც. დეველოპერების გუნდი თვით ორგანიზებას აკეთებს რომ შეასრულოს სამუშაო პროდუქტის ბექლოგიდან.
პროდუქტის მფლობელს შეუძლია დაეხმაროს რომ განმარტოს პროდუქტის ბექლოგის ელემენტები და მოახდინოს გაცვლები(ივაჭროს პრიორიტეტებით). თუ დეველოპერების გუნდი გადაწყვეტს რომ მას გააჩნია ძალიან ბევრი ან ძალიან ცოტა სამუშაო, მას შეუძლია გადახედოს არჩეული პროდუქტის ბექლოგის ელემენტებს პროდუქტის მფლობელთან ერთად. დეველოპერების გუნდს ასევე შეუძლია მოიწვიოს სხვა ადამიანები რომ დაესწრონ და წარმოადგინონ ტექნიკური ან სხვა ტიპის რჩევები.
სპრინტის დაგეგმვის დასასრულს, დეველოეპრების გუნდს უნდა შეეძლოს რომ აუხსნას პროდუქტის მფლობელს და SCRUM_ის ოსტატს თუ როგორ აპირებს მუშაობას როგორც თვითორგანიზებადი გუნდი რომ მიაღწიოს სპრინტის მიზანს და შექმნას მოსალოდნელი ინკრემენტი.
სპრინტის მიზანი
სპრინტის მიზანი არის ამოცანების კრებული სპრინტისათვის, რაც შეიძლება მიღწეული იქნას პროდუქტის ბექლოგის იმპლემენტაციის პირობებში. იგი წარმოადგენს სახელმძღვანელოს დეველოპერების გუნდისათვის იმის თაობაზე თუ რატომ აშენებს იგი ინკრემენტს. ის იქმნება სპრინტის დაგეგმვის შეხვედრაზე. სპრინტის მიზანი აძლევს დეველოპერების გუნდს გარკვეული სახის მოქნილობას, ფუნქიონალობბის განხორციელებაზე სპრინტის შიგნით. არჩეული პროდუქტის ბექლოგის ელემენტები აბარებს ერთ მომდევნო ფუნქციას, რომელიც შეიძლება იყოს სპრინტის მიზანი. სპრინტის მიზანი შეილება იყოს ნებისმიერი თანმიმდევრულობა რაც გამოიწვევს დეველოპერების გუნდის მხრიდან ერთად მუშაობას, და არა ცალკეულ ინიციატივებს.
როცა დეველოპერების გუნდი მუშაობს, ის ინახავს გონებაში სპრინტის მიზანს. სპრინტის მიზანის დასაკმაყოფილებლად, იგი იმპლემენტაციას უკეთებს ფუნცქციონალს და ტექნოლოგიას. თუ სამუშაო აღმოჩნდება განსხვავებული ვიდრე დეველოპერების გუნდს წარმოედგინა, ისინი ურთიერთობენ პროდუქტის მფლობელთან რომ განიხილონ სპრინტის ბექლოგის მოცულობა სპრინტის ფარგლებში.
დღიური SCRUM_ი.
დღიური SCRUM_ი არის 15 წუთიანი დროში შეზღდუდული ღონისძიება დეველოპერების გუნდისთვის. დღიური სქრამი იმართება ყოველი სპრინტის დღეს(ანუ იმ დღეს როცა სპრინტზე მუშაობა მიმდინარეობს. უქმე დღეებში არ იმართება). მასზე, დეველოპმენტის გუნდი გეგმავს სამუშაოებს შემდეგი 24 საათისთვის. ეს ოპტიმიზირებას უკეთებს გუნდის ურთიერთქმედებას და შედეგიანობას , რადგან ამოწმებს წინა SCRUM-ის დროს შესრულებულ სამუშაოს და მომავალში პროგრნოზირებას უკეთებს მოსალოდნელი სპრინტის სამუშაოს. დღიური SCRUM ყოველთვის ერთიდაიგივე ადგილზე და დროს იმართება რომ შეამციროს ამ გზით სირთულეები.
დეველოპერების გუნდი იყენებს დღიურ SCRUM-ს რომ შეამოწმოს პროგრესი სპრინტის მიზანთან მიმართებაში და რომ შეამოწმოს როგორი ტრენდი აქვს პროგრესს სპრინტის ბექლოგში წარმოდგენილ საქმესთან მიმართებაში. დღიური SCRUM-ი ოპტიმიზებას უკეთებს იმის ალბათობას რომ დეველოპერების გუნდმა მიაღწიოს სპრინტის მიზანს. ყოველდღე, დეველოპერების გუნდმა უნდა გაიგოს როგორ მუშაობს თვითორგანიზებადი გუნდი სპრინტის მიზნის მისაღწევად და განსაზღვრული ინკრემენტის შესაქმნელად სპრინტის ბოლომდე.
შეხვედრის სტრუქტურა არის დადგენილი დეველოპერების გუნდის მიერ და შეიძლება ჩატარდეს სხვადასხვა გზით, თუ ის სპრინტის მიზნის მიღწევის პროგრესზე ფოკუსირდება. ზოგ დეველოპერთა გუნდები იყენებენ კითხვებს, ზოგი უფრო დისკუსიაზე ორიენტირებულია. ქვემოთ მოყვანილია მაგალითები, აღნიშნული რაში შეიძლება იყოს გამოყენებული:
- რა გავაკეთე გუშინ, რაც დაეხმარა დეველოპერების გუნდს სპრინტის მიზნის მიღწევაში?
- რას გავაკეთებ დღს რომ დავეხმარო დეველოპერების გუნდს სპრინტის მიზნის მიღწევაში?
- ვხედავ რამე ხელის შემშლელ ფაქტორებს რომელსაც შეუძლიათ შეაჩერონ მე ან დეველოპერების გუნდი სპრინტის მიზნის მიღწევაში?
დეველოპერების გუნდი ან მისი წევრები ხშირად ხვდებიან დღიური სქრამის შემდეგ დეტალური დისკუსიებისთვის, რომ ადაპტაცია, გადაგეგმვა მოახდინონ სპრინტის სამუშაოს დარჩენილი ნაწილისა.
სქრამის ოსტატი რწმუნდება რომ დეველოპერების გუნდს ატარებს შეხვედრას, მაგრამ დეველოპერების გუნდის წევრები არიან პასუხისმგებლები დღიური SCRUM-ის ჩატარებაზე.
SCRUM_ის ოსტატი ასწავლის დეველოპერების გუნდს თუ როგორ ჩატიონ დღიური SCRUM-ი 15 წუთიან ინტერვალში.
დღიური SCRUM_ი არის შიდა შეხვედრა დეველოპერების გუნდისთვის. თუ სხვები ესწრებიან, SCRUM-ის ოსტატი უზრუნველყოფს იმას რომ მათ არ ჩაშალონ შეხვედრა.
დღიური SCRUM-ები აუმჯობესებს კომუნიკაციას, ამცირებს სხვა შეხვედრების საჭიროებას, აღმოაჩენს შემაფერხებენ გარემოებებს დეველოპმენტისთვის რომ აღმოფხვრას, მონიშნოს და წაახალისოს სწრაფად გადაწყვეტილების მიღება და გააუმჯობესოს დეველოპმენტის გუნდის ცოდნის დონე. ეს არის საკვანძო „ინსპექტირების და ადაპტაციის„ შეხვედრა.
სპრინტის განხილვა
სპრინტის განხილვა ხდება ყოველი სპრინტის ბოლოს რომ შემოწმდეს ინკრემენტი და ადაპტირება მოვახდინოთ პროდუქტის ბექლოგისა, საჭიროების შემთხვევაში. სპრინტის განხივლის დროს, SCRUM_ის გუნდი და მეწილეები ურთიერთობენ იმის თაობაზე თუ რა იყო გაკეთებული სპრინტის დროს. ამაზე დაყრდნობით და ნებისმიერი ცვლილებისას პროდუქტის ბექლოგში სპრინტის მიმდინარეობისას, დამსწრეები ურთიერთბენ შემდგომ საკითხებზე რა შეიძლება გაკეთდეს რომ ღირებულების ოპტიმიზება ოხდეს. ეს არის არაფორმალური შეხვედრა, არა სტატუს შეხვედრა და ინკრემენტის პრეზენტაცია ხდება რომ უკუკავშირი გამოიწვიოს და კოლაბორაცის შეუწყოს ხელი.
ეს არის ყველაზე ხშირად ოთხ საათიანი შეხვედრა ერთ თვიანი სპრინტებისთვის. მოკლე სპრინტებისთვის აღნიშნული ღონისძიება უფრო ნაკლები დროისაა. SCRUM-ის ოსტატი უზრუნველყოფს იმას რომ ღონისძიება ჩატარდეს და დამსწრეებმა გაიგონ მისი დანიშნულება. SCRUM-ის ოსტატი ყველას ჩართულ პირს ასწავლის როგორ ჩაეტიონ შეზღუდულ დროში.
სპრინტის განხილვა შეიცავს შემდეგ ელემენტებს:
- დამსწრეებს შეადგენენ SCRUM_ის გუნდი და საკვანძო მეწილეები, რომელიც მოწვეულია პროდუქტის მფლობელის მიერ
- პროდუქტის მფლობელი აღწერს რომელი პროდუქტის ბექლოგის ელემენტები „გაკეთდა“ და რა არ „გაკეთდა“.
- დეველოპერების გუნდი განიხილავს რა მიდიოდა კარგად სპრინტის მიმდინარეობისას, რა პრობლემები არსებობდა და როგორ გადაწყდა აღნიშნული პრობლემები.
- დეველოპერების გუნდი ადემონსტრირებს „გაკეთებულ“ სამუშაოს და პასუხობს კითხვებს ინკრემენტის გარშემო.
- პროდუქტის მფლობელი განიხილავს პროდუქტის ბექლოგს . იგი გეგმავს მისაღებ(მოსაწონ) მიზანს და ჩაბარების დროს, არსებულ თარიღში მიღწეულ პროგრესზე დაყრდნობით.
- მთლიანი გუნდი ურთიერთქმედებს იმაზე თუ რა უნდა გაკეთდეს შემდეგი, ასე რომ სპრინტის განხილვა უზრუნველყოფს ღირებულ შენატანს მომდევნო სპრინტის დაგეგმვისთვის.
- განიხილავს თუ როგორ შეიცვალა ბაზრის სიტუაცია ან პოტენციური გამოყენება, შესაბამისად რა არის ყველაზე ღირებული რამე, რაც შემდეგში უნდა გაკეთდეს; და ,
- განიხილოს თაიმლაინი, ბიუჯეტი, პოტენციური შესაძლებლობები და ბაზრის მოცემულობა პროდუქტის შემდეგი ფუნქციონალისა და შესაძლებლობების დაგეგმილი რელიზებისთვის.
სპრინტის განხილვის რეზულტატი არის გადამოწმებული პროდუქტის ბექლოგი რაც განსაზღვრავს შესაძლო ბექლოგის ელემენტებს შემდეგი სპრინტისთვის. პროდუქტის ბექლოგი შეიძლება ასევე დაზუსტდეს მთლიანობაში რომ ახალ შესაძლებლობებს მიეგებონ.
სპრინტის რეტროსპექტივა
სპრინტის რეტროსპექტივა არის შესაძლებლობა SCRUM_ი გუნდისთვის რომ შეამოწმოს საკუთარი თავი და შექმნან გეგმა შემდეგი სპრინტის დროს გამოსასწორებელი საქმეებისა.
სპრინტის რეტროსპექტივას ადგილი აქვს სპრინტის განხილვის შემდეგ და შემდეგი სპრინტის დაგეგმვის დაწყებამდე შუალედში. ეს არის უმეტესად 3 საათიანი შეხვედრა ერთ თვიანი სპრინტებისთვის. უფრო მოკლე სპრინტებისთვის, ღონისძიება როგორც წესი უფრო მოკლეა. SCRUM-ის ოსტატი უზრუნველყოფს რომ ღონისძება ტარდება და დამსწრეებს ესმით მისი მნიშვნელობა.
SCRUM_ის ოსტატი უზუნველყოფს რომ შეხვედრა პოზიტიური და პროდუქტიული იყოს. SCRUM-ის ოსტატი ასწავლის ყველას რომ ჩაეტიონ გამოყოფილ დროში. SCRUM-ის ოსტატი მონაწილეობს როგორც ყველა ცალკეული გუნდის წევრი რათა აღრიცხული იყოს SCRUM-ის პროცესი.
სპრინტის რეტროსპექტივის მიზანი არის რომ:
- გამოიკვლიოს(შეამოწმოს) ბოლო სპრინტის მიმდინარეობა, ხალხთან, ურთიერთობების კუთხით, პროცესთან და ხელსაწყოებთან მიმართებაში.
- გამოავლინოს და დაალაგოს მთავარი ელემენტები, რაც კარგად წავიდა და პოტენციური გაუმჯობესებები; და
- შექმნას გეგმა გასაუმჯობესებელი საკითხების შესრულების ისე, როგორც SCRUM_ის გუნდი აკეთებს ამ საქმეს.
SCRUM-ის ოსტატი ახალისებს SCRUM-ის გუნდს რომ გააუმჯობესონ SCRUM-ის პროცესი ფრეიმვორკის შიგნით, მისი შესრულების პროცესი და რომ შემდეგი სპრინტისთვის უფრო ეფექტური და სახალისო გახადოს მისი განხორციელების პრაქტიკები. ყოველი სპრინტის რეტროსპექტივის დროს, SCRUM_ის გუნდი გეგმავს სხვადასხვა გზებს რომ გაზარდონ პროდუქტის ხარისხი სამუშაო პროცესის გაუმჯობესების გზით ან ადაპტაცია მოახდინონ „გაკეთებულია“-ს განსაზღვრების, თუ შესაბამისი და პროდუქტთან ან ორგანიზაციულ სტანდარტთან კომფლიქტში მყოფი არ არის.
სპრინტის რეტროსპექტივის ბოლოში, SCRUM-ის გუნდს უნდა ჰქონდეს იდენტიფიცირებული გაუმჯობესებები რომელსაც იგი განახორციელებს შემდეგი სპრინტის დროს. ამ გაუმჯობესებების გამოსწორება შემდეგ სპრინტში არის SCRUM_ის გუნდის მიერ შემოწმების მიმართ ადაპტაცია. ამასთან გაუმჯობესებები შეიძლება განხორციელდეს ნებისმიერ დროს, სპრინტის რეტროსპექტივა წარმოადგენს ფორმალურ შესაძლებლობას რომ ჩვენი ფოკუსი მივმართოთ შემოწმებისა და ადაპტაციისკენ.
SCRUM_ის არტეფაქტები
SCRUM_ის არტეფაქტები წარმოადგენს სამუშაოს ან ღირებულებას რომ განახორციელოს(უზრუნველყოს) გამჭვირვალეობა და შესაძლებლობები შემოწმებისა და ადაპტაციისთვის. SCRUM-ში განსაზღვრული არტეფაქტები არის სპეციფიურად შექმნილი რომ მაქსიმალური გამჭვირვალეობა მოხდეს საკვანძო ინფორმაციისა, ისე რომ ყველას ჰქონდეს აღნიშნული არტეფაქტის ერთნაირი გაგება.
პროდუქტის ბექლოგი
პროდუქტის ბექლოგი არის დალაგებული სია ყველაფრისა რაც ვიცით რომ გასაკეთებელია პროდუქტში. ეს არის ერთადერთი წყარო მოთხოვნებისა პროდუქტზე განსახორციელებელი ნებისმიერი ცვლილებისთვის. პროდუქტის მფლობელი პასუხისმგებელია პროდუქტის ბექლოგზე, მათ შორის მის კონტენტზე, დალაგებაზე და ხელმისაწვდომოაზე.
პროდუქტის ბექლოგი არასოდეს არის დასრულებული. მისი ადრეული დეველოპმენტი ეფუძნება საწყისად ცნობილ და საუკეთესოდ გაგებულ მოთხოვნებს. პროდუქტის ბექლოგი ვითარდება ისე როგორც პროდუქტი და ის გარემო ვითარდება, სადაც იგი შეიძლება გამოიყენონ. პროდუქტის ბექლოგი არის დინამიური; იგი მუდმივად იცვლება რომ განსაზღვროს რა სჭირდება პროდუქტს რომ იყოს მისაღები, ანგარიშგასაწევი(კონკურენტუნარიანი) და საჭირო. თუ პროდუქტი არსებობს, მისი ბექლოგიც არსებობს ამავდროულად.
პროდუქტის ბექლოგი შეიცავს ყველა ფუნქციონალს, ფუნქციებს, მოთხოვნებს, გაუმჯობესებებს, და გამოსწორებებს რაც წარმოადგენს იმ ცვლილებებს რაც უნდა განხორციელდეს პროდუქტზე მომდევნო რელიზებისას. პროდუქტის ბექლოგის ელემენტებს აქვს შემდეგი ატრიბუტები: განსაზღვრება(აღწერა), დალაგება(ადგილი სიაში), შეფასება და ღირებულება. პროდუქტის ბექლოგის ელემენტები ხშირად შეიცავენ სატესტო განსაზღვრებებს(აღწერებს) რაც კიდევ ერთხელ დაამტკიცებს მის დასრულებას როცა „დასრულდება“(ანუ ტესტის გავლის შემდეგ უფრო გასაგები ხდება თუ რაც უნდა ნიშნავდეს სიტყვა „დასრულებული“).
რადგანაც პროდუქტი გამოიყენება და იპოვებს ღირებულებას და ბაზარი იძლევა უკუკავშირს, პროდუქტის ბექლოგი გამოდის უფრო დიდი და დამღლელი სია. მოთხოვნების ცვლილებები არ ჩერდება, ასე რომ პროდუქტის ბექლოგი არის ცოცხალი არტიფაქტი. ცვლილებებმა ბიზნესის მოთხოვნებში, ბაზრის მდგომარეობაში ან ტექნოლოგიებში შეიძლება გავლენა იქონიოს პროდუქტის ბექლოგის ცვლილებაზე.
რამოდენიმე SCRUM-ის გუნდები ხშირად მუშაობენ ერთად ერთიდაიგივე პროდუქტზე. ერთი პროდუქტის ბექლოგი გამოიყენება პროდუქტზე ჩასატარებელი სამუშაოების აღწერისთვის. პროდუქტის ბექლოგი იმის იმას გვაჩვენებს რომ ეს ელემენტები შეიძლება დაჯგუფდეს.
პროდუქტის ბექლოგის დახვეწა არის დეტალების, შეფასების და დალაგების დამატების აქტი პროდუქტის ბექლოგში. ეს არის მიმდინარე პროცესი, რომელშიც პროდუქტის მფლობელი და დეველოპერების გუნდი ურთიერთობს პროდუქტის ბექლოგის ელემენტების დეტალებზე. პროდუქტის ბექლოგის დახვეწის დროს, ელემენტები არის გადახედილი და განახლებული. SCRUM-ის გუნდი წყვეტს, თუ რა და როგორ უნდა დაიხვეწოს. დახვეწა ხშირად იკავებს არაუმეტეს 10%(ათი პროცენტი)-სა დეველოპერების გუნდის მოცულობის(შესაძლებლობების). ერთი სიტყვით, პროდუქტის ბექლოგის ელემენტები შეიძლება განახლდეს ნებისმიერ დროს პროდუქტის მფლობელის მიერ ან მისი შეხედულებით.
მაღლა დალაგებული პროდუქტის ბექლოგის ელემენტები როგორც წესი უფრო ნათელია და მეტად დეტალიზებული, ვიდრე დაბლა დალაგებული ელემენტები. მეტი სიზუსტით ხორციელდება დროში განსაზღვრა, რადგან დაფუძნებულია მეტ სიცხადეზე და დეტალების გაზრდაზე. რაც უფრო დაბლაა პროდუქტის ბექლოგის ელემენტი მით უფრო ნაკლებ დეტალიზებულია. პროდუქტის ბექლოგის ელემენტები რომელიც დეველოპერების გუნდს თავზე ახვევია მომდევნო სპრინდის დროს არის დაზუსტებული ისე, რომ ნებისმიერი ელემენტი შეიძლება გონივრულად „გაკეთებულია“ იყოს სპრინტის თაიმ ბოქსის დროს. პროდუქტის ბექლოგის ელემენტები რაც შეიძლება იყოს „გაკეთებული“ დეველოპმენტის გუნდის მიერ ერთი სპრინტის დროს ითვლება „მზად“არჩევისას სპრინტის დაგეგმვის დროს. პროდუტის ბექლოგის ელემენტები როგორც წესი გახდება ხოლმე ამ დრონის გამჭვირვალე ზემოთ აღწერილი დაზუსტების მოქმედებების შედეგად.
დეველოპერების გუნდი პასუხისმგებელია ყველა შეფასებაზე. პროდუქტის მფლობელი შეიძლება დაეხმაროს რომ გააგებინოს დეველოპერების გუნდის წევრებს გააცნობიერონ და აირჩიონ გაცვლები, მაგრამ ვინც სამუშაო უნდა შეასრულოს, მანვე უნდა განსაზვღოს სამუშაოს საბოლოო შეფასება.
მიზნებთან მიმართებაში პროგრესის მონიტორინგი
ნებისმიერ დროს, შესაძლებელია მიზნის მიღწევამდე დარჩენილი სამუშაოების დაჯამება. პროდუქტის მფლობელი აღრიცხავს ამ მთლიანი დარჩენილ სამუშაოს, როგორც მინიმუმ ყოველი სპრინტის განხილვის დროს. პროდუქტის მფლობელი ადარებს ამ რაოდენობას წინა სპრინტის განხილვების დროს დარჩენილ სამუშაოებს რომ შეაფასოს პროგრესი დასასრულებელი დაგეგმილი სამუშაოებისა მიზნისათვის მისაღებ დროსთან მიმართებაში. ეს ინფორმაცია არის გამჭვირვალე ყველა მეწილისთვის.
სხვადასხვა შეფასების პრაქტიკები არსებობს პროგრესის განსაზღვრისთვის, როგორც ჩაწვა(burndown), აწვა(burn-ups) ან თვითმყოფადი დინებები. ამათ დაამტკიცეს საკუთარი სარგებლობა. ერთ სიტყვით, ესენი არ ცვლიან ემპირიციზმის საჭიროებას. კომპლექსურ გარემოებში, რა შეიძლება მოხდეს, უცნობია. მხოლოდ რაც უკვე მოხდა შეიძლება გამოიყენებული იყოს მომავალში გადაწყვეტილების მიღებისთვის.
სპრინტის ბექლოგი
სპრინტის ბექლოგი არის პროდუქტის ბექლოგის გარკვეული ელემენტების ერთობლიობა, რომელიც არჩეულია სპრინტისთვის, დამატებული პროდუქტის ინკრემენტის ჩაბარების და სპრინტის მიზნის მიღწევის გეგმა. სპრინტის ბექლოგი არის დეველოპერების გუნდის მიერ გაკეთებული შეფასება, იმის თაობაზე თუ რა ფუნქციონალობა იქნება შემდეგ ინკრემენტში და რა სამუშაოები იქნება საჭირო რომ გადაიქცეს ფუნციონალობა „გაკეთებულ“-ს ინკრემენტად.
სპრინტის ბექლოგი ხილულს ხდის ყველა სამუშაოს, რასაც დეველოპერების გუნდი აღმოაჩენს რომ საჭიროა სპრინტის მიზნის მისაღწევად. რომ უზრუნველყოს განგრძობადი გაუმჯობესება, ის შეიცავს მინიმუმ ერთ მაღალი პრიორიტეტულობის პროცესის გაუმჯობესებას, რომელიც წინა რეტროსპექტივის შეხვედრის დროს არის აღმოჩენილი.
სპრინტის ბექლოგი არის გეგმა საკმარისად დეტალიზებული იმისათვის რომ პროგრესში ცვლილებები გაგებული იყოს დღიურ SCRUM-ში. დეველოპერების გუნდი ცვლის სპრინტის ბექლოგს სპრინტის განმავლობაში და სპრინტის ბექლოგი წარმოიშვება ხოლმე სპრინტის დროს. ახლის წარმოშობის საჭიროება ჩნდება მაშინ, როცა დეველოპერების გუნდი მუშაობს გეგმის მიხედვით და მეტს სწავლობს სამუშაოს შესახებ რომ სპრინტის მიზანს მიაღწიოს.
მას მერე რაც ახალი სამუშაოს საჭიროება დგება, დეველოპერების გუნდი ამატებს მას სპრინტის ბექლოგში. თუ სამუშაო შესრულებული ან დასრულებულია, შეფასებული დარჩენილი სამუშაო განახლებულია. როცა გეგმის ელემენტები ითვლება არასაჭიროდ, ისინი მოცილებულია. მხოლოდ დევლოპერების გუნდს შეუძლია მისი სპრინტის ბექლოგი სპრინტის მიმდინარეობისას. სპრინტის ბექლოგი არის მაღალი დონის ჩვენებადი, რეალური დროის სურათი იმ სამუშაოსი, რაც დეველოპერების გუნდის მიერ დაგეგმილია რომ შეასრულებს სპრინტის დროს, და ის მთლიანად ეკუთვნის დეველოპერების გუნდს.
სპრინტის პროგრესის მონიტორინგი
სპრინტის მიმდინარეობისას ნებისმიერ მომენტში, სპრინტის ბექლოგში დარჩენილი სამუშაო უნდა დაჯამდეს. დეველოეპრების გუნდი აკონტროლებს დარჩენილ სამუშაოს მინიმუმ ყოველდღიური SCRUM-ისთვის რომ დაგეგმოს შესრულების რეალურობა სპრინტის მიზნის მისაღწევად. იმის გამო რომ აკონტროლებენ დარჩენილ სამუშაოს სპრინტის მიმდინარეობისას, დეველოპერების გუნდს შეუძლია მართოს მისი პროგრესი.
ინკრემენტი
ინკრემენტი არის მთლიანი პროდუქტის ბექლოგის ელემენტების ჯამი, შესრულებული სპრინტის დროს და ღირებულება ყველა წინა ინკრემენტები ყველა წინა სპრინტის დროს. სპრინტის ბოლოს, ახალი ინკრემენტი უნდა იყოს „გაკეთებული“, რაც ნიშნავს რომ იგი უნდა იყოს გამოსაყენებ მდგომარეობაში და ასახავდეს SCRUM-ის გუნდის განსაზღვრებას „გაკეთებულია“-ს თაობაზე. ინკრემენტი არის სხეული, შემმოწმებადი, გაკეთებული საქმისა რომელიც მხარს უჭერს ემპირიციზმს პრინტის დასრულებისას. ინკრემენტი არის ნაბიჯი წინ მიზნისკენ ან მისიისკენ. ინკრემენტი უნდა იყოს გამოყენებად მდგომარეობაში მიუხედავად იმისა პროდუქტის მფლობელი გადაწყვეტს თუ არა მის გაშვებას.
არტეფაქტების გამჭვირვალეობა
SCRUM_ი ემყარება გამჭვირვალეობას. გადაწყვეტილებები ღირებულების ოპტიმიზების კუთხით და რისკის კონტროლი დაფუძნებულია არტეფაქტების აღქმად მდგომარეობაზე. იმ შემთხვევაში თუ გამჭვირვალეობა არის სრული, ამ გადაწყვეტილებებს აქვთ ხმის ბაზისი. იმ შემთხვევაში თუ ეს არტეფაქტები შეიძლება ბოლომდე გამჭვირვალე არ არის, ეს გადაწყვეტილებები შეიძლება ყალბი იყოს, ღირებულება შეიძლება შემცირებული ჰქონდეს და რისკი შეიძლება გაიზარდოს.
SCRUM-ის ოსტატმა უნდა იმუშაოს პროდუქტის მფლობელთან, დეველოპერებთან ერთად და სხვა ჩართულ მხარეებთან რომ გაიგოს სრულად გამჭვირვალეა თუ არა არტიფაქტები. არსებობს პრაქტიკები რომელიც უმკლავდება არასრულ გამჭვირვალეობას; SCRUM-ის ოსტატი ეხმარებას ყველას რომ გაითავისონ შესაბამისი პრაქტიკები სრული გამჭვირვალეობის არ არსებობის პირობებში. SCRUM-ის ოსტატმა შეიძლება აღმოაჩინოს არასრული გამჭვირვალეობა არტეფაქტების შემოწმეიბს დროს, იგრძონს პატერნები, მოუსმინოს გულისყურით რაც ითქვა და აღმოაჩინოს განსხვავებები მოსალოდნელ და დამდგარ შედეგს შორის.
SCRUM-ის ოსტატის საქმეა SCRUM-ის გუნდთან და ორგანიზაციასთან მუშაობა რომ გაზარდოს გამჭვირვალეობა არტეფაქტებისა. სამუშაო როგორც წესი გამოიწვევს სწავლას, დაჯერებას და ცვლილებას. გამჭვირვალეობა არ დგება ერთ დღეში, მაგრამ ეს არის გზა მის უზრუნველსაყოფად.
„დასრულებული“-ს განსაზღვრება
როცა პროდუქტის ბექლოგის ელემენტები ან ინკრემენტი არის აღწერილი როგორც „დასრულებული“, ყველას უნდა ესმოდეს რაც ნიშნავს „დასრულებული“. ამასთან ეს მნიშვნელოვნად შეიძლება განსხვავდებოდეს სხვადასხვა SCRUM-ის გუნდების მიხედვით, თუმცა წევრებს უნდა ჰქონდეს გაზიარებული გაგება იმისა თუ რაც ნიშნავს როცა სამუშაო დამთავრებულია, რომ უზრუნველყონ გამჭვირვალეობა. ეს არის „დასრულებული“-ს განსაზღვრება SCRUM-ის გუნდებისთვის და გამოიყენება შესაფასებლად, როცა სამუშაო არის დასრულებული პროდუქტის ინკრემენტისთვის.
იგივე განსაზღვრების მიხედვით უნდა იხელმძღვანელოს დეველოპერების გუნდმა იმ შემთხვევაში რომ გაიგონ რამდენი პროდუქტის ბექლოგის ელემენტები შეუძლიათ რომ მონიშნონ სპრინტის დაგეგმვისას. ყოველი სპრინტის მიზანი არის რომ ჩააბაროს პოტენციურად გაშვებადი ფუნციონალის ინკრემენტი, რაც მყარად არის დაცული SCRUM-ის გუნდის მიერ „დასრულებული“-ს განსაზღვრების საკითხში.
დეველოპერების გუნდი აბარებს პროდუქტის ფუნქციონალის ინკრემენტს ყოველი სპრინტის დროს. ეს ინკრემენტი არის გამოყენებადი, ისე რომ პროდუქტის მფლობელს შეუძლია აირჩიოს რომ ეგრევე გაუშვას იგი. თუ „გაკეთებული“-ს განსაზღვრება არის კონვენციების, სტანდარტების და სახელმძღვანელოს ნაწილი დეველოპერული ორგანიზაციისა, ყველა SCRUM_ის გუნდები უნდა მიყვნენ მას როგორც მინიმუმ.
თუ ინკრემენტის „დასრულებული“ არ არის განსაზღვრული დეველოპერული ორგანიზაციის კონვენციის მიხედვით, მაშინ დეველოპერების გუნდი SCRUM-ის გუნდი შიგნით უნდა შეთანხმდეს და ჩამოაყალობოს „დასრულებული“-ს განსაზღვრება პროდუქტის შესაბამისად. თუ არის რამოდენიმე SCRUM_ის გუნდი რომელიც მუშაობს სისტემაზე ან პროდუქტის გაშვებაზე, დეველოპერების გუნდებმა ერთობლივად უნდა განსაზვღონ თუ რას ნიშნავს „დასრულებული“.
ყოველი ინკრემენტი არის დამატებებები ყველა წინა ინკრემენტისათვის და შესაბამისად გატესტილია, უზრუნველოფს რა რომ ყველა ინკრემენტები მუშაობს ერთად კარგად.
როცა SCRUM-ის გუნდები იზრდება, მოსალოდნელია რომ მათი განსაზღვრებები „დასრულებული“-ასთან მიმართებაში შეიძლება გაფართოვდეს რომ მოიცვას მეტი მკაფიო კრიტერიუმები მაღალი ხარისხის უზრუნველსაყოფად. ახალმა განსაზღვრებებმა, რომელიც იქნება გამოყენებული, შეიძლება გამოავლინოს ჩასატარებელი სამუშაოები წინა „დასრულებული“ ინკრემენტებისთვის. ყოველ ცალკეულ პროდუქტს ან სისტემას უნდა ჰქონდეს განსაზღვრება „დასრულებული“-სა რაც იქნება სტანდარტი ყოველი სამუშაოსთვის რაც უნდა ჩატარდეს.
