Що таке Scrum і де його використовують?
Ну, риба любить дно глибше, а підприємства - дешевше, якщо перефразувати приказку. А в світі високих технологій одним із способів зробити розробку більш передбачуваною, а отже, і витрачати менше грошей на розробку, було впровадження методологій Lean або Agile.
Цей підхід прижився, і тепер у середньому кожна друга вакансія менеджера з продукту або проекту містить знання та досвід Agile як обов’язкову вимогу. Розробники також чують запитання про знання Agile під час телефонного або особистого інтерв’ю, хоча це могло бути і не зазначено в описі.
Якщо ви шукаєте свою першу роботу, або раніше мали лише досвід роботи тільки з Waterfall - вам буде корисно глибше зануритися в філософію та маніфест Agile.
Agile методології
Чому у розробці треба бути гнучкими? Тому що концепція «конкретний обсяг і конкретний результат за N років» суперечить деяким бізнес-моделям. Іноді можна швидко запустити прототип бізнесу, перевірити, чи це є прибутковим, і лише після цього приступати до повноцінної розробки. Бачення може змінюватися щомісяця, тому логічно відмовитися від документів з непорушними вимогами і замінити їх на Agile, що буквально означає «гнучкий».
Нижче ми розглянемо деталі, але для першого враження наведемо таблицю із порівнянням трьох основних методів розробки.
Kanban і Kanban дошки
Незважаючи на ряд трекерів робочих завдань з інтерактивним рухом об’єктів, Канбан зазвичай асоціюється з дошкою і колонками. Хоча, загалом, це засіб для спеціаліста, який взаємодіє з десятками списків бажань.
Ця методологія чітко обмежує кількість незавершених завдань, як правило, до 3 (можна домовитися про іншу кількість). Це означає, що незалежно від того, наскільки сильно вони підштовхують вас ззовні, команда оброблятиме лише три елементи робочого процесу одночасно, а четвертий додасться до потоку лише у випадку, якщо один із перших трьох буде виконано.
Під «виконано» ми маємо на увазі визначення «готово» (Definition of Done), тобто «фінал» за критеріями команди. Наприклад, коли зміни пішли в реліз для використання замовником.
Теоретичні міркування та застосування Канбан добре викладені в книзі «Канбан. Альтернативний спосіб Agile» Девіда Андерсона.
Що таке Scrum?
Батьком методології вважається Джефф Сазерленд. А в оригінальному формулюванні Scrum визначається як система максимальної адаптації до зовнішніх і внутрішніх факторів.
Scrum за Дж. Сазерлендом — це фреймворк, оптимальний для команд із семи чоловік (плюс-мінус два). Тому окремому розробнику може бути важко пристосуватися до нової моделі на новій роботі: йому потрібно не тільки звикнути до роботи з колегами, але й багато часу буде приділено організаційним питанням. Позитивним є те, що є скрам-майстер, який допоможе подолати труднощі.
Головна турбота скрам-майстра — привести команду до постійного вдосконалення та шукати відповідь на питання «Як зробити ще краще те, що ми вже робимо добре?».
Ще одна роль у команді Scrum — власник продукту (Product Owner). Він відповідає за координацію проекту (те, що ми робимо), ведення документації (як ми робимо) та визначення пріоритетів завдань (коли ми робимо). Це позбавляє розробника потреби бути мішенню для клієнтів і відволікатися на численні обговорення та редагування технічних характеристик. Крім того, найкращі методи вимагають детального вивчення завдання та підготовки дизайну, перш ніж команда розробників почне планувати. Це значно зменшує спори та затримки в процесі виконання.
Якщо у вас є час і ви любите читати історії успіху, проведіть кілька днів, читаючи «Scrum» Сазерленда або його книгу у співавторстві з Кеном Швабером.
Scrumban та інші гібридні підходи
Команди, які спробували і Scrum, і Kanban і відчули, що обидві методології підходять не ідеально, рано чи пізно приходять до чогось проміжного. Досить часто легкість Kanban поєднується з регулярними зустрічами синхронізації та (трохи рідше) зі спринтами, щоб мати можливість спланувати роботу та релізи нової функціональності.
Як впровадити Agile в розробку
Що вас чекає, якщо процеси почнуть будувати після того, як ви прийшли в команду?
Як правило, з усіх артефактів частіше за все відбуваються щоденні зустрічі/стендапи/ синхронізації. Іноді їх вводять поступово, починаючи з кількох разів на тиждень.
Agile тренери
З Agile тренером все більш-менш зрозуміло: людина приходить ззовні і тренує команду. Потім протягом кількох тижнів допомагає підтримувати новий процес.
Плюси: члени команди все ще розмовляють один з одним
Мінуси: потрібно витрачати час на пошук фахівця з методики, а не з продажу повітря. Це може виявитися дорожче, ніж зробити все самостійно (але це припущення).
Впровадження Scrum самостійно
Реалізація методології може бути повністю покладена на керівника. Попередня атестація в цьому випадку стає в нагоді. Якщо її нема, то на допомогу приходять пошукові запити на кшталт «scrum habrahabr» і переймання досвіду інших.
Плюси: це дешевше, ніж наймати стороннього консультанта; менеджер реалізує процеси між основними завданнями; керівник знайомий з командою.
Мінуси: напружена атмосфера («ну тільки вчора він був один із нас»), неприйняття («давайте повернемося до того ж старого»), розчарування (чужий досвід не завжди позитивний).
Нюанси: керівник теж людина і має засвоїти практичні знання. Тому великих сюрпризів від нього не буде.
Який би метод не вибрала ваша компанія та які б інструменти ви не використовували, головне завдання методологій гнучкого виробництва — зробити клієнта щасливішим, а команду — менш втомленою від овертаймів. Тому і цінується досвід роботи зі Scrum: це означає, що майбутній співробітник налагодив планування та координацію своєї діяльності з колегами. В епоху інтернаціональних команд менталітети та мови можуть бути різними. Завдяки Scrum ці відмінності набагато менше заважають рутинним завданням.
