Переваги Scrum і Agile розробки програмного забезпечення

About
Latest Posts

Executive MBA, Head of Sales at eVolpe Consulting Group

Ukończyłem Zarządzanie na WSB oraz dwa kierunki podyplomowe na Uniwersytecie Ekonomicznym w Poznaniu: Zarządzanie projektami IT, oraz Zarządzanie relacjami z klientem CRM. Jestem certyfikowanym specjalistą do spraw produktów: SugarCRM oraz Creatio.

W eVolpe doradzam na temat oprogramowania dla korporacyjnego biznesu. Prawdziwą wartość systemów CRM/CX dostrzegam w funkcjach pozwalających na analitykę danych. W rozmowach z moimi klientami często podkreślam, jak istotna jest skrupulatność wprowadzania informacji do systemu. Szczególnie, jeśli zakładacie zastosowanie mechanizmów sztucznej inteligencji. Z tym także z przyjemnością pomogę.

W razie pytań zapraszam do kontaktu. Jestem też na LinkedInie!

Latest posts by Sławomir Wnuk (see all)

Чому польським підприємцям подобаються IT On-Premise системи? - 24 Вересня 2024
Чи є низький код і відсутність коду лише варіаціями на одну тему? - 13 Березня 2023
Чи система no-code не позбавить програмістів роботи ? - 1 Березня 2023

На написання цієї статті мене надихнула реальна історія. Деякий час тому я спілкувався з клієнтом про правила подальшої співпраці. Швидко знайшли спільну мову. Петро (назвемо його так) проявив велике розуміння щодо гнучкого підходу та реалізації обговорюваного проекту в Scrum. Проблема в тому, що йому довелося переконати ще кількох осіб, які приймають рішення – людей, які ніколи цим не займалися…

Тоді він попросив мене про допомогу. Йому потрібен був упорядкований список аргументів, які він міг би використати. Спільно з Асьою з відділу Маркетингу ми підготували для нього спеціальний додаток. Я подумав, що подібний матеріал буде тобі також корисний.

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

Waterfall – в чому проблема?

Водоспад є традиційною методологією впровадження. ІТ-проекти «Каскадово» реалізовували на світанку. Узгоджено кінцевий ефект, узгоджено ціну, оформлено документацію готової системи та докладено зусиль для її завершення.

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

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

Але почнемо з остаточної деконструкції міфу про традиційний (водоспадний) підхід. Пізніше буде трохи більше про фреймворк Scrum.

Недоліки проектів, заснованих на жорсткій документації

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

Найгірше, що навіть спільно погоджена та виконана на 100% документація не гарантує успіх проекту впровадження. Ти отримаєш працездатну систему, в узгодженому вигляді і за певну суму грошей, але з великою часткою ймовірності – значною мірою «прострочену».

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

Важко керувати змінами

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

Scrum – порятунок у гнучкому підході до справи

Сьогодні я не хотів би дублювати аргументи визначення. Тут уже багато разів розповідалося про те, що таке Scrum і як працює «гнучка» реалізація ІТ-системи. Якщо ти сумніваєшся, відвідай цю підсторінку: https://evolpe.pl/scrum/ або переглянь додане нижче відео.

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

№ 1 Захист інтересів клієнта

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

№ 2 Кошторис проекту

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

# 3 Поглиблене вивчення потреб

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

# 4 Негайно починай працювати над системою

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

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

Після перших 2 тижнів (зазвичай одна ітерація в Scrum) ти отримуєш перші функції для тестування. Результати роботи команди можуть бути навіть одразу «вироблені».

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

№ 5 Твоя активна участь у проекті

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

English Product Owner – це ім’я призначеного тобою координатора проекту. Бере участь у численних нарадах, під час яких визначається напрямок реалізованої діяльності. Отримує доступ до системи проектування. Повідомлення про прогрес надходять на його електронну адресу. Від імені компанії він тестує та затверджує «частини» системи, створені командою розробників.

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

# 6 Гнучкий підхід до змін

У проектах scrum зміни є природними. Прямо як у житті. Навіщо прикидатися інакше? Це може бути результатом як мінливих потреб Клієнта, так і погоджених покращень у способі роботи на постійній основі.

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

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

Ну, хіба що ви самі затверджуєте або замовляєте такі зміни.

# 7 Оплата часу та ресурсів, використаних у проекті

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

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

Також може статися, що ти заплатиш менше.

# 8 Партнерська співпраця та відчуття безпеки

Перевагою методології agile впровадження є низький ступінь формалізації всього процесу. Тобі не потрібно подавати кожну поправку в письмовій формі. Все, що тобі потрібно зробити, це залишити коментар під відповідною темою в Redmine (система дизайну, яка використовується в eVolpe).

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

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

Переваги гнучкої методології впровадження – підсумок

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

Підсумовуючи основну тему, я сподіваюся, що ця стаття остаточно розвіяла сумніви щодо вибору Waterfall vs. Agile. Не хотілося б багато повторюватися, але нехай це прозвучить вголос: Scrum і гнучка методологія як така наразі є єдиним правильним способом реалізації проектів впровадження. Переваги співпраці в Scrum стосуються насамперед договірних питань, долідження потреб, правил розробки ПЗ, білінгу та відкритості до змін. Якщо у тебе виникнуть додаткові запитання, внизу знайдеш календар бронювання для індивідуальної консультації з експертом. Раджу тобі скористатися цією опцією. Я радий розповісти вам про свій досвід у цій сфері у співпраці з такими клієнтами, як: MAN Truck & Bus Polska, Mokate, Empik, NASK або Contrain.

Побачимося !