Коли припинити писати історії користувачів та почати кодування?

Виявляючи історії для першого спринту, як ви знаєте, коли припинити писати і рухатися вперед?

Я запитав кількох людей, яких я знаю, і, в основному, відповідь, яку я отримав, залежить від контексту, в якому існує проект, і від того, наскільки оброблений тимчасовим загальним проектом.

Чи існує якийсь стандартний спосіб дізнатися, коли потрібно припинити писати історії користувачів, і якщо так, то на чому ґрунтується і як це застосовується до майбутніх спринтів?

Ви повинні оцінювати кожну історію після того, як ви її детально опрацювали - це передбачає, що ви отримуєте свої розповіді в порядку черговості і що вони досить розроблені для розвитку.

Коли ви достатньо оцінили ітерацію, починайте кодувати.

Коли у вас є повне відставання продукту та хороші повні історії користувачів про всі випадки. Потім розділіть їх на ітерації та починайте програмування.

Дві дії не є антагоністичними.

Написання розповіді - це визначення бажаних потреб під обмеженням надання ділової цінності.

Початок коду відбувається в середині спринту. Для початку спринту єдина необхідна умова - це визначений відставання спринту - попередньо визначений PO (автор історії) та обраний командою.

Вам слід припинити писати історії (= зупинити проект), коли гранична вигода від впровадження розповіді порівняно з витратами на реалізацію та актуалізованою операційною вартістю визначеної функції є негативною.

Ви повинні почати кодувати в контексті спринту, коли історія зрозуміла (аналіз) і визначено тестування та реалізація (дизайн) - класичний підхід до розробки програмного забезпечення.

коли розповіді стають достатньо деталізованими, щоб перетворитись на програмовану логіку .. і коли програмісти можуть присвоїти певну кількість точок історії, що вписуються в часову шкалу спринтів ..

історія, яка оцінюється в 50 годин / сюжетні точки, буде важкою (IMO), щоб зайняти спринт довше тижня. Знищення історії далі дозволить іншим взяти на себе різні частини завдання, але якщо код не може розвиватися паралельно, то, ймовірно, це так коротко, як ви можете піти.

Чи існує якийсь стандартний спосіб дізнатися, коли потрібно припинити писати історії користувачів, і якщо так, то на чому ґрунтується і як це застосовується до майбутніх спринтів?

Я особисто не знаю стандартного методу. Це дійсно зводиться до поєднання вашої методології та очікувань вашого клієнта.

Я виявив, що краще починати кодування, як тільки у вас є "достатньо" історій від вашого клієнта, щоб почати. Як говорили інші, це може бути для однієї ітерації, однак це може бути і для іншого. Ваша міра достатньо повинна орієнтуватися на те, як часто ви маєте намір випустити робочий код для свого клієнта, а не замість того, щоб ваш клієнт надав вам і нескінченний список історій (багато з яких, ймовірно, ніколи не закінчуються, можуть змінитися, а може і не складіть свій основний термін випуску), краще попросити свого клієнта про перші 3-5 найважливіших та найвищих пріоритетних функцій. Коли це буде зроблено та передано вашому клієнту, ви збираєте наступні найважливіші 3-5 функцій тощо. Попросіть більш-менш залежно від того, наскільки ймовірно триватимуть ваші ітерації.

Ваш клієнт або контракт або термін, можливо, можуть підказати вам, коли насправді перестати просити історії, але тим часом ви просили розповіді і зупинялися так часто, як у вас були ітерації. Коли за домовленістю ви та замовник вважаєте, що продукт достатньо завершений, ви можете вирішити, що робити з будь-якими історіями, які клієнт, можливо, вам ще не дав.

Основна перевага цього підходу полягає в тому, що ви в кінцевому підсумку надаєте найбільшу цінність для замовника, і коли проект зростає і проходить час, величина вартості, яку ви доставляєте клієнту, зменшується до точки, за якою клієнт може зробити рішення про "останні 20% функцій", яких вони могли б побажати, і які ніколи фактично не можуть бути використані. Він також скорочує час, що витрачається на тривіальні пункти з низьким рівнем пріоритету, що покладає на себе відповідальність (і стрес) за визначення пріоритетності та планування ітерацій, і все ґрунтується виключно на потребах замовника. Це не означає, однак ви не повинні надавати керівництву клієнту, щоб уникнути складних вузьких місць планування, які можуть стати очевидними під час розмови з клієнтом.

Прочитайте про розробку програмного забезпечення Poppendeicks, якщо ви хочете більш детальний опис цього підходу в більш широкому контексті.

Ви ніколи не припиняєте писати історії. Це просто те, що у вас буде достатньо історій для спринту 1, ви будете робити планування спринту, і ваша команда почне працювати відповідно до відставання спринту.

Власник продукту буде продовжувати розробляти відставання продукту, тобто писати більше історій користувачів, розбивати великі історії, тобто епоси, на більш дрібні, детальніше розробляти критерії прийняття історій, пріорітизуючи ...