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

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

Навигация по статье:

• Ложные убеждения о человеческой природе
• Закон Паркинсона
• Континуум стилей декомпозиции
• Человечная декомпозиция
• Стратегии декомпозиции
• От прецедента к должностной инструкции
• Источники

Ложные убеждения о человеческой природе

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

1. Человек от природы порочен, и только давление общества заставляет его сдерживать свои порывы.
2. Человек ленив, и его нужно заставлять работать, иначе он будет прокрастинировать.
3. Человек склонен до бесконечности улучшать любой достаточно хороший результат, даже если это объективно не несёт никакой ценности (перфекционизм).
4. Человеком движет жажда материальных ценностей для себя (эгоизм и алчность).
5. Человек нуждается в подчинении и в том, чтобы ему подчинялись (авторитаризм).
6. Человек не любит людей и стремится избегать взаимодействия с ними в процессе решения рабочих и жизненных задач (мизантропия).

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

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

Закон Паркинсона

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

Работа заполняет время, отпущенное на неё.

Это Первый закон Паркинсона, который в 1955 году сформулировал историк Сирил Норткот Паркинсон в сатирической статье на основе наблюдений за британской бюрократией. К сожалению, эта сатира очень быстро распространилась и стала универсальным законом. Даже менеджмент в индустрии программного обеспечения взял его на вооружение, стал тиражировать и бороться с его проявлениями.

В книге Человеческий фактор. Успешные проекты и команды Том ДеМарко и Тимоти Листер обосновывают неприменимость этого закона к людям, занимающимся креативной деятельностью, в противоположность серийному промышленному производству и бюрократии. Здесь и далее я ставлю название закона в кавычки, чтобы подчеркнуть отношение к нему как к ложному утверждению в контексте, отличном от описания бюрократии.

Континуум стилей декомпозиции

Стили декомпозиции работы лежат в континууме:

• от микротаскинга, то есть дробления на неделимые атомарные задачи;
• до #NoEstimates, то есть полного отсутствия формального дробления и оценки трудозатрат.

Микротаскинг

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

• Если человек ленив (ложное убеждение 2), то задания нужно делать максимально мелкими, чтобы не было возможности ни минуты сфилонить и получить оплату за прокрастинацию.

  
  

• Если человек не любит людей и общение (ложное убеждение 6), то всех участников производства нужно обезличить и организовать процесс так, чтобы не требовалось никакого взаимодействия, кроме того, что выражается в коде, документации к нему и тикетах.

  
  

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

  
  

Это устройство производственного процесса очень напоминает конвейер, на котором рабочие могут выполнять незатейливые, изолированные операции, не требующие ни большой квалификации, ни взаимодействия с другими людьми. Ещё Карл Маркс в 1840-х и Эрих Фромм в 1960-х годах описали такое устройство производства и экономические причины его существования. Также они описали, насколько губительно и невыносимо это для человека. Участвуя в производстве такого характера, человек теряет связь с результатами своего труда, отчуждается от них. Для человека исчезает смысл в его деятельности, он ощущает подавленность и тревогу. Всё это ведёт к раннему профессиональному выгоранию и более тяжёлым последствиям.

Когда все задачи мелкие, то постоянно приходится переключать контекст внимания. Переключение контекста требует от мозга больших энергозатрат (об этом хорошо написано в книге Thinking Fast And Slow). Это огромный источник потерь для смётки. Ослабление смётки приводит к ошибкам. При микротаскинге нет места для восстановления мыслительных ресурсов, или, как это ёмко называет Максим Дорофеев, мыслетоплива. Забота об этом ложится на плечи работника.

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

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

NoEstimates

#NoEstimates (термин возник из хештега в Твиттере) предполагает, что любая фича в продукте разрабатывается быстрее, чем заинтересованные в ней лица успевают спросить про оценку трудозатрат.

Я узнал об этой концепции из доклада Асхата Уразбаева на AgileDays'14. Основными условиями для достижения ситуации, когда не возникает необходимости в оценках, Асхат называет следующие:

1. Непрерывная доставка ценности заказчику.
2. Отсутствие зависимостей, которые могут что-то сломать. Для обеспечения этого свойства нужен налаженный процесс непрерывной интеграции (CI) с междукомандными интеграционными тестами.
3. Уравновешивание возможностей, то есть пропускной способности команды, и потребностей заказчика.

Будучи под влиянием доклада и своего опыта, я пришёл к более строгим критериям, необходимым для работы без оценок:

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

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

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

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

Человечная декомпозиция

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

Свойства человечной декомпозиции

При человечной декомпозиции каждая задача удовлетворяет следующим критериям:

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

Вся совокупность задач должна соответствовать архитектурному принципу Loose Coupling / High Cohesion (Слабая зависимость / Сильная сплочённость), а именно:

• Loose Coupling: Зависимости между задачами должны быть минимальными.

  
  

• High Cohesion: каждая задача должна содержать сильно сплочённые функциональные возможности, чтобы ничего нельзя было выбросить без потери целостности размышлений о задаче.

  
  

Верификация декомпозиции

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

Контрольные вопросы к каждой задаче:

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

Контрольные вопросы к совокупности задач:

