Я заметил, что зависимости через модели и поля в БД гораздо лучше, чем зависимости по API сервисных объектов. Объясняю это тем, что проектирование изменений в БД производится тщательнее, поэтому, когда принято решение, вероятность его изменения низка.
Зависеть же от ещё не разработанных сервисных объектов крайне дискомфортно. Я бы советовал рассматривать зависимости между задачами по API сервисных объектов как decomposition smell (термин аналогичен code smell), то есть маркер низкого качества декомпозиции.

Пример ошибки раздельного проектирования модели и пользовательского интерфейса в проекте на Ruby on Rails

SPL
На ревью кода коллегам сразу будут видны и модель, и код пользовательского интерфейса, её использующий, будет очевидно большинство принятых решений.
Может показаться, что если следовать этому правилу, то задачи будут слишком большими по оценке трудозатрат. Можно попробовать заводить две задачи. Одну — для реализации основного поведения, а вторую — для второстепенных улучшений, про которые сразу не подумаешь. Хотя если менеджмент понимающий, то я бы рекомендовал заводить крупные целостные задачи и не пользоваться этим советом.
Разделение внутри алгоритма
Рассмотрим пример фичи:

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

Если для такой задачи делать человечную декомпозицию, то можно выделить основную задачу одному человеку на 5 дней, а вспомогательные задачи небольшого объёма дать коллегам, чтобы разгрузить голову основного исполнителя. Если же исходить из того, что люди ленивые и дата релиза уже назначена, то нужно «подстраховаться»: разбить весь объём работ на небольшие задачи менее двух дней в объёме трудозатрат и раздать двум доступным разработчикам.
Между кусками работы этих разработчиков будет много зависимостей. Один разработчик будет создавать узкоспециализированный сервисный объект, который должен будет использовать другой. До начала разработки они должны предугадать подходящий API и потом рассчитывать, что он не изменится, чтобы не подкинуть друг другу лишней работы. Принятый ими API не может быть достаточно хорошо продуман, ибо в этой ситуации некому думать об алгоритме целостно. В нём гарантированно будут ошибки, и он будет оказывать давление на психику исполнителей.
С горем пополам разработчики реализуют свои части мозаики алгоритма. С чувством уверенности, что они сделали свои части работы хорошо, даже автотесты проходят, они выкатятся на ручное тестирование. Хорошо, если ручные тестировщики есть в команде.
И тут выяснится, что только 10% сценариев использования работают корректно, а именно: при добавлении строки в первое множество происходит изменение состояния во втором множестве, при удалении же ничего не происходит.
Винить в этом разработчиков было бы несправедливо. Ни у одного из них не могло быть в голове целостной картины, ибо поставленные им задачи имели узкие границы, конкретные постановки и сроки без запаса по времени, а сроки срывать никто не любит. У них не было и достаточно политического веса, чтобы сказать, что по такой декомпозиции невозможно сделать работу качественно. Заранее можно иметь лишь интуитивное и смутное ощущение неправильности декомпозиции. Важным маркером здесь является наличие зависимостей между разработчиками по API сервисных объектов, но как это доказать в моменте, совершенно неочевидно.
Эта история из жизни позволила ретроспективно выявить проблемы и формализовать интуитивные действия при декомпозиции, которые мне удалось сформировать за годы работы.
Стратегии декомпозиции
Рассмотрим, какие стратегии помогут с небольшим количеством итераций приходить к человечной декомпозиции.
1. Отказ от декомпозиции
Если слово «декомпозиция» воспринимать буквально как разделение на части, то может показаться, что на выходе этого процесса должно обязательно получаться больше одной задачи.
Одна задача, даже большая, вполне может быть результатом процесса декомпозиции.
Если фича недостаточно велика и верхнеуровнево оценена в 3—5 дней, то может так случаться, что дальнейшее деление не даст преимуществ, но может создать проблемы, если ошибиться в границах задач. В особенности, если дать их разным исполнителям в надежде выполнить работу быстрее.
2. Делегирование исполнителю
У тимлида может сложиться ложное впечатление, что в его обязанности входит выполнение всех декомпозиций и спуск задач сверху членам команды разработки. Так может случиться, если в должностной инструкции не донести мысль, что от тимлида требуется обеспечить процесс декомпозиции, а не выполнить её самому. Ещё это впечатление может сложиться из ложного убеждения № 5, что человек нуждается в подчинении и чтобы ему подчинялись. Если же постановку задач делегировать их исполнителю, то никакой власти у тимлида не останется, никакого авторитета не будет и подчиняться ему как следует не смогут, при том что нуждаются в этом.
Тимлиду может даже казаться, что декомпозиция работы — это его основная обязанность, за которую его ценят. Или может казаться, что проще самому декомпозировать и требовать выполнения получившихся задач, чем помогать делать это другим. Эта иллюзия подкрепляется ложным убеждением № 6, что человек стремится избегать взаимодействия с людьми из-за мизантропии. Кажется, что проще спустить сверху готовое задание исполнителю, а не помочь ему сформировать это задание самостоятельно, исходя из понимания требований самим исполнителем.
На самом же деле декомпозиция работы для других людей — это крайне отчуждённая деятельность, которая выматывает и никогда не приносит удовлетворения. К тому же она имеет тенденцию превращать тимлида в «бутылочное горлышко» команды.
Если же декомпозицию делегировать, то у тимлида освобождается время для более творческой деятельности по стратегическому развитию продукта.
Тимлид может заниматься поиском инноваций и воплощением их в спокойном режиме вне критического пути создания ценности, непосредственно необходимой заказчику. Именно так произошло с тимлидом команды, к которой я принадлежу — тут я описываю настоящий опыт.
Таким образом, лучшим решением будет выбор главного исполнителя для реализации фичи и делегирование ему процесса декомпозиции. У главного исполнителя будет максимальная мотивация разобраться в требованиях и обеспечить себе и коллегам задачи с комфортными формулировками и оценками трудозатрат.
Лично я не могу приступить к написанию кода, пока у меня в голове не сложится приблизительный образ решения. Чтобы он сложился, необходимо точно знать, какую проблему и для кого нужно решить. Без этого мозг отказывается работать над задачей.
Если, напротив, меня поставят перед фактом назначенных мне конкретных задач с жёсткими требованиями по реализации и спущенными сверху оценками, то я оказываюсь демотивирован и ощущаю подавленность.
Можно возразить, что есть много разработчиков, предпочитающих работать по чётко сформулированным детальным требованиям, когда им говорят, что конкретно делать. Так и есть. Важно знать своих коллег и их предрасположенности. Таким сотрудникам я бы рекомендовал поручать второстепенные механизмы, требования к которым, как правило, более понятны и могут быть сформулированы заранее с достаточной точностью. Об этом далее в пункте 6 про выделение смыслового ядра.
3. Отказ от детального проектирования
Может сложиться убеждение, что для осуществления декомпозиции необходимо провести детальное проектирование или даже что декомпозиция и детальное проектирование — это одно и то же. Мне кажется, что декомпозиция всё-таки ближе к предварительному проектированию. Производя декомпозицию, лучше всё время оставаться как можно выше уровней реализации и проектирования — где-то между уровнем бизнес-требований и системных требований.
Удобно представлять себе весь объём функциональности как кусок мрамора. От него нужно отделять крупные части, границы которых очевидны уже во время предварительного проектирования.
Может помочь и такой приём: в воображении посмотреть на решение через прищуренные глаза. При этом картинка расплывчата, но различаются силуэты и границы подсистем.
Если произвести детальное проектирование во время декомпозиции, неизбежны ошибки и низкое качество. Ещё сильнее возрастают риски, если задачи будут делегированы голове, отличной от головы декомпозирующего. В результате исполнитель будет парализован в возможности вовремя распознать ошибки, допущенные уровнем выше, и тем более не сможет их исправить.
4. Группировка функциональности по сходному уровню сложности, неопределённости или риска
При планировании и оценке трудозатрат удобно разделять задачи по уровню сложности, неопределённости и риска. В зависимости от характера продукта может подойти разное количество баллов для оценки.
Допустим, получился вариант разделения на задачи и кажется, что он оставляет желать лучшего, но не понятно, как его улучшить. В этой ситуации нужно попробовать оценить, содержит ли каждая задача внутри себя вещи, сходные по уровню сложности, неопределённости или риска.
Если внутри задачи есть пункты с разными уровнями по этим свойствам, то с такой задачей можно застрять, при том что некоторые части уже готовы и их можно было бы продвинуть по конвейеру создания ценности. Это увеличивает объем незавершённой работы — W.I.P. (work in progress). Эмоциональное самочувствие исполнителя ухудшается, потому что на него давит этот незавершённый гештальт.
5. Поэтапная декомпозиция
Иногда бизнес приходит с очень большими фичами или наборами связанных фич, которые для бизнеса важны целиком, а не по частям.
В этом случае нужно разделить работу над этим большим набором фич по нескольким этапам, релизам, спринтам. Частично готовую функциональность можно выкатывать на продакшн, но скрывать за фича-флагами или за авторизацией, чтобы бизнес-пользователи их не видели.
Не нужно обеспечивать декомпозицию сразу по всем этапам. Нужно откладывать процесс декомпозиции до последнего момента, когда её уже необходимо сделать, чтобы коллектив не простаивал.
К этому моменту будет собрана максимально возможная информация для принятия решений и распределения работы по исполнителям. Бережливое производство учит откладывать момент принятия важных решений до последнего момента.
6. Выделение смыслового ядра
Часто в бизнес-фиче можно выделить смысловое ядро и второстепенные механизмы.
Например, смысловое ядро представляет собой алгоритм вычисления чего-либо, а второстепенный механизм осуществляет рассылку результатов вычисления на почту или поставляет их в точку интеграции с другой системой.
Эти концепты я почерпнул из главы 15 «Дистилляция» книги Эрика Эванса «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем». Для простоты рассуждений я объединил неспециализированные подобласти (Generic Subdomains) и связные механизмы (Cohesive Mechanisms), от которых очищается смысловое ядро (Core Domain), в категорию второстепенных механизмов.
Смысловое ядро всегда содержит больше сложности, неопределённости и риска, а второстепенные механизмы часто бывают более понятны, и границы их хорошо видны на этапе предварительного проектирования.
Хорошим решением может быть поручить смысловое ядро основному исполнителю по этой бизнес-фиче, а второстепенные механизмы отдать его помощникам. Таким образом, основной исполнитель освобождает свою голову от второстепенных деталей, снижается давление на него. Риск не уложиться в сроки релиза снижается.
Эта стратегия очень похожа на метафору хирургической бригады Фреда Брукса из книги «Мифический человеко-месяц».
Автор рекомендует назначать хирургом самого продуктивного программиста, а ассистентами менее продуктивных коллег с меньшим опытом.
Во времена, которые описывает Фред Брукс, системы были больше и обладали огромной случайной сложностью (accidental complexity) из-за неразвитости технологий и железа. Фичи были огромными, а итерации очень длинными.
Но стоит пойти дальше, ведь сейчас типичные бизнес-приложения разрабатываются небольшими приращениями, укладывающимися в итерации длиной от двух до четырёх недель. Технологии скрывают значительную часть сложности за абстракциями. Особенно в этом преуспевают omakase-фреймворки, в частности Ruby On Rails и подобные ему.
При этом есть огромный дефицит разработчиков на рынке, который только возрастает. Для компаний становится стратегически важно ускоренно выращивать младших сотрудников в средних и старших. Исходя из этой стратегии развития людей, стоит стараться чаще назначать хирургом не самого старшего, а самого младшего разработчика в команде и оказывать ему усиленную поддержку. Он будет вникать в фичу от уровня требований через декомпозицию с поддержкой наставника. Будучи максимально вовлечённым, младший разработчик будет ощущать драйв, осмысленность своей деятельности и быстрее расти.
Уже полтора года мы стараемся поступать таким образом, и опыт этот весьма результативный и благодатный.
В команде может оказаться добротный разработчик, отлично справляющийся с работой по чётким требованиям, но не желающий расти подобным образом. Ему можно поручать задачи по второстепенным механизмам, когда их декомпозирует хирург данной фичи. Других же разработчиков нужно назначать хирургами как можно чаще.
7. Выделение прототипа
Выделенное смысловое ядро может оказаться достаточно большим и неуправляемым по трудозатратам. Может быть не очевидным, как его разделить на подзадачи управляемого размера. В этом случае может выручить прототипирование. Стоит взять верхнеуровневую оценку трудозатрат на фичу и часть этого времени выделить на создание прототипа, а остальное время на продуктовую версию.
Можно поделить в пропорции «золотого сечения», когда меньшая часть времени отдаётся на прототип, можно поделить и в отношении 1:3. Но важно выделять на прототип достаточно времени, чтобы не ощущалось чрезмерное давление. Лучше по факту закончить прототипирование чуть раньше — тогда больше времени останется на продуктовую версию.
Как результат создания прототипа появится достаточно информации для разделения работы на задачи, выявления смыслового ядра и второстепенных механизмов, которые можно делегировать другим людям.
Прототип — это тренировочная версия фичи, целью которой является обкатка решений проектирования.
При разработке прототипа допускается снижение стандартов качества, чтобы уменьшить давление на разработчиков и немного сэкономить время. Например, можно не покрывать тестами побочные сценарии. Можно даже не разрабатывать через тесты, если это не оправдано в рамках проверки идеи. Можно не заботиться о логировании, обработке ошибок и надёжности.
Важно понимать и донести это до менеджмента, что ни в коем случае нельзя брать прототип как есть и дорабатывать его до продуктового состояния, как бы ни был велик соблазн.
Продуктовую версию следует разрабатывать с нуля в соответствии со всеми принятыми практиками и дисциплинами, на прототип же лишь посматривать для следования очертаниям решения. Главный эффект от прототипа — это формирование образа решения в голове и отбрасывание ошибочных предположений об алгоритме.
Когда нужно разработать какую-то фичу, обладающую достаточной новизной в системе, ощущается огромное давление. Нужно разработать всё сразу и не ниже уровня своего внутреннего стандарта. Это чувство парализует мозг и вгоняет в жёсткую прокрастинацию. Нужно дать возможность мозгу поэкспериментировать в более лёгкой, игровой форме, не требуя образцовых результатов.
Практика создания прототипов подробно описана в книге Дейва Томаса и Энди Ханта «Программист прагматик. Путь от подмастерья к мастеру» в 1999 году. Ещё раньше, в 1975 году, Фред Брукс описал подобную практику создания опытных систем в книге «Мифический человеко-месяц».
Приведу яркую цитату из Главы 11 «Планируйте на выброс» для тех, кто скептически относится к прототипам:

