Громадська організація мене попросила провести неформальний семінар з приводу 101 спритного розвитку, що пояснює терміни та концепції Scrum, Kanban тощо. Я працював у спритних умовах вже близько п’яти років, але не вважаю мене євангелістом Scrum.

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

Ці обмеження виглядають дещо суперечать основним принципам спритного розвитку, чи не так?

Чи Scrum просто несумісний у такому середовищі?

Що б ви порадили цій організації?

Scrum, мабуть, не підходить для цієї організації.

З посібника з Scrum "Scrum - це основа для розробки, доставки та підтримки складних продуктів". Він також розроблений для команди з 3–9 членів команди розробки, яка працює над продуктом, власника продукту та майстра Scrum (який може бути, а може і не бути членом команди розробки) для загальної кількості 4-11 осіб.

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

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

18F, агентство цифрових послуг в уряді США, проробило багато роботи над тим, як уряд може складати договори, щоб дозволити використання спритних методологій таким чином, що відповідає законодавству, визначаючи загальні результати, а не детальні вимоги до того, як працює має бути зроблено. Деякі з їхніх ресурсів включають:

• Поліпшення результатів уряду через спритний формат контрактів
• Договір купівлі Agile Blanket
• Модульне узгодження (розбиття великих проектів на більш дрібні модульні з спритним розвитком)
• Чи використовується ваш проект "agilefall"?

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

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

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

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

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

Ось чому стільки таких проектів провалюються. Після того, як вони подолали бюджет.

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

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

Це не так, як "ми хотіли б мати цю систему, і ми готові докласти певних зусиль до неї і подивитися, наскільки ми можемо її зайняти".

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

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

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

Ні, SCRUM не сумісний з публічними тендерами. Вам потрібно чітко вказати, що ви купуєте на публічному тендері.

"Покупець прагне придбати 10 двотижневих спринтів розробки, від досвідченої команди SCRUM, яка містить 5 розробників та сертифікованого майстра SCRUM (покупець заповнить роль зацікавлених осіб). Спринти працюватимуть з березня 2018 року до липня 2018 року" - це досить розумно початок тендеру. Звичайно, вам потрібно буде перелічити необхідні навички команди та дати уявлення про проект, над яким вони працюватимуть, але цілком прийнятно провести тендер, щоб найняти команду.

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

Важко.

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

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

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

Якщо ви дозволите певну гнучкість, ви можете покращити це.

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

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

Це залежить, але, ймовірно, так.

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

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

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

Що б ви порадили цій організації?

На даний момент нічого.

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

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

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

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