.png){kind=small}
ოდესმე გიფიქრია, რატომ გამოუვიდა ზოგიერთ გუნდს მაგარი პროდუქტი, ხოლო ზოგს - არა? საქმე ისაა, რომ წარმატებული პროდუქტის უკან ყოველთვის დგას კარგად განსაზღვრული ხარისხის სტანდარტები.
სწორედ ამ სტანდარტების განსაზღვრაში გვეხმარება Definition of Done (DoD). გადავწყვიტე გაგიზიარო 10 ყველაზე გავრცელებული მითი DoD-ის შესახებ, რომელთა გაცნობაც დაგეხმარება თავი აარიდო ტიპურ შეცდომებს შენს პროექტებში.
მითი 1: DoD საჭიროა მხოლოდ Feature მზაობის შესამოწმებლად
ერთი შეხედვით ეს მართალი ჩანს - გუნდი ხომ მართლაც ამოწმებს ფუნქციონალის მზაობას მისი დასრულების შემდეგ. თუმცა, სინამდვილეში DoD გამოიყენება მთლიანი პროდუქტის ინკრემენტისთვის. შენი მიზანია დარწმუნდე, რომ ახალი ფუნქციონალი არა მხოლოდ სწორად მუშაობს, არამედ არ აზიანებს არსებულსაც. სწორედ ამიტომ ხდება ტესტირების ავტომატიზაცია ასეთი მნიშვნელოვანი - ის გეხმარება ხშირად და საიმედოდ შეამოწმო მთლიანი პროდუქტის გამართულობა.
მითი 2: DoD არის უბრალოდ მოთხოვნების სია
როდესაც მოთხოვნებზე საუბრობ, ხშირად მხოლოდ ფუნქციონალური მოთხოვნები გახსენდება. თუმცა არსებობს სხვა ტიპის მოთხოვნებიც: არაფუნქციონალური მოთხოვნები, ხარისხის სტანდარტები და ზოგჯერ პროცესის მოთხოვნებიც კი.
ფუნქციონალურ მოთხოვნებს DoD-ში ადგილი არ აქვთ - ისინი პროდუქტის ბექლოგში უნდა იყოს. DoD-ში თავს იყრის ხარისხის სტანდარტები, გუნდური შეთანხმებები (მაგალითად, კოდის განხილვის წესები) და პროდუქტის გამოშვების პროცედურები. თუ გყავს სრულფასოვანი კროს-ფუნქციური გუნდი, აქ შეიძლება შევიდეს რელიზის შემდგომი აქტივობებიც - მაგალითად, მომხმარებლების ინფორმირება ან მეტრიკების შეგროვება.
მითი 3: DoD იგივეა, რაც ჩაბარების კრიტერიუმები
ეს ორი ცნება განსხვავებულია. მიღების კრიტერიუმები გეხმარება შეამოწმო, რამდენად შეესაბამება კონკრეტული ფუნქციონალი მოლოდინებს. ისინი იცვლება feature-ის მიხედვით. DoD კი მთლიან პროდუქტზე ვრცელდება და მუდმივია. თუმცა, კარგი პრაქტიკაა DoD-ში გქონდეს პუნქტი იმის შესახებ, რომ ყველა მიღების კრიტერიუმი უნდა იყოს დაკმაყოფილებული.
მითი 4: DoD განსაზღვრავს Fteature-ის წარმატებას
ეს არასწორი შეხედულებაა. DoD შეიცავს პროდუქტის ხარისხის სტანდარტებს და ვერ გეტყვის, რამდენად წარმატებულია შენი ფუნქციონალი ბიზნეს მიზნების თვალსაზრისით. თუმცა, DoD-ში შეგიძლია ჩართო ისეთი პუნქტები, რომლებიც დაგეხმარება წარმატების გაზომვაში - მაგალითად, ანალიტიკის მარკერების დაყენება ან მეტრიკების შეგროვების გეგმის შემუშავება.
მითი 5: DoD შეცვლა არ შეიძლება
ესეს მცდარი შეხედულებაა. DoD არის "ცოცხალი" დოკუმენტი, რომელიც უნდა ვითარდებოდეს შენს გუნდთან ერთად. თუ ხედავ, რომ პროდუქტის ხარისხის გასაუმჯობესებლად რაიმე ცვლილებაა საჭირო, თამამად შეიტანე ეს ცვლილება DoD-ში. მაგალითად, თუ გადაწყვიტე code review-დან წყვილში პროგრამირებაზე გადასვლა, ეს ცვლილება უნდა აისახოს შენს DoD-ში. სქრამში ამისთვის სპეციალური ადგილიც კი არსებობს - სპრინტის რეტროსპექტივა.
მითი 6: DoD მხოლოდ დეველოპერების საქმეა
სქრამში არ არსებობს დაყოფა "დეველოპერებად" და "ბიზნესად". არის ერთიანი სქრამ გუნდი, სადაც ყველა - Product Owner-იც და დეველოპერებიც - ერთად მუშაობენ პროდუქტის შესაქმნელად. DoD არის მთელი გუნდის საერთო შეთანხმება ხარისხის სტანდარტებზე. შეუძლებელია ეს სტანდარტები მხოლოდ გუნდის ნაწილს ეხებოდეს.
მითი 7: DoD არააუცილებელი ელემენტია
კენ შვაბერმა 2011 წლის Scrum Guide-ის პრეზენტაციაზე ასე რამე თქვა: თუ სქრამის ერთ ელემენტზე დაყვანა მოგვიწევდა, ეს იქნებოდა Done ინკრემენტი. შესაბამისად, DoD, რომელიც განსაზღვრავს რას ნიშნავს "Done", არის ფრეიმვორკის ერთ-ერთი უმნიშვნელოვანესი ნაწილი. ის გეხმარება უზრუნველყო გამჭვირვალობა და საერთო გაგება იმისა, თუ რას ნიშნავს დასრულებული სამუშაო.
მითი 8: დიდი DoD ანელებს Development-ის პროცესს
წარმოიდგინე შემდეგი სიტუაცია: შენი გუნდი პროდუქტს ქმნის და ყველაფერს ხელით ტესტავს. დროთა განმავლობაში, ფუნქციონალის ზრდასთან ერთად, ტესტირება სულ უფრო მეტ დროს მოითხოვს. გადაწყვეტ ტესტების ავტომატიზაციას და ამას DoD-ში ჩაწერ. თავდაპირველად ეს მართლაც შეანელებს Development-ს. საჭიროა ტესტების დაწერა და ახალი უნარების შესწავლა. თუმცა გრძელვადიან პერსპექტივაში ეს დაგიზოგავს დროს უფრო სწრაფი და საიმედო ტესტირების ხარჯზე.
მითი 9: სხვადასხვა დავალებას შეიძლება განსხვავებული DoD ჰქონდეს
შენს ბექლოგში სხვადასხვა მოცულობის სამუშაოები გექნება. ზოგი მთელ პროდუქტს შეეხება, ზოგი - მხოლოდ ერთ კომპონენტს. მაგალითად, თუ მხოლოდ ვებ-გვერდზე ტექსტს ცვლი, არ გჭირდება ბექენდის სრული ტესტირება. თუმცა ეს არ ნიშნავს, რომ DoD განსხვავებული უნდა იყოს - უბრალოდ ზოგიერთი პუნქტი შეიძლება არ იყოს რელევანტური კონკრეტული დავალებისთვის.
მითი 10: DoD მხოლოდ ერთი გუნდისთვისაა
DoD მიეკუთვნის პროდუქტს და არა გუნდს. თუ შენს პროდუქტზე რამდენიმე გუნდი მუშაობს, მათ უნდა ჰქონდეთ საერთო DoD. ეს განსაკუთრებით მნიშვნელოვანია, როცა გუნდებს საერთო Code base აქვთ - საერთო DoD საშუალებას გაძლევს შეათანხმო კოდის სტანდარტები, ტესტირების მიდგომები და სხვა მნიშვნელოვანი საკითხები. ამასთან, თითოეულ გუნდს შეიძლება ჰქონდეს დამატებითი პუნქტები, რომლებიც აზუსტებს საერთო DoD-ს მათი სპეციფიკის გათვალისწინებით.
როგორც ხედავ, DoD არის გაცილებით მეტი, ვიდრე უბრალო ჩექლისტი. ის არის შენი გუნდის ხარისხის გარანტი და წარმატების საწინდარი. მთავარია გახსოვდეს, რომ DoD უნდა იყოს მოქნილი, გუნდის საჭიროებებზე მორგებული და მუდმივად განვითარებადი. ნუ მოგერიდება მისი გადახედვა და განახლება - ეს არის საუკეთესო გზა პროდუქტის ხარისხის მუდმივი გაუმჯობესებისკენ.
Comments