От прецедента к должностной инструкции
У меня есть убеждение, что вместо стремления к недостижимому идеалу необходимо бороться за уменьшение степени несовершенства и боли. Для меня самым масштабным достижением на этом пути стало формулирование идей человечной декомпозиции.
Уже полтора года мы в команде осознанно применяем обозначенные в статье приёмы. Это дало тимлиду возможность не заниматься постоянно декомпозицией работы для других, а производить инновации: существенно улучшить архитектуру работы с логами, мониторингом и многими другими общими инфраструктурными механизмами. Тимлид смог поучаствовать в качестве основного разработчика в создании нескольких бизнес-фич. Младший разработчик смог сделать то же самое. Он получил драйв, самостоятельность и в результате вырос до мидла. Я сам стал работать ещё комфортнее, чем до изменений. Другие команды стали применять человечную декомпозицию и рассказали мне о положительном опыте.
Моя инструкция по человечной декомпозиции стала в FunBox частью должностных инструкций и отстаивается техническим руководством перед менеджментом в случае недопонимания.
Надеюсь, стремление к человечной декомпозиции поможет всем нам попасть в мир, в котором больше компаний с развитой инженерной культурой и продуктами, обладающими большей концептуальной целостностью.
Источники
Прийти к идеям человечной декомпозиции мне помогли следующие книги:

