Чи нестача функціональних вимог спритна?

Сьогодні всі хочуть бути спритними. У кожній команді, з якою я працював, форма спритного була різною. Деякі речі є загальними - наприклад, щоденні зупинки або планування, але інші частини значно відрізняються.

У моїй нинішній команді є одна деталь, яка мені здається тривожною. Це відсутність функціональних вимог. Не тільки немає письмової форми очікувань, але й у завданнях досить невиразно визначено, що потрібно зробити.

Мета проекту - переписати стару систему з використанням нових технологій. Стара система також не має жодної розумної документації. Напевно, на сьогоднішній день такого не існує. Опис вимог власників бізнесу - давайте робити це в новій реалізації так само, як і старі. Здається розумним, але це не так. Стара система є своєрідним кодом спагетті, а витяг з неї вимог бізнесу є дорогим. Схоже, ситуація впливає на планування негативно. Напевно він схильний до помилок та помилок у новій реалізації (опускаючи деякі деталі).

Тому я думаю - чи справді спритний не мати вимог до бізнесу у випадку переписування старої системи?

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

Вам потрібно сказати власнику бізнесу, що ви не маєте уявлення про те, як працює стара система.

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

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

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

Ви отримаєте одне з наступних:

• Власні вимоги та швидший цикл розвитку
• Час зібрати вимоги та відновити програмне забезпечення
• Новий проект, який не закінчиться чорною позначкою у вашій кар’єрі

Agile не змінює потреби у функціональних вимогах, але, як правило, змінює спосіб їх збирання . Не спритний спосіб - хтось пройти довгий процес, а потім надати вам якийсь документ, що містить усі вимоги до системи.

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

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

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

Захоплення вимог є важливою частиною будь-якого (успішного) програмного проекту. Але написання специфікації вимог не є.

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

  Agile методи передбачають, що розробники повинні збирати вимоги безпосередньо від експертів з теми, як правило, кінцевих користувачів. Існує різноманітна техніка для цього, наприклад, розмовляючи за прикладом сценарію з МСП. Devs добре розкривати крайові випадки та просити МСП роз'яснити, як програмне забезпечення повинно вести себе у цьому крайовому випадку.

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

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

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

У випадку, коли ви переписуєте стару систему, оригінальна система може стати чудовим джерелом вимог. Але які аспекти є актуальними? Чи використовуються навіть його ніші? Які помилки потрібно повторно доповнити для сумісності? Зазвичай немає розмов для розмови з кінцевими користувачами.

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

Зауважимо, що проекти з фіксованим терміном із встановленим часом із наступаючими термінами є протилежністю спритного. Звичайний спритний підхід полягає в тому, щоб вибрати частину функціональності і спочатку поставити це, а потім повторити. Найважливіші речі виконуються спочатку, менш важливі речі - пізніше (або ніколи). Якщо все важливо і ОБОВ'ЯЗКОВО зробити це якнайшвидше, тоді нічого важливого не буде, і проект навряд чи нічого доставить.

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

Ось як ми це зробили. Ми поговорили з власниками. Ми поговорили з менеджерами. Ми поговорили з користувачами, які виконують цю роботу. Що ми з'ясували, сідаючи за стіл користувача та спостерігаючи (і задаючи питання), було надзвичайно корисним. Менеджери знали, з якими користувачами ми повинні сісти.

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

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

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

Це запитання натякає на те, що пішло не так у рухливому русі. Не винна людина, яка задає питання; Я постійно потрапляю в цю пастку, тому що роки корпоративного життя мене навчали.

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

Не маючи "функціональних специфікацій" чи будь-чого іншого, це звучить тривожно, але це може бути не так. Скільки деталей потрібно для початку? Безпека та продуктивність - це очевидні, які відомі наперед та застосовуються на всьому протязі. В іншому випадку це механізм ціноутворення опцій або додаток для годинника?

Чи буде постійно випускати, обговорювати, вивчати, повертатися назад та змінювати програмне забезпечення? Ви будуєте м'який посуд чи металовироби?

Розробники, що працюють у процесі водоспаду, часто не втягуються на більш пізній етап, що є проблемою. Залучення до них раніше чи з самого початку означає, що вони невідомі до того, що речі будуть незрозумілими, невизначеними та напівфабрикатими, що, здається, засмучує давніх розробників, коли насправді частина їх роботи полягає в тому, щоб задавати питання, наприклад "що таке функціональні вимоги до цієї речі, яку ми збираємось будувати? "

Визначення дірок у плані не полягає у виявленні помилок, а лише у розробці програмного забезпечення.

З цієї причини я люблю відповідь Гая.