20 квітня Java Hiring Challenge у Дніпрі. Отримай Job Offer в 1 день

Что такое 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. Ищите, что можно улучшить. Экспериментируйте с формой и структурой чеклистов, их содержанием.

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

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

LinkedIn

37 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Ниже уже частично затрагивали эту тему, но:

задача инженера — составить пошаговый Implementation Plan

и

нужно прописать все изменения

Так получается это займёт столько же по времени Senior/Lead разработчика сколько заняло бы у этого разработчика реализовать фичу. Наверное это имеет смысл отдавать на разработку только не к новым разработчикам, а, скажем, если реализацию предыдущей фичи разработчик ну очень сильно затянул (x2, x3 estimate) или ну очень сильно не туда завернул — чтоб поставить его на нужные рельсы и с каждой новой таской давать описание всё более и более абстрактно. С целью в идеале вообще убрать из процесса старшего товарища и ставить таск в виде BDD feature/story. Чтоб задачи могли зразу от BA/PO/PM или кто там её ставит попадать напрямую разработчику после planning’а, в котором действительно участвует вся команда, например играя в покер и тем самым утрясая подводные камни кто какие видит.
Когда-то давно слышал легенду что от какого-то не особо крупного немецкого заказчика кому-то пришло такое т.з. Разработчик был рад и счастлив — думать ничего не надо, только взять и по каждой строчке т.з. код написать. Это же деньги на шару. Я тогда подумал: «а зачем такое детальное т.з. ещё кому-то отдавать? Это ж обман клиента получается. Он то по сути сам всю работу сделал. А ему ещё и денег платить кому-то.» А так вы, получается, дважды биллите кастомера. Первый раз за синьёра который опишет

все изменения

в плоть до файла/поля что надо изменить и второй раз — за джуна (продажей и его как синьёра не балуетесь? С таким то тз...) который всё закодит. И, если это не инвестиции в развитие джуна чтоб потом получить самостоятельный юнит, а реальный плановый процесс — это ппц. Хотя, если кастомеру это продали...
Касательно

возникают следующие проблемы:
  1. Задачи оцениваются неточно, и в итоге результат сильно отличается от ожидаемого.
  2. Задачи выполняются не самым эффективным образом, либо занимают больше времени, чем предполагалось.
  3. Не рассматриваются потенциально действенные альтернативные варианты решений.
  1. Это точно происходило после общего планнинга (типа покера иже с ними)? Или кто-то подумал и решил что это займёт столько-то?
  2. Наблюдения действительно реальны, не может быть это выдаванием желаемого (то что методика работает) за действительное (методика жрёт столько же или больше платного времени как если бы её не было)?
  3. Сравнивали на реальных примерах? Например дать двум синьёрам, хорошо знакомым с проектом, с одинаковым KPI, максимально близким/схожим по прочим показателям производительности, один и тот же таск, только одному на реализацию сразу, а другому на детальный, построчный, пофайловый план и с реализацией джуном? Реально второй закончит за день и ещё день будет джун возиться и первый все два дня просидит? Чёт слабо верится. Скорее, если второй и выдаст план за 8h то первый спушит за 6h или меньше.
  4. Пробовали сразу дать таск на реализацию и после пуша провести детальное ревью тем инженером что в вашей методике составлял бы план? По платному времени должно быть столько же или меньше.

Спасибо за развернутый комментарий!

Я уже отмечал выше, что время, потраченное на планирование реализации не будет потрачено впустую. Т.к. то же самое время будет потрачено во время реализации фичи, пути реализации которой не были должным образом спланированы.

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

Вам не обязательно прописывать 100% детальное тз. Можно остановиться на этапе, когда вы будете ясно понимать, как задачу реализовать и сколько это времени займет. Если в конце спринта окажется, что вы ошиблись — попробуйте в следующий раз спланировать детальнее.

Это точно происходило после общего планнинга (типа покера иже с ними)? Или кто-то подумал и решил что это займёт столько-то?

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

Наблюдения действительно реальны, не может быть это выдаванием желаемого (то что методика работает) за действительное (методика жрёт столько же или больше платного времени как если бы её не было)?

Мы ограничиваем время на подобное планирование. От 4 до 6 часов в первый день спринта. К примеру спринт начинается в понедельник, планнинг митинг назначен на 7 вечера, время до планнинг митинга посвящается созданию implementation planов для каждой задачи.

Сравнивали на реальных примерах?

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

за джуна (продажей и его как синьёра не балуетесь? С таким то тз...)

Мы, в целом, не привыкли раздавать всем тайтлы. Официально все просто «инженеры»

Так получается это займёт столько же по времени Senior/Lead разработчика сколько заняло бы у этого разработчика реализовать фичу