• Дейв Томас и Энди Хант «Программист прагматик. Путь от подмастерья к мастеру».
  
• Фред Брукс «Мифический человеко-месяц».
  
• Эрик Эванс «Предметно-ориентированное проектирование (DDD). Структуризация сложных программных систем».
  
• Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».
  
• Мери и Том Поппендик «Бережливое производство программного обеспечения. От идеи до прибыли».

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

• Все книги Эриха Фромма.
  
• Николай Бердяев «Смысл творчества. Опыт оправдания человека» и «О назначении человека. Опыт парадоксальной этики».
  
• Кен Уилбер «Благодать и стойкость. Духовность и исцеление в истории жизни и смерти Трейи Киллам Уилбер».
  
• Даниэль Каннеман Thinking Fast And Slow.
  
• Роберт Пёрсиг «Дзен и искусство ухода за мотоциклом», в особенности рассуждения автора о смётке и вещах, которые её истощают. Я и само это слово узнал из книги.

Направления дальнейшего моего поиска:

• Клер Уильям Грейвз «Спиральная динамика». Первый раз услышал о спиральной динамике от Максима Цепкова на конференции AgileDays'14, кстати, тогда же, когда и про #NoEstimates. Это знание сильно повлияло на меня.
  
• Кен Уилбер «Интегральный подход». У Уилбера много книг. Я только начал их изучение но кажется, его миросозерцание созвучно Николаю Бердяеву и потому интересно, до каких озарений дошёл современный нам человек, интересующийся широким спектром вопросов философии, психологии, духовности и науки.

