Епоси є заповнювачами
Практично щодо будь-якої методології Agile концепція Epics була б стільки, скільки вам потрібно для специфікації вимог, на цьому рівні вам потрібні власники місць. Ці записи будуть надавати пріоритет постійно, будь-яка деталізація витрачає зусилля, якщо вимога протягом тривалого часу стає низькою, або ніколи навіть не буде виконана. Документування його та управління документацією навколо нього було б повним марнуванням часу. YAGNI поширюється на вимоги, а також кодування.
Інструменти - твій друг!
Якщо ви використовуєте належний інструмент для збору та управління історіями користувачів, ви можете генерувати з них Специфікацію вимог. Специфікація вимог все одно є тимчасовим артефактним документом, це не живий документ, це знімок вимог у часі. І ніколи не співпадає з реальністю.
Автоматично створювати артефакти
Історії користувачів, які можна експортувати з належного інструменту, набагато цінніші, ніж будь-який статичний артефактний документ будь-коли. Особисто я віддаю перевагу Pivotal Tracker відстежувати Історії користувачів, я навіть написав набір плагінів MoinMoin в Python, щоб публікувати всі різноманітні Історії та їхні стани у Вікі (який містив детальні нотатки розробника та подібні історії), живі дані завжди краще, ніж статичні дані.
Вікі стала живим документом усіх магазинів / вимог та їхнього стану завершеності та пріоритетності з деталями та коментарями та іншими метаданими.
Набагато краще, ніж величезний документ Word у Sharepoint, який просто надсилається по електронній пошті постійно та ніколи не оновлюється, гарантуючи, що всі мають іншу версію та не синхронізовані з усіма іншими!
Історії користувачів багатші, ніж випадки використання
Історія використання набагато цінніша за Випадок використання, оскільки вони говорять ЧОМУ .
Формат користувацької історії: As a [ROLE] I [ACTIVITY] so that [WHY]набагато виразніше, ніж подібні випадки використання The System [shall/shall not/may/must] perform [action](де дія - блок-схема).
З Користувачем Story, ви повинні ВООЗ хоче зробити що - то, у вас є ЩО вони хочуть робити (що може вказувати на більш детальну схему / документ для складних завдань) , і у вас є найважливіша частина ЧОМУ вони хочуть зробити цю діяльність.
Якщо у вас є перше, друге зовсім зайве, а в кращому випадку просто шум. Традиційна специфікація формальних вимог методології Водоспад не має місця в спритному середовищі.
Наприкінці
Якщо ваше керівництво не прагне змінитись, ви не отримаєте успіху з новою методологією. Я працював у компанії на 100+ мільярдів доларів на рік, вони не зробили кроків дитини, щоб перейти до Agile / SCRUM, вони просто сказали, вся компанія рухається до цього, ось новий спосіб робити, ось ось коли ваше навчання за новим способом розпочнеться, ось нові інструменти, які ми збираємось використовувати, ось дата, коли ми починаємо робити так. Це спрацювало на них менше року. Я працював над тим, щоб реалізувати це в менших компаніях з однаковим успіхом.
Прихильність
реалізація кроків дитини , незалежно від зміни, є рецептом відмови. Це кодове слово для управління, яке вони спокійно не погоджуються і пасивно агресивно налаштовують вас на невдачу. Вони говорять, що я не вірю в це достатньо для того, щоб зробити це, тому я дозволю вам зробити так само, щоб провалитись / не досягти успіху , тому вони можуть сказати, що намагалися, і це не вийшло, і вони, як вони керували, працювали просто добре все разом. Часткове зобов’язання врешті-решт призводить до невдачі.
У вашому випадку вони, ймовірно, спокійно не вірять у Історії користувачів, і через деякий час вони почнуть заявляти, що Історії користувачів є марними, а не SRS, і змусять припинити писати Історії користувачів. , що просто призведе вас назад, а не вперед.