Да, но есть «но», как всегда :)
В данном случае наиболее важное «но» — эта штука должна помочь уменьшить усилия по интеграции и верификации.
Если процесс построен таким образом, что разработчик полностью имплементировал фичу сам (без разделение на backend и frontend, к примеру), сам её покрыл всеми необходимыми тестами (не только unit, но ещё и integration + system как минимум), сам их прогнал, убедился, что фича на 100% работает и вылил на прод, после чего к этому коду больше никогда не вернулся — никаких проблем, ему этот план не нужен, он только тратит своё время на его написание.
Теперь несколько других моментов:
1. Интеграция. Особенно вкусен момент, когда интегрируемся с другой командой, которые не совсем в курсе наших задач. Во-первых, наличие такого плана значительно сократит 2-й команде время на интеграцию: куда проще интегрироваться, если описано, что поменялось vs реверс-инжиниринга или копания в чужих сорцах. На крайняк, когда разрабу с той стороны надоест копаться в чужой репе, он подойдёт к автору изменений и потратит своё время и его на уточнение, что же было сделано. В принципе, тот же кейс можно применить к frontend-разрабу с упором на JavaScript и его попыткам понять, что же там в Java backend разрабы накодили.
2. Тестирование. Не вдаваясь в детали, могу просто сказать, что такая штука, во-первых, улучшит качество тестов, а, значит, и качество проекта (проще написать тест, когда знаешь, что и как было сделано), а, во-вторых, уменьшит количество «closed by design» багов, сэкономив время как тестировщиков на открытие таких багов, так и разработчиков на их вычитку.

Если процесс построен таким образом, что разработчик полностью имплементировал фичу сам (без разделение на backend и frontend, к примеру), сам её покрыл всеми необходимыми тестами (не только unit, но ещё и integration + system как минимум), сам их прогнал, убедился, что фича на 100% работает и вылил на прод, после чего к этому коду больше никогда не вернулся — никаких проблем, ему этот план не нужен, он только тратит своё время на его написание.

справедливости ради это не совсем так причём настолько что сам «разработчик полностью сам» чисто технически полностью абстрактен просто потому либо настолько гениален что полностью держит в уме «несоставленный план» и следует ему в каждый любой момент своей работы либо и сам настолько глубоко не заинтересован в её результатах что ему вообще всё равно... ))

Просто потому что первая функция которая есть у всяких «приложений нотатников» это чеклисты по которым можно соотв. сперва составить список а потом проставлять галочки «ок это сделано» и это и есть тот самый план.

В более же ж реальном мире как только в результатах работы этого разработчика заинтересован кто-либо включая его самого так сразу же ж появляется «план» как форма отчётности и оценки «а где мы вообще делаем и когда планируем закончить и что вообще происходит?»

В этом месте основная борьба уже с уровнями детализации как стремлением к микроменджменту с одной стороны так и уровнями недетализации как стремлением к тому самому «непланированию как неспособности как-либо оценить и предсказать что вообще получится».

Государь не любил уступать иностранцам и верил в своих русских мастеров. Он приказал Платову отвезти блоху в Тулу и показать её тульским мастерам. Платов взял блоху и поехал в Тулу. Оружейники посмотрели блоху и обещали что-нибудь придумать. Три самых лучших мастера, один из них косой левша, две недели работали в полном секрете. Приехал Платов, спросил «Готово?» «Всё, — отвечают. — Готово.» Платов открыл шкатулку, а там лежит английская блоха как и была раньше. «Что же вы ничего не сделали! Я вам голову сниму!» А тульские мастера отвечают: «Мы вам секрета нашей работы сейчас не скажем. Везите нас к государю.» Схватил Платов левшу и повёз его в Петербург.

Вопрос именно в том что в промышленном производстве такой подход не работает одно дело гвоздики 2 недели выковать чтобы блоху подковать а другое дело запустить завод по выковке гвоздиков и к нему фабрику по подковке блох и к нему сервисную службу поддержки чтобы иметь эту блоху каждый дурак мог даёшь 100 рублей и на тебе айфон мериканский блоха английкая.

Вот об этом в основном история и умалчивает.

настолько глубоко не заинтересован в её результатах что ему вообще всё равно... ))
как только в результатах работы этого разработчика заинтересован кто-либо включая его самого так сразу же ж появляется «план»

Так вот об этом же и речь! )))
Если интеграции нет как факта — то никакой план не нужен. Если же появляется потребность в интеграции — с другими программерами, с тестировщиками, да даже с пользователями, в конце концов — сразу же появляются вопросы «а что же было сделано?», «как нам понять, что новая фича работает?» или хотя бы «покажи, на что ты потратил неделю своего времени, за которую тебе заплатили».

1. Интеграция. ... vs реверс-инжиниринга или копания в чужих сорцах.

