Scrum dun rite

Мені пощастило працювати на проекті, де скрам сприймали дуже серйозно. Там було все, що треба і всі процеси були прописані. Тім: три девелопера і один тестер. Продакт оунер - на стороні клієнта, проджект менеджер - на нашій стороні. Скрам мастер - один з девелоперів. Всі свині і курки присутні (якщо ви не розумієте про що я, перевірте свої знання скраму). Спрінти - двотижневі. Все як в типовому нормальному скрамі. З двотижневого спрінта один день припадає на планінг. Не важливо, що наш тім складався лише з чотирьох осіб, важливо те, що в процесах було прописано, що на планінг іде один день і клієнт це узгодив. Отже цілий день ми дивимося ютюб, граємо в настільний теніс і п’ємо чай на кухні. І ось в четвертій вечора приходить наш скрам мастер і ми починаємо планінг.

Беклог

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

Велосіті

Ну ми знаємо, що велосіті - це середньє арифметичне сторіпоінтів за попередні спрінти. Але в нас велосіті - це константа, яка рівна 14. Чому константа? Тому що якщо а) ми запхаємо в цей спрінт менше сторіпоінтів ніж 14, це означає, що цих два тижні ми не допрацьовуємо. Але якщо б) ми вирішимо що цього спрінта ми зробимо їх цілих 15, то це означає не тільки те, що всі наступні спрінти нам теж треба мати не менше ніж 15 сторіпоінтів (див. пункт а), але це також означає що всі попередні спрінти ми на один сторіпоінт халявили. Оскільки жодна перспектива нам не подобається, то наше велосіті - 14. Не менше і не більше. І проджект менеджер спокійний і клієнту подобається наша стабільність.

Ну добре, вирішили ми, що треба нам 14 сторіпоінтів. І далі починається комбінаторна проблема. Якщо клієнт нам дав два завдання, як їх проестімейтити, щоб вийшло рівно 14? Згідно з процесами всі сторі мають мати кількість сторіпоінтів рівних числу фібоначі (нагадую їх - 1, 2, 3, 5, 8, 13 - далі не цікавить, бо 21 вже в наше велосіті і так не вміщається). Отже два завдання ще можна проестімейтити 13+1. А якщо сторі приблизно рівновеликі? 7+7 не можна, бо 7 - не число фібоначі, 8+5 теж ні, бо числа хоч і фібоначі, але в сумі на сторіпоінт менше. Тоді ми починаємо розбивати сторі на сабсторі, щоб можна було їх якось запхати. Іноді це простіше, іноді ні. В нашому випадку можна зробити 8 + 3 + 3 або 8 + 5 + 1, залежить від того, як легко якась зі сторі розбиваєтсья на сабсторі. Якщо ж сторь більше, то задача теж відповідно ускладнюється. Ну наприклад -як розбити одну велику, дві середніх і одну маленьку сторі на 14 сторіпоінтів (завдання вам додому).

І насправді це ще не все. Тому що сторіпоінти - це для проджект менеджерів і продакт оунерів. Нам, звичайним девелоперам все одно доведеться час логувати в годинах, тому треба ці абстрактні сторіпоінти переводити в години. Оскільки переводити сторіпоінти в години за якимось абстрактними коефіцієнтами - це не за процесами, то в нас є просто верхні-нижні границі для кожного числа фібоначі (наприклад 5 поінтів - від 40 до 65 годин). Не завжди коли ми естімейтимо сторі в годинах і розбиваємо їх на таски, ці години збігаються з вказаними рамками. Тоді треба змінювати або естімейт в годинах, або естімейт в сторіпоінтах. Оскільки друге пов’язане з вирішенням комбінаторних задач, ми обираємо перше.

Естімети

