ეჯაილი და სკრამი: ისტორია, შემქმნელები და მთავარი იდეები

ეჯაილი და სკრამი სხვადასხვა რამეს ნიშნავს

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

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

რატომ გახდა საჭირო განსხვავებული მიდგომა

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

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

სკრამის ფესვები ეჯაილ მანიფესტზე ადრინდელია

მნიშვნელოვანი წინაპირობა ჰიროტაკა ტაკეუჩისა და იკუჯირო ნონაკას 1986 წლის სტატიაა — The New New Product Development Game. რაგბის მეტაფორა პროდუქტის შექმნას გუნდის შეთანხმებულ მოძრაობად წარმოაჩენდა და არა მხოლოდ სამუშაოს თანმიმდევრულ გადაბარებად. სტატია ზოგადად პროდუქტის განვითარებას ეხებოდა; ის მოგვიანებით ჩამოყალიბებულ პროგრამულ სამუშაო ჩარჩოში, მისი სრულად განსაზღვრული სახით, არ უნდა აგვერიოს.

კენ შვაბერმა და ჯეფ საზერლენდმა სკრამი 1990-იანი წლების დასაწყისში განავითარეს და 1995 წელს OOPSLA-ს კონფერენციაზე ერთობლივად წარადგინეს. ისინი მის თანაშემქმნელებად არიან აღიარებული, თუმცა განვითარებაში სხვა პრაქტიკოსებიც მონაწილეობდნენ. პირველი Scrum Guide 2010 წელს გამოჩნდა. თანმიმდევრობას მნიშვნელობა აქვს: სკრამი ეჯაილ მანიფესტამდე არსებობდა, შემდეგ კი ეჯაილ განვითარებასთან დაკავშირებულ ერთ-ერთ ყველაზე ცნობილ ჩარჩოდ იქცა.

2001 წლის შეხვედრამ ეჯაილს საერთო სახე მისცა

2001 წლის 11–13 თებერვალს პროგრამული უზრუნველყოფის ჩვიდმეტი პრაქტიკოსი იუტის შტატში, სნოუბერდში შეხვდა. ისინი სხვადასხვა მიდგომას წარმოადგენდნენ, მათ შორის ექსტრემალურ პროგრამირებას, სკრამსა და Crystal-ს. შეხვედრის ოფიციალური ისტორიის მიხედვით, მათი მიზანი მძიმე, დოკუმენტებზე ორიენტირებული პროცესების მიღმა საერთო საფუძვლის პოვნასაც მოიცავდა. შედეგად შეიქმნა პროგრამული უზრუნველყოფის ეჯაილ განვითარების მანიფესტი, რომელსაც ჩვეულებრივ ეჯაილ მანიფესტს უწოდებენ.

მისი ჩვიდმეტი ხელმომწერია: კენტ ბეკი, მაიკ ბიდლი, არი ვან ბენეკუმი, ალისტერ კოუბერნი, უორდ კანინგემი, მარტინ ფაულერი, ჯეიმს გრენინგი, ჯიმ ჰაისმითი, ენდრიუ ჰანტი, რონ ჯეფრისი, ჯონ კერნი, ბრაიან მერიკი, რობერტ სესილ მარტინი, სტივ მელორი, კენ შვაბერი, ჯეფ საზერლენდი და დეივ თომასი. შესაბამისად, ეჯაილს კოლექტიური ავტორობა აქვს. სკრამის ორივე თანაშემქმნელი ხელმომწერებს შორის იყო, მაგრამ უფრო ფართო მოძრაობა მხოლოდ მათ ვერ მიეწერება.

ოთხი ღირებულება მნიშვნელოვანი დაზუსტებით

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

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

რას ამატებს ამ იდეებს სკრამი

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

