Аджайл і скрам

Aджайл — це підхід до розробки програм, описаний в Аджайл-маніфесті. Цей документ розкриває філософію аджайлу через чотири основні цінності:

  1. люди і взаємодії важливіші, ніж процеси й інструменти;
  2. працююча програма важливіша, ніж вичерпна документація;
  3. співпраця з Замовником важливіша за узгодження умов контракту;
  4. готовність до змін важливіша, ніж вірність початковому плану.

Aджайл-маніфест — це скоріше посібник про аджайл і його використання, ніж методологічний припис. Цінності й принципи Аджайл-маніфесту передбачають його адаптацію під кожну конкретну ситуацію. Тому аджайл втілюється в різних фреймворках.

Один із найрозповсюдженіших фреймворків — скрам. Згідно з опитуванням ScrumAlliance за 2015 рік (2015 State of Scrum Survey Report), скрам широко застосовується і буде застосовуватися в різних бізнес-галузях для успішної розробки різних проєктів. Ця стаття присвячена скрам-фреймворку, його історії, перевагам використання скраму в компаніях, його обмеженням і тому, як застосовувати скрам-структуру в вашій організації.

Що таке скрам

Будь-яка розмова про успішне управління проєктами через скрам має починатися з визначення скраму.

«Скрам — це фреймворк управління, згідно з яким одна чи декілька кросфункціональних команд створюють продукт інкрементами, тобто, поетапно. В команді може бути близько семи людей».

«У скрамі є система ролей, подій, правил і артефактів. У цій моделі за створення й адаптацію робочих процесів відповідають команди».

«У скрамі використовуються ітерації фіксованої тривалості, які називаються спринтами. Зазвичай вони займають 1-2 тижні (не більше 1 місяця). Скрам-команди прагнуть створювати готовий до релізу (якісно протестований) інкремент продукту в кожній ітерації».

Scrum Reference Card

Розберемо ці твердження, щоб краще зрозуміти методологію, фреймворки й процеси скраму.

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

Приходьте на Scrum Core 2.0

Чим не є скрам

Скрам — не лінійний метод розробки; це не каскадна модель. Каскадна модель (англ. waterfall) — лінійна послідовність подій, коли продукт планують, розробляють, тестують і так далі в суворій послідовності. Жоден наступний етап не починається, допоки не завершено попередній.

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

Нащо потрібен скрам

У скрам-фреймворку аджайл-розробки чотири основні переваги:

  1. Відгук на потреби клієнта. Компанії-розробники програм добре знайомі з вимогою «зробити на вчора». Традиційні організації, які працюють за методом водоспаду, вбудовують важливі фічі й функції у розклад з двома релізами на рік — і через це часто втрачають клієнтів. Ті, що не пішли зразу, можуть зостатися невдоволеними й покинути вас з часом, коли зустрінуть більш відповідального конкурента. Працюючи короткими й частими циклами, ви можете надавати клієнтам продукти практично зразу за вимогою, а також швидше адаптуватися до нових вимог.
  2. Зменшення вартості розробки. Aджайл і скрам довели свою економічність і ефективність. У цих моделях ролі розробників більш різноманітні, адже невеликі одиниці можна ефективно тестувати тією ж командою, котра їх розробила. Спеціалізація зникає чи скорочується, скорочуючи витрати.
  3. Задоволення роботою. Постачаючи продукти швидко, команда переживає ситуацію успіху щоразу, коли роботу виконано і представлено до релізу. Кожна команда розробки знає, як це приємно. Зі скрамом команда радіє релізу не двічі, а як мінімум дванадцять разів на рік.
  4. Більше швидких доходів. Кошти від клієнтів також надходять не двічі на рік, а значно частіше. Нові фічі також можна додавати частіше, завдяки чому вдається приводити більше клієнтів і швидше обробляти їхні особливі потреби.

Коротка історія

Після появи дослідження доктора Уінстона Ройса «Управління розробкою крупних програмних систем» (Managing the Development of Large Software Systems) у 1970 році багато компаній розпочали пошук нового підходу до розробки, що допоміг би боротися з недоліками каскадної моделі, розкритикованої у статті.

Назва «скрам» походить із дослідження Такеючі й Нонаки 1986 року «Розробка нових продуктів: нові правила гри» (The New New Product Development Game). У цій статті говориться про те, що найкращий спосіб досягти мети — дати невеликій команді точний план дій.

У 1995 році Джеф Сазерленд і Кен Швабер привели скрам в систему у статті «Розробка програмного забезпечення за скрамом» (SCRUM Software Development Process).

Відтоді головний посібник зі скраму — Скрам Гайд — регулярно обновлялось. Самая свежая информация по нему содержится в Скрам Гайде 2020 года, а в этой статье мы коротко приводим основные ее разделы.

Як працює структура скраму

Процес розробки за скрамом

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

Ролі в скрамі

У скрамі існує три ролі, що разом утворюють скрам-команду.

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

Сертифікаційний тренінг для Власників Продукту від Scrum.org — PSPO I

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

3. Скрам-майстер виступає фасилітатором роботи скрам-команди. Скрам-майстер допомагає власнику продукту і розробникам виконувати роботу без перешкод і відволікаючих факторів. Уся комунікація людей з-поза команди з командою розробки відбувається через скрам-майстра. (Часом скрам-команди взаємодіють у форматі скраму скрамів, коли скрам-майстри команд мають власні окремі зустрічі).