Як правильно проестімейтити? Естімейтити завжди треба правильно, бо якщо ви естімейтите не правильно, то не знаєте свою роботу. Це нам чітко дав зрозуміти наж проджект менеджер. Раз ми йому сказали, що ми швидше виконали роботу, ніж планували. Його строгий погляд і питання “Отже ви оверестімейтнули?” я досі пам’ятаю. І ми знайшли відповідь на питання, як правильно естімейтити. Хочете вірте, хочете - ні, але від тепер наші естімейти завжди були вірними. Ніколи не було такого, щоб таска була на п’ять годин, а ми її зробили за дві або за тринадцять. В чому ж секрет такої швейцарської точності? Приведу приклад - треба нам додати на ЮАй кнопку. Хай це буде якийсь рефреш-батон. Я собі прикидаю, що роботи там на півгодинки, але так щоб з чаєм, то можна і на годинку розтягнути. Мене питається наш скрам мастер “скільки часу” я кажу “ну півгодинки-годинку”. Він на те - “пишемо дві”. Ну дві то дві, зрештою. А що, якщо в годину не впишуся й справді. “Стилі ще треба прикрутити”, “Які стилі?” - питаюся я, “Це-еС-еС”. Хм, я думав, що це вже включено, але мій скрам мастер мене обганяє “ще дві години”. Мені вже здається, що це - занадто, але тут він видає “Ну і ще сам функціонал додати, ще дві години”. Оскільки ми логуємо шість годин в день (все за процесами - людина не може фізично всі вісім годин щось кодати, є ж і скрам-стенд-апи і різні обговорення), то виходить що кнопку, яку я по факту зробив за хвилин 15 (так, моїх півгодини - це був оверестімейт) я роблю один день. Але в естімейт я вписуюся. А це гарно виглядає на графіку, які так любить наш проджект менеджер. Ну і завжди приємно мати такі буферні таски, якщо випадково навіть при таких щедрих естімейтах певне завдання виконуватиметься довше.

Регрешн тестінг

Один день зі спрінта йде на регрешн тестінг. Система - складна і все що ми робимо теоретично може її поламати. Теоретично, тому що ми знаємо що нічого з того, що ми зробили не може зачепити функціонал, який прописаний в тесткейсах. Тесткейси були написані дуже давно, ще коли нас не було на цьому проекті, їх написав хтось дуже розумний, тому ми їх і не апдейтили. І навіть нові не писали (зрештою - скрам не вимагає писати тесткейси). І що з того що половина з них вже неактуальна? Є тест-кейси, отже треба їх прогнати. І ми сиділи, всім тімом і проганяли тест-кейси на регрешн тестінг. Був такий процес, отже треба виконувати. Регрешн баги ніколи не знаходилися і це було показником, що ми добре робили свою роботу.

Демо

Один день зі спрінта іде на демо. Так прописано в процесах і клієнт на це підписався. Перетин з клієнтом - година-дві в день. Отже цілий день ми активно готуємося до демо. Бо демати є що. Навіть якщо б і не було, проти процесів ж не попреш. Уважний читач можливо вже встиг підрахувати, що з десяти днів спрінта працюємо ми лише сім (мінус планінг, мінус регрешн, мінус демо) без поправки на наші ідеальні естімейти. Але кому доводилося найгірше - це нашому тестеру.

Тестування

Трохи згадаємо, що таке спрінт. Спрінт - це проміжок часу, за який команда має видати ітеративно кращий продукт, готовий до запуску в продакшн. Це, звичайно трохи ідеалізовано, але те, що спрінт видає готовий шматок функціоналу - це факт. І ось як вписати сюди тестера? Ну перший день спрінта він планує разом з нами, але що ж йому робити другий день? Нічого ще не написно а тестувати щось треба. Тестер чекає хоч чогось. Хоча розуміє, що тестувати напівнаписаний продукт - це невдячна справа, тому що все одно треба буде перетестовувати. Але тестер не переживає. Він чекає тиждень поки щось вже буде написане. З нашими щедрими естімейтами ми зазвичай готові заздалегідь і в нього є десь два дні, щоб потестувати, а в нас теж є два дні щоб фіксити баги. Якщо багів нема - то робочий час на спрінті - це п’ять днів. Помітимо - якби наші естімейти були менш досконалі і ми завершували роботу рівно в середу в шостій вечора, як і проестімейчено, то тестеру б довелося тестувати в ніч з середи на четвер. Я раз намагався запропонувати, щоб тестер перші дні спрінта тестував сторі попереднього спрінта, але мені швидко пояснили, що це - не за процесами і мені довелося погодитися.