Скрам. Фокусуйтеся на створенні цінності, а не функцій
Сьогодні я мав цікаву розмову з однією з тестувальниць програмного забезпечення в Китаї, яка мала труднощі розуміння деяких конепцій планування у скрамі.
Вона хотіла знати, чи може скрам-команда, якщо вона закінчила всю свою роботу в спринті раніше, взяти в цей спринт щось із того, що запланувала на наступний спринт.
Моєю першою відповіддю було: «Ні, цю роботу вже розплановано, тому команда може взяти цілком нові задачі, які їй слід обов’язково завершити до закінчення спринту». Та їй і далі було складно зрозуміти тонкощі концепції, аж доки я не накидав на дошці все, що мав на увазі. І оскільки це була цікава розмова, мені захотілося поділитися думками з неї з іншими.
Чому в скрам-плануванні так робити не можна?
Припустимо, у вас є скрам-команда, що створила план релізу історій користувачів. У кожної історії є цінність (позначимо її знаком $) і відносний розмір порівняно з іншими історіями. Загальна цінність, що створюється цією командою в релізі третього спринту, складає $20.
Ця робота пов’язана з зобов’язаннями, які власник продукту може передати зацікавленим сторонам із достатньою впевненістю, що протягом 6 тижнів, до дати релізу, її буде виконано. Кажучи “достатня впевненість”, я маю на увазі впевненість на 85%. Ми певні, що всі задачі буде виконано в першому спринті, але менш певні цього стосовно задач із нижчою цінністю в третьому спринті.
Не забувайте про те, що коли ви створюєте план релізу за Agile, ви працюєте з неповною інформацією. Ми проводимо досить часу над історіями користувачів, щоб зрозуміти високорівневий об’єм задач, високорівневі подробиці впровадження і провести високорівневе оцінювання.
Та оскільки ми не витрачаємо так багато часу на деталі, наші початкові оцінки плану релізу можуть виявитися завищеними чи навпаки заниженими. Ми приймаємо цю неточність, оскільки вона дозволяє нам презентувати стейкхолдерам вищу цінність.
Планування в скрамі
Часто нам здається, що на практиці це буде нескладно, адже існують три сили, що використовуються в роботі зі скрам-командами і дозволяють надати зацікавленим сторонам очікуваний (і навіть краще) результат.
- В Agile-командах стейкхолдери мають змогу отримувати максимальну цінність від кожного тижня програмування. Якщо команда має додаткові можливості, вона бере на себе додаткову роботу.
- На початку кожного спринту ми просимо команду повторно оцінити історії користувачів, спираючись на власні знання додатку, індивідуальні навички, вміння працювати в команді і нещодавній досвід роботи з додатком. Як правило, це дозволяє з легкістю реалізувати сторі чи розширити об’єм задач. У кожному разі, під рукою завжди є власник продукту, щоб внести корективи.
- Ми сконцентровані на наданні завершених фрагментів цінності, а не на написанні коду для найбільшої кількості функціональних можливостей продукту. У скрамі не можна переносити незавершену роботу з одного спринту в інший, а також скрам-командам не дозволяється брати задачі, які не реально завершити до кінця спринту. Жодна незавершена задача не має виходити за рамки спринту.
Цінності в скрамі
Якщо скрам-команда закінчила виконувати задачі раніше поставленого дедлайну, чи може вона взятися за сторі, заплановані на пізніші спринти? Якщо історію користувача можливо завершити в межах таймбоксу, будь ласка!
Утім, гарні власники продукту, з якими я мав змогу працювати, завжди намагаються додати більше цінності в реліз, а не виконати роботу раніше за встановлений дедлайн. У багатьох великих компаніях вас не похвалять за завчасне завершення задач, зате похвалять за виконання більшого об’єму задач, ніж вимагалось, тобто за демонстрацію підвищеної продуктивності.
Якби ви як власник продукту мали виконати оцей план релізу?
Тоді, як власник продукту, ви б принесли $24 цінності протягом цього спринту замість очікуваних $20.
Як так може вийти?
Деякі історії користувачів (сині поля) спершу оцінювалися як великі, та коли їх завершили, виявилося, що залишився вільний час. Причини бувають різними (і це варто розглянути на ретроспективі), та в результаті в команди з’явився додатковий ресурс. А власник продукту заповнив вільний відрізок часу новою історією користувача (зелені поля), котра вмістилася в спринт.
За моїм досвідом, ці нові історії користувача надзвичайно цінні в очах стейкхолдерів і клієнтів. Вони потрапляють в реліз у вигляді додаткових бонусів. І напевне вони всіх потішать.
Та чому б не взяти історії раніше? Хіба не можна додати всі ці бонусні історії в останній спринт? Можна, але перекидання в спринт 2 роботи, запланованої на спринт 3, не додасть йому цінності. Пробіл у спринті 2 краще заповнити чимось ціннісноутворюючим.
Взявши елемент зі спринту 3, ми нічого не додамо до загальної цінності, закладеної командою в реліз, а просто збережемо поточний рівень цінності.
