როგორ უნდა მართო დამოკიდებულებები Scrum-ში

ამ სტატიაში მოგიყვები, რას ნიშნავს დამოკიდებულებები Scrum-ში, როგორი ტიპის დამოკიდებულებები არსებობს და როგორ უნდა მოხდეს მათი მართვა.

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

გიზიარებ დამოკიდებულებების სამ ძირითად კატეგორიას, რომლებმაც შესაძლოა Scrum გუნდის ცხოვრებაში თავი იჩინოს.

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

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

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

• Product backlog item-ებს შორის დამოკიდებულებები;

• Sprint backlog item-ებს შორის დამოკიდებულებები;

ნებისმიერი შემთხვევაში, ეს დამოკიდებულებებიც საჭიროებენ შესაბამის ქმედებებს, რომელიც შეიძლება იყოს:

• მეტად დამოუკიდებელი Backlog item-ების შესაქმნელად გუნდმა შეიძლება გამოიყენოს Backlog Refinement ან/და Sprint Planning შეხვედრები, რათა ხელახლა გაიაზროს და საჭიროების შემთვევაში მოახდინოს Backlog item-ების დეკომპოზიცია და გადააზრება.

• Sprint Planning-ზე გუნდმა გაიაზროს პოტენციური რისკები, რომლებმაც შესაძლოა გამოიწვიონ Item-ებს შორის დამოკიდებულელები და იმსჯელონ, როგორ შეიძლება აღნიშნული რისკების მართვა.

გუნდებს შორის დამოკიდებულებები

ეს დამოკიდებულების შედარებით რთული სცენარია, როდესაც რამდენიმე გუნდი მუშაობს ერთი პროდუქტის ბექლოგზე. ეს არის მდგომარეობა, როდესაც Scrum გუნდი Sprint Backlog-ში მოცემულ ამოცანებს დამოუკიებლად ასრულებს, მაგრამ მომხმარებლისთვის პროდუქტის მიწოდებისთვის ჭირდება სხვა გუნდებთან კოორდინაცია და ტექნიკურ საკითხებთან დაკავშირებით მუდმივი სინქრონიზაცია.

თუ არ გავართულებთ და მსჯელობაში არ შემოვიყვანთ scaling-ის მოდელებს (Nexus, LeSS, SAFe და ა.შ) აღნიშნული კატეგორიის მართვა შესაძლებელია ეფექტური იყოს შემდეგი პრაქტიკებით:

• მნიშვნელოვანია, ე.წ "ცენტრალურ ბექლოგს" ყავდეს Product Owner, რომელიც აღნიშნული ბექლოგის ჭრილში იქნება პასუხისმგებელი პრიორიტეტიზაციაზე;

• Feature Bazar კონცეპტის დანერგვა, სადაც "ცენტრალური ბექლოგის" Product Owner გამოიტანს ახალ Epic, User Story-ებს. ამის შემდეგ გუნდები ირჩევენ საკითხებს, რომლებზეც სურთ მუშაობა. საკითხების გუნდებზე მინიჭების შემდეგ, სწრაფადვე უნდა ჩატარდეს Cross-Team Refinement შეხვედრა.

• Cross-Team Refinement შეხვედრის დანერგვა, რომელიც გუნდების ერთმანეთზე დამოკიდებულებას გამჭირვალეს გახდის და იქნება ადგილი, სადაც ისინი შეძლებენ იმსჯელონ აღნიშნული დამოკიდებულის მართვასა და თავიდა არიდებაზე

• Cross-Team Refinement შეხვედრა უნდა ტარდებოდეს მუდმივად და უნდა ხდებოდეს დამოკიდებულებების ვიზუალიზაცია (შესაბამისი Board-ის ან ნებისმიერი სხა ინსტრუმენტის საშუალებით)

• Scrum of Scrums კონცეპტს დანერგვა. ეს არის scaled agile ტექნიკა, რომელიც ეხმარება ბევრ გუნდს საქმის კოორდინაციასა და სინქრონიზაციაში.

სხვა გუნდზე, სერვისზე, ვენდროზე დამოკიდებულებები

ეს დამოკიდებულების ყველაზე რთული სცენარია, როდესაც Scrum გუნდს არ შეუძლია დამოუკიებლად დაიწყოს ან/და დაასრულოს product backlog item-ზე მუშაობა სხვა გუნდის, დეპარტამენტის, Vendor-ის დახმარების გარეშე.

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

• პირველ რიგში უნდა დარწმუნდე, რომ გუნდის Capacity-ში გათვალისწინებულია აღნიშნული კატეგორიის დამოკიდებულებები

• იმ შემთხვევაში, თუ დამოკიდებულებები გამოწვეულია მესამე მხარის არასტაბულური სერვისების ან/და ნებისმიერ სხვა საკითხით, მაშინ მნიშვნელოვანია, რომ აღნიშნულ მომწოდებელთან იქონიო მჭიდო კომუნიკაცია. სასურველია, რომ ამ შემთხვევაში სერვისის მოწოდება გათვალისნებული იყოს SLA (Service Level Ageement) ტიპის დოკუმენტით.

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

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