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

Основне. Що таке спринт у скрамі

Як пишеться в Посібнику зі скраму, спринт — це часовий відрізок тривалістю місяць або менше, протягом якого створюється «готовий», тобто придатний до використання й релізу інкремент продукту. Для ефективної розробки спринти мають мати однакову тривалість. Новий спринт завжди починається відразу ж по завершенню попереднього.

Під час спринту:

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

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

Міф перший. Зворотний зв’язок можна часом ігнорувати

Десятиліттями успіх проєктів з розробки вимірювався за допомогою “золотого трикутника менеджера”, тобто за співвідношенням тривалості, вартості й об’єму робіт. Як результат, загинув не один проєкт і народився не один безтолковий продукт: цей трикутник стосується успіху продукту лише опосередковано.

Та як тоді зробити проєкт успішним? Перш за все, пам’ятати про те, що скрам створено для розробки креативних ПРОДУКТІВ (не проєктів).

Головна ціль у застосуванні скраму — створити продукт, що користуватиметься попитом у користувачів і даватиме достатню окупність інвестицій (ROI). Найсерйозніший ризик у розробці — випустити нікому не потрібний продукт. Скрам зменшує цей ризик за допомогою частих циклів зворотного зв’язку. Щоб розробити потрібний продукт, скрам-команда регулярно проводить демонстрації (інспектує інкремент) на оглядах спринту. На цих зустрічах ключові стейкхолдери і кінцеві користувачі працюють з інкрементом продукту. Так ми отримуємо зворотний зв’язок, а власник продукту корегує плани — адаптує беклог продукту, а часом і план релізу.

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

Міф другий. Спринт провалився, якщо в ньому не вдалося досягти цілей

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

Кен Швабер у книзі «Софт за 30 днів» (Software in 30 days) так описує випадковості в розробці: «Від початку в нас є бачення чи можливість, якою ми маємо скористатися. Розробники створюють додаток, щоб втілити найважливіші сторони нашого бачення. Ми дивимося на інкремент і починаємо думати, як будемо його використовувати. Ми обговорюємо, що додати, щоб зробити інкремент кориснішим. У деяких дисциплінах це також називається проміжним контролем. Ми проводимо його в кожній ітерації».

Якщо спринт розглядати як експеримент, а скрам — як емпіричний процес, стає зрозуміло:

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

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

Приклад вдалого спринту:

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

Приклад невдалого спринту:

Команда змогла закінчити багато функцій і виконати до огляду спринту все заплановане (завдяки овертаймам і зниженню якості). Та ніхто, крім власника продукту, не прийшов на огляд спринту. Розробники досі не бачать реакції користувачів, а стейкхолдери надто зайняті, щоб ходити на огляди. Немає жодного зворотного зв’язку про інкремент. Якщо так, то можна пропустити і ретро — всі надто зайняті. А тоді — почати новий «успішний» спринт.

Миф третій. Спринт не обов’язково закінчується випуском готового інкременту

Недосвідчені фахівці вважають, що не всі спринти мають закінчуватися створенням готового інкременту. В результаті з’являються різні види «недоспринтів», яких слід уникати. Ось деякі з них.

Спринт нуль

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

Дизайн-спринт

Такий «спринт» починають, щоб створити технічну архітектуру — посібник для всього наступного релізу. Цей випадок «важчий» за попередній: окрім того, що він не відповідає визначенню спринту, він ще й заважає інспекції й адаптації в наступних спринтах. Знову ж таки, ескізи архітектури й функціоналу можуть бути корисними як частина бачення продукту: так команда уникне ризику і налагодить діалог зі стейкхолдерами. Однак не слід розробляти детальний і фіналізований  дизайн процесу.

Жорсткий спринт (Hardening Sprint)

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

Висновки

• Тим, хто працює за скрамом, потрібно створювати діючі творчі продукти, а не проєкти.
• Кожен спринт — це експеримент. Його результати обов’язково підлягають інспеції й адаптації.
• Якщо результати спринту не можна інспектувати й адаптувати, спринт вважається невдалим.
• У результаті спринту має з’являтися готовий інкремент продукту, а не жорстко визначений план наступних робіт. На цьому базується емпіризм скраму.

Успішних вам спринтів!

Стаття підготовлена за матеріалами й мотивами:

• What is a Sprint in Scrum? (Scrum.org)
• What is a failed Sprint? (Ілля Павліченко)
• Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (Алекс Белерин Латр)

Перекладено й адаптовано командою BrainRain.