კომპიუტერული ინდუსტრია სავსეა ორაზროვანი ენებით, უხეში ჟარგონითა და რთული იდეებით, რომლებიც ძნელად გასაგებია და შეიძლება თქვენი გონება გამოთვლითი ბუფერირების აზარტში გადაიყვანოს.
ჩანჩქერი? სკრამი? სწრაფი?
თუ ეს ფრაზები სრულიად უცხოა თქვენთვის, არ ინერვიულოთ; HashDork-ის ტექნიკური პერსონალის თქვენი დამხმარე გუნდი აქ არის, რათა დაგეხმაროთ გაიგოთ განსხვავება განვითარების პროცესის ამ გადამწყვეტ ეტაპებს შორის, რათა გახდეთ მცოდნე.
მოქნილი, სკრამის და ჩანჩქერის ტექნიკა იქნება გაშუქებული ამ ბლოგპოსტში, ასევე, თუ როგორ შეუძლია თითოეულ მათგანს დაეხმაროს თქვენს გუნდს მთლიანობაში.
დავიწყოთ მოქნილებით, დანარჩენს კი გავაგრძელებთ.
რა არის სწრაფი?
სწრაფი პროგრამული უზრუნველყოფის შემუშავება მიჰყვება განმეორებით, თანდათანობით მიდგომას. პროექტის დასაწყისში ვრცელი მომზადების ნაცვლად, Agile ტექნიკა მოქნილია დროთა განმავლობაში ცვალებად საჭიროებებთან მიმართებაში და ხელს უწყობს საბოლოო მომხმარებლების უწყვეტ გამოხმაურებას.
ჯვარედინი ფუნქციური გუნდები მუშაობენ პროდუქტის გამეორებაზე დროთა განმავლობაში, და ეს ნამუშევარი იყოფა ნაკლოვანებად და პრიორიტეტულია ბიზნესის ან მომხმარებლის ღირებულებიდან გამომდინარე. თითოეული გამეორების მიზანია შექმნას გამოსაყენებელი პროდუქტი.
ლიდერობა ხელს უწყობს თანამშრომლობას, პასუხისმგებლობას და პირისპირ კომუნიკაციას Agile მეთოდოლოგიებში.
ბიზნესის დაინტერესებული მხარეები და დეველოპერები უნდა ითანამშრომლონ, რათა უზრუნველყონ, რომ პროდუქტი აკმაყოფილებს მომხმარებლის მოთხოვნებს და კომპანიის მიზნებს.
ფრაზა „სწრაფი განვითარება“ ეხება მრავალფეროვან მეთოდებსა და ჩარჩოებს, რომლებიც ეფუძნება იდეალებსა და დებულებებს. სწრაფი მანიფესტი.
ექსპერტები გვირჩევენ დაიცვან მოქნილი პრინციპები და ღირებულებები და გამოიყენოთ ისინი სახელმძღვანელოდ, რათა გადაწყვიტოთ სწორი ქმედებები კონკრეტულ გარემოში პროგრამული უზრუნველყოფის შემუშავებისას.
კოლაბორაციული და თვითორგანიზებული გუნდი არის პროგრამული უზრუნველყოფის განვითარების სწრაფი საზოგადოების ძირითადი მიმართულება.
გუნდებს უფლება აქვთ დამოუკიდებლად გადაწყვიტონ, თუ როგორ გაუმკლავდებიან კონკრეტულ პროექტს, მაგრამ ეს არ ნიშნავს, რომ ზედამხედველები არ არიან. სწრაფი გუნდები, შესაბამისად, ჯვარედინი ფუნქციონალურია.
მოქნილ პარადიგმაში მენეჯერები ჯერ კიდევ აუცილებელია. ისინი დარწმუნდებიან, რომ გუნდის თითოეულ წევრს აქვს ან იძენს პროექტისთვის აუცილებელ უნარებს.
მენეჯერები მოქნილ ჩარჩოში მოქმედებენ ატმოსფეროს შემუშავებით, რომელიც გუნდში საუკეთესოს გამოიმუშავებს. მაგრამ ნაცვლად ლიდერობისა, ისინი ხშირად იკავებენ მეორე ადგილს და აძლევენ გუნდს გადაწყვეტილების მიღების საშუალებას.
მენეჯერები მხოლოდ მაშინ ჩაერთვებიან, როდესაც გუნდები არაერთხელ ცდილობენ პრობლემების უშედეგოდ გადაჭრას.
სწრაფი განვითარების ციკლი
Agile განვითარების ციკლის ეტაპები ჩამოთვლილია ქვემოთ. მნიშვნელოვანია გვახსოვდეს, რომ ეს ფაზები არ უნდა მოხდეს წესრიგში, რადგან ისინი მოქნილია და მუდმივად ცვალებადია. ამ ეტაპებიდან ბევრი ერთდროულად მიმდინარეობს.
- დაგეგმვა: მას შემდეგ რაც პროექტის გუნდმა გადაწყვიტა, რომ იდეა პრაქტიკული და გამოსადეგია, ისინი იწყებენ ფუნქციების ძიებას. ეს ეტაპი მიზნად ისახავს თითოეული მახასიათებლის პრიორიტეტიზაციას და მას განმეორებით მინიჭებას მას შემდეგ, რაც იდეის დაყოფა მცირე სამუშაო ნაწილებად (ფუნქციები).
- მოთხოვნების ანალიზი: ბიზნესის მოთხოვნების დასადგენად, ეს ნაბიჯი მოიცავს რამდენიმე დისკუსიას მენეჯერებთან, დაინტერესებულ მხარეებთან და მომხმარებლებთან. ვინ გამოიყენებს პროდუქტს და როგორ გამოიყენებს მას, გუნდმა უნდა შეაგროვოს დეტალები. ეს სტანდარტები უნდა იყოს სპეციფიკური, გამოსაყენებელი და რაოდენობრივი.
- დიზაინი: წინა ეტაპზე ნაპოვნი მოთხოვნები გამოიყენება სისტემის და პროგრამული დიზაინის მოსამზადებლად. ჯგუფმა უნდა გაითვალისწინოს პროდუქტის ან ხსნარის გარეგნობა. ტესტის სტრატეგია ან გეგმა ასევე შეიმუშავებს ტესტის ჯგუფს.
- დანერგვა, კოდირება ან განვითარება: ამ ეტაპის ყურადღება გამახვილებულია მახასიათებლების აგებასა და შეფასებაზე და გამეორებების განლაგების დაგეგმვაზე (იტერაციული და ინკრემენტული განვითარების მიდგომის მიხედვით [IID]). იმის გამო, რომ არ არის მოწოდებული ფუნქციები, იწყება განვითარების პერიოდის გამეორება 0. ისეთი აქტივობების დასრულებით, როგორიცაა კონტრაქტი, პარამეტრების დაყენება და დაფინანსება, ეს გამეორება ქმნის საფუძველს მომავალი ზრდისთვის.
- ტესტირება: კოდის შექმნის შემდეგ, ის შემოწმდება მოთხოვნების შესაბამისად, რათა დარწმუნდეს, რომ პროდუქტი ნამდვილად აკმაყოფილებს მომხმარებლის მოთხოვნებს და აკმაყოფილებს ბიზნესის მიზნებს. ამ ეტაპზე ტარდება ერთეულის, ინტეგრაციის, სისტემის და მისაღები ტესტირება.
- განლაგება: ტესტირების შემდეგ, პროდუქტი ეგზავნება კლიენტებს, რათა მათ შეძლონ მისი გამოყენება. თუმცა, განლაგების შემდეგ პროექტი არ დასრულებულა. პროდუქტის გამოყენების დაწყების შემდეგ მომხმარებელს შეუძლია წააწყდეს დამატებითი პრობლემები, რაც პროექტის გუნდს დასჭირდება გამოსავლის მოსაძებნად.
უპირატესობები
- უფრო სწრაფი, უმაღლესი ხარისხის მიწოდება: პროექტის გამეორებად (მართვადი ერთეულებად) დაყოფით გუნდს შეუძლია კონცენტრირება მოახდინოს უმაღლესი ხარისხის თანამშრომლობაზე, განვითარებასა და ტესტირებაზე. როდესაც ტესტირება კეთდება ყოველი გამეორებით, პრობლემები უფრო სწრაფად მოიძებნება და აგვარდება. გარდა ამისა, მუდმივი, შემდგომი გადასინჯვით, ამ მაღალი ხარისხის პროგრამული უზრუნველყოფის მიწოდება უფრო სწრაფად შეიძლება.
- ცვლილება მისასალმებელია: მიუხედავად იმისა, რომ დაგეგმვის ციკლები უფრო მოკლეა, მარტივია ცვლილებების მიღება და დაკმაყოფილება პროექტის ნებისმიერ ეტაპზე. ნარჩენები ყოველთვის შეიძლება გაუმჯობესდეს და პრიორიტეტულად განისაზღვროს, რაც გუნდებს საშუალებას მისცემს შეიტანონ ცვლილებები პროექტში რამდენიმე კვირაში.
- საბოლოო მიზანი შეიძლება არ იყოს ცნობილი: Agile შესანიშნავია პროექტებისთვის, როდესაც საბოლოო მიზანი მკაფიოდ არ არის განსაზღვრული. როგორც პროექტი წინ მიიწევს, მიზნები გახდება ნათელი და განვითარება შეძლებს ადვილად დააკმაყოფილებს ამ ცვალებად საჭიროებებს.
- უწყვეტი გაუმჯობესება: მოქნილი პროგრამები ხელს უწყობს მომხმარებლის და გუნდის შეყვანას პროექტის ყველა ეტაპზე, რაც საშუალებას იძლევა გამოიყენოს ის, რაც ისწავლეს შემდგომი გამეორების უკეთესად.
- მომხმარებელთა აზრი ფასდება: მომხმარებელს აქვს რამდენიმე შესაძლებლობა, უყუროს სამუშაოს დასრულებას, შესთავაზოს გამოხმაურება და რეალურ შედეგზე გავლენა მოახდინოს. პროექტის გუნდთან ასე მჭიდრო ურთიერთობით, მათ შესაძლოა განუვითარდეთ საკუთრების გრძნობა.
- ძლიერი გუნდური მუშაობა: Agile ხაზს უსვამს რეგულარული კომუნიკაციისა და პირისპირ შეხვედრების მნიშვნელობას. ადამიანებს შეუძლიათ აიღონ პასუხისმგებლობა და ფლობდნენ პროექტის გარკვეულ კომპონენტებს გუნდში მუშაობისას.
ნაკლოვანებები
- გუნდის წევრებს უნდა ჰქონდეთ ცოდნაე: სწრაფი გუნდები ხშირად მცირეა. ამრიგად, გუნდის წევრებს უნდა ჰქონდეთ უნარების ფართო სპექტრი. გარდა ამისა, მათ უნდა გაიგონ და თავი კომფორტულად იგრძნონ შერჩეული Agile ტექნიკის გამოყენებით.
- დაგეგმვა შეიძლება ნაკლებად ზუსტი იყოს: ზოგჯერ შეიძლება რთული იყოს მიწოდების ზუსტი თარიღის დადგენა. Agile აგებულია დროში შეზღუდულ მიწოდებაზე და პროექტის მენეჯერები ხშირად ანაწილებენ ამოცანების პრიორიტეტებს. ამრიგად, სავარაუდოა, რომ ზოგიერთი მიწოდება, რომელიც თავდაპირველად იყო დაგეგმილი, დროულად არ დასრულდება. გარდა ამისა, მეტი სპრინტი შეიძლება დაემატოს პროექტის ნებისმიერ ეტაპზე, რაც გაახანგრძლივებს მთელ განრიგს.
- დოკუმენტაცია შეიძლება უგულებელყო: გუნდის ზოგიერთ წევრს შეიძლება სჯეროდეს, რომ დოკუმენტაციაზე კონცენტრირება ნაკლებად მნიშვნელოვანია, რადგან Agile Manifesto უპირატესობას ანიჭებს სამუშაო პროგრამულ უზრუნველყოფას საფუძვლიან დოკუმენტაციაზე მაღლა. სწრაფი გუნდებმა უნდა დაამყარონ იდეალური ბალანსი დოკუმენტაციასა და დიალოგს შორის, მაშინაც კი, როცა საფუძვლიანი დოკუმენტაცია ვერ უზრუნველყოფს პროექტის წარმატების გარანტიას.
- საბოლოო გამომავალი შეიძლება მნიშვნელოვნად განსხვავდებოდეს: შეიძლება არ არსებობდა მკაფიო სტრატეგია Agile-ის საწყისი პროექტისთვის და, შესაბამისად, დასრულებული შედეგი შეიძლება მნიშვნელოვნად შეიცვალოს თავიდან მოსალოდნელისგან. არსებითად განსხვავებული საბოლოო შედეგი შეიძლება მოჰყვეს კლიენტის შეყვანის შეცვლაზე დაფუძნებული ახალი გამეორებების დამატებით, რადგან Agile იმდენად ადაპტირებადია.
- დეველოპერების დროის ვალდებულება: განვითარების გუნდი სრულად უნდა იყოს ერთგული პროექტის მიმართ, რათა სწრაფი იყოს ეფექტური. Agile მეთოდი, რომელსაც უფრო მეტი დრო სჭირდება, ვიდრე ჩვეულებრივი მიდგომა, მოითხოვს მუდმივ აქტიურ მონაწილეობას და თანამშრომლობას. გარდა ამისა, ეს გულისხმობს, რომ დეველოპერებმა უნდა დაიცვან პროექტის სრული ხანგრძლივობა.
რა არის ჩანჩქერი?
სისტემის განვითარების სასიცოცხლო ციკლის (SDLC) ყველაზე პოპულარული გამეორება პროგრამული უზრუნველყოფის ინჟინერიისა და IT პროექტებისთვის ცნობილია როგორც „ჩანჩქერის მიდგომა“, რომელიც მიჰყვება თანმიმდევრულ, ხაზოვან პროცედურას.
Gantt-ის დიაგრამა, ზოლიანი დიაგრამის ფორმა, რომელიც აჩვენებს თითოეული სამუშაოს დაწყების და დასრულების თარიღებს, ზოგჯერ გამოიყენება მის დასაგეგმად.
დეველოპერული გუნდი მიიწევს შემდეგ დონეზე რვა ფაზიდან ერთ-ერთი დასრულების შემდეგ. გუნდს არ შეუძლია დაუბრუნდეს წინა ეტაპზე მთელი პროცედურის გადატვირთვის გარეშე.
გარდა ამისა, კლიენტს შეიძლება დასჭირდეს მოთხოვნების შეფასება და მიღება, სანამ გუნდი მომდევნო დონეზე გადავა.
ჩანჩქერის მოდელი შემუშავდა წარმოებისა და სამშენებლო სექტორების მაღალ ორგანიზებულ გარემოში, სადაც კორექტირება შეიძლება იყოს ძალიან ძვირი ან თუნდაც შეუძლებელი.
ჩანჩქერის ტექნიკას ასე ეწოდა, რადგან ის გამიზნულია მხოლოდ ერთი მიმართულებით - ქვევით - ჩანჩქერის მსგავსად მიედინება. მისი ფაზები მოიცავს ანალიზს, დაწყებას, ტესტირებას, დიზაინს, მშენებლობას, განლაგებას, შენარჩუნებას და ტესტირებას.
ჩანჩქერის ტექნიკას აქვს რამდენიმე უპირატესობა, ისევე როგორც ნებისმიერ სხვა სტრატეგიას. ერთი ის არის, რომ პროექტის დაგეგმვისა და დიზაინის ფაზები უფრო კარგად არის ჩამოყალიბებული.
მომხმარებლები და დეველოპერების გუნდი უფრო თანმიმდევრულები არიან, როდესაც საქმე ეხება პროექტის მიწოდებას, ჩანჩქერის პროგრამული უზრუნველყოფის გამოყენებისას. იმის გამო, რომ თქვენ თავიდანვე იცით პროექტის ფარგლები, ჩანჩქერის განვითარება ასევე აადვილებს პროგრესის მონიტორინგს.
ჩანჩქერის პროცესი იყენებს სპეციალისტებს, დეველოპერებს, ანალიტიკოსებს და ტესტერებს, რათა კონცენტრირდნენ პროექტში თავიანთ სამუშაოებზე, ვიდრე მთელი გუნდის ხაზგასმა ერთ ნაბიჯზე.
ჩანჩქერის ეტაპები
ჩანჩქერის ექვსი ნაბიჯი ერთმანეთის მიყოლებით უნდა მოხდეს:
- მოთხოვნების შეგროვება და შენახვა: თქვენ უნდა დააგროვოთ საფუძვლიანი ცოდნა იმის შესახებ, თუ რას მოითხოვს ეს პროექტი ამ დროს. ამ მონაცემების შეგროვების რამდენიმე ტექნიკა არსებობს, მათ შორის ინტერვიუები, გამოკითხვები და ერთობლივი გონებრივი შტორმი. პროექტის საჭიროებები აშკარა უნდა იყოს ამ ეტაპის დასრულებამდე და თქვენს გუნდს უნდა მიეღო მოთხოვნების დოკუმენტის ასლი.
- სისტემის დიზაინი: სისტემა შექმნილია თქვენი გუნდის მიერ წინასწარ განსაზღვრული სპეციფიკაციების გამოყენებით. ამ ეტაპზე კოდირება არ კეთდება, მაგრამ გუნდი ადგენს მოთხოვნებს ტექნიკის ან პროგრამირების ენაზე.
- განხორციელება: ეს ეტაპი მოიცავს კოდირებას. წინა ეტაპის მონაცემებს იყენებენ პროგრამისტები გამოსაყენებელი პროდუქტის შესაქმნელად. კოდი ხშირად ხორციელდება პატარა ნაწილებად, რომლებიც გაერთიანებულია ერთი ფაზის დასასრულს ან მეორის დასაწყისში.
- ტესტირება: პროდუქტის ტესტირება შეიძლება დაიწყოს კოდის დასრულების შემდეგ. ნებისმიერი პრობლემა საგულდაგულოდ არის ნაპოვნი და მოხსენებული ტესტერების მიერ. თქვენს პროექტს შეიძლება დასჭირდეს დაბრუნება პირველ ფაზაში ხელახალი შეფასებისთვის, თუ მნიშვნელოვანი პრობლემები გამოჩნდება.
- მიწოდება/განლაგება: პროდუქტი ამ ეტაპზე დასრულებულია და თქვენი გუნდი წარუდგენს მიწოდებას განსათავსებლად ან გასაშვებად.
- ტექნიკური: კლიენტმა მიიღო პროდუქტი და იყენებს მას. თქვენს გუნდს შეიძლება დასჭირდეს შესწორებებისა და განახლებების შემუშავება, როდესაც პრობლემები გამოჩნდება მათ გამოსასწორებლად. კიდევ ერთხელ, მნიშვნელოვანმა პრობლემებმა შეიძლება მოითხოვოს პირველ საფეხურზე დაბრუნება.
უპირატესობები
- მარტივი მუშაობა და მართვა: ჩანჩქერის მიდგომა მარტივია გამოსაყენებლად და გასაგებად, რადგან თითოეული პროექტი განიხილება იმავე თანმიმდევრობით. ჩანჩქერის პროექტის დაწყებამდე გუნდს არ მოეთხოვება რაიმე წინასწარი ექსპერტიზა ან ტრენინგი. ჩანჩქერის მიდგომა ძალიან მკაცრია; თითოეულ ეტაპს აქვს მიწოდების კომპლექტი და მიმოხილვა, რაც მარტივს ხდის მის ადმინისტრირებას და შენარჩუნებას.
- საჭიროა კარგად დოკუმენტირებული მეთოდოლოგია: ჩანჩქერის მეთოდოლოგიით მოთხოვნილი დოკუმენტაცია ხელს უწყობს ტესტებისა და კოდის უკან დასაბუთების გარკვევას. გარდა ამისა, ის ქმნის ქაღალდის კვალს იმ შემთხვევაში, თუ დაინტერესებულ მხარეებს სურთ დამატებითი ინფორმაცია გარკვეულ ფაზაზე ან მომავალ ინიციატივებზე.
- დისციპლინის აღსრულება: ჩანჩქერის პროექტში ყოველ ნაბიჯს აქვს დასაწყისი და დასასრული, რაც ამარტივებს პროგრესის კომუნიკაციას დაინტერესებულ მხარეებთან და კლიენტებთან. გუნდს შეუძლია შეამციროს ვადის დაკარგვის შესაძლებლობა, კოდის წარმოებამდე პირველ რიგში დააყენოს მოთხოვნები და დიზაინი.
ნაკლოვანებები
- შეიძლება რთული იყოს ზუსტი მოთხოვნების შეგროვება: მომხმარებლებთან და დაინტერესებულ მხარეებთან საუბარი მათი საჭიროებების დასადგენად არის ჩანჩქერის პროექტის ერთ-ერთი საწყისი ეტაპი. პროექტის ამ ადრეულ ეტაპზე შესაძლოა რთული იყოს მათი კონკრეტული მოთხოვნების დადგენა. კლიენტები ხშირად იგებენ თავიანთი მოთხოვნების შესახებ პროექტის განვითარებით, ვიდრე წინასწარ გამოხატონ ისინი.
- ცვლილებები რთულია: ეკიპაჟი ვერ განაახლებს მუშაობას ფაზის დასრულების შემდეგ. ძალიან რთული და ძვირია უკან დაბრუნება და შეკეთება, თუ ტესტირების ფაზაში გაიგებენ, რომ ფუნქციონირება აკლია მოთხოვნების პროცესში.
- პროგრამული უზრუნველყოფა მოწოდებულია მისი ვადის გასვლის შემდეგ: პროექტის ორი-ოთხი ეტაპი უნდა დასრულდეს რეალური კოდირების დაწყებამდე. შედეგად, დაინტერესებული მხარეები ვერ ნახავენ ფუნქციურ პროგრამულ უზრუნველყოფას სიცოცხლის ციკლის გვიანობამდე.
რა არის Scrum?
Agile-ის პრაქტიკაში გამოყენებისთვის ერთ-ერთი ყველაზე პოპულარული პროცესის ჩარჩო არის Scrum, რომელიც Agile-ის ქვეჯგუფია.
ეს არის განმეორებადი პარადიგმა რთული პროგრამული უზრუნველყოფისა და პროდუქტების შექმნის მართვისთვის. სპრინტები, რომლებიც არის ფიქსირებული სიგრძის გამეორებები, რომლებიც გრძელდება ერთიდან ორ კვირამდე, საშუალებას აძლევს გუნდს გამოუშვას პროგრამული უზრუნველყოფა რეგულარული გრაფიკით.
დაინტერესებული მხარეები და გუნდის წევრები იკრიბებიან, რათა განიხილონ შემდეგი ნაბიჯები ყოველი სპრინტის შემდეგ. როლები, პასუხისმგებლობები და შეხვედრები Scrum-ში მუდმივი რჩება.
მაგალითად, Scrum აკონკრეტებს სპრინტის დაგეგმვას, ყოველდღიურ სტენდი, სპრინტის დემო და სპრინტის რეტროსპექტივას, როგორც ოთხ რიტუალს, რომლებიც უზრუნველყოფენ თითოეულ სპრინტის სტრუქტურას.
გუნდი გამოიყენებს ვიზუალურ არტეფაქტებს, როგორიცაა დავალების დაფები ან დამწვრობის სქემები ყოველი სპრინტის დროს, რათა აჩვენოს პროგრესი და მიიღოს დამატებითი გამოხმაურება.
Scrum-ში გუნდი და პროდუქტის მფლობელი მჭიდროდ თანამშრომლობენ სისტემის ფუნქციონირების იდენტიფიცირებისთვის და პრიორიტეტებისთვის. ისინი ამას მიაღწევენ პროდუქტის ბექლოგის შექმნით, რომელიც შეიცავს ყველა ამოცანას, რომელიც აუცილებელია პროგრამული უზრუნველყოფის წარმოებისთვის, რომელიც ფუნქციონირებს დანიშნულებისამებრ.
შეცდომების პატჩები, არაფუნქციური მოთხოვნები და ფუნქციები უნდა იყოს შეტანილი რიგში. ჯვარედინი ფუნქციონალურმა გუნდებმა უნდა შეაფასონ და დარეგისტრირდნენ, რათა უზრუნველყონ პროგრამული უზრუნველყოფის ზრდა უწყვეტი სპრინტების განმავლობაში, რომლებიც, როგორც წესი, გრძელდება 30 დღე, მიზნების დადგენის შემდეგ.
მხოლოდ გუნდს შეუძლია დაამატოს ფუნქციონირება სპრინტზე ამ სპრინტზე ნარჩენების შესრულების შემდეგ.
შემდეგი სპრინტის მიწოდება, პროდუქტის ნარჩენები ფასდება და, საჭიროების შემთხვევაში, პრიორიტეტირებულია, და შემდეგი მიწოდების ნაკრები არჩეულია შემდეგი სპრინტის ნაწილად.
სკრამის პროცესი
- პროდუქტის backlog: პროდუქტის ბექლოგში არსებული ნივთების შესაკვეთად, პროდუქტის მფლობელი და Scrum გუნდი ხვდებიან (პროდუქტის ბექლოგზე მუშაობა მოდის მომხმარებლის ისტორიებიდან და მოთხოვნებიდან). პროდუქტის ბექლოგი არის პროდუქტის ყველა სასურველი მახასიათებლის სია და არა იმ ამოცანების ჩამონათვალი, რომლებიც უნდა დასრულდეს. ამის შემდეგ, დეველოპერების გუნდი ირჩევს დავალებებს პროდუქტის ნარჩენებიდან, რათა შეასრულოს ყოველი სპრინტის განმავლობაში.
- სპრინტის დაგეგმვა: ყოველი სპრინტის დაწყებამდე პროდუქტის მფლობელი გუნდს აწვდის სპრინტის დაგეგმვის შეხვედრაზე ჩამორჩენილ ძირითად პუნქტებს. შემდეგ ჯგუფი ირჩევს ნივთებს პროდუქტის ბექლოგიდან, რომლებიც მათ შეუძლიათ დაასრულონ სპრინტის დროს და გადააქვთ მათ სპრინტის ბექლოგში (ეს არის სპრინტში შესასრულებელი ამოცანების სია).
- ნარჩენების დახვეწა/მოწესრიგება: იმის უზრუნველსაყოფად, რომ ნარჩენები მომზადებულია შემდეგი სპრინტისთვის, გუნდი და პროდუქტის მფლობელი იკრიბებიან ერთი სპრინტის დასასრულს. გუნდს შეუძლია გააუქმოს მომხმარებლის ისტორიები, რომლებიც აღარ არის აქტუალური, დაამატოთ ახლები, გადახედოს მათი განხილვის თანმიმდევრობას, ან დაყოს მომხმარებლის ისტორიები მცირე ამოცანებად. ამ შეხვედრის დროს დარწმუნდებით, რომ ნარჩენები მხოლოდ აქტუალურ, სიღრმისეულ და პროექტის მიზნებს შეესაბამება.
- Scrum შეხვედრები ყოველდღე: 15-წუთიან შეხვედრაზე, რომელსაც ეწოდება Daily Scrum, გუნდის თითოეული წევრი განიხილავს თავის მიზნებს და წარმოშობილ პრობლემებს. ყოველდღე მთელი სპრინტის განმავლობაში, გუნდი მონაწილეობს Daily Scrum-ში, რომელიც ყველას ახორციელებს სამუშაოზე.
- შეხვედრა სპრინის შესაფასებლადt: გუნდი წარადგენს თავის ნამუშევარს სპრინტის მიმოხილვის შეხვედრაზე ყოველი სპრინტის დასასრულს. ანგარიშის ან PowerPoint პრეზენტაციის ნაცვლად, ეს შეხვედრა უნდა მოიცავდეს რეალურ დემონსტრაციას.
- რეტროსპექტიული სპრინტის შეხვედრა: გუნდი განიხილავს ნებისმიერ ცვლილებას, რომელიც უნდა განხორციელდეს შემდეგ სპრინტში და ასევე რამდენად კარგად მუშაობს Scrum მათთვის ყოველი სპრინტის დასასრულს. გუნდს შეუძლია განიხილოს სპრინტის დადებითი ასპექტები, უარყოფითი ასპექტები და გაუმჯობესების სფეროები.
უპირატესობები
- მეტი პასუხისმგებლობა გუნდისგან: არ არსებობს პროექტის მენეჯერი, რომელიც ავალებს scrum გუნდს რა და როდის გააკეთოს. სამუშაო, რომელიც შეიძლება დასრულდეს თითოეულ სპრინტში, წყვეტს მთლიანად გუნდს. ისინი ყველა თანამშრომლობენ და ხელს უწყობენ ერთმანეთს, აძლიერებენ გუნდურ მუშაობას და ხელს უწყობენ ინდივიდუალურობას გუნდის თითოეულ წევრში.
- გაუმჯობესებული პროექტის ხილვადობა და გამჭვირვალობა: ნაკლები გაუგებრობა და გაურკვევლობაა, რადგან გუნდში ყველამ იცის თავისი პასუხისმგებლობა ხშირი სტენდი შეხვედრების წყალობით. გუნდს შეუძლია გაუმკლავდეს პრობლემებს, სანამ ისინი კონტროლიდან გამოვა, რადგან პრობლემები წინასწარ არის გამოკვეთილი.
- გაძლიერებული ხარჯების შემცირება: მუდმივი კომუნიკაცია აცნობებს გუნდს ნებისმიერი პრობლემის ან ცვლილების შესახებ, როგორც კი ისინი მოხდება, რაც ხელს უწყობს ხარჯების დაზოგვას და ხარისხის გაუმჯობესებას. ფუნქციების მცირე ნაწილი უზრუნველყოფს მუდმივ უკუკავშირს და იძლევა შეცდომების ადრეული გამოსწორების საშუალებას, სანამ უფრო დიდი შეცდომების გამოსწორება ძალიან ძვირი გახდება.
- მარტივი ადაპტაცია ცვლილებებთან: ცვლილებებთან გამკლავება და ადაპტაცია უფრო მარტივია, როდესაც ხშირია უკუკავშირის ციკლები და მოკლე სპრინტები. ილუსტრაციისთვის, თუ გუნდს შეხვდება მომხმარებლის სრულიად ახალი ამბავი ერთი სპრინტის დროს, მათ შეუძლიათ სწრაფად დაამატონ ეს ფუნქცია შემდეგ სპრინტში, ბექლოგის დახვეწის შეხვედრაზე.
ნაკლოვანებები
- ფარგლების ცოცვის საფრთხე: დასრულების განსაზღვრული თარიღის არარსებობის გამო, Scrum-ის ზოგიერთ პროექტს შეიძლება დაემუქროს მასშტაბები. დაინტერესებულ მხარეებს შეუძლიათ გააგრძელონ მეტი ფუნქციის მოთხოვნა, თუ არ არის დასრულების ვადა.
- ცუდმა სკრამ მასტერმა შეიძლება ყველაფერი გადაშალოს: პროექტის მენეჯერი არ არის იგივე, რაც scrum master. Scrum Master-მა უნდა ენდოს გუნდს, რომელსაც ზედამხედველობს და არასოდეს მისცეს ინსტრუქციები. Scrum Master-ს არ აქვს ძალაუფლება გუნდზე. პროექტი ჩავარდება, თუ სკრამის მასტერი გუნდის მართვას შეეცდება.
- სიზუსტის პრობლემები შეიძლება წარმოიშვას არასწორად გაწერილი ამოცანების შედეგად: თუ ამოცანები მკაფიოდ არ არის მითითებული, პროექტის ხარჯები და განრიგი ზუსტი არ იქნება. დაგეგმვა ხდება რთული და სპრინტებს შესაძლოა მოსალოდნელზე მეტი დრო დასჭირდეს, თუ საწყისი მიზნები არ არის განსაზღვრული.
- გამოცდილება და ერთგულება აუცილებელია გუნდისთვის: იმისათვის, რომ გუნდი იყოს წარმატებული, როლები და მოვალეობები მკაფიოდ უნდა იყოს განსაზღვრული. Scrum Team მოითხოვს გუნდის წევრებს ტექნიკური უნარებით, რადგან არ არსებობს მკაფიოდ განსაზღვრული როლები (ყველა ყველაფერს აკეთებს). გუნდმა ასევე უნდა მიიღოს მონაწილეობა Scrum-ის ყოველდღიურ სესიებში და ერთად დარჩეს პროექტის სიცოცხლის განმავლობაში.
Agile Vs Scrum
მიუხედავად იმისა, რომ Agile და Scrum იყენებენ ერთსა და იმავე მეთოდოლოგიას, ამ ორს შორის არის გარკვეული ვარიაციები. Agile Manifesto ასახავს პროგრამული უზრუნველყოფის შექმნის პრინციპების ერთობლიობას განმეორებითი განვითარების გზით.
Scrum, თავის მხრივ, არის სახელმძღვანელო მითითებების ერთობლიობა, რომელიც უნდა დაიცვან Agile პროგრამული უზრუნველყოფის განვითარების დროს. Agile არის კონცეფცია, ხოლო Scrum არის მისი პრაქტიკაში გამოყენების ტექნიკა.
Scrum არის Agile-ის დანერგვის მეთოდი, ამიტომ ორივეს ბევრი რამ აქვს საერთო. ორივე მიდგომა განმეორებადია, პრიორიტეტი ენიჭება პროგრამული უზრუნველყოფის ადრეულ და ხშირ მიწოდებას და იღებს ცვლილებას. ისინი ასევე მხარს უჭერენ ღიაობას და მუდმივ განვითარებას.
სწრაფი Vs ჩანჩქერი
Rigid vs. flexible საუკეთესოდ აღწერს განსხვავებას Waterfall-ის პროცესსა და Agile-ს შორის. მიუხედავად იმისა, რომ Agile არის თხევადი და მუდმივად იცვლება, ჩანჩქერი ბევრად უფრო მკაცრი, უფრო მკაცრი მეთოდოლოგიაა.
ეს შემდგომი განსხვავებები მათ შორის შემდეგია:
- Agile არ საჭიროებს ხაზოვან მიდგომას, ხოლო ჩანჩქერი თანმიმდევრულია.
- მიუხედავად იმისა, რომ საჭიროებები ხშირად წინასწარ არის განსაზღვრული Waterfall-ის პროექტებში, მოსალოდნელია, რომ ისინი შეიცვლება და ადაპტირდება Agile ინიციატივებში.
- Agile-სგან განსხვავებით, ჩანჩქერის პროექტები არ იძლევა წინა ეტაპზე დასრულებულ სამუშაოზე ცვლილებების შეტანის საშუალებას.
- ჩანჩქერი არის ორგანიზებული პროცედურა, რომლის დროსაც თქვენ უნდა დაასრულოთ ყოველი ნაბიჯი შემდეგზე გადასვლამდე. თუმცა, Agile არის მოქნილი მეთოდოლოგია, რომელიც საშუალებას გაძლევთ განაგრძოთ პროექტი საკუთარი ტემპით.
Agile Vs ჩანჩქერი Vs Scrum
- ჩანჩქერი ზრდის ნდობას იმის მიმართ, რაც დაიგეგმება ძალიან მალე. Agile ეყრდნობა განვითარების გარემოს საუკეთესო პრაქტიკას. აქ, მრავალი პროექტის რისკის მართვა შესაძლებელია კარგად, რადგან შედეგები მუდმივად ფასდება.
- ჩანჩქერი არ ითვალისწინებს გუნდისა და პროექტის დაფუძნებას იმავე ადგილას. მიუხედავად იმისა, რომ სკრამს და სისწრაფეს სჭირდება თანამშრომელთა თანამდებარეობა.
- Agile ყურადღებას ამახვილებს პროექტის გადამუშავების შემცირებაზე და ხელს უწყობს ცვლილებების უფრო ადრე ჩართვას. ჩანჩქერისგან განსხვავებით, რომელიც განსხვავებულად რეაგირებს, სკრამი ასევე იძლევა ცვლილებების ადრეულ აღმოჩენას.
- საბოლოო პროდუქტის უფრო კომპაქტური გეგმა მოწოდებულია სწრაფი და scrum-ით. ეს ქმნის პრობლემას მყიდველისთვის მიცემულ დაპირებებთან დაკავშირებით. ამის საპირისპიროდ, ჩანჩქერის გრაფიკა კლიენტებსა და დეველოპერებს უკეთეს შთაბეჭდილებას ტოვებს დასრულებული შედეგის შესახებ.
- თითოეულ ამ ტექნიკას აქვს ინსტრუმენტების კომპლექტი მათი შექმნის პროცესში ჩართული ამოცანების ორგანიზებისა და სიმულაციისთვის.
დასკვნა
თუ აქამდე მიჰყევით და დარწმუნებული ხართ, რომ იცით განსხვავება Waterfall, Agile და Scrum პროცესებს შორის, თქვენ უკვე უნდა იცოდეთ რომელი სტრატეგია იმუშავებს საუკეთესოდ თქვენთვის და თქვენი გუნდისთვის.
ჩანჩქერის ტექნიკა, რომელიც განკუთვნილია გარკვეული მოცულობის, დროისა და ბიუჯეტის მქონე პროექტებისთვის, შეიძლება იყოს თქვენი საუკეთესო ვარიანტი, თუ მოგწონთ რთული წესები და პროცედურები და აღმოაჩენთ, რომ მათ სიცხადე მოაქვთ.
მეორეს მხრივ, თუ Agile-ის შეთავაზების თავისუფლება და ადაპტირება შთაგაგონებთ, ის შეიძლება იყოს ადგილი, სადაც ყურადღება უნდა მიაქციოთ.
Scrum არის გზა გასავლელი, თუმცა, თუ გსურთ ცოტა დისციპლინა მოქნილი ჩარჩოში.
თუმცა, თქვენ უნდა გაითვალისწინოთ ეს მიდგომები იმ პროექტის გათვალისწინებით, რომელზეც მუშაობთ და თქვენი საბოლოო შედეგი.
დატოვე პასუხი