Чи неправильно використовувати Agile, коли вимоги клієнтів взагалі не змінюються?

12

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

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

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

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

EDIT: Основний момент тут полягає в тому, що: ми НЕ МОЖЕ звинуватити клієнтів у зміні вимог. Припустимо, що клієнти вказали на дуже конкретну проблему, розкажіть нам список бажань в дуже розумних деталях і залиште нас у спокої (тобто клієнти мають свої продуктивні справи, більше не помиляйтесь ними. Тільки демонстрація для них поблизу закінчуються, коли у вас мінімальний робочий прототип). Чи було б неправильним використовувати Agile в цьому сценарії?

agile development-process

— ПоінформованийA
джерело

2

@randomA: насправді, IMHO ніколи не слід пробувати чистий водоспад, лише якщо ти хочеш створити робочий продукт, на який потрібно більше тижня.

— Док Браун

10

Будь ласка, дайте мені своїх клієнтів

— razethestray

7

Я дам удвічі більше для ваших клієнтів, ніж @razethestray

— Euphoric

2

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

— Док Браун

3

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

— Doc Brown

16

Чи вважатиметься це поганим, ковбойське кодування, анти-модель.

Коротка відповідь: ні. Робити "спритний" правильно, не означає "не планувати", це означає не перенасичувати речі.

Однією з головних причин використання Agile є те, що клієнти часто змінюють свої вимоги.

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

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

— Док Браун
джерело

3

Робити "водоспад" правильно, не означає "планувати все", це означає не уникати речей.

— Джорджіо

1

@Giorgio: робити "водоспад" правильно - це не застосовувати його, коли вимоги "трохи розпливчасті" і "програмне забезпечення є досить складним, що є деталі, проблеми, які я б не розпізнав, поки я насправді не зіткнувся з ними" (цитуйте з оригінальне запитання).

— Док Браун

6

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

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

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

Б) Потенційно достатньо, щоб вони були щасливі і звільнилися.

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

— SpoonerNZ
джерело

Я не розумію, яким способом А) вирішує проблему, про яку ви згадали на початку вашої відповіді: як ви знаєте, якщо останні кілька історій займуть кілька днів чи два роки? Ви дійсно знаєте, коли ви їх справді робите, чи не так?

— Джорджіо

1

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

— SpoonerNZ

Це залежить: якщо всі заплановані функції є істотними, то продукт із 90% -ними функціями є непридатним / не звільняється: його можна використовувати лише для демонстрації того, що вже є. На мій досвід, спритний не є кращим у будь-яких ситуаціях: є проекти, для яких більш придатний спритний (зміна вимог, невеликі, самостійні та незалежні функції) та проекти, для яких він не є (стабільні вимоги, складні та / або критичні завдання) особливості).

— Джорджіо

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

— SpoonerNZ

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

— Джорджіо

3

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

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

— Барт ван Інген Шенау
джерело

1

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

— user99561

@ user99561: ви праві, але в таких ситуаціях вимоги здебільшого не розпливчасті, вони кришталево чисті - доки нова програма поводитиметься точно так само, як і стара. У такій ситуації "спритний" підхід дійсно не потрібен. Ітеративного підходу, орієнтованого на кілометрів (без особливої взаємодії з клієнтом) буде справді достатньо.

— Док Браун

Кристально чистий? Удачі, з'ясувавши, яка саме поведінка, і які винятки. Здебільшого навіть ділові люди не розуміють, що відбувається в додатку. Моя порада: біжіть якнайшвидше від цих проектів. Тому що ви знаєте, коли проект починається, але ви не знаєте, коли буде виправлена остання помилка, опублікована через те, що програми ведуть себе по-різному.

— user99561

0

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

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

— Сільвіу Бурча
джерело

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

— Поінформовано