а это уже снова об другом история это уже история об стандартизации и контрактах года болт м4 он имеет конкретные допуски и никакой «процент брака» чисто технически недопустим.

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

В принципе, тот же кейс можно применить к frontend-разрабу с упором на JavaScript и его попыткам понять, что же там в Java backend разрабы накодили.

причём вот именно про это же ж и речь! ))

Стандартизация — это прекрасно, но если разраб Вася — спец по фронтенду с каким-нить Node.js, а разраб Петя наваял микросервисную архитектуру, о которой Вася знает только в теории, и то в рамках полустраницы на хабре, то как ему за пару минут копания в коде, который он видит 1-й раз в жизни, понять, какие там изменения сделал Вася и, главное, как они повлияют на то, с чем ему надо интегрироваться?
Разумеется, потратив день-другой, Петя будет способен понять, что там написал Вася — но за день-другой ему надо было эту таску закрыть и приступить к следующей :)

понять, какие там изменения сделал Вася и, главное, как они повлияют на то, с чем ему надо интегрироваться?

эм... специфицировать интерфейсы протоколы вот это всё?

ЗЫ: чёртова классика актуальная наши дни #внезапно ))

Англичане встретили левшу как равного, по плечу похлопали, за руку поздоровались и сказали: «Камрад — хороший мастер.» Спросили его, где и чему он учился, знает ли арифметику. Левша ответил, что учился он по Псалтырю, а арифметику не знает. «Жаль, — говорят англичане, — если бы ты арифметику знал, то сообразил бы, что в каждой машине точный расчет силы есть, и машина в блохе точно рассчитана, и подков нести не может, поэтому она теперь не танцует. Левша согласился: «Мы науки не изучали.»

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

Цікава методика, схожа на написання псевдокоду. А не було бажання спробувати щось на подобі event storming для деталізації вимог та покращення розуміння домену?

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

Столкнулся на новом проекте с подобным подходом (план не просто пишется, а проходит ревью, возможно с коррекциями). За полгода впечатления неоднозначные с точки зрения разработчика (веб фуллстэк).

С одной стороны, при детальном планировании минимизируются шансы, что на код-ревью большой кусок кода будет зареджекчен с мотировкой типа «это вообще на бэке(или фронте, или хранимкой) надо делать». Это, конечно, плюс.

Минусы:
— при задаче, относящейся к типу с которым ещё не сталкивался, это «планирование» плавно перетекает в написание и отладку половины, и то и больше необходимого кода, а итоговый план выглядит как «доработать в ветке UI и обработку ошибок за пару часов», когда «планирование» заняло часов 50 (утрирую, но не сильно)
— на простых (которые сразу понятно как делать) задачах влом сильно расписывать, в том числе писать полные пути и упоминать все файлы, особенно инфраструктуры типа роутингов, переводов, навигации и прочего, не относящегося к бизнес-логике. Но потом краткий подход автоматом переносится и на более сложные задачи, что часто даёт неадекватный результат на код-ревью
— использовать планы в качестве документации к задаче не получается потому что они позиционируются именно как планы, от которых можно отступить в случае необходимости без необходимости их актуализировать. В результате бывает, что ищешь задачу аналогичную своей, копипастишь и адаптируешь её план, начинаешь делать, что-то идёт не так, лезешь в код и видишь что не соответствует плану.

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

Или предпочёл бы просто иметь возможность спокойно разбить задачи на подзадачи.

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

>

при задаче, относящейся к типу с которым ещё не сталкивался, это «планирование» плавно перетекает в написание и отладку половины, и то и больше необходимого кода, а итоговый план выглядит как «доработать в ветке UI и обработку ошибок за пару часов», когда «планирование» заняло часов 50 (утрирую, но не сильно)

Мы в таких случаях говорим, что нужно выделить время на tech spike для дополнительного исследования или экспериментов. spike всегда заранее лимитируется временем, от 4х часов до 2х дней, в зависимости от сложности и размера задачи. в конце спайка всегда проще увидеть, что можно разбить на подзадачи, как дальше продолжать.
временный лимит позволяет не закопаться в задачу слишком глубоко без необходимости.
в то же время, тот код, который вы напишете во время spike, скорее всего пригодится вам и для конечной реализации. то есть время не будет потрачено впустую.

>

Но потом краткий подход автоматом переносится и на более сложные задачи, что часто даёт неадекватный результат на код-ревью

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

>

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

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

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

Вот такие фразы меня всегда смущали по отношению к обычным, не исследовательским в целом задачам. Есть задача — её надо сделать, если она уже появилась, то есть необходимость. Пускай для знающего предметную область, систему, инфраструктуру и т. п. человека реализация займёт пару дней, а для новичка — пару недель. За пару дней на рисерч он или набросает высокоуровневый план, полный неопределенностей, либо сделает 20% задачи, не представляя как дальше делать. В обоих случаях почти нет разницы в итоге.