Сертифікаційний тренінг для скрам-майстрів від Scrum.org — PSM I

Події в скрамі

Існує п’ять типів скрам-подій:

  1. Спринт (Sprint) — самісіньке серце скраму, де ідеї набувають цінності. Всередині спринту виконується вся робота, необхідна для досягнення цілі продукту, в тому числі планування спринту, дейлі скрами, огляд і ретроспектива спринту.
  2. Планування спринту (Sprint Planning) — в ньому беруть участь усі члени скрам-команди. На цій зустрічі відбувається презентація продукту. Кожен член команди може висловитися про те, що цікавить або турбує його. Під час зустрічі встановлюються пріоритети й оцінюються терміни.
  3. Дейлі скрам (Daily Scrum) — скрам-події, які проходять щодня під час спринтів. Вони короткі (до 15 хвилин) і призначені для планування денного розкладу розробників. На цих зустрічах обговорюють робочі труднощі, пояснюють незрозумілі історії користувачів. Дейлі є обов’язковим для розробників. Присутність скрам-майстра необов’язкова.
  4. Огляд спринту (Sprint Review) — демонстрація діючого продукту, розробленого протягом спринту. Ця подія відбувається наприкінці спринту і призначена в першу чергу для того, щоб детально продемонструвати досягнення стейкхолдерам.
  5. Ретроспектива спринту (Sprint Retrospective) — щось схоже на розтин. Це обговорення того, як команда спрацювала протягом спринту, і пошук, як підвищити якість її роботи в майбутньому.

На додаток до цих подій під час спринту команди можуть проводити також уточнення беклогу (Backlog Refinement) — обговорювати елементи беклогу й готуватися до наступного спринту. В рамках цієї зустрічі можна обговорити пріоритетність елементів і розділити елементи беклогу на дрібніші складові.

Артефакти

Aртефакти скраму — це робота, яку потрібно виконати, щоб завершити проєкт або спринт. Завдяки їм інформація про проєкт залишається прозорою для всіх, хто над ним працює.

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

Aртефакти спринту і їх компоненти — це:

  • Беклог продукту — всі необхідні дії, пов’язані з користувацькою і технічною сторонами проєкту.
  • Беклог спринту — сукупність всіх задач, які потрібно виконати протягом ітерації спринту. Його отримують із беклогу продукту під час планування спринту.
  • Інкремент — це сума всіх елементів беклогу продукту, виконаних під час спринту, а також цінність інкрементів усіх попередніх спринтів. До закінчення спринту новий інкремент має бути готовий, тобто працездатний і відповідний визначеним раніше критеріям готовності.
  • Елемент беклогу продукту — частина роботу, яку слід виконати протягом ітерації спринту. Зазвичай розбивається на декілька малих задач.
  • Ціль спринту — те, що треба зробити, щоб виконати елемент беклогу продукту.
  • Бьорн-даун чат спринту — робота, що залишається до повного виконання задач спринту. Бьорн-даун чат може мати висхідний або низхідний характер, залежно від того, з чим стикається команда при виконанні задачі. Він слугує не звітом про прогрес команди, а методом подолання труднощів і підтримки активності.
  • Реліз продукту/бьорн-даун чат продукту — наприкінці кожного спринту оновлюється скрам-майстром. Горизонтальна вісь відповідає спринтам, вертикальна — показує, скільки роботи (на початку кожного спринту) залишилось до кінця проєкту.

Правила скрам-фреймворку

Ролі, події й артефакти — основні правила скраму, та є й інші, що також підвищують ефективність процесу:

  • Скрам-команда складається тільки з власника продукту, скрам-майстра і команди розробки;
  • усі спринти повинні мати однакову тривалість;
  • по завершенню одного спринту відразу ж починається інший;
  • кожен спринт починається з планування спринту. Команда розробки щоранку проводить дейлі скрам;
  • у кожному спринті проводиться огляд спринту, щоб стейкхолдери могли надавати зворотний зв’язок;
  • доповнювати беклог спринту під час спринту — не найкраща практика.

Більше інформації щодо термінології скраму можна отримати з глосарію.

Обмеження в скрамі

  • Scrum часто спричиняє скорочення об’єму робіт через відсутність загального дедлайну проєкту;
  • високі шанси провалити проєкт, якщо команда не надто зацікавлена чи не готова до співпраці;
  • застосовувати структуру Scrum у великих командах складно, але можливо. Для цього існують фреймворки масштабування: LeSS, SAFe, Nexus та інші;
  • якщо один із членів команди звільниться під час проєкту, це може дуже негативно вплинути на проєкт.

Яка аджайл-методологія підійде вашій команді?

Як і при прийнятті будь-якого іншого важливого рішення, при виборі аджайл-методології слід спершу розглянути варіанти. Наприклад, eXtreme Programming (XP).

Методологія XP подібна зі скрамом, але спринти в ній коротші, зміни беклогу під час спринту допускаються, а пріоритети XP визначаються замовником.

З іншого боку, вам може підійти скрамбан (Scrumban). Скрамбан дозволяє доповнювати беклог під час спринту і не потребує оцінки термінів під час планування.

Сертифікаційний тренінг зі скраму з канбаном від Scrum.org — PSK I

Перекладено, адаптовано й доповнено командою BrainRain у відповідності з єдиним офіційним документом, де пояснюється зміст скраму — Скрам Гайдом (The Scrum Guide Reordered, 2020).