===========
Источник:
habr.com
===========
Похожие новости:

• [Тестирование IT-систем, Программирование, Тестирование веб-сервисов] Как мы «разогнали» команду QA, и что из этого получилось
  
• [IT-компании, Удалённая работа, Управление персоналом] Стажировки Google останутся удаленными и в следующем году
  
• [DIY или Сделай сам, Программирование микроконтроллеров] Дистанционное управление громкостью IP TV приставки при помощи Attiny13A
  
• [Искусственный интеллект, Машинное обучение, Управление персоналом] Логика у HR проста — обучать ИИ на «прижившихся»
  
• [Управление персоналом, Карьера в IT-индустрии, Читальный зал] Почему не работают реферальные программы найма в IT?
  
• [Высокая производительность, Python, Программирование, Машинное обучение] Deep Learning Inference Benchmark — измеряем скорость работы моделей глубокого обучения
  
• [Git, Программирование, Системы управления версиями] И полгода не прошло: выпущена система управления версиями Git 2.29
  
• [DevOps, Конференции, Управление продуктом, Управление разработкой] Как стать кросс-функциональной командой
  
• [Программирование, Scala] Scala как первый язык
  
• [Разработка веб-сайтов, JavaScript, Программирование] Веб-компоненты: руководство для начинающих (перевод)

Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_programmirovanie (Программирование), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_upravlenie_personalom (Управление персоналом), #_upravlenie_razrabotkoj (Управление разработкой), #_dekompozitsija_zadach (декомпозиция задач), #_tselostnost (целостность), #_delegirovanie_polnomochij (делегирование полномочий), #_loose_coupling, #_high_cohesion, #_zakon_parkinsona (закон паркинсона), #_zavisimosti (зависимости), #_perfektsionizm (перфекционизм), #_prokrastinatsija (прокрастинация), #_trevozhnost (тревожность), #_kachestvo (качество), #_inzhenernaja_kultura (инженерная культура), #_tehnicheskij_dolg (технический долг), #_proektirovanie (проектирование), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_programmirovanie (
Программирование
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_upravlenie_personalom (
Управление персоналом
), #_upravlenie_razrabotkoj (
Управление разработкой
)