Менеджмент Scrum-проекту: чи не надто часто ми відступаємо від правил

12 березня
Senior QA і Senior Team Lead Олексій Мелентьєв, Project Manager і Business Analyst Анастасія Мазур
Менеджмент Scrum-проекту: чи не надто часто ми відступаємо від правил
Ми — Олексій Мелентьев, Senior QA і Senior Team Lead з 10-річним досвідом в IT, та Анастасія Мазур, Project Manager і Business Analyst, в IT 4 роки — приблизно по три роки працюємо в DataArt, методологією Scrum та її практичним застосуванням цікавимося давно.

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

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

Відразу обмовимося, що ми ні в якому разі не беремося оцінювати доцільність самого Scrum-підходу чи ефективність його застосування в окремих командах. Ітиметься виключно про поширені випадки невідповідності теорії та практики, уявлення самих IT-фахівців про цей метод. А всім, хто сам працює за Scrum, наш матеріал допоможе перевірити базові налаштування.

Команди без Scrum-майстра

Близько 70 % опитаних відповіли, що в їхній команді немає Scrum-майстра. Це безперечний антирекорд нашого опитування. Втім, для аутсорсингових проектів результат, мабуть, виглядає передбачуваним: не так просто продати замовнику фахівця, чия задача — лише стежити за процесом. Принаймні саме так найчастіше виглядає Scrum-майстер з погляду замовника.

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

Ця, на перший погляд, невинна психологічна проблема призводить до іншої, більш практичного характеру. Ми з подивом виявили, що в переважній більшості проектів останнє слово залишається за менеджером проекту, тімлідом, продакт-оунером, тільки не за командою. Тут ми бачимо пряме протиріччя принципам Scrum, згідно з якими саме команда має вирішувати, хто і що буде робити, а потім спільно нести повну відповідальність за хід і результати роботи. Scrum-майстер або той, хто виконує його роль, лише організовує процес, допомагаючи ухвалити правильне рішення, а потім якісно та вчасно впоратися з задачами, які колеги (при його рівній участі) поставили самі собі.

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

Робота без планування

Лише 12 % опитаних відповіли, що користуються техніками планування, такими як Planning Poker. 45 % заявили, що проводять командне планування без застосування будь-яких технік, а 43 % зізналися, що командного планування не проводять взагалі, довіряючи цей етап роботи проджект-менеджеру чи тімліду.

Нам ці дані здаються гнітючими. Як команда може нести відповідальність за те, про що її не питали? Як PM чи TL може знати всі підводні камені дизайну, розробки та тестування?

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

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

Ще до DataArt Настя працювала у проекті, де планування й оцінки робили тільки Dev Lead і Project Мanager, не радячись із тими, хто безпосередньо виконуватиме задачу. Як результат — або терміни зривались і доводилось поясняти це замовнику, або розробники таємно овертаймили, відчуваючи провину за те, що не встигають. Хоча дедлайнів вони самі не встановлювали. Після цього всі зрозуміли, що підхід був у корені неправильним і брати участь у плануванні мають усі.

Життя без сторі-поїнтів

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

Мабуть, кожен, хто працював за Scrum-методом, колись обурювався: “Кому потрібні ці сторі-поїнти?”. Цей період у кар'єрі триває рівно доти, поки не потрапиш у проект, де вони тобі дійсно допоможуть. Story points дозволяють правильно оцінювати обсяг роботи, яку команда встигає зробити за спринт.

Чим це відрізняється від оцінки у годинах? Сторі-поїнти допомагають відв'язатися від звичних “Я виконаю цю задачу за 10 годин. А я протестую її за 5” та оцінювати складність задачі загалом, ґрунтуючись на досвіді. Тому що виявляється, що 10 годин на розробку плюс 5 годин на тестування не гарантують виконання задачі за 15 годин. Частина часу витрачається на комунікацію, на уточнення всіляких деталей, на погуглити, попити кави тощо. Можливо, задача ще й не пройде тестування з першого чи другого разу та вимагатиме доопрацювання. Можливо, знайдуться неточності у вимогах.

І таких “можливо” в кожному проекті безліч. Саме завдяки сторі-поїнтам можна абстрагуватися від дрібниць та оцінити складність задачі загалом. Вони допомагають тверезо поглянути на обсяг задач, який ваша команда встигає виконати за спринт. Адже в підсумку важливий саме обсяг роботи, а не час, витрачений на неї.

Зростання команди без кордонів

Близько 35 % опитаних відповіли, що їхня команда налічує понад 10 осіб. Нам і самим доводилося працювати в команді 40+ фахівців. Результат гранично передбачуваний: дейліки по годині, ретроспективи на 10 із гаком годин... Як ми до такого докотилися, запитаєте ви? Дуже просто!

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

У нашому випадку на одному з дейліків ми просто усвідомили, що далі так тривати не може, та почали перебирати варіанти, що робити далі. У підсумку ми розбилися на підкоманди. У кожної команди були свої ліди, які ходили на зідзвони своєї підкоманди та на лідовській зідзвон. Результат: дейліки стали укладатись у 30 хвилин, а їхня ефективність зросла в рази.

Робота без зідзвонів? Зідзвони без колег?

