Что такое Implementation Plan, или Как планировать реализацию при разработке

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

Что такое 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.

Несколько важных моментов, которые стоит учитывать:

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

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

Насколько детальным должен быть Implementation Plan

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

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

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

Если план неясен, мы открываем код и пытаемся понять, как он работает и что нужно добавить / изменить. По сути, вы будете делать то же самое при разработке, если у вас нет плана.

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

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

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

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

Мы работаем в таком подходе уже несколько лет, и за это время он доказал свою эффективность:

1. Мы вникаем в детали каждой user story до начала разработки. Это позволяет увидеть картину целиком, выяснить все требования, вопросы, обдумать возможные решения.
2. Определяем сложность каждой из user stories. В дальнейшем это помогает более точно оценить необходимое время и ресурсы.
3. Заранее планируем детали реализации. Это позволяет минимизировать количество дополнительных вопросов к клиенту или продакт-менеджеру во время самой итерации.

Особенности составления планов для разных типов задач

Небольшие и очевидные задачи

Может показаться, что нет необходимости создавать Implementation Plan для маленьких и простых задач, когда всё и так очевидно.

Однако даже в таких случаях создание чеклиста для простой задачи позволит:

• передать задачу в разработку другим инженерам, особенно новым в проекте;
• продемонстрировать продакт-менеджеру все этапы реализации, аргументировать оценку;
• убедиться, что задача действительно простая и не несет за собой дополнительных зависимостей.

Практика показывает, что на крупных проектах простые, на первый взгляд, задачи могут оказаться гораздо сложнее. А если задача действительно простая, то и план ее реализации будет составлен очень быстро. Ради уверенности обычно имеет смысл взглянуть на код и набросать план.

Задачи с некоторым уровнем неопределенности

Если некоторые аспекты задачи непонятны, хорошей идеей будет провести несколько экспериментов перед тем, как планировать пути реализации.

Например, можно:

• потратить немного времени на написание кода для проверки идеи;
• открыть консоль веб-сервера или базы данных и проверить основные запросы.

Это помогает выяснить, что именно вас блокирует и куда двигаться дальше. Вы в любом случае будете делать то же самое во время реализации, так что время на эксперименты не будет потрачено зря.

Полностью непонятные задачи

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

Принцип планирования для таких задач такой же: нужно экспериментировать. Открыть код, посмотреть, как он работает, начать писать то или иное решение. Составить чеклисты для тех моментов, которые понятны. Это должно внести ясность.

Если же спустя два-три часа планирования подобной задачи вы особо не продвинулись, имеет смысл обсудить этот момент с менеджером и предложить дополнительный день или два на spike (более детальное изучение путей реализации).

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

Об использовании Implementation Plans в разных командах

Работая с разными командами, я имею возможность наблюдать за тем, как разные люди работают с Implementation Plan подходом. В том числе и за тем, как перестают ему следовать и как это влияет на реализацию запланированных задач.

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

Обычно, когда в команду проекта приходит новый человек, он с большим энтузиазмом относится к созданию подробных планов, поскольку это помогает ему быстро войти в процесс и отслеживать прогресс. Но чем основательнее он разбирается в тонкостях проекта, тем менее охотно придерживается процесса планирования.

Чеклисты становятся всё менее подробными и в какой-то момент инженер прекращает их писать вовсе. С большей уверенностью инженеры начинают оценивать задачи «на глаз». В итоге бывает, что задача, оцененная в два поинта, оказывается не законченной через неделю или две.

Команды, избегающие детального планирования задач

Многие предпочитают минимизировать планирование перед реализацией. Либо не делают планирование достаточно детальным.

В таких случаях часто возникают следующие проблемы:

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

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

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

Плюсы подхода:

1. Он позволяет команде:
   
   • дать более точную оценку задачам;
   • разобраться в сложностях и запутанных моментах;
   • выявить блокеры на стадии планирования и сократить tech debt;
   • улучшить процесс обмена знаниями.
2. Implementation Plan в виде чеклиста дает четкую структуру этапов реализации задачи и возможность отслеживать прогресс.
3. Детальный план действий экономит время и позволяет оптимизировать процесс разработки благодаря возможности:
   
   • рассмотреть различные опции и сценарии, перед тем как начать писать код;
   • представить полную картину с самого начала работы;
   • упростить синхронизацию с участниками команды и внешними экспертами;
   • делегировать задачи другим инженерам.

У любого, даже самого интересного и эффективного подхода есть и другая сторона. Вот несколько проблемных моментов:

1. Implementation Plan не бывает идеальным, его нужно улучшать, дорабатывать и обсуждать, а это требует времени.
2. Если вы работаете на клиентском проекте, иногда бывает сложно убедить клиента в том, что целесообразно один полный день уделить планированию вместо написания кода.
3. Результат может быть не заметен сразу. Изменения в процессах обычно требуют нескольких спринтов, чтобы понять эффективность.

Есть и психологический момент: нужно поверить в то, что подход детального планирования себя оправдывает. Иногда стоит отбросить уверенность в своих знаниях проекта и способностях оценивать задачи на глаз.

Следующие шаги

Целью статьи было поделиться нашим подходом к планированию, обсудить плюсы и минусы, которые мы выявили в процессе.

Если вас заинтересовал этот метод, предлагаю попробовать внедрить его у себя на проектах:

1. Начните с составления чеклистов для простых задач.
2. Покажите их другим разработчикам: будут ли им понятны ваши пункты? Смогут ли они по ним работать?
3. Попробуйте оценить задачи исходя из сделанных планов.
4. Анализируйте результаты. Насколько точными оказались ваши оценки? Что изменилось в процессе работы?
5. Ищите, что можно улучшить. Экспериментируйте с формой и структурой чеклистов, их содержанием.

Поначалу, как, впрочем, и с любым другим инструментом, процесс может быть трудозатратным. Но в какой-то момент планирование начнёт занимать меньше времени и и улучшит вашу эффективность.

Возможно, у вас есть похожие процессы и подходы? Или наоборот, вы работаете по совершенно другой схеме? Буду рад обсудить в комментариях.