Как по мне, то жёстких лимитов на незнакомые задачи быть не должно, вместо дедлайнов -контроль прогресса, а если выходит за разумные рамки, то или помощь, или переназначение задачи, или отмена задачи.

вы после можете передать задачу на разработку другому инженеру

Такие сценарии не рассматривал, но как мне кажется между инженерами они в редких случаях применимы (вхождение в проект в основном, и то лучше, по-моему будет, как у нас — новичок сам составляет план, а кто-то его ревьювит). Как по мне это больше от инженера к техникам («кодерам») или от архитектора/техлида к инженерам. В последнем случае план скорее высокоуровневый без имен файлов, классов и методов обычно, максимум публичный API описан детально. Выдавать детальный план инженеру — сводить его роль от инженера к технику, убивать творческую составляющую инженерного труда. Может кому-то и понравится такая роль, но многим это убъёт (или должно убить :) ) мотивацию.

Кстати, и после составления детального плана желание собственно код писать может пропасть: задача уже решена и в бизнес, и в технических терминах, осталось только рутинно закодить\, имплементировать. Спасибо, что навели на эту мысль, понял почему не люблю детальные планы писать :)

Как по мне, то жёстких лимитов на незнакомые задачи быть не должно

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

Кстати, и после составления детального плана желание собственно код писать может пропасть: задача уже решена и в бизнес, и в технических терминах, осталось только рутинно закодить\, имплементировать.

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

У нас примерно такой же процесс, только называем мы его Implementation Roadmap.
В зависимости от изначальной сложности user story, разработчик либо дальше требует декомпозиции (если слишком сложно), либо сам выписывает roadmap. Кстати выписывать его должно именно тот, кому собственно и делать — если например выписал/оценил один, а затем таск попал другому, то последний соответственно имеет право переписать roadmap согласно своему видению и дать оценку.

Implementation plan/roadmap очень хорош в связке работы senior/junior. Но даже если на проекте работает два разработчика примерно одинакового уровня, то хорошей практикой является cross-check — взаимная проверка правильности понимания истории и как её стоит делать.

Согласен с вами.
Вы также можете передавать истории с написанным Implementation Roadmap другому инженеру просто для knowledge sharing. К примеру, если в команде есть два опытных инженера, каждый из которых хорошо знает одну часть системы, но имеет плохое понимание остальных.

Даже часть потом может пойти в документацию при правильном оформлении.

Эффективней и в плане решения задачи, и в плане шаринга знаний будет, по-моему, совместное составление плана с активной ролью у менее опытного в этой части системы, а у более опытного — ролью модератора, корректирующего ошибки.

В первую очередь мы определяем, какие из user stories реализуем в следующем спринте. Далее задача инженера — составить пошаговый Implementation Plan для реализации каждой из них.

А как вы определяете что реализовывать в следующем спринте до того как у вас есть план? Без плана оцениваете и потом вносите изменения если после составления плана выснилось что нужно больше времени на задачу?

У нас есть написанные продакт менеджером или инженерами user story с описанием задачи внутри. Выстраиваем список таких историй, например, в колонке Next Up — это потенциальные кандидаты на следующую итерацию.
Затем, во время планнинг митинга, не без помощи implementation planов оцениваем истории из Next Up. И в замисимости от средней velocity команды и текущих приоритетов проекта, выбираем окончательные истории на следующую 2х недельную итерацию.

Спасибо.
Глобально подход нормальный. Разбивать на задачи каждую US.
Вот меня смущает один момент, детальное разбиение задач. Для этого должна быть хорошая экспертиза. А если проект только начался и там больше 4 разработчиков и все меняется?
Из статьи слабо понятно комплексное решение, надо слушать и общаться :)

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

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

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

Это именно то, что раньше называли Waterfall

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

Суть атерфола именно в таком детальном планировании. Я работал по ватерфолу много лет и знаю о чем говорю.

Суть ватерфолла не в детальном планировании как таковом, а долгосрочном детальном планировании строго до начала любой разработки.

Просто не нужно слушать некоторых «ортодоксальных» Agile-коучей, у которых вотерфолл — это всё, что не укладывается в их личное понимание аджайла.

я скорее описал планирование в рамках одной задачи (user story). предполагается, что каждая отдельная user story не должна занимать больше 2х дней на реализацию.
к тому изменения плана в процессе реализации — абсолютно нормальная ситуация.

Тогда этот план превратится не в план, а в отчёт о реализации?

изначальная цель — иметь план действий, но конечный чеклист с отмеченными пунктами можно конечно рассматривать и как отчет.

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

Подписаться на комментарии