1. Нет ли между задачами слишком сильных зависимостей, возможно, неявных, в особенности если они даются разным исполнителям?
2. Являются ли все задачи управляемыми по объёму (оценка не превышает 35 дней)?
3. Не слишком ли мелко разбиты задачи и не нарушена ли их целостность?

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

Обоснование выбранной цифры для границы размеров задач

35 дней цифра условная. Граница размера задачи, которая помещается в голове, будет зависеть от сложности технологии. Данную цифру я привожу для проекта на Ruby on Rails.

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

Многих такая большая цифра может тревожить, если они склонны соглашаться c законом Паркинсона. Я встречал два вида опасений, связанных с этим законом:

1. Человек будет прокрастинировать всё время, которое ему выделят на работу, и под конец срока в авральном режиме сделает халтурное решение.
2. Человек быстро сделает всё, что нужно, но так как ещё остаётся время, то он из перфекционизма (ложное убеждение 3) будет заниматься ненужными улучшениями решения вместо того, чтобы перейти к следующей задаче.

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

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

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

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

Примеры нарушения целостности задач и ощущения исполнителей

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

Разделение работы над моделью и кодом, её использующим

Предположим, что реализуемая фича требует наличия сущности с персистентным хранением (модель в терминах Ruby on Rails) и CRUD пользовательского интерфейса для неё.
Напрашивающимся решением по декомпозиции будет завести задачу на реализацию модели и на реализацию пользовательского интерфейса, её использующего.

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

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

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

Разделение внутри алгоритма

Рассмотрим пример фичи:

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

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

Между кусками работы этих разработчиков будет много зависимостей. Один разработчик будет создавать узкоспециализированный сервисный объект, который должен будет использовать другой. До начала разработки они должны предугадать подходящий API и потом рассчитывать, что он не изменится, чтобы не подкинуть друг другу лишней работы. Принятый ими API не может быть достаточно хорошо продуман, ибо в этой ситуации некому думать об алгоритме целостно. В нём гарантированно будут ошибки, и он будет оказывать давление на психику исполнителей.

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

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

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

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

Стратегии декомпозиции

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

1. Отказ от декомпозиции

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

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 частью должностных инструкций и отстаивается техническим руководством перед менеджментом в случае недопонимания.

Надеюсь, стремление к человечной декомпозиции поможет всем нам попасть в мир, в котором больше компаний с развитой инженерной культурой и продуктами, обладающими большей концептуальной целостностью.

Источники

Прийти к идеям человечной декомпозиции мне помогли следующие книги:

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

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

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

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

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

Всем привет.

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

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

Вы их легко узнаете, это постоянные пациенты, просто напомню про них:

1. Архитектура хромает, внедрить новое решение сложно
2. Ошибки кодирования
3. Отсутствует автоматическое тестирование

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

Я сильно на этом не останавливаюсь, это тема 1 в рефакторинге, поэтому сразу к выводам, которые я сделал.

Разработанный продукт это коллективная экспертиза

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

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

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

Это замкнутый круг 1 экспертизы команды не хватает, но начинается рефакторинг, и делают его, внимание, те же посоны, которые это и написали.

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

Получится эдакий естественный отбор на проекте.

Люди боятся менять код

Добро пожаловать, это сеанс психологии для программистов.

Программисты реально боятся менять код, и их можно понять:

1. Тестов не хватает или нет
2. Как работает код не понятно
3. Сроки горят
4. Ресурсов нет
5. Менеджмент не поймет (обычный, но если управление огонь, всё будет хорошо)

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

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

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

Так вот, я считаю что это проблема 1, страх перед кодом и рисками.

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

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

Совет огонь, все про него знают, но на деле список выше никуда не делся, поэтому нельзя просто взять и отрефакторить, потому что получите проект, который разваливается, а почему?

Потому, что нет тестов, как работает код не понятно, и в итоге вместо смены чертежей автомобиля и сборки получится что Вася и Петя взяли болгарку, распилили Солярис, и собрали обратно в Таврию, а она не едет. Почему? ой, а потому что мы не знали про то влияние/поведение/задачи

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

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

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

Тесты это ключ

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

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

Поэтому получаем цепочку:
Тесты -> Рефакторинг -> Прощай борода и легаси

Звучит просто, красиво, но на практике тестов бывает мало. Или вообще не бывает, и причин тому несколько, как обычно:

1. Разработчики считают тесты отдельной темой и не вкладывают в оценки, пишут отдельно от разработки. Еще сложнее, если так думает управление проекта и хотят урезать тесты чтобы сложиться в сроки.
2. Тесты это время, а проект нужно сдавать сейчас, некогда писать нам тесты (это по идее тоже самое что и пункт 1)
3. Проект/компонент простой, зачем там тесты, там всё предельно просто и работает?
4. Сначала код напишем, потом покроем тестами. Но нет, руки не дошли, проект на месте не стоит, времени не нашлось. Так и лежит эта задача в черном ящике веки вечные.

Причин на самом деле миллион, но факт в том, что это блокирует рефакторинг, и, как следствие, не дает качеству расти вверх.

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

Что делать, Хьюстон?

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

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

В результате поймете что тесты это:

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

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

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

P.S. Если есть желание, напишите ваш опыт рефакторинга в комментариях, всем будет интересно.