Як планувати спринти, або 13 порад для успішного релізу
Автори: Катерина Ревтова, Head of PM/BA в компанії OpenGeeksLab, та Тетяна Рева, Project Manager у компанії OpenGeeksLab.
Талант перемагає в іграх, а командна робота та інтелект — у чемпіонатах.
Майкл Джордан
Поговоримо про планування спринтів. А саме про те, що враховувати, як вимірювати результати й коригувати їх. Цей чек-лист стане в пригоді всім охочим, але насамперед радимо ознайомитися новачкам.
Ілюстрація Марії Рибак
Як планувати правильно
Спринти є основою для хорошої команди розробників Agile. І що краще ти підготовлений до спринту, то більше шансів мінімізувати сюрпризи й досягти поставлених цілей.
Проте планувати спринти часто буває легше на словах, ніж на ділі, якщо у тебе немає певного досвіду. Ба більше, спринт може легко зійти з колії та «з‘їсти» добрячий шматок бюджету, не досягнувши мети. А неправильне планування, своєю чергою, впливатиме на весь воркфлоу проєкту.
Тож як переконатись, що ти робиш саме те, що треба, аби гарантувати успіх?
1. Формулюй чітку ціль
Найважливішим у спринті вважаємо чітко сформульовану ціль. Це означає, що всі розробники мають розуміти, яка мета на найближчий спринт і за яких умов можна вважати спринт завершеним. Має бути чітке визначення.
✔️ Створення профілю користувача з конкретними робочими розділами.
✖️ Створення профілю користувача з мінімальним функціоналом.
✔️ Створення чату (не групового) з можливістю писати текстові повідомлення, редагувати їх та видаляти.
✖️ Створення чату.
Це все можна зафіксувати під так званим helicopter view на тимчасовій прямій у вигляді project roadmap.
2. Оцінюй правильно
Щоб зрозуміти, скільки зусиль потрібно витратити на завдання, найочевидніше рішення — оцінити це в годинах. Але в умовах невизначеності відповідь краще дати у відносних одиницях, а саме у Story Points. У них зручніше працювати з командою, швидкість якої ти вже знаєш. Оскільки Story Points показують зусилля для виконання сторі, команда повинна оцінити все, що вплине на ці зусилля. Зазвичай це обсяг, складність роботи, а також ризики (або невизначеність) під час її виконання.
Наприклад, у нас був спринт і розробники оцінювали завдання. Була реєстрація, зокрема через Facebook, і заповнення профілю користувача. Звичайна реєстрація і заповнення профілю користувача займали три Story Points, а на Facebook виділили їх п’ять. З цього бачимо, що реєстрація через Facebook — складніша задача, аніж звичайна реєстрація та оформлення профілю.
3. Виділяй час на планування спринту
Одного разу наш клієнт дав про себе знати в п’ятницю і хотів стартувати вже з понеділка, без планування. Але так робити неправильно. Ми йому пояснили, що важливо виділити час на узгодження спринту. Варто скласти план того, хто чим займається і який буде порядок виконання завдань.
Також Project Manager потрібно пам’ятати, що на початок спринту мають бути підготовлені дизайни, розписані задачі, надано API-документацію.
Клієнти не люблять платити за ніщо й не завжди хочуть визнати свою помилку. Тому важливо пінгувати замовника, доносити, що тобі це потрібно, щоб обидві сторони не чекали та не втрачали час. Якщо цього немає, то клієнт може пропустити щось важливе. Тому все має бути зрозуміло «на березі».
4. Переконайся, що у всіх однакове бачення продукту
Украй важливо мати однакове бачення продукту та спільну мету. В іншому разі може накритися весь проєкт. Ба більше, на відправній точці треба з’ясувати, який стейкхолдер за що відповідає і кому що надавати. Тож доцільно буде скласти комунікаційний лист, щоб уникнути непорозумінь.
Так, у нас був клієнт, який описав суть проєкту і познайомив нас з Product Owner. Коли ми почали планувати спринт з ним, то зрозуміли, що його бачення відрізняється від бачення клієнта, яке було озвучено спочатку. Тож ми запросили замовника взяти участь у спринт-планінгу, щоб уникнути плутанини. І далі після кожного дзвінка чи зустрічі ми повідомляли клієнту те, до чого дійшли.
5. Розбивай великі сторі на маленькі
Вибери завдання з беклогу продукту, які закривають мету спринту, та обов’язково розбивай великі Story Points на маленькі. У кожної сторі повинні бути критерії прийому (англ. Acceptance criteria, AC) та критерії готовності (англ. — definition of done, DoD), щоб учасники команди розуміли, коли вони вважаються закритими. А розробник, своєю чергою, бачить, що завдання закінчене, у вигляді чек-листа.
6. Коригуй Story Points
Якщо є команда, з якою ти довго працюєш, то можеш сам провести оцінювання і зрозуміти, скільки Story Points варто виділити на два тижні. І щоб розробник не вимірював завдання годинами, він може говорити, скільки це вийде у Story Points.
Так ми постійно дивимося, як фахівець працює, як розвивається і що йому ще можна запропонувати. Якщо все ок, можемо дати йому оцінити завдання іншого, вищого рівня складності або, навпаки, призначити йому щось простіше.
7. Залишай час на тестування, реліз, демо і фікс багів
Якщо ти пообіцяв клієнту виконати завдання, а часу на регресійне тестування в кінці спринту, реліз і демо не залишається, це погано й матиме негативні наслідки. Обов’язково треба закладати на це час. А ще — на ризики. А також виділяй кілька годин на виправлення помилок після тестування. До того ж на ретро проаналізуй, скільки в середньому пішло на реліз, окремо — на фікс багів, окремо — на демо.
Оскільки ми несемо відповідальність за продукт, який розробляємо, то завжди плануємо релізи і демо, коли що буде закінчено. Також ні один реліз не відбувається без попереднього тестування з нашого боку. Тоді ми ручаємося за результат.
8. Вимірюй результати
Ми використовуємо діаграму згоряння завдань (Burndown Chart) в Jira, з нею легко відстежувати прогрес. Для отримання результату беремо загальний обсяг роботи на два тижні й вираховуємо відсоток того, що вже зроблено. Наприклад, у беклозі може бути 15 карток з 25, але це всього 20% від загального обсягу роботи. Та це будуть мінорні задачі, тому це не показник.
9. Давай команді час на розгін
У нас був новий проєкт, на який сформували команду (розробники до цього не працювали разом).
Спочатку хлопці робили по 60 Story Points за спринт. Але після кількох спринтів команда спрацювалася, більше ознайомилася з проєктом. Вони зрозуміли, що можуть виконувати за спринт більше завдань і закривали вже по 80 Story Points тієї ж складності.
10. Бери на проєкт розробників з різними скілами
Наша компанія постійно розширюється, приходять нові розробники з різним рівнем знань. На кожному проєкті є Team Lead. Іноді ми готові дати джуніору закривати нескладні завдання разом із сильними розробниками. Так новачок вчиться працювати в команді, розбиратися в проєкті, розуміти, що є відповідальність не тільки перед клієнтом, а й перед командою. Таким чином ми допомагаємо кожному зрости та стати самостійним розробником.
11. Ретроспектива після кожного спринту
Проводь ретроспективу на регулярній основі, оскільки так можна краще зрозуміти настрій клієнта, чи він задоволений, щоб у майбутньому розробка велася більш гладко. На ретроспективі дай собі відповідь на питання: «Що так?», «Що не так?», «Чому так?» і «Що можна вдосконалити?».
В одного з наших клієнтів був негативний досвід роботи з іншою компанією. Та компанія «пилила» проєкт, нічого йому не показувала, годувала постійними обіцянками. Клієнт нічого не розумів і в результаті вирішив від них піти.
Коли він прийшов до нас, то зі зрозумілих причин спочатку відчував недовіру. Ми стартували роботу за звичним флоу розробки. Почали щільно комунікувати. На ретро проговорили, що замовнику подобається, а що ні. На той момент у нас не було щоденних дзвінків з ним. На ретро клієнт сказав, що частіше хотів би спілкуватися з командою. Так, після першого ж ретро ми ввели щоденні коли.
12. Що досвідченіший Product Owner, то більший успіх матиме проєкт
Бувають різні Product Owners. Є ті, які вміють вести проєкти, у яких це не перший досвід. А є ті, які тільки починають. Це стає зрозуміло з перших хвилин спілкування, оскільки видно, що Product Owner не знає основ.
Наш клієнт хотів бачити конкретного Product Owner. А Product Owner був новачком. До того як взятися до розробки, наш Project Manager пояснив Product Owner’у, як правильно складати документацію, як потрібно заводити задачі в беклог і розписувати їх, щоб потім ми могли планувати спринти та спокійно за ними працювати.
13. Клієнт і команда — по одну сторону барикад
І найголовніше: проєкт — це спільна справа, де всі в одному човні. За результат відповідає не тільки команда розробника, а й компанія клієнта. Обидві сторони зацікавлені в успішному запуску проєкту, але при цьому мають різні компетенції, тому вкрай важливий внесок кожної.
Післямова
Як і будь-які відносини, відносини між клієнтом і командою вимагають спілкування та ясності. Тож треба витратити час, щоб переконатися, що очікування зрозумілі, бачення спільне, а команда може це втілити.
Agile заохочує постійне вдосконалення, тому не засмучуйся, якщо твої перші зустрічі з планування спринту пройшли не так, як хотілося. Планування спринтів — це ремесло, тому з часом ти станеш ще скіловішим і навчишся адаптувати найкращий спосіб працювати у спринті у своїй команді.
Нам дуже цікаво дізнатись, що робите ви, щоб планування спринтів було ще кращим! Залиште коментар, і будемо вчитися одне в одного.
