ზოგიერთი Agile მიდგომა უკვე მოძველდა და საჭიროებს მოდერნიზაციას.
დღეს მინდა ტექნიკური User Story-ის დაწერის ტრადიციული მეთოდები (Invest, 3C და ა.შ) დავაჩელენჯო.
ბევრი კომპანიის დეველოპერთან კომუნიკაციის შედეგები და რეტროსპექტივების ანალიზი აჩვენებს, რომ მათთვის ტრადიციული Story Writting მიდგომა "As a [role], I want [feature] so that [benefit]" გაუგებარია და ვერ ხვდებიან რა ღირებულება უნდა შეიქმნას აღნიშნული ამოცანის ფარგლებში.
ამ ყველაფერს დავამატოთ, რომ ასევე საკმაოდ ხშირია, რომ Product Owner-ებსაც ხშირად არ აქვთ დეველოპერების კითხვაზე პასუხი.
გსმენია 4T Framework-ის შესახებ?
ეს არის ტექნიკური User Story-ების წერის მეთოდი, რომელიც შედგება 4 ელემენტისგან: Technical, Testable, Traceable, და Transparent.
Technical: მომხმარებლის ისტორია ნათლად უნდა აღწერდეს ტექნიკურ სამუშაოს, რომელიც უნდა გაკეთდეს. ეს მოიცავს ნებისმიერ ცვლილებას კოდების ბაზაში, მონაცემთა ბაზაში ან ინფრასტრუქტურაში.
Testable: მომხმარებლის ამბავი უნდა იყოს ტესტირებადი, რაც იმას ნიშნავს, რომ შესაძლებელი უნდა იყოს ავტომატური ტესტების დაწერა, რათა დადასტურდეს, რომ სამუშაო წარმატებით დასრულდა.
Traceable: მომხმარებლის ამბავი უნდა იყოს მიკვლევადი, რაც იმას ნიშნავს, რომ შესაძლებელი უნდა იყოს ნამუშევრის მიკვლევა თავდაპირველ მოთხოვნამდე ან ბიზნეს საჭიროებამდე.
Transparent: მომხმარებლის ამბავი უნდა იყოს გამჭვირვალე, რაც იმას ნიშნავს, რომ დაინტერესებული მხარეებისთვის ადვილი უნდა იყოს იმის გაგება, თუ რა კეთდება და რატომ.
როგორ უნდა დაწერო ტექნიკური User Story-ები 4T Framework-ის გამოყენებით:
ნათლად აღწერე ტექნიკური სამუშაო, რომელიც უნდა შესრულდეს. ეს შეიძლება მოიცავდეს ცვლილებებს კოდების ბაზაში, მონაცემთა ბაზაში ან ინფრასტრუქტურაში.
განსაზღვრე ჩაბარების კრიტერიუმები (Acceprance Criteria), რომლებიც გამოყენებული იქნება იმის დასადგენად, არის თუ არა სამუშაო წარმატებით დასრულებული. ეს კრიტერიუმები უნდა იყოს შემოწმებადი და მიკვლევადი.
შეაფასე სამუშაოს შესასრულებლად საჭირო გუნდური ძალისხმევის რაოდენობა.
გააკეთე User Story-ის Review გუნდთან ერთად, რათა დარწმუნდე, რომ ის ნათელი და სრულყოფილია.
Comments