Що таке Implementation Plan, або Як планувати реалізацію в розробці

Як Full Stack Engineer у компанії Railsware, я належу до тієї категорії людей, яка вважає, що правильне планування робочого процесу — половина успіху. Тому хочу поділитися способом, який ми використовуємо під час планування роботи над user stories у кожному спринті. Ми називаємо його implementation plan або ж ImPlan.

Що таке Implementation Plan

Отже, implementation plan — це детальний конкретизований план, прописаний у форматі чекліста. Його складають розробники перед початком роботи над кожною user story.

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

Будемо відверті: часто інженери лінуються додавати ще один крок до звичних процесів, особливо коли йдеться про планування. Для цього потрібні вагомі причини. На мій погляд, implementation plan дає команді такі переваги:

1. Уникнути неправильного розуміння вимог до кожного завдання та максимально точно оцінити час на реалізацію.
2. Продумати задачу, перш ніж фактично почати писати код.

Більш детально про переваги цього підходу розповім наприкінці статті.

У чому суть підходу

Процес виглядає так: спочатку ми визначаємо, які user stories реалізовуватимемо в наступному спринті. Далі завдання інженера — скласти покроковий implementation plan для реалізації кожної з них. Зазвичай він включає:

• Повний шлях до файлу, який потрібно змінити.
• Зміни, які потрібно внести у цей файл. Наприклад:

`add ’user_id’ parameter to required params of ’api/shares_controller.rb’`

• План тестування. Він може містити конкретні файли, які слід покрити тестами, а також набори даних, які потрібно перевірити.

Важливо прописувати всі кроки максимально конкретно: наприклад, запис «написати тести» сам по собі не дасть достатньо інформації.

Для зручності читання і навігації ми структуруємо чекліст за такими блоками:

• Front-end
• Backend
• UI Library
• Specs

Кілька важливих моментів, які варто враховувати:

1. У процесі реалізації не завжди обов’язково суворо дотримуватися порядку кроків, зазначених у плані: він може змінюватися під час розробки.
2. Деталі плану не є статичними — їх можна коригувати в ході реалізації.
3. Створювати Implementation Plan і безпосередньо виконувати прописані кроки можуть різні люди.

Для створення самого чекліста можна використовувати будь-який зручний сервіс. Зазвичай, ми працюємо з Trello, Smart Checklist для Jira чи Clubhouse.

Наскільки детальним має бути implementation plan

Наша головна мета — структурувати та спростити процес розробки.

В ідеалі потрібно прописати всі зміни, необхідні для реалізації (або ж імплементації) функціональності. Вони мають бути зрозумілими кожному інженерові, який працюватиме над user story, щоб навіть нові учасники процесу могли долучитися без додаткових розʼяснень.

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

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

Якщо ж неясно, як саме реалізувати — який фреймворк використовувати, яку частину застосунку змінити, — то можна почати писати код і експериментувати. Обмеживши експеримент у часі (наприклад, одним днем), ви проясните незрозумілі моменти і при цьому не витратите надто багато часу на спроби.

Процес планування на клієнтських проєктах

Перед початком ітерації ми проводимо IPM (Implementation Planning Meeting) — зустріч для планування та оцінки завдань на найближчі два тижні.

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

Ми працюємо за таким підходом уже кілька років, і за цей час він довів свою дієвість:

1. Заглиблюємося в деталі кожної user story до початку розробки. Це дає змогу побачити загальну картину, з’ясувати всі вимоги, поставити запитання та продумати можливі рішення.
2. Визначаємо складність кожної user story. Надалі це допомагає точніше оцінити необхідний час і ресурси.
3. Заздалегідь плануємо деталі реалізації. Це дає змогу мінімізувати кількість додаткових запитань до клієнта або продакт-менеджера під час ітерації.

Особливості складання планів для різних типів завдань

Невеликі та очевидні завдання

Може здаватися, що немає потреби створювати implementation plan для маленьких і простих завдань, коли все й так зрозуміло.

Однак навіть у таких випадках створення чекліста для простої задачі дасть змогу:

• Передати завдання на розробку іншим інженерам, особливо новим yf проєкті.
• Продемонструвати продакт-менеджеру всі етапи реалізації та обґрунтувати оцінку.
• Переконатися, що завдання справді просте та не тягне за собою додаткових залежностей.

Практика показує, що у великих проєктах «прості на перший погляд» завдання можуть виявитися значно складнішими. А якщо завдання дійсно просте, то план його реалізації скласти дуже швидко. Заради впевненості зазвичай варто подивитися на код і накидати план.

Завдання з певною невизначеністю

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

Наприклад, можна:

• виділити трохи часу на написання коду, щоб перевірити ідею;
• відкрити консоль веб-сервера або бази даних і перевірити основні запити.

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

Повністю не зрозумілі завдання

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

Принцип планування для таких завдань той самий: потрібно експериментувати. Відкрити код, подивитися, як він працює, почати писати те чи інше рішення. Скласти чекліст для тих моментів, які вже зрозумілі. Це допоможе внести ясність.

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

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

Як використовувати implementation plans у різних командах

Працюючи з різними командами, я маю можливість спостерігати, як люди використовують підхід implementation plan. Зокрема, як вони припиняють йому слідувати та як це впливає на реалізацію запланованих завдань.

Нові інженери

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

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

Команди, які уникають детального планування завдань

Багато хто схильний мінімізувати планування перед реалізацією або зовсім не робити його достатньо детальним.

У таких випадках часто виникають наступні проблеми:

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

Переваги та недоліки implementation plans

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

Підсумуймо.

Переваги підходу — він дозволяє команді:

• дати точнішу оцінку завданням;
• розібратися в складнощах і заплутаних моментах;
• виявити блокери на стадії планування та скоротити технічний борг;
• покращити процес обміну знаннями.

План реалізації (Implementation Plan) у вигляді чекліста дає чітку структуру етапів реалізації завдання та можливість відстежувати прогрес. Детальний план дій економить час і дозволяє оптимізувати процес розробки завдяки можливості:

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

У будь-якого, навіть найцікавішого та найефективнішого підходу є й інша сторона. Ось кілька проблемних моментів:

• План реалізації не буває ідеальним, його потрібно покращувати, доопрацьовувати та обговорювати, а це вимагає часу.
• Якщо ви працюєте на клієнтському проєкті, іноді буває складно переконати замовника в тому, що доцільно один повний день приділити плануванню замість написання коду.
• Результат може бути непомітний одразу. Зміни в процесах зазвичай вимагають кількох спринтів, щоб зрозуміти ефективність.
• Є й психологічний момент: потрібно повірити в те, що підхід детального планування себе виправдовує. Іноді варто відкинути впевненість у своїх знаннях проєкту та здібностях оцінювати завдання на око.

Наступні кроки

Метою статті було поділитися нашим підходом до планування, обговорити плюси та мінуси, які ми виявили в процесі. Якщо вас зацікавив цей метод, пропоную спробувати впровадити його у себе на проєктах:

• Почніть зі складання чеклістів для простих завдань.
• Покажіть їх іншим розробникам: чи будуть їм зрозумілі ваші пункти? Чи зможуть вони за ними працювати?
• Спробуйте оцінити завдання, виходячи з зроблених планів.
• Аналізуйте результати. Наскільки точними виявилися ваші оцінки? Що змінилося в процесі роботи?
• Шукайте, що можна покращити. Експерементуйте з формою та структурою чеклістів, їх змістом.

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU