Як з'явився Scrum?
Перші витоки концепції Scrum сягають 1980-х років, коли Хіротака Такеучі та Ікудзіро Нонака згадали її у статті «Розробка нового продукту». Вони назвали це цілісним і регбійним підходом.
На початку 1990-х Кен Швабер використовував Scrum у своїй компанії, а Джефф Сазерленд розробив подібний підхід у Easel Corporation. Пізніше вони створили офіційний фреймворк Scrum і посібник зі Scrum, які набули великої популярності, особливо в індустрії розробки програмного забезпечення.
Деякі форми Scrum запровадили Google, Yahoo, Microsoft і кілька інших компаній зі списку Fortune 500.
10 хибних уявлень про методологію Scrum
Нижче наведено 10 найпоширеніших хибних уявлень про Scrum і пояснено, чому вони шкодять клієнтам і працівникам.
Scrum — це процес
Це одна з найпоширеніших помилок, яких припускаються люди, розповідаючи про Scrum. Поширений вислів, який ви можете почути, — це процес Scrum. Насправді Scrum — це не процес, а набір простих правил, які допомагають Scrum-команді розробити власний процес.
Scrum — це абревіатура
Це доволі підступне хибне уявлення. Кажу так, бо це можна використати як запитання з підступом на співбесіді. Якщо хтось стверджує, що є експертом зі Scrum, запитайте його, що означає абревіатура «SCRUM». Якби він був експертом зі Scrum, то сказав би, що це не абревіатура. Scrum походить від терміна, який використовують у регбі. Великі літери в назві Scrum часто можна побачити в резюме й описах вакансій, складених людьми, які не знають, як виник Scrum.
Scrum — це срібна куля
Я знову й знову бачив, як менеджери вважали, що саме Scrum спричиняє провал або успіх проєкту. Насправді це не може бути правдою. Кажу так, бо Scrum — це лише набір правил, дотримання яких допомагає команді виробити власний процес. Люди, які впроваджують Scrum, досягають успіху або зазнають невдачі залежно від того, наскільки вони адаптивні й проникливі. Гарна аналогія, щоб це зрозуміти, — шахи. Якщо ви програли партію в шахи, не можна звинувачувати в поразці самі шахи. Шахи — це просто гра з набором правил; програють або виграють люди, які грають у шахи, а не шахи. Scrum — як шахи.
Scrum означає відсутність документації
Схоже, це хибне уявлення поступово зникає, але воно досі існує. Упровадження Scrum не означає відмови від усієї документації. У вас і надалі може бути документація у вигляді блок-схем, створених під час сесій біля дошки, користувацьких історій, нотаток з бізнес-аналізу чи будь-якої іншої допоміжної документації, необхідної для користувацької історії.
Scrum — це мікроменеджмент
Як працівник компанії, що впроваджує Scrum, не варто вважати, що Scrum — це мікроменеджмент. Мікроменеджмент може виникнути як побічний ефект нерозуміння менеджером того, що таке Scrum, але Scrum не рекомендує мікроменеджмент. Насправді Scrum дає команді більше можливостей для створення продукту.
Scrum — це лише ітеративна розробка
Якщо ви думаєте, що дотримуєтеся Scrum, займаючись лише ітеративною розробкою, то бачите лише половину картини. Деякі нові команди, які переходять на Scrum, можуть потрапити в цю пастку, і це не принесе великої користі ані команді, ані замовнику. Scrum — це не лише зустрічі й ітерації, а й культура, командна робота та кросфункціональна взаємодія.
Scrum-команди займаються ковбойським програмуванням
Через відносно швидкий темп Scrum деякі команди, яким бракує належного керівництва, можуть піти коротким шляхом, що здатне призвести до низької якості коду. Це не обов'язково означає, що Scrum призводить до ковбойського програмування. Насправді Scrum — це лише фреймворк для управління проєктами. Безперервна інтеграція коду, автоматичні перевірки його якості та розробка через тестування — це методи ощадливого програмування, які можна застосовувати в будь-якому середовищі, зокрема й у Scrum.
У Scrum не залишається часу на справжню роботу
Звісно, неправда, що в Scrum забагато нарад. Насправді в Scrum мінімалістичний підхід до зустрічей. Усіх зустрічей у Scrum достатньо, щоб команда могла перевіряти й адаптуватися. Основні зустрічі Scrum — це щоденна підготовка, планування спринту, огляд спринту, ретроспектива спринту й підготовка беклогу продукту. Усе, що виходить за межі цих зустрічей, — це спеціальні зустрічі, додані командою.
Scrum не може працювати з CMMI
Я бачив проєкти, у яких успішно отримали сертифікацію CMMI, дотримуючись Scrum. Можуть бути певні державні проєкти, у яких замовник вимагає, щоб проєкт мав сертифікацію CMMI. Усе ще можна отримати сертифікат CMMI рівня 3, внісши кілька змін у процес, якого ви дотримуєтеся в Scrum.
Замовник може змінювати вимоги будь-коли й будь-де
Клієнт, який постійно змінює напрям під час спринту, може зашкодити моральному духу Scrum-команди. Scrum-команді потрібна принаймні повна ітерація, щоб пройти весь життєвий цикл. Це небезпечне хибне уявлення можна усунути, провівши навчання зі Scrum для замовника.
Підсумуймо
Згідно зі статистикою, Scrum на сьогодні є найпопулярнішою методологією.
Жоден інший Agile-фреймворк не приділяє клієнту більше уваги.
