User Story არის პროგრამული უზრუნველყოფის ფუნქციის ახსნა, საბოლოო მომხმარებლის პერსპექტივიდან. ეს ეხმარება Agile გუნდებს გააცნობიერონ რა სურთ მომხმარებლებს, რათა მათ შეძლონ საუკეთესო ფუნქციების შექმნა.
ამ პოსტში User Story-ზე მოგიყვებით – როგორ უნდა დავწეროთ ეფექტურად, რა გავლენას ახდენს საბოლოო მომხმარებელზე და ა.შ.
რა არის User Story
როგორც უკვე ვახსენეთ, User Story ეს არის პროგრამული უზრუნველყოფის ფუნქციის არაფორმალური ახსნა, რომელიც დაწერილია საბოლოო მომხმარებლის პერსპექტივიდან. Story უნდა დაიწეროს არატექნიკური ენის გამოყენებით, მისი მიზანია სწორი კონტექსტის მიტანა დეველოპმენტის გუნდისთვის.
User Story, როგორც წესი, აღწერილია ერთი წინადადებით, შემდეგი ფორმატით: „როგორც [მომხმარებელს], მე მინდა [გავაკეთო ეს მოქმედება], რათა შევძლო [შედეგი]“.
ვინ წერს User Story-ს?
ძირითად შემთხვევებში User Story-ს პროდუქტის მფლობელი (Product Owner) წერს და პროდუქტის Backlog-ში შეყავს. მიუხედავად იმისა, რომ User Story-ს დაწერა ნებისმიერს შეუძლია, პროდუქტის მენეჯერის პასუხისმგებლობაა, უზრუნველყოს ყველა ინფორმაცია, რომელიც დეველოპერულ გუნდს სჭირდება თავისი ინიციატივების განსახორციელებლად.
როგორ დავწეროთ კარგი User Story?
User Story-ს შექმნის დროს სამი ძირითადი კომპონენტი უნდა გავითვალისწინოთ:
- საბოლოო მომხმარებლის პერსონა
- საჭიროების აღწერა
- დანიშნულება
თქვენი User Story უნდა შეიცავდეს ამ სამივე კომპონენტს. მოდით განვიხილოთ თითოეული ელემენტი, რათა უკეთ გაიგოთ, თუ როგორ უნდა დაწეროთ ეფექტური User Story.
ნაბიჯი 1. საბოლოო მომხმარებლის პერსონა
განსაზღვრეთ საბოლოო მომხმარებლის პერსონა თქვენი სამიზნე აუდიტორიის შეფასებით. იფიქრეთ იმაზე, თუ ვისზე იმოქმედებს პროგრამული უზრუნველყოფის ფუნქცია.
აქ არის რამოდენიმე შეკითხვა, რომელიც უნდა დაუსვათ საკუთარ თავს და თქვენს გუნდს მომხმარებლის პერსონის იდენტიფიცირებისას:
- ვისთვის ვქმნით ამ პროგრამული უზრუნველყოფის ფუნქციას?
- რა სახის პროდუქტის მახასიათებლები სურს საბოლოო მომხმარებელს?
- როგორია საბოლოო მომხმარებლის დემოგრაფია და ფსიქოგრაფიული მახასიათებლები?
User Story-ში შეიძლება იყოს მრავალი პერსონა, რაც დამოკიდებულია სამიზნე აუდიტორიის ზომაზე.
მაგალითი: ქეთი, პროექტის მენეჯერი, რომელიც ხელმძღვანელობს 10 წევრისგან შემდგარ გუნდს
ნაბიჯი 2. აღწერეთ საჭიროება
აღწერეთ, როგორ გამოიყენებს საბოლოო მომხმარებელი თქვენს პროგრამულ ფუნქციას და რატომ. ეს მნიშვნელოვანია, რათა თქვენმა გუნდმა გაიგოს, რატომ გამოიყენებს სამიზნე აუდიტორია თქვენს ფუნქციას.
განიხილეთ ეს კითხვები საბოლოო მომხმარებლის განზრახვის გაანალიზებისას:
- რის მიღწევას ცდილობს საბოლოო მომხმარებელი?
- როგორ დაეხმარება თქვენი პროგრამული უზრუნველყოფის ფუნქცია საბოლოო მომხმარებელს მიზნების მიღწევაში?
- მოერიდეთ კონკრეტულ მახასიათებლებზე ფოკუსირებას – ამის ნაცვლად, გაითვალისწინეთ რას ეძებს საბოლოო მომხმარებელი და როგორ დაეხმარება თქვენი პროგრამული უზრუნველყოფა მათ მიზნების მიღწევაში.
ნაბიჯი 3. განსაზღვრეთ მიზანი/ღირებულება
განსაზღვრეთ აღნიშნული ფუნქციონალის შექმნის მიზანი, რა ღირებულება გააჩნია მას საბოლოო მომხმარებლისთვის? რა პრობლემას აუმჯობესებს?
დაუსვით საკუთარ თავს ეს კითხვები მიზნის განსაზღვრაში:
- რა სარგებელი მოაქვს კონკრეტულ ფუნქციას?
- რა არის პრობლემა, რომელსაც კონკრეტული ფუნქციონალით გადაჭრით?
- როგორ თანხვედრაშია კონკრეტული ფუნქციონალის მიზანი მთლიანი პროდუქტის მიზნებთან?
User Story მაგალითი: მომხმარებლის გამოცდილება
როგორც მომხმარებელი, რომელმაც ერთხელ უკვე ვისარგებლე ონლაინ მაღაზიით, მე მაქვს მოლოდინი, რომ ჩემი “Billing” ინფორმაცია შეინახება, რათა შევქმნათ უფრო გამარტივებული გადახდის გამოცდილება.
რჩევები ეფექტური User Story-ს დასაწერად
ზემოთ ჩამოთვლილი სამი კომპონენტის გარდა, ეფექტური User Story უნდა შეიქმნას INVEST სტანდარტის გამოყენებით.
რა ნიშნავს INVEST?
Invest არის ერთგვარი სტანდარტი, რომელიც წარმოადგენს აბრევიატურას და შედგება შემდეგი სიტყვებისგან – დამოუკიდებელი(Independent), შეთანხმების შესაძლებლობა(Negotiable), ღირებული(Valuable), შეფასების შესაძლებლობა (Estimable), მცირე(Small) და გატესტვადი (Testable). მოდით განვიხილოთ ეს კომპონენტები, რათა უკეთ გავიგოთ, თუ როგორ დაგეხმარებათ INVEST-ის კრიტერიუმები უფრო ეფექტური ისტორიების დაწერაში:
Independent: User Story უნდა იყოს დამოუკიდებელი, რაც იმას ნიშნავს, რომ ის არ არის დამოკიდებული სხვა ამოცანებზე.
Negotiable: User Story უნდა იყოს განხილვადი, ანუ მისი აღწერა არ ნიშნავს რომ ის ნამადვილად ისე უნდა გაკეთდეს როგორც აღწერაშია, უნდა შეიძლებოდეს მისი განხილვა და დისკუსია გუნდის შიგნით.
Valuable: User story უნდა იყოს ღირებული საბოლოო მომხმარებლისთვის და მის აღწერაში უნდა იყოს გადმოცემული მისი ღირებულება.
Estimable: User Story-ს აღწერით, დეველოპმენტის გუნდმა უნდა შეძლოს მისი შეფასება და პროგნოზირება.
Small: User Story უნდა იყოს სამუშაოს მცირე ნაწილი, რომელიც შეიძლება დასრულდეს მოკლე დროში.
Testable: User Story-ს უნდა ქონდეს მკაფიო გასნაზღვრა იმისა, თუ რას ნიშნავს “შესრულებულია”, გუნდის ყველა წევრს უნდა ესმოდეს User Story-ს გაკეთების შინაარსი და მისი “შესრულებულია”-ს დეფინიცია.
