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

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

Що таке Implementation Plan

Отже, Implementation Plan — це детальний конкретизований план, прописаний у форматі чеклиста. Він складається розробниками перед початком роботи над кожною user story.

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

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

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

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

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

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

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

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

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

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

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

Front-end;
Backend;
UI Library;
Specs.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Може здатися, що немає необхідності створювати Implementation Plan для маленьких і простих задач, коли все і так очевидно.

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

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

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

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

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

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

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

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

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

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

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

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

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

Про використання Implementation Plans в різних командах

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

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

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

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

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

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

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

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

Плюси і мінуси Implementation Plans

Вище я описав переваги складання Implementation Plans, розповів про те, з якими труднощами ми стикаємося при відсутності належного планування. Давайте підсумуємо.

Плюси підходу:

Він дозволяє команді:
- дати більш точну оцінку завданням;
- розібратися в складнощах і заплутаних моментах;
- виявити блокери на стадії планування і скоротити tech debt;
- поліпшити процес обміну знаннями.
Implementation Plan у вигляді чеклиста дає чітку структуру етапів реалізації завдання і можливість відслідковувати прогрес.
Детальний план дій економить час і дозволяє оптимізувати процес розробки завдяки можливості:
- розглянути різні опції і сценарії, перед тим як почати писати код;
- уявити повну картину з самого початку роботи;
- спростити синхронізацію з учасниками команди і зовнішніми експертами;
- делегувати завдання іншим інженерам.

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

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

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

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

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

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

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

Спочатку, як, втім, і з будь-яким іншим інструментом, процес може бути трудомістким. Але в якийсь момент планування почне займати менше часу і поліпшити вашу ефективність.

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

Опубліковано: 14/01/19 @ 08:00
Розділ Різне

SEO Блог