Scrum Guide სამ ანგარიშვალდებულებას გამოყოფს. Product Owner პროდუქტის ღირებულების მაქსიმიზაციასა და პრიორიტეტების მიხედვით დალაგებული Product Backlog-ის მართვაზეა პასუხისმგებელი. Developers გამოსაყენებელ შედეგს ქმნიან და საკუთარ სამუშაოს ორგანიზებას უწევენ. Scrum Master სკრამის დამკვიდრებასა და გუნდის ეფექტიანობის გაუმჯობესებას ეხმარება. ის არ არის განსაზღვრული უფროსად, რომელიც ყოველდღიურ დავალებებს ანაწილებს, Product Owner კი ერთი ადამიანია და არა გადაწყვეტილებების მიმღები კომიტეტი.

სამუშაო ციკლი და არა მხოლოდ შეხვედრების კალენდარი

Sprint Planning განსაზღვრავს, რატომ არის მომავალი სპრინტი მნიშვნელოვანი, რისი აღება შეუძლია გუნდს და როგორ აპირებს მოქმედებას. სპრინტის განმავლობაში Daily Scrum Developers-ს თხუთმეტ წუთს აძლევს მიზნისკენ წინსვლის შესამოწმებლად და გეგმის მოსარგებად. Sprint Review შედეგს დაინტერესებულ მხარეებთან ერთად განიხილავს და მომავალ სამუშაოზე მოქმედებს. Sprint Retrospective კი გუნდის თანამშრომლობის გაუმჯობესებაზეა მიმართული.

ამ მოვლენებს განსხვავებული მიზნები აქვს. Review უბრალოდ დამტკიცების ბარიერი არ არის, რეტროსპექტივა კი რთული კვირის გამო ვინმეს დადანაშაულების საბაბი არ უნდა გახდეს. ყოველდღიური შეხვედრაც მხოლოდ ფეხზე დგომით არ ხდება ეფექტიანი. გარეგნულ ფორმაზე მნიშვნელოვანი დაკვირვებასა და მოქმედებას შორის კავშირია: თუ დაბრკოლება ან მცდარი ვარაუდი გამოჩნდა, გუნდს რეაგირების რეალური შესაძლებლობა უნდა ჰქონდეს.

როგორ გამოიყურება მიდგომა ჩვეულებრივ პროდუქტში

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

ეს საილუსტრაციო მაგალითია და არა ისტორიული პროექტი. ის ორ შემავსებელ იდეას აჩვენებს: ინკრემენტული განვითარება გამოსაყენებელ შესაძლებლობებს ამატებს, იტერაციული განვითარება კი ნასწავლს ან უკვე შექმნილს უბრუნდება და აუმჯობესებს. იდეის შესასწავლი პროტოტიპი შეიძლება ღირებული იყოს, მაგრამ ავტომატურად დასრულებულ პროდუქტულ დამატებად არ იქცევა. სკრამში სამუშაო გუნდის Definition of Done-ს უნდა აკმაყოფილებდეს, სანამ დასრულებული Increment-ის ნაწილად ჩაითვლება.

სად თავსდება სხვა პრაქტიკები და ადამიანები

ეჯაილი სკრამზე ფართოა. ექსტრემალური პროგრამირება განსაკუთრებულ ყურადღებას პროგრამული ინჟინერიის პრაქტიკებს უთმობს; კანბანი კი სამუშაო ნაკადის მართვასა და ერთდროულად მიმდინარე სამუშაოს შეზღუდვაზეა ორიენტირებული. გუნდებმა შეიძლება მომხმარებლის ისტორიები, შეფასების ტექნიკები ან ვიზუალური დაფებიც გამოიყენონ. ისინი მუშაობას ეხმარება, თუმცა სკრამი მომხმარებლის ისტორიებს, Story Points-სა და დაგეგმვის პოკერს არ მოითხოვს. გავრცელებული რეკომენდაციის ოფიციალურ წესში არევა ჩარჩოს იმაზე რთულად წარმოაჩენს, ვიდრე სინამდვილეშია.

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

რას უნდა ნიშნავდეს წარმატება სინამდვილეში

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

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