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

Я читаю Scrum - Pocket Guide Gunther Verheyen, і він говорить:

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

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

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

Тож, Scrum створить додаткові накладні витрати для проекту, де вимоги не змінюються?

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

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

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

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

Більш повна відповідь така:

Взагалі кажучи, існує три форми управління процесом: визначений контроль процесів, статистичний контроль процесів та емпіричний процес управління. Визначений контроль процесів - це найдешевший. Це можливо, коли часто повторювана робота була вдосконалена з часом, щоб знайти "найкращий" спосіб виконати роботу. CI / CD в розробці програмного забезпечення належить до цієї категорії. Ви не хочете, щоб у вашому процесі збирання були різні варіанти, щоб ви стандартизували процес, коригували, поки ви не задоволені ним, а потім автоматизуєте його. Цей автоматизований процес, очевидно, набагато дешевший, ніж пройти через ручну боротьбу через розгортання.

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

Далі йде емпіричний контроль над процесами, який на сьогоднішній день є найдорожчим, тому що ви повинні відкривати процес у процесі роботи. Навчання неймовірно високе, але ціною продуктивності та ефективності. Однак майже вся робота над проектом потребує цього, оскільки раніше було зроблено мало проектів. Звичайно, є винятки. Налаштування великого активного середовища каталогів є більш статистичним, оскільки ви працюєте з деякими перевіреними інструкціями, від яких трохи відхиляєтесь, як того вимагають обставини. Але якщо ваш проект не повинен виконати точну роботу, яку було зроблено раніше, це майже напевно вимагає Emperical Control Control.

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

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

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

Але переважна більшість програмних проектів не така.

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

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

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

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

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

Я думаю, це може перефразовувати те, що говорить @Cort Ammon, але ось моя думка:

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

Врахуйте, що:

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

• Деякі вимоги можуть бути надто загальними або неоднозначними: "бути простим у використанні", "будь безпечним". Важко проаналізувати безпеку або зручність використання системи, щоб вона не була закінчена. Деякі можуть мати приховані наслідки або можуть бути недостатньо зрозумілими.

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

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

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

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

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

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

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

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

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