Ми всі знаємо поширені “церемонії” у Scrum: щоденні зідзвони, планування, ретро, ​​демо тощо. Але, на жаль, багато команд нехтують усіма або деякими зустрічами.

Щоденні стендапи проводять багато команд, хоча навіть їх іноді вважають зайвою витратою часу. Колись давно Настя працювала в нерозподіленій команді, де вирішили заощадити 15­–20 хвилин на відмові від якихось стендапів: “Ми ж в одній кімнаті сидимо, навіщо нам зайвий раз збиратися?”. У підсумку на розпитування на кшталт “А коли буде готове?” та ”Вже готове?” витрачали по три години на день. Тож колеги знову почали збиратися за чашкою кави вранці, щоб швиденько обговорити актуальні задачі та проблеми на нашому шляху.

Однак, коли команда велика, дотримуватись регламенту в 15 хвилин складно. Часто люди починають обговорювати деталі конкретної задачі, і зідзвон перетворюється на балаган. Принцип золотої середини вимагає говорити по суті та швидко — так, щоб укластись у відведений час.

Найчастіше команди нехтують загальним плануванням, залишаючи всі оцінки тімліду. Потім команді лишається дивуватись, намагаючись відповідати плану, який їм нав'язали.

Ще частіше ігнорують ретро. Менше 50 % опитаних не проводять ретроспективу та рев'ю спринту, тому що вважають це зайвою витратою часу.

Але сам факт проведення ретро не розв’язує всі проблеми. Деякі команди проводять його, але не роблять ніяких заміток і action items. А якщо й роблять, то в багатьох вони залишаються без уваги. Добре — призначати відповідальних або виконавців для всіх action items, а кожне чергове ретро починати з аналізу того, що було записано на попередньому.

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

Спринт без зрозумілої мети

Багато хто знає, що беклог спринту змінювати не можна. І так, і ні. Але чому так складно?

Уявіть, що під час спринту ви маєте побудувати одноповерховий будинок. У середині спринту кажуть, що потрібно змінити колір фіранок у вітальні цього будинку з синього на зелений. Але ж беклог не можна змінити!

Найголовніше — не беклог спринту, а його мета. Якщо було вирішено, що потрібно побудувати будинок — це та мета, якої ви прагнете. Зміна кольору фіранок ніяк не вплине на успіх вашого спринту, якщо будинок буде побудовано. Виявилося, що потрібні зелені? Якщо це можливо, чому б ні. Звісно, я не кажу про ситуацію, коли замість одного поверху раптом знадобилося два та ще й гараж, про який спочатку не йшлося. Для такого оновлення вимог, можливо, навіть знадобиться зупинка спринту та переоцінка всіх змін. Однак у будь-якому випадку головне — розуміти, якими будуть наслідки внесення нових вимог.

В одному з перших серйозних проектів Льоші замовник дуже любив змінювати цілі, побачивши якісь нові фічі на конференціях. Він негайно вимагав таких самих, і його не хвилювало, що співробітники працюють зовсім над іншим. Як то кажуть, бажання замовника — закон. Потрібно терміново? Терміново перемикаємось. Потім з'ясовується, що нова задача тягне зміни не лише фронту, а й логіки на бекенді. “А якщо ми почали робити зміни на бекенді, чи не додати нам ще ось таку фічу?”, — запитує замовник. Підсумок — реліз побачив тільки третю версію сайту на рік пізніше, ніж було заплановано.

Недосяжний ідеал

В ідеальному Scrum-проекті всі учасники мають бути багатофункціональними. На жаль, поки настільки універсальних команд ми не зустрічали. Здогадуємося, чому: людина не може вміти робити все. У нашому світі немає супергероїв, навіть людина типу “і швець, і жнець” (нехай навіть без музичних здібностей) — велика рідкість. Неможливо однаково успішно розвиватись у всіх напрямках, тому й виникає спеціалізація та зони професійної відповідальності.

Чіткий поділ обов'язків дозволяє налагодити паралельні процеси. Можливо, ви дивилися фільм “Засновник” про засновників мережі McDonald's. Брати Макдональди придумали, як вибудувати виробничий ланцюжок з великою кількістю людей, де кожен робить свою роботу: смажить котлети, нарізає овочі, наливає напої чи пробиває замовлення на касі. Це стало запорукою швидкості виробництва без втрати якості: на кожному етапі за нього відповідає співробітник, що досконально знає свою ділянку роботи.

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

Підсумки або Мораль без моралізаторства

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

  2. Успішний та ідеальний — це не синоніми. Ідеальних Scrum-команд в аутсорсингу, за нашими спостереженнями, просто не існує. Навряд комусь вдасться переконати замовника оплатити всі процеси, без яких ідеалом називатися не вийде. Але саме собою це не зруйнує вашого проекту: ви можете робити успішні релізи, наближаючись до методології вашої мрії в рамках затвердженого бюджету. Головне — не лише плисти за течією, а й звірятися з прокладеним курсом.

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

Підлаштовуючись під обставини, не забувайте про спеціальну літературу, кращі практики та власний досвід  — підводні камені, на які нас іноді повторно несе.

Літератури зі Scrum, звісно, багато, але нижче ми вирішили залишити трохи класики, що допоможе зрозуміти, як правильно побудувати процес:

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    19 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    10 вересня