Scrum — це гнучка методологія розробки програмного забезпечення, яка зараз використовується багатьма компаніями та корпораціями в рамках ініціатив цифрової трансформації.
Про Scrum
Роль методології Scrum полягає в тому, щоб забезпечити структуру для гнучкої розробки програмного забезпечення, яка дозволяє командам працювати спільно й ефективно для надання високоякісних програмних продуктів.
Це основа для спільної роботи команд над розробкою складних продуктів. Замість того, щоб випускати продукт після довгих етапів планування, проектування, розробки та тестування, scrum має на меті постачати готові до використання продукти з самого початку невеликими кроками.
Основні принципи Scrum — прозоре командне спілкування, регулярна перевірка якості та вміння адаптуватися до змін. Якщо прийняти та використовувати належним чином, команди можуть надавати високоякісні програмні продукти вчасно та ефективно.
Ключові переваги Scrum
Джерело: scrum.org
- Можна домогтися підвищення продуктивності. Бути командою Scrum означає, що команда розбиває складні проблеми на маленькі частини. Потім ці невеликі фрагменти доставляються в спринтах як кроки спринту. Члени команди можуть зосередитися на конкретних завданнях у межах спринту (визначений період часу, протягом якого розробляються прирости, наприклад, два тижні).
- Scrum заохочує регулярне спілкування між усією командою. Це гарантує, що всі чітко розуміють масштаби та очікування. Це зменшує досить значну кількість непорозумінь, які могли б статися інакше. Особливо, якщо ви хочете розвивати високий темп від спринту до спринту, уся команда повинна працювати над досягненням однієї мети день у день.
- Scrum розроблений як гнучкий, щоб команди могли адаптуватися до мінливих вимог і пріоритетів. Це дозволяє командам швидко реагувати на зміни обсягу проекту або потреб клієнта. Замість того, щоб чекати, поки закінчиться весь життєвий цикл розробки, ви можете просто змінити вміст між спринтами.
- Scrum наголошує на важливості тестування та гарантії якості, в ідеалі в автоматичному режимі. Кінцевою метою є підвищення якості кінцевого продукту. Це знижує ризик дефектів і забезпечує відповідність продукту вимогам замовника.
- Scrum розроблений таким чином, щоб бути орієнтованим на клієнта, що означає, що клієнт бере участь у процесі розробки від початку до кінця, зазвичай у ролі власника продукту або з прямим зв’язком із власником продукту (докладніше про це пізніше). Це гарантує, що кінцевий продукт відповідає потребам клієнта та має правильний пріоритет.
Далі ми обговоримо роль методології scrum.
Роль методології Scrum
Джерело: hangoutagile.com
Метою методології Scrum є створення основи для гнучкої розробки програмного забезпечення, яка дозволяє командам працювати разом. Ви створюєте Scrum-команду, яка збирається щодня та регулярно та має заплановані обговорення (церемонії) у спринті, який повторюється кожен спринт. Як правило, наступні церемонії є частиною основного складу команди scrum:
- Щоденні стендапи – час і місце, де всі члени команди збираються та обговорюють, що було зроблено минулого дня, що буде працювати наступного дня та які поточні перешкоди, якщо такі є.
- Уточнення історій – тут обговорюється та завершується новий вміст (для наступних спринтів).
- Планування спринту – під час цієї церемонії команда оцінює готовий до використання вміст (визначений у Stories), а потім бере участь у певному піднаборі з них, головним чином на основі оцінки пріоритету та зусиль.
- Огляд спринту – тут команда зустрічається із зацікавленими сторонами та представляє їм, чого досягла команда в останньому спринті.
- Ретроспектива спринту – діалог, присвячений команді лише для обговорення того, що можна покращити або що команда вважає за необхідне змінити в майбутньому.
Значення методології Scrum полягає в її здатності допомогти командам працювати ефективніше. Основні принципи методології Scrum базуються на Agile Manifesto, і вони полягають у наступному.
Емпіричне управління процесом
Scrum базується на ідеї, що прогрес найкраще досягається через емпіричний процес безперервної перевірки та адаптації. Це означає, що команди повинні регулярно перевіряти свою роботу та адаптувати свої процеси для покращення продуктивності.
Самоорганізаційні команди
Команди Scrum самоорганізовуються, що означає, що вони відповідають за управління своєю роботою та прийняття рішень щодо досягнення своїх цілей. Це сприяє співпраці та підзвітності в команді.
Ітерації, обмежені часом
Ви можете розділити scrum-проекти на обмежені за часом ітерації, які називаються спринтами, які зазвичай тривають від одного до чотирьох тижнів. Це гарантує, що команда працює над досягненням конкретної мети та постійно прогресує.
Пріоритетний резерв продукту
Беклог продукту — це пріоритетний список функцій і вимог, над якими команда працюватиме під час проекту. Власник продукту несе відповідальність за підтримку резерву продукту та забезпечення того, щоб він відображав потреби та пріоритети клієнта.
Постійне вдосконалення
Scrum наголошує на важливості постійного вдосконалення. Як щодо продукту, що розробляється, так і щодо процесів, які використовуються для його розробки. Це означає, що команди повинні регулярно аналізувати свою роботу та шукати способи покращити свою продуктивність.
Виклики
Джерело: scrum.org
Хоча методологія Scrum може бути дуже ефективною в розробці програмного забезпечення, є також деякі проблеми, з якими можуть зіткнутися команди під час її впровадження.
Опір змінам
Scrum вимагає значних змін у мисленні та культурі, що може бути важко прийняти деяким членам команди. Деякі члени команди можуть бути стійкими до змін, що може ускладнити ефективне впровадження Scrum. Іншими словами, вам потрібно «отримати це». Поки ви цього не зробите, вас немає.
Відсутність досвіду
Для ефективної реалізації вам потрібен певний рівень досвіду та знань. Якщо члени команди не знайомі з методологіями Scrum або Agile, це є проблемою, яку потрібно подолати.
Відсутність зобов’язань
Scrum потребує високої відданості з боку всіх членів команди, включаючи власника продукту, Scrum-майстра та команду розробників. Якщо члени команди не повністю віддані процесу, може бути важко досягти бажаних результатів.
Погане спілкування
Scrum значною мірою покладається на спілкування та співпрацю між членами команди. Якщо члени команди не спілкуються часто та ефективно, це може бути для них складним завданням.
Надмірний акцент на процесі
Хоча Scrum надає структуру для Agile-розробки програмного забезпечення, важливо пам’ятати, що це лише структура. Якщо члени команди стануть надто зосередженими на дотриманні процесу, вони можуть втратити з поля зору кінцеву мету — створення високоякісних програмних продуктів.
Ролі команди Scrum
Кожна scrum-команда, щоб бути ефективною, повинна складатися з кількох конкретних ролей. Якщо ці ролі не призначені для команди або неправильно підраховані, успішне формування такої scrum-команди може бути під загрозою.
#1. Команда розвитку
Це виконавча частина команди, тому з точки зору доставки продукту, можливо, найважливіша частина команди. Типова команда scrum-розробників складається з фахівців з розробки/тестування/архітектури/аналітиків загальною кількістю 4-10 осіб. Якщо менше, то сумнівно, чи можна все ще називати це командою. Якщо він буде більшим, усі церемонії та керування обговореннями в команді стануть надто складними, і їх підтримка не вартуватиме зусиль.
Команда розробників бере історії з резерву, оцінює їх і реалізує в спринтах. Команда відповідає за розробку історії та тестування, а після завершення – також за розгортання у виробництві.
#2. Scrum Master
Скрам-майстер виконує роль оркестратора команди розробників. Він планує регулярні зустрічі, гарантує, що команда розробників чітко розуміє зміст, і організовує діяльність під час спринту з метою досягнення плану та цілей спринту.
Це насправді не змістова роль. Насправді, скрам-майстру не потрібно технічно нічого розуміти з вмісту історій, які розв’язує команда розробників (хоча це точно допомагає). Однак scrum master обслуговує команду розробників і захищає її від зовнішнього середовища. Під захистом я маю на увазі дозвіл команді працювати на основі гнучких принципів. Будьте спікером команди й не дозволяйте змінювати узгоджений план спринту будь-якими незапланованими запитами.
#3. Власник продукту
Сервери власника продукту (PO) для зв’язку між командою розробників і бізнес-користувачами (зацікавленими сторонами), зовнішніми щодо команди. PO обговорює вміст із усіма відповідними сторонами та передає узгоджений вміст команді Scrum.
Потім PO створює історії для команди з чіткими описами та очікуваннями. PO має переконатися, що команда розробників розуміє цей вміст, щоб команда могла оцінити кожну історію. Таким чином, PO володіє обговореннями вдосконалення історій у команді.
Окрім керування контентом і повним резервом, PO також відповідає за встановлення пріоритетів для кожної історії всередині резерву. Проте PO не несе відповідальності за відбір конкретних історій для спринту. Те, що може зробити лише команда розробників, прийнявши зобов’язання щодо масштабу, команда вибере для наступного спринту. PO може вплинути на цей вибір, лише правильно встановивши та повідомляючи пріоритети.
Взаємодія ролей у команді Scrum
Джерело: scrum.org
Навіть з усіма людьми та ролями, комунікація справді є ключем до успіху. Найголовніше, правильна комунікація, тому що є так багато способів зробити її неправильною. І це насправді найбільша причина, чому багато команд зі скраму не досягають успіху. Вони просто неправильно ставлять.
Наприклад, власники продукту часто просять команду розробників придумати нові історії вмісту. Але це не мета команди розробників створювати відставання. Звичайно, вони можуть допомогти визначити історії, зробити їх деталізованими та розділити їх, щоб їх можна було виконувати в спринтах. Але власник продукту несе відповідальність за відставання. PO в ідеалі не просити команду розробників зв’язатися з бізнес-стейкхолдерами.
З іншого боку, ні скрам-майстер, ні власник продукту не повинні визначати, якою саме буде сфера наступного спринту. У будь-якому випадку це дуже часто трапляється, оскільки ролі скрам-майстра та власника продукту є свого роду природними лідерськими ролями всередині команди скраму. Але насправді вони не в змозі вирішувати, що команда розробників брати в спринт, а що ні. Команда розробників — єдина, хто може виконати це, тому це вирішує команда розробників. Це означає, що PO надає інформацію про те, наскільки важлива історія з точки зору бізнесу; PO може навіть упорядкувати резервні історії від найважливіших до найменш важливих. Таким чином команда розробників має відчуття, які історії взяти в першу чергу.
Власник продукту повинен докладати зусиль, щоб регулярно обговорювати з командою новий контент, який PO хоче, щоб команда надала. PO тут, щоб ретельно обговорити кожну історію, яку він/вона створює або доносить до резерву. Усі в команді розробників повинні розуміти історію, і їм ясно, які критерії прийнятності.
Scrum-майстер — це не лише оркестровник команди; певним чином SM захищає команду від власника продукту, керівництва чи інших зовнішніх зацікавлених сторін. SM забезпечує роботу внутрішніх процесів scrum і керує більшістю церемоній для команди. Під час щоденних дзвінків про статус SM стежить за тим, щоб усі повідомляли лише важливі оновлення за день, щоб зустріч не тривала довше, ніж було заплановано. Це фактично стосується всіх дзвінків.
SM також організовує регулярні ретроспективні дзвінки для команди, під час яких він/вона допомагає команді обміркувати роботу, виконану в попередньому спринті, і визначити сфери, де команда може покращитися.
Заключні слова
Створення успішної scrum-команди зазвичай є довгим шляхом. Необхідно накопичувати досвід всередині команди, навіть якщо конкретні члени команди вже мають певний досвід. Кожна scrum-команда унікальна, і пошук способу працювати та співпрацювати разом як команда над спільними темами завжди потребує часу.
Найголовніше, щоб команда була стабільною, якщо ви її вже сформували. Тільки тоді команда може починати вдосконалюватися з кожним наступним спринтом. Кінцевою метою є перетворення на самоорганізовану команду, де навіть присутність майстра покидьків більше не є обов’язковою більшу частину часу. Якщо ви не можете утримати команду разом, ви все ще будете на етапі навчання.
Далі ознайомтеся з найкращими інструментами scrum для стартапу та середнього бізнесу.