ზოგიერთი 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 გუნდთან ერთად, რათა დარწმუნდე, რომ ის ნათელი და სრულყოფილია.
