Agile, водоспад та зміни вимог

10

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

agile requirements

— Aravind A
джерело

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

— NoChance

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

— Aravind A

@Aravind A: UAT відбувається в кінці спринту, чи не так? Тоді будь-які нові ідеї / зміни, що з’являються під час UAT, зазвичай мають стати історіями для наступного спринту (якщо ви використовуєте спринти).

— sleske

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

— NoChance

9

Вимоги Agile процесу слід визначити на початку спринту та переглянути його. Я маю рацію в цьому?

Ні, це залежить від характеру проекту (і процесу).

Є кілька гнучких моделей розробки, де вимоги мають бути зафіксовані під час спринту, і вони повинні змінюватися лише для наступного спринту (помітний приклад - Scrum).

Однак є також процеси, коли зміни можуть відбуватися практично будь-коли (до тих пір, поки замовник приймає затримки та додаткову роботу, яку викликає зміна). Kanban часто використовується для управління цими робочими процесами (хоча Kanban також можна поєднувати з Scrum).

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

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

Це зводиться до принципів із спритного маніфесту - "Індивіди та взаємодія над процесами та інструментами" та "Відповідь на зміни за планом".

— sleske
джерело

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

— Aravind A

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

— maple_shaft

2

@maple_shaft є правильним - якість (принаймні здебільшого) є ортогональною щодо зміни вимог. Надайте мені запит: я починаю писати хороший код. Якщо я закінчую і отримую новий запит, або напівзроблений і отримую зміни, я починаю (пере) писати хороший код. Після того , виділені вплив на поточний графік / зобов'язання / і т.д ..

— sdg

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

— MaR

@sles Дякую за пояснення. Я думаю, я зараз це зрозумію. Думаю, мені доведеться більше познайомитися з Agile.

— Aravind A

12

Я думаю, що питання, яке ви повинні задати, таке: Чому вас переповнюють зміни вимог? До поширених причин можна віднести:

Розробники не мають (достатньо) контакту з кінцевими користувачами, щоб вони не могли зрозуміти потреби користувачів. Натомість вони ставляться до вимог як до абстрактного куба Рубіка - вони слідують літерам вимог, навіть не намагаючись зрозуміти їхній дух
Хтось (наприклад, з маркетингу) додає вимоги, які не мають сенсу для кінцевого користувача (але, наприклад, добре звучать у брошурі). Таким чином, відбувається битва між "реальними" вимогами та "іншими" вимогами, які воюють на спині розробників
Обсяг проекту не визначений ("Ну, якщо ви все одно реалізуєте текстовий процесор, чи не могли б ви просто додати невеликий модуль, який веде облік оплати праці? О, і Білл з іншої команди розробників запитав, наскільки важко це було б" бути, щоб також текстовий процесор склав код C ++? ")

Якою б не була коренева проблема, вам потрібно це виправити. Заглушити його під шарами "Agile" (або будь-якої іншої методології) не вийде.

— нікі
джерело

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

— Aravind A

9

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

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

Можливо, вам потрібні коротші спринти?

— Адам Яскевич
джерело

+1 для необхідності коротших спринтів. Поверніть масштаб до 2 тижнів і подивіться, чи це допомагає.

— Іван

1

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

— Carson63000

7

Для розумності програмістів найкраще, якщо вимоги не змінюються під час перегляду / спринту.

У вашій ситуації є два очевидних варіанти:

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

Дуже рекомендую і те і інше .

— Стівен А. Лоу
джерело

3

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

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

— Ладіслав Мрнка
джерело