Agile розробка програмного забезпечення: як ви фінансово реагуєте на зміну вимог користувачів?

Я завжди дивувався, читаючи про всі ці "спритні розробки" тут, на SE та інших сайтах:

У "традиційній" інженерії програмного забезпечення, ви

1. збирати потреби користувача,
2. написати специфікацію на основі цих вимог,
3. віддати його замовнику та виставити йому рахунок за виконану роботу,
4. зробити (грубу) технічну конструкцію, щоб можна було оцінити витрати на впровадження,
5. дати користувачеві ціну на реалізацію,
6. зачекайте, коли клієнт підпише специфікацію та прийме пропозицію,
7. проектувати, впроваджувати, тестувати,
8. вексель.

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

Отже, як це працює (фінансово) у гнучкому проекті, де часті зміни вимог є частиною процесу?

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

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

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

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

Тут варто відзначити два ризики. По-перше, клієнт може злякатися, якщо він не зрозумів спритності вперед. Схоже, він ризикує. Тільки досвід показує, що він насправді не є.

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

Але якщо ви, як компанія, поясніть це досить добре, кожен переможець.

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

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

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

Будь ласка, не подайте Agility à toutes les соусів . Ми повинні використовувати відповідне рішення даної проблеми.

Це насправді не пов'язано з програмою Agile або будь-якою моделлю, яку ви використовуєте. Працюючи фрілансером, я використовую суміш Waterfall і V-модель, але все ж маю ту саму проблему: що робити, якщо замовник хоче щось змінити під час детального проектування? Що робити, якщо він внесе зміни під час впровадження?

Підхід, який ви повинні використовувати, залежить від замовника та ваших відносин.

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

Для інших клієнтів підхід, який працює добре, такий:

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

• Коли замовник просить змінити вимогу, оцініть її вартість та порівняйте її з фактичною вартістю та станом. Якщо ви майже закінчили товар і реальна вартість становить 2,108,36 долара, а вартість зміни оцінюється до 150 доларів, просто зробіть це. Якщо, з іншого боку, існує ризик досягти максимуму, то скажіть своєму клієнту, що вам доведеться разом переоцінювати загальну вартість.

Agile та "Написати пропозицію" здаються антитезою :) - остання не продуктивна інженерія програмного забезпечення: D

Гаразд, тепер, коли у нас жарт не виходить - повернімось до справжнього.

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

Що це означає? Це означає, що в контракті прописано, що ми (клієнт) встановлюємо початкову оцінку вартості та +/- відхилення%, з якими ми можемо впоратися, наприклад, ставка в розмірі 100 000 доларів, але я готовий піднятися до $ 120 000 (цього МОЖЕ не бути частина договору, але на увазі замовника).

Тепер, коли зміни дизайну наступають, ви рухаєтесь з оцінкою та плануванням: - ви збираєте свою команду і запитуєте їх у «сюжетній точці», оцінюючи складність факторів факторизації змін. Завдяки деякій оцінці швидкості, ви можете їх помножити та дати графік оцінки. Якщо ви знаєте команду та їх відносну заробітну плату (порівняно з усіма зарплатами ВСЕГО), ви маєте відносно легко зменшити вартість за сюжетну точку (ви не піддастеся на недолік середніх показників).

Чи потрібно повертатися до замовника з фінансами? НІ. Не обов'язково. Ви замовте їх заздалегідь встановити пріоритет та вставити їх у потрібне місце у відставанні. Тепер, коли ви знаєте розмір відставання (якщо ви цього ще не зробите), і виходячи з фінансових показників (вартість за кожну історію), ви знаєте, які вимоги з низьким пріоритетом можуть бути недосяжніми для даного бюджету. Покажіть їм репріоритоване відставання з оцінкою придатних функцій відповідно до $$ контракту. Тоді нехай вони вирішать, чи готові вони платити більше, щоб отримати більше, якщо / коли ви / вони туди потраплять. Якщо вони хочуть його безкоштовно ... ви берете позицію і скажете їм, що це обійдеться дорожче.

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

Сподіваюся, це допомагає!

Досвід інших людей, ймовірно, відрізнятиметься, але один із способів, який я бачив, це значною мірою такий же, як і ваш "традиційний", з кількома речами, які слід зазначити:

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

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

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