Comments 2
Спасибо за интересный и подробный рассказ о Вашем опыте. Хотелось бы попробовать внедрить что-то подобное и у себя в команде...
Я пока не разбирался подробно в самой описанной технологии, но есть несколько вопросов после прочтения самой статьи. Насколько я понял метрики оценки, дизайн занял 3 дня (правда не понятно сколько человек участвовало на этом этапе и сколько фактически человеко-часов было потрачено) и потом 4 разработчика реализовали доработку за 18 дней (4 * 18 * 8 = 576 человеко-часов). По мне, так это далеко не маленьких проект...
В описании Вы делаете упор на то, что по факту трудозатраты на дополнительный этап дизайн-проекта почти не увеличивают общий скоуп проекта за счет "уменьшения" трудозатрат на последующих этапах разработки... Однако, мне кажется, что такой вывод можно сделать далеко не для всех проектов, а только для проектов больше определенного (мне пока не понятного) объема.
Объясню суть. В моей практике, неоднократно, были задачи с оценкой, например, 8 человеко-часов или около того. Да, это могут быть довольно "простые" и небольшие по объему задачи, но они имеют место быть! Наверняка у Вашего подхода к дизайн-проекту есть какое-то минимальное время на выполнения... По ощущениям, это никак не меньше нескольких часов и это при варианте если участвует всего один человек, иначе на кодирование времени вообще не останется...
Хотелось бы узнать Ваше мнение о таком варианте использования вашей методики, ведь небольшие задачи тоже нужно делать и это совсем не значит, что делать их нужно "некачественно"...
Спасибо за Ваш вопрос!
Мы тоже задавались вопросом — в каких случаях явно выделенный этап проектирования повышает эффективность разработки, а в каких понижает и при этом не даёт преимуществ в долгосрочной перспективе.
Начну с общих соображений.
Длительность проектирования тем больше, чем сложнее реализуемая задача.
В общем случае цена исправления ошибочного решения увеличивается со сложностью задачи.
Небольшие, но частые изменения в проекте оказывают влияние на его архитектуру. Поэтому важно реализовывать их качественно.
В нашей команде изначально мы внедряли процесс проектирования для крупных задач, так как его необходимость там наиболее очевидна. При этом, в небольших задачах тоже иногда встречались неудачные решения, которые приходилось дорабатывать по результатам код-ревью, либо со временем при рефакторинге. Поэтому следующей итерацией было описание дизайна вообще для всех задач, где было больше одного изменения в коде. И это дало интересный результат, поскольку в процессе дизайн-ревью мы действительно несколько раз отлавливали неудачные решения, то есть экономили время на последующей реализации. Сейчас описание дизайна у нас остаётся на усмотрение разработчика.
Мне кажется что для небольших и однотипных задач можно применить такой подход: Если дизайн по задачам такого типа не проектировался, описать его и вынести в техническую документацию проекта. В дальнейшем, при реализации похожих задач можно заглядывать в этот документ и использовать выбранные решения. Преимуществом тут будет то, что дизайн описывается более абстрактно чем код, поэтому переносить его с задачи на задачу (пусть даже мысленно) проще.
Если говорить про пример из статьи, то это была крупная задача. Проектировал её один человек, затем было ревью с командой и раздача декомпозированных подзадач.
На описание дизайна небольших задач уходит от 30 минут до двух часов. И здесь важно чтобы коллеги по команде смогли быстро подключиться и прочесть дизайн. При этом, можно фиксировать кто проводил дизайн-ревью и подключать этого же специалиста для код-ревью. Тогда экономится время, поскольку он уже знаком с задачей и остаётся проверить совпала ли фактическая реализация с дизайном описанным до её начала.
Надеюсь, ответил на Ваш вопрос.
Хороший, плохой, никакой: почему важно проектировать дизайн и как это делать?