Сорванные дедлайны IT-проектов — головная боль многих компаний. Это не только нервы, но и удорожание производства. Мы тоже периодически сталкиваемся с такой проблемой. Моя команда не исключение. Я решил исправить ситуацию и разобраться, где прячется корень зла.
В этой статье расскажу про наш опыт оптимизации работы, а именно, как мы внедрили Documentation First.
Почему мы не успевали сдавать проекты в срок
Наша основная боль была в том, что мы постоянно всё переделывали. Разработчики понимали свою конкретную задачу, но общего контекста не осознавали. То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты. Они думали, что надо просто вывести новый пункт и кнопку покрасить. А на самом деле под капотом надо было сделать еще 100500 правок, чтобы не задеть рядом стоящий функционал или полностью замкнуть кейс. Часто выходило так, что в начале проекта мы жалели времени на детальное продумывание задачи и потом получали "волейбол": разработчики отдавали задачи тестировщикам, те возвращали им обратно… и так снова и снова, долго и мучительно.
Берите плед, что-то вкусное и/или напитки, будем разбираться, почему так происходит и как с этим бороться.
Признаем честно: разработка программного обеспечения — это процесс производства. Какая бы доля творческого подхода ни была, написание ПО больше напоминает сборку изделия на конвейере, чем создание нового шедевра живописи или литературы. Вместо станков — люди, объединенные в четко построенную цепочку. А значит, как и в любом цеху, в разработке программного обеспечения тоже есть узкие места — звенья цепи, которые тормозят все процессы, а, следовательно, и все проекты.
Как мы поняли, что гибкие методологии не работают
Мы пытались внедрять гибкие методологии, но практика показала Agile-семейство не с лучшей стороны — чем более "гибким" становился подход, тем сильнее проявлялись узкие места.
Так происходит потому, что все agile-методологии придерживаясь одних и тех же ценностей приводят к увеличению точек контроля (т.е. частой демонстрации промежуточного результата). Кажется, что вот оно, счастье.
Но на практике это не так, и мы сейчас поймем, почему!
Где кроется истинная проблема: гипотеза
Чтобы заказчик понял, итерацию (результат), надо показать ему замкнутую цепочку. Логи в консоли или div без стилей ему ничего не скажут. Если результат можно разложить на конкретные требования, то всё ок. Но где сложность?
В реальной продуктовой разработке всё должно быть реализовано в существующей кодовой базе/продукте. Следовательно, у нас возникает много условий, связей, требований.
Мы не просто делаем фичу, нам необходимо аккуратно добавить решение новой проблемы в кодовую базу, которая уже решает задачи и имеет свои правила, ограничения и как-то влияет на данные "сбоку".
Если пренебрегать этим, то тестирование заведет 100500 ошибок, а заказчик щедро одарит дополнительными правками ("все равно будете править, тогда и вот это сделайте"). Так, фича стоимостью "5 рублей" становится серьезной доработкой на "50 рублей".
Но это лишь айсберг проблемы. Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки. И это не противоречит ценностям Agile. В рамках методологий такой подход является нормой: показываем итерацию, получаем правки, исправляем, а потом снова показываем "полуфабрикат", который продолжает быть проблемой в живом продукте…Начинаются доброски "в последний вагон" перед релизом.
Что мы получаем? Нервы на пределе, сроки сдвинуты, заказчик недоволен, команда выгорела, а ключевые сотрудники подумывают написать заявление на увольнение.
(!) Важно понимать, что в новом продукте эта ситуация будет менее выраженной. Там нет ландшафта, живых клиентов, уже работающего функционала. Ваши итерации ничему не будут мешать и не будут создавать столько проблем.
Основная проблема — понимание реальной сложности доработки. "Ручное TDD" (высокий уровень операционных затрат) усугубляет ситуацию.
Из-за уже имеющейся кодовой базы в месте стыковки с новыми фичами точки отказа появляются, как грибы. А исправления пожирают время разработчиков и тестировщиков, но не приносят нужного результата.
Как так получается? Мы планируем итерацию, а не пытаемся решить всю задачу, следовательно, пренебрегаем анализом дополнительных требований к ней. Они исходят не от заказчика, который о них может не помнить или банально не знать, а от реализации. Именно глубиной анализа итерации мы жертвуем, применяя гибкие методы управления проектами.
Как решить проблему?
Ввести дополнительный шаг, который позволит провести ревью решения до реализации (фактически, проверить ход мыслей). Для этого Брукс в своей книге "Мифический Человекомесяц" предлагает простое решение: перед написанием кода стоит разработать техническую документацию, но не простую, а ту, которую никто не любит делать. В ней обязательно должны быть:
бизнес-результаты прямо по месту доработки,
окружения: взаимосвязи, на что влияет и т.п.,
логические схемы решения и применяемые алгоритмы,
типовые выборки и используемые в них индексы базы данных,
ограничения реализации.
Сегодня такой подход называется Documentation First.
Как встроить написание документации в рабочий процесс типовой команды разработки, используя привычные инструменты
Как оказалось, достаточно просто. Разработка документации — такая же доброска, как и любое изменение кода, ведь лишь малый круг задач требует доработки технической документации в вашей базе знаний (хотя, такое тоже бывает, и мы планируем этим так же заниматься). Рабочий процесс будет выглядеть следующим образом:
Разработчик берется за задачу, изучает её и пишет документацию прямо в файлах проекта, оставляет комментарии по месту планируемых изменений. Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка. Именно описанный сценарий — отправная точка для проверки всего остального. Он позволяет ревьюеру проверить логическую цепочку.
Если есть замечания по решению, ревьюер возвращает доброску на доработку документации с комментариями. Разработчик дорабатывает документацию. Проверка повторяется.
Если с решением все хорошо, доброска возвращается с комментарием "делаем".
Как только получили одобрение по решению, начинаем писать код. Не раньше!
После реализации доброска снова уходит на ревью ответственному разработчику.
Мы просто используем привычный для любого разработчика merge-request, что позволяет внедрить Documentation First в любой команде, не сильно меняя привычные процессы.
Что даёт такое решение?
Ожидаемый эффект выглядит привлекательно:
повышаем осознанность доработок,
идентифицируем требования для реализации,
понижаем вовлеченность тестирования в реализацию,
сокращаем количество итераций до готового состояния,
улучшаем уровень документации кодовой базы, то есть снижаем операционные затраты.
А ещё мы упрощаем разработку автотестов, ведь в коде доброски уже есть вся необходимая информация. То же самое касается и доработки статьи в базе знаний: после реализации задачи разработчику достаточно взять комментарии из кода и с минимальными правками перенести их.
Можно предположить, что такой же эффект даст применение BDD-тестов. Но это не так! Тесты не дают возможность провести ревью решения. Они отражают только достижение конкретного результата, который может быть не полным и так же не учитывать часть сценариев.
Чтобы BDD стало полезным инструментом, все равно нужно провести анализ окружения, требований и ограничений и сформировать их как задачу для разработки теста — сначала описать и формализовать задачу (документировать).
Иными словами, нам не избежать разработки документации, если мы хотим решить проблему, описанную выше.
Проблемы внедрения Documentation First
Мотивация к переходу. Любой разработчик будет пытаться не делать так, как вы предлагаете. Он привык работать иначе и в принципе не любит писать документацию... а ещё ему кажется: чем скорее он начнет писать код, тем быстрее решит задачу. Эта проблема будет самой сложной в решении. Советую заранее готовиться спорить и искать аргументы — приводить реальные примеры проблем, которых можно было бы избежать через документацию.
Контроль выполнения. Люди будут пытаться найти причину, почему именно в их случае проще не делать так, как вы хотите. Вам нужно заранее продумать инструменты контроля того, что Documentation First применяется, как задумано. Сделать это нужно до того, как у вас в плане работ появятся первые задачи, которые будут придерживаться этой методологии. Исследуйте инструменты контроля версий, регулярно проверяйте доброски. Это трудно, но постепенно у команды наступит принятие, и выработается привычка.
Система доработки требований. Скорее всего, приведенного способа на основе добросок вам окажется мало. А еще у вас будут отличаться требования для backend и frontend. Для каких-то случаев нужно сделать исключение... вы должны быть открыты к предложениям, а также уточнять требования и дорабатывать вашу "методичку" по Documentation First для вашей команды. Именно тут стоит применить Аgile.
Эти три проблемы придется решить в любом случае, но, скорее всего, вы столкнетесь и со своими, индивидуальными. О них будет интересно почитать в комментариях к материалу — делиться опытом всегда полезно.
Если проявите упорство и не опустите руки, то первые результаты получите достаточно быстро.
Промежуточные итоги: наш опыт
Эту статью я в пишу в сентябре 2025 года. Мы начали внедрять методологию два месяца назад.
В первый месяц начал проверять её на себе и прошел все пять стадий принятия того, что свои задачи я должен также документировать, пусть и в виде промежуточных документов.
С августа мы начали внедрять метод Documentation First в одной из команд направления, а с сентября — распространять методологию по всем командам и параллельно разрабатывать инструкции, которые подойдут нам.
Первый результат: пока не понимаем необходимый объем документации, который нужно делать при таком подходе. На обсуждение этого ушло больше времени, чем на непосредственное написание, но мы справились и смогли определить требования к содержанию на сегодня.
При анализе добросок по задачам получилась следующая картина:
У нас нет ошибок и потерянных бизнес-процессов, а ревью кода для новых компонентов прошло с первого раза (мы нарисовали схему перед разработкой).
По имеющимся ошибкам, которые как раз связаны с оперативностью результата, правки вносятся быстро, а состояние задач по методу Documentation First стало понятнее.
Тестирование не стесняется посмотреть доброску и прочитать написанное и без долгих объяснений получает указания, что проверить.
При доработках backend-методология показывает себя даже лучше, чем на интерфейсе — меньше файлов надо "потрогать", более линейная логика доработок.
И "на закуску"
Могу сказать с полной уверенностью: Documentation First приводит к повышению гарантий качества и не исключает соблюдения ценностей семейства Agile. Документация — это потерянный артефакт в мире гибких методологий. Многие ошибочно ассоциируют работу Брукса с waterfall. Documentation First призван устранить недостатки гибких методологий\фреймворков, снизить риски за счет бюрократизации в нужных местах. Я поговорил с некоторыми командами компании и увидел, что они интуитивно начинали приходить к этому подходу.
Сейчас мы в начале пути внедрения Documentation First. Пока новый подход дается непросто, но потихоньку приносит свои плоды. Предстоит сделать еще очень много: разработать инструкции, начать использовать Documentation First для всех направлений, разработать блок-схемы и т.д. Но даже сейчас можно сказать: методология, которую разработали до всех вариаций Agile, и сегодня прекрасно справляется с проблемами.
Наш эксперимент продолжается. Посмотрим, какие результаты будут через полгода. Обязательно поделюсь итогами в новой статье в блоге Тензора.
Комментарии (42)
Zenitchik
06.10.2025 10:18Мне сразу видится узкое место в частых итерациях. "Дураку пол-работы не показывают" (с) народная мудрость. На практике, это выливается в необходимость дополнительной работы по приведению в презентабельный вид промежуточного состояния проекта.
trixt3r Автор
06.10.2025 10:18Да, подготовка итерации к демонстрации - в реальном мире при существании функционирующего продукта отнимает много ресурсов. Чтобы этого избежать или должна быть итерация, которая замыкает какой-то кейс (то есть будет понятна заказчику)...или заказчик должен смириться, что он видит что-то с точки зрения бизнеса не живое.
MisterKot
06.10.2025 10:18Вы написали отличную статью о том, как вы и ваша команда провалили внедрение Agile. И немудрено — сложно внедрить то, что не понимаешь. Рассмотрим примеры этого непонимания в цитатах.
Разработчики понимали свою конкретную задачу, но общего контекста не осознавали.
Это говорит об отсутствии инженерной культуры. В принципах Agile есть такой пункт:
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Нет контекста — нет условий и поддержки. И даже если это было до внедрения, это говорит о провале в управлении командой, который методология не исправит.Наша основная боль была в том, что мы постоянно всё переделывали. Разработчики понимали свою конкретную задачу, но общего контекста не осознавали. То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
Из принципов:
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
Agile очень сильно нацелен на коммуникацию, а у вас же это одна из проблем. При этом есть еще один принцип:Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.Так происходит потому, что все agile-методологии придерживаясь одних и тех же ценностей приводят к увеличению точек контроля (т.е. частой демонстрации промежуточного результата)
Ценностей придерживается команда. И если вы поняли ценности как "показывать демо", то вы не поняли Agile. В самом манифесте, кстати, ничего нет про частую демонстрацию. Из принципов:
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцевиРаботающий продукт — основной показатель прогресса. Демо является не "точкой контроля", как у вас написано, а инструментом для получения обратной связи. На демо можно понять, то ли вообще делали, какие дальше шаги и т.д. Это больше синхронизация команды и заказчика, а не лишь бы показать что-то ради галочки. Если что — никто не гонит сделать за две недели что-то рабочее. В гибких методологиях слово "гибкость" является ключевым, но вместо этого описаны какие-то рамки. из-за которых страдает процесс разработки.Ожидаемый эффект выглядит привлекательно:
повышаем осознанность доработок,
----------------
Иными словами, нам не избежать разработки документации, если мы хотим решить проблему, описанную выше.
Agile не против документации. Как и не против нормального планирования. Мотивированные профессионалы должны прекрасно понимать важность документации, проектирования, планирования. Из принципов:
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.Мы планируем итерацию, а не пытаемся решить всю задачу, следовательно, пренебрегаем анализом дополнительных требований к ней. Они исходят не от заказчика, который о них может не помнить или банально не знать, а от реализации. Именно глубиной анализа итерации мы жертвуем, применяя гибкие методы управления проектами.
В Agile ничего не сказано про пренебрежение и жертвование глубиной анализа. Это ваш неправильный вывод, которому вы следовали. Из принципов:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Более того, вы же прекрасно понимали, что жертвуете анализом, так что мешало применить принцип о способах улучшения стиля работы? По тому, что написано складывается ощущение, что вы сами придумали два стула: "либо Agile", "либо анализ"Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки. И это не противоречит ценностям Agile. В рамках методологий такой подход является нормой: показываем итерацию, получаем правки, исправляем, а потом снова показываем "полуфабрикат", который продолжает быть проблемой в живом продукте…
Забавно то, что это не имеет отношения к Agile. Это провал управления командой и планированием. Из принципов:
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Не надо показывать итерацию. На демо должен показываться готовый к выпуску продукт (или его часть, которая должна пройти DoD), а не задеплоенное наспех и без тестирования на демо-стенд нечто. И технически это не противоречит ценностям, да. Как не противоречит им и непонимание методологии. Просто таких вещей там быть не должно. Как должно быть — читаем для начала манифест, там очень простые вещи, которые написали инженеры. И в качестве единственной проблемой в живом продукте выступает только тот, кто пытается внедрять методологию без ее понимания, а этим пронизана вся статья.Сегодня такой подход называется Documentation First.
Вы изобрели этап нормального планирования. Конечно, лучше поздно, чем никогда, но всё это должно быть следствием принципа из Agile:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Выяснили детали — создали документацию, верифицировали через бизнес. Иначе как можно приступать к работе, если сами не понимаете, как должно работать в итоге.Документация — это потерянный артефакт в мире гибких методологий.
Что, простите? Да, есть ценность
Работающий продукт важнее исчерпывающей документации, но если вы ее истолковали как документация не нужна, то это снова не проблема Agile. Вот специально же написано в манифесте, чтобы не было кривых интерпретаций:То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Вот прям еще раз:не отрицая важности того, что справа, то есть "исчерпывающей документации". Но у вас это превращается впотерянный артефакт. На сайте манифеста это шесть строк, которые не противоречат друг другу, но каким-то немыслимым образом это читают как "мы документация не пишем, у нас Agile", загоняют проекты в яму, а затем винят методологию в собственной некомпетентности.Получается интересная картина. Чтобы работать по Agile, нужно его хоть немного понимать или быть к нему открытым. Но в большинство статей о неудачах с гибкими методологиями говорится не "мы облажались при попытке внедрить", а "Agile не работает". И вот это "облажались" есть в этой статье, но оно подается как "Agile плохой".
vmkazakoff
06.10.2025 10:18Дорогая редакция! Спасибо вам за рецепт. Авокадо мы заменили отварным картофелем, а креветки - поджаренным салом, но в целом ваш рецепт салата из авокадо с креветками нам очень понравился.
То есть автор сделал ровно то, что вообще говоря и должен был изначально. Сел, подумал немного над вопросом "а чо нам, собственно, мешает жить"...
А вообще, так как этому "новомодному" фреймворку уже четверть века, то все эти проблемы успели разжевать 100500 раз. А если у автора реально 60 человек, то тут вообще нужно что-то типа SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum) или Nexus, а может быть даже Lean. Хотя это все так или иначе "аджыле", но просто автор скорее всего не интересовался историей вопроса и не знает что было до этого. Когда департаменты, работающие над одной кнопкой сидели в разных зданиях и иногда в разных частях поясах...
trixt3r Автор
06.10.2025 10:18Это говорит об отсутствии инженерной культуры.
Если проект небольшой - да, все верно. Но проект может касаться очень большой системы, которая имеет "под капотом" большое количество не явных факторов. Для того, чтобы такие системы дешевле было дорабатывать - DF и нужен.
Нет контекста — нет условий и поддержки. И даже если это было до внедрения, это говорит о провале в управлении командой, который методология не исправит.
Контекст для менеджера/заказчика и контекст для разработчика - могут быть разными. В идеальном мире, задача уже содержит решение. В реальном мире - часть реакций большой системы подразумевается как следствие доработок и может быть не зафиксировано явно. DF решает эту проблему тем, что дает точку, в которой разработчик должен обсудить все требования и критерии качества.
Из принципов:
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.Agile очень сильно нацелен на коммуникацию, а у вас же это одна из проблем. При этом есть еще один принцип:Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.DF - это и есть один из способов общения, который обеспечивает коммуникацию и заставляет участников не просто обсудить задачу, а зафиксировать требования, решения и ограничения. Т.е. по-факту смотреть не только на вершину айсберга и сделать такой анализ проверяемым результатом.
Демо является не "точкой контроля", как у вас написано, а инструментом для получения обратной связи. На демо можно понять, то ли вообще делали, какие дальше шаги и т.д. Это больше синхронизация команды и заказчика, а не лишь бы показать что-то ради галочки.
Не соглашусь - для заказчика "демо" и есть точка контроля, гарантия того, что он получает нужный ему результат. Можно играть словами и называть корректировки "обратная связь", но сути это не меняет. И да, DF позволяет синхронизироваться намного раньше момента, когда команда уже "пошла не туда".
Agile не против документации. Как и не против нормального планирования. Мотивированные профессионалы должны прекрасно понимать важность документации, проектирования, планирования. Из принципов:
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.Красивая идея - чаще всего в жизни не работает. Как раз Брукс в "Мифический человекомесяц" это очень хорошо показал. И ошибка тут будет для начала понимании "самые лучшие" - для инженера и заказчика, скорее всего, они будут отличаться.
В Agile ничего не сказано про пренебрежение и жертвование глубиной анализа. Это ваш неправильный вывод, которому вы следовали.
А как вы определяете необходимую глубину анализа? Часто - проблемы того или иного решения в сложной системе оценить получается при достаточно подробном анализе и формировании документации по решению. Собственно вот мы и пришли к DF.
Из принципов:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Более того, вы же прекрасно понимали, что жертвуете анализом, так что мешало применить принцип о способах улучшения стиля работы? По тому, что написано складывается ощущение, что вы сами придумали два стула: "либо Agile", "либо анализ"А где вы в статье нашли либо\либо или увидели противоречие?
Собственно статья и говорит о том, что можно сохранять гибкий подход вводя "бюрократизацию" решения с DF, при этом не терять гибкости разработки. Т.к. ни один из гибких фреймворков не регламентирует точки документирования - для этого был приложен DF, который хорошо себя показал.
Не надо показывать итерацию
Каждая итерация в методологии Agile должна быть полезна для бизнеса — создавать ценность для заказчика, улучшать процессы и адаптироваться к изменениям. Все гибкие методологии фокусируются на итеративной разработке, постоянном взаимодействии с заказчиком и быстрой адаптации к изменениям.
Думаю тут вы спорить не будете - выше об этом говорили сами.
Убирая показы итераций из Agile или не привлекая к итерациям заказчика - выбрасывается один из основных инструментов, обеспечивающих гибкость. При этом не все итерации для заказчика могут быть полезными, с его точки зрения.
Применение DF в этом случае помогает сохранить итерационность и определить размер полезной итерации.
Вы изобрели этап нормального планирования. Конечно, лучше поздно, чем никогда, но всё это должно быть следствием принципа из Agile:
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Выяснили детали — создали документацию, верифицировали через бизнес. Иначе как можно приступать к работе, если сами не понимаете, как должно работать в итоге.Я ничего не изобретал :). В том, что вы привели есть две основные проблемы
ни один из фреймворков agile не определяет глубины требуемой документации и точки её появления. Более того, даже задача может быть корректна с точки зрения SMART, но не иметь описания всех реакций сложной системы (в то же время и документация, получаемая по такой задаче - может её не иметь, т.к. её ценность не выражена в виде требования),
тезис "работать вместе" не фиксирует результат и требования к нему.
Собственно, DF и дает вполне применимые инструменты, чтобы заполнить "белое пятно". Мы заполнили это так - в чем тут проблема?
Что, простите? Да, есть ценность
Работающий продукт важнее исчерпывающей документации, но если вы ее истолковали как документация не нужна, то это снова не проблема Agile.Для заказчика разработка технической документации чаще всего будет ниже работающей фичи. И в этом одна из основных проблем применения гибкой методологии. Собственно, в компании мне сейчас повезло - ценность этапа осознается бизнесом и даются ресурсы на использование DF. В "среднем по больнице" будет не так (в реальном мире).
Вот специально же написано в манифесте, чтобы не было кривых интерпретаций:
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Вот прям еще раз:не отрицая важности того, что справа, то есть "исчерпывающей документации". Но у вас это превращается впотерянный артефакт. На сайте манифеста это шесть строк, которые не противоречат друг другу, но каким-то немыслимым образом это читают как "мы документация не пишем, у нас Agile", загоняют проекты в яму, а затем винят методологию в собственной некомпетентности.Это красивая идея, которая разбивается о реальным мир. Для большинства компаний ценность документации будет минимальна по сравнению с ростом продаж от работающей фичи. А проблемы - можно поправить. Рынок динамичен, конкуренты не будут сидеть сложа руки - это аргументация бизнеса, вполне обоснованная.
DF придает ценности этапу разработки документации.
Получается интересная картина. Чтобы работать по Agile, нужно его хоть немного понимать или быть к нему открытым. Но в большинство статей о неудачах с гибкими методологиями говорится не "мы облажались при попытке внедрить", а "Agile не работает". И вот это "облажались" есть в этой статье, но оно подается как "Agile плохой".
Признание проблем методологии - позволила начать внедрение DF и я в этом не вижу проблемы. Собственно, статья и говорит о том, как обойти проблемы и закрыть белые пятна.
MisterKot
06.10.2025 10:18Весь ваш комментарий подчеркивает, что вы снова ставите во главу угла не коммуникации между людьми, а какой-то подход. Точно такая же ситуация была в самой статье. Вы последовательно подменяете принципы живой коммуникации формальными процессами. И возникает риторический вопрос — не постигнет ли DF такая же участь?
Но проект может касаться очень большой системы, которая имеет "под капотом" большое количество не явных факторов.
Вы не первая и не последняя компания, работающая с легаси. В мире накоплен огромный инженерный опыт решения именно таких проблем с помощью гибких подходов (LeSS, Lean, etc.). Фразы про "большую систему" или про "реальный" мир в 2025 выглядят не как реальные трудности, а как менеджерский провал, который разгребает команда.
Контекст для менеджера/заказчика и контекст для разработчика - могут быть разными. В идеальном мире, задача уже содержит решение.
И снова вы пишете, что у вас проблемы с коммуникацией, которые вы не решаете. Даже не так — вы считаете, что решили их через внедрение DF. Но под коммуникацией (я рассмотрю Agile) подразумевается общение между заказчиком, аналитиком, дизайнером, разработчиком, тестировщиком, менеджером. Если все эти люди вовлечены в процесс обсуждения полученной документации, то снимаю шляпу. Но что-то мне подсказывает, что это даже близко не так.
DF решает эту проблему тем, что дает точку, в которой разработчик должен обсудить все требования и критерии качества.
Переложили ответственность на разработчиков. И, кстати, здесь тоже вы пишите про проблемы с коммуникацией. Пока нет документации, нет понимания у каждого участника процесса, должно быть написано 0 строчек кода. И это не только не противоречит Agile, но и прекрасно ложится на описанные принципы.
DF - это и есть один из способов общения, который обеспечивает коммуникацию и заставляет участников не просто обсудить задачу, а зафиксировать требования, решения и ограничения. Т.е. по-факту смотреть не только на вершину айсберга и сделать такой анализ проверяемым результатом.
А это еще раз говорит и о проблемах с коммуникацией (и непониманием, что это концептуально такое) и непониманием Agile, хотя я специально привел принципы, в которых нет ничего сложного или противоречивого. Кратко: DF это не один из способ общения, не натягивайте сову на глобус.
Я раскрою страшную тайну. DF это просто нормальный процесс проектирования с артефактами в виде документации. И в целом сам подход можно описать как "семь раз отмерь, один отрежь". Ну или "сначала думаем, потом делаем". Это было задолго до прошлого века. Как и подходы, сформулированные в Agile манифесте, использовались задолго до его создания. Более того, любая небольшая команда (а не набор разношерстных специалистов, запертых в одном помещении) придет примерно к тем же выводам, которые есть в Agile, будучи с ним незнакомыми.
Не соглашусь - для заказчика "демо" и есть точка контроля, гарантия того, что он получает нужный ему результат. Можно играть словами и называть корректировки "обратная связь", но сути это не меняет. И да, DF позволяет синхронизироваться намного раньше момента, когда команда уже "пошла не туда".
Не соглашаться вы можете с чем угодно. Это ваше личное мнение и право. Однако, есть пропасть между обоснованным личным мнением и тотальным непониманием какой-то концепции. Вот здесь мы имеем второй случай, и, что примечательно, при всех цитатах вы продолжаете доказывать свою точку зрения, хотя могли бы разобраться в предмете дискуссии. Конкретно по этому абзацу — для вас демо это формальный акт приемки заказчиком. Для Agile это то, что я описал — момент синхронизации для всех участников процесса, на котором показываемый функционал не должен быть сюрпризом для заказчика, потому что коммуникация должна быть постоянной. Вы же этого так и не поняли. Демо это не пилить что-то срочно две недели, чтобы потом показать, это готовый результат (инкремент) итеративного процесса разработки с полным вовлечением заказчика. Игра слов это вот выше про "DF как один из способов общения", а процесс с демо является следствием из принципов Agile. Там прям написано: разработчики и представители бизнеса должны ежедневно работать вместе. Не можете этому следовать? Agile не для вас, не надо его насильно впихивать. "И да, DF позволяет синхронизироваться" — кхм, весь Agile про общение, но чтобы понять важность коммуникации, понадобился DF? И снова — тут тоже про проблему коммуникации.
Красивая идея - чаще всего в жизни не работает. Как раз Брукс в "Мифический человекомесяц" это очень хорошо показал.
Удобная позиция, но не сработает. Проблема в том, что для внедрения чего-либо, нужно сначала очень хорошо провести анализ. Но с Agile почему-то другая ситуация, его бегут внедрять, потому что другие же тоже бегут. Хотя с учетом постоянного упоминания Брукса складывается ощущение, что новые подходы внедряются по мере прочитанных книг. И прежде чем ссылаться в 10 раз на одного и того же автора, стоило бы ознакомиться с книгой "Чистый Agile" от Боба Мартина, чтобы закрыть свои пробелы и понять, что же на самом деле у вас пошло не так и почему виноват не Agile. Небольшой спойлер — там прям написано, что Agile для малых и средних команд.
Для ясности — я не топлю за какую-то конкретную методологию. Но я категорически против бездумного внедрения чего-либо, что здесь и было описано, а затем обвинения инструмента в своей некомпетентности.
Будем называть вещи своими именами. DF это не откровение, а базовый этап проектирования (все мы помним "семь раз отмерь, один отрежь"), который существовал задолго до всех нас. Вы пришли к нему, потому что провалили внедрение Agile.
У вас на старте большой проект с плохой документацией. Вместо того, чтобы начать с разбора техдолга и налаживания человеческих коммуникаций, вы попытались внедрить "новомодную" методологию, вырвав из нее ритуалы, но проигнорировав ценности. Когда это предсказуемо провалилось, вы обвинили методологию. И своим ответом вы лишь подтвердили это.
trixt3r Автор
06.10.2025 10:18Весь ваш комментарий подчеркивает, что вы снова ставите во главу угла не коммуникации между людьми, а какой-то подход.
Коммуникацию должен обеспечить какой-то инструмент. Мы работаем не в идеальном мире с идеальными людьми, которые будут взаимодействовать просто по-умолчанию. Мало того, точки взаимодействия не всем и не всегда очевидны.
Точно такая же ситуация была в самой статье. Вы последовательно подменяете принципы живой коммуникации формальными процессами. И возникает риторический вопрос — не постигнет ли DF такая же участь?
Если любой инструмент не имеет конкретно обозначенного результата, с измеримыми критериями - его не будет.
Формализация результата и обозначения точек, где он ожидается - нормальная часть любого рабочего процесса, который нацелен на решение конкретных проблем\достижение конкретных целей.
Взаимодействие без целей, без измеримого результата - не даст оптимального решения.
Простой пример: мы с Вами можем сесть и начать обсуждать какой подход для реализации некоей потребности клиента лучше использовать. Ввиду возможной разницы в представлении "лучше" мы будем делать это очень долго, возможно даже не договоримся вообще.Потому, что наша задача "обсудить и когда-нибудь придти к решению".
У конкурента к моменту, когда мы договоримся - уже и решение в релиз пойдет, возможно.
Поэтому нормально, формализовать процесс коммуникации и обозначить результат в виде документа и конкретного срока, к которому надо получить описание предлагаемого решения.
Вы не первая и не последняя компания, работающая с легаси. В мире накоплен огромный инженерный опыт решения именно таких проблем с помощью гибких подходов (LeSS, Lean, etc.). Фразы про "большую систему" или про "реальный" мир в 2025 выглядят не как реальные трудности, а как менеджерский провал, который разгребает команда.
Обозначенные подходы решают проблемы коммуникации, но не решают проблему полноты информации. И не решат. Хотя бы потому, что носитель знаний в условно завтра уже может не работать над продуктом и вы окажитесь с ситуацией, что система реагирует вот так - а почему и зачем именно так было сделано, никто не вспомнит.
Из примера "огромного инженерного опыта" в OpenSource могу привести один драйвер для MondoDB, который поддерживал какое-то время для Racket. Там был нюанс с тем, как разворачивался макрос. Зачем именно так - смог пояснить только изначальный автор (далеко не самый плохой разработчик, участник OpenSource, разработчик многих используемых и сегодня в продакшене пакетов). Потратил я на решение проблемы ощутимое время (дебаг), хотя было достаточно написать 1 строчку документации кода.
К чему это я - в идеальном мире нет проблем связанности кода, все за счет коммуникаций корректно оценивают правильные решения. И автор конкретного решения всегда в доступе, а все нюансы бизнес-процессов, которые реализовали "когда-то" все хорошо осознают.
К сожалению, в действительности - для обеспечения такого состояния должна быть какая-то материализация информации.
И снова вы пишете, что у вас проблемы с коммуникацией, которые вы не решаете. Даже не так — вы считаете, что решили их через внедрение DF. Но под коммуникацией (я рассмотрю Agile) подразумевается общение между заказчиком, аналитиком, дизайнером, разработчиком, тестировщиком, менеджером. Если все эти люди вовлечены в процесс обсуждения полученной документации, то снимаю шляпу. Но что-то мне подсказывает, что это даже близко не так.
Это проблема не коммуникации как таковой, а видения и восприятия.
Оптимальное решение а точки зрения заказчика - может очень сильно отличаться от оптимального решения с точки зрения разработчика. И они оба будут правы.
Общение, без фиксации его результат приведет только к тому, что кто-то будет понимать то о чем договорились по-своему, а не так как требуется в итоге. И это нормально, так как у людей как минимум разный контекст.
Переложили ответственность на разработчиков. И, кстати, здесь тоже вы пишите про проблемы с коммуникацией. Пока нет документации, нет понимания у каждого участника процесса, должно быть написано 0 строчек кода. И это не только не противоречит Agile, но и прекрасно ложится на описанные принципы.
Нет противоречит. Но, как сказано в манифесте от 2001 года работающий функционал лучше полной\хорошей технической документации. Бизнес готов жертвовать здесь и сейчас качеством документации ради скорости релиза фичи. И это нормально с его позиции.
И нет тут никакого перекладывание ответственности. Разработчик должен понимать, что он должен сделать. Без этого он не сможет сформировать ответ на вопрос "как решить эту задачу". То есть DF является точкой входя для коммуникации, так как появляется проверяемый результат для неё, а не формальное "всё понятно, надо просто сделать".
А это еще раз говорит и о проблемах с коммуникацией (и непониманием, что это концептуально такое) и непониманием Agile, хотя я специально привел принципы, в которых нет ничего сложного или противоречивого. Кратко: DF это не один из способ общения, не натягивайте сову на глобус.
Общение без измеримого результата будет просто хаотичным обсуждением чего-то, что возможно когда-то примет форму и не гарантированно эффективного решения.
Документация - одна из форм коммуникации, которая позволяет сформулировать осознанные вопросы, а не просто "а как это использовать".
Я раскрою страшную тайну. DF это просто нормальный процесс проектирования с артефактами в виде документации. И в целом сам подход можно описать как "семь раз отмерь, один отрежь". Ну или "сначала думаем, потом делаем". Это было задолго до прошлого века. Как и подходы, сформулированные в Agile манифесте, использовались задолго до его создания. Более того, любая небольшая команда (а не набор разношерстных специалистов, запертых в одном помещении) придет примерно к тем же выводам, которые есть в Agile, будучи с ним незнакомыми.
Замечу, вы сейчас подгоняете уже Agile под практику DF, так как сложно отрицать очевидный плюс от осознанного проектирования с фиксацией результат в виде документации.
Правда, это противоречит одному из принципов Agile - работающий код важнее полной\хорошей документации.
И да, к каким-то ценностям Agile придет в итоге любая команда. Они, в большинстве своем, логичны и обоснованы.
Но, Agile имеет конкретную цель - с минимальными издержками для бизнеса получить в наименьшие сроки желаемый результат. Документация часто воспринимается как те издержки, которые должны пойти "под нож" и то, что можно отложить на "потом".
Замечу, последнее - это реалии общения с заказчиками до работы в компании (я уже писал тут документация воспринимается как понятная ценность). Плюс есть некоторый опыт работы людей, с которыми я поддерживаю контакты.
Мне нравятся ценности Agile, но в выборке о которой я знаю - я ещё не встречал примеров использования, которые или не приводили бы в итоге к обозначенным мной проблемам, или не начинали отходить от принципов Agile для нивелирования проблем. Возможно я ошибаюсь и у вас есть иные, реальные примеры. Было бы (без шуток) интересно узнать конкретные примеры\опыт (не евангелистическое "просто надо понимать и правильно использовать").
Не соглашаться вы можете с чем угодно. Это ваше личное мнение и право. Однако, есть пропасть между обоснованным личным мнением и тотальным непониманием какой-то концепции. Вот здесь мы имеем второй случай, и, что примечательно, при всех цитатах вы продолжаете доказывать свою точку зрения, хотя могли бы разобраться в предмете дискуссии. Конкретно по этому абзацу — для вас демо это формальный акт приемки заказчиком. Для Agile это то, что я описал — момент синхронизации для всех участников процесса, на котором показываемый функционал не должен быть сюрпризом для заказчика, потому что коммуникация должна быть постоянной. Вы же этого так и не поняли. Демо это не пилить что-то срочно две недели, чтобы потом показать, это готовый результат (инкремент) итеративного процесса разработки с полным вовлечением заказчика. Игра слов это вот выше про "DF как один из способов общения", а процесс с демо является следствием из принципов Agile. Там прям написано: разработчики и представители бизнеса должны ежедневно работать вместе. Не можете этому следовать? Agile не для вас, не надо его насильно впихивать. "И да, DF позволяет синхронизироваться" — кхм, весь Agile про общение, но чтобы понять важность коммуникации, понадобился DF? И снова — тут тоже про проблему коммуникации.
Извините, но Вы пытаетесь все свести к одной единственной проблеме и инструменты. Так не работает.
Вот Вы сами же и привели пример, почему DF обеспечивает коммуникацию. Бизнес и разработка должны работать вместе, а у работы должен быть проверяемый результат. Но принимать участие в процессе разработки 8 часов, закрыв на свои задачи глаза - не может большая часть заказчиков.
Если я сегодня с Вами обсуждаю задачи - то результатом обсуждения должна быть формализация того, о чем мы с Вами договорились.
Дальше - этот результат как-то должен быть достигнут и тут мы уже говорим о том, что должна пойти некая проработка решения, которую я буду делать с условным разработчиком или сам. И тут тоже появляется формализованный, проверяемый результат. Который, вероятно - будет иметь некие ограничения. Как следствие - у меня получается снова точка для обсуждения уже с бизнесом, "что мы можем" и "сколько это будет стоить", а что не можем вообще. И так далее..
Коммуникация без формализации в виде какого-то результата (документа) приведет к слишком большим затратам заказчика. Ведь нет некоего источника знаний о том, что надо сделать. Все решается в обсуждении, пусть и с фиксацией в виде тикетов. А что делать, когда тикет был закрыт пять лет назад, разработчик ушел, а заказчик уже и не помнит?
Давайте разберем жизненный пример, компании где я когда-то работал и где как раз использовался Agile. Необходимо было сделать небольшие доработки по корзине в интернет-магазине. Так как работающий функционал важнее документации - не был описан небольшой нюанс в скриптах (использовался gulp) и при корректной с точки зрения внешней документации конфигурации модуль мог не корректно импортироваться в части случаев. Так получилось, что человек, который реализовал скрипты сборки SPA попал на очень длительный срок в больницу, без возможности связи (а знал только он об этой особенности). Заказчик принимал участие во всем процессе доработки, тут все как положено. Итог - 2 месяца часть клиентов не могли купить товар, прямые убытки. Проблема решилась бы, будь документация...
Про "демо", простите - опять же, вы немного лукавите. Забываю о неудобной в данном случае ценности, что любая итерация должна быть полезна для бизнеса. А это не всегда так с точки зрения заказчика. Давайте простой пример, вот у меня есть итерация по подготовки структуры БД для некоей задачи. Я написал скрипты миграции, завел все положенные индексы и т.п. С точки з рения разработки - с делал очень полезную работу, подготовил БД к тому, чтобы туда кто-то мог положить данные. С точки зрения заказчика - такая итерация не несет ценности, у него есть только перспектива, что тут появятся нужные ему данные. Собственно, такие итерации являются одними из слабых мест Agile. Да, Вы, конечно сейчас парируете "ну так разработчик и заказчик должны общаться и в общении заказчик осознает ценность". В целом да, такое возможно. А ещё лучше, если у заказчика появится документ, где будет зафиксирована полезность (в виде понятных для него, измеримых показателей) и сделает для него такую техническую итерацию понятной и проверяемой.
Собственно, у нас разница в восприятии Agile - для вас гибкая разработка есть совместное "творчество", для меня это процесс производства с повышенными гарантиями нужного результата. На мой взгляд первое возможно, но до тех пор пока продукт не стал большим и ошибки в его логике не приводят к издержкам клиентов. И DF как раз позволяет повысить полезность коммуникации.
Удобная позиция, но не сработает. Проблема в том, что для внедрения чего-либо, нужно сначала очень хорошо провести анализ. Но с Agile почему-то другая ситуация, его бегут внедрять, потому что другие же тоже бегут. Хотя с учетом постоянного упоминания Брукса складывается ощущение, что новые подходы внедряются по мере прочитанных книг. И прежде чем ссылаться в 10 раз на одного и того же автора, стоило бы ознакомиться с книгой "Чистый Agile" от Боба Мартина, чтобы закрыть свои пробелы и понять, что же на самом деле у вас пошло не так и почему виноват не Agile. Небольшой спойлер — там прям написано, что Agile для малых и средних команд.
Вы наверняка не поверите. но я с ней знаком. Как и с другими основными трудами по производным. Проблема в том, что все семейство гибких методологий имеет примерно одни и те же недостатки, которые можно решить куда проще. Вместо часовых споров о решении - формализация функции полезности архитектором доработки, описание решение и ревью с предметными обсуждениями. Вместо постоянного вовлечения заказчика по одним и тем же вопросам - материализация ответов в виде документа.
Еще раз, я не отрицаю важности коммуникации (этот тезис нравится Вам), я говорю то, что результатом любой коммуникации должен стать некий проверяемый результат. И этот результат - техническая документация.
Для ясности — я не топлю за какую-то конкретную методологию. Но я категорически против бездумного внедрения чего-либо, что здесь и было описано, а затем обвинения инструмента в своей некомпетентности.
В статье этого и нет. Есть описание проблем, которые никак не решаются в гибких методологиях (это отдается на откуп команде), есть конкретное решение примененное конкретной командой - которое вам не нравится, так как коммуникацию понимается Вами иначе.
Будем называть вещи своими именами. DF это не откровение, а базовый этап проектирования (все мы помним "семь раз отмерь, один отрежь"), который существовал задолго до всех нас. Вы пришли к нему, потому что провалили внедрение Agile.
А где-то сказано что это откровение? Даже в статье обозначено, что документировать стоит до того как писать. И недостаток Agile как раз в том, что он хорошо решает только часть проблем, а часть - оставляет "на усмотрение команды".
Что было принято командой - и описывается в материале.
У вас на старте большой проект с плохой документацией. Вместо того, чтобы начать с разбора техдолга и налаживания человеческих коммуникаций, вы попытались внедрить "новомодную" методологию, вырвав из нее ритуалы, но проигнорировав ценности. Когда это предсказуемо провалилось, вы обвинили методологию. И своим ответом вы лишь подтвердили это.
По Agile большей ценностью является не разбор техдолга, а релиз функционала. Коммуникация в том то и дело, что налажена - но она не решает проблемы техдолга, не решает проблем отсутствия полного набора нужной информации. И не может - хотя бы потому, что все привлеченные могут и не знать о чем-то (как пример с SPA интернет-магазина), нет конкретных инструментов.
DF позволяет закрыть эти проблемы, которые гибкие методологии оставляют как раз на усмотрение команды.
MisterKot
06.10.2025 10:18Вижу, что сообщение вы отредактировали. Хотя ничего нового я не увидел.
А как вы определяете необходимую глубину анализа? Часто - проблемы того или иного решения в сложной системе оценить получается при достаточно подробном анализе и формировании документации по решению. Собственно вот мы и пришли к DF.
DoR, груминг. Это гибче, чем DF. И ваш DF это по сути DoR, который вы зачем-то противопоставили Agile.
Для заказчика разработка технической документации чаще всего будет ниже работающей фичи.
И снова проблема в коммуникации. Я надеюсь, вы понимаете, что она слишком часто повторяется что в статье, что в ответе, что в дополненном ответе? Что это не случайность, а систематическая проблема.
В том, что вы привели есть две основные проблемы
Эм. Там ноль проблем, если понять, что вы используете гибкую методологию, а не набор жестких регламентов. Вы сами определяете, какая глубина анализа нужна под конкретно ваш продукт. И это очевидно из всей философии Agile.
тезис "работать вместе" не фиксирует результат и требования к нему.
Так если вам и этот принцип не подходит, зачем тогда тащили себе Agile? Вам нужны директивы, но Agile не про это. Но вот конкретно в этом предложении вы не понимаете, что "работа вместе" это процесс, в ходе которого создаются артефакты: пользовательские истории, критерии приемки, документация, схемы и т.д. Agile не говорит "ни в коем случае ничего не фиксируйте!". Он говорит о фиксации результатов совместной работы, хотя и в явном виде это не указано. Ваше непонимание этого базового различие между процессом и результатом показательно.
Собственно, DF и дает вполне применимые инструменты, чтобы заполнить "белое пятно". Мы заполнили это так - в чем тут проблема?
Проблема не в том, что вы сделали, а как. Белое пятно не в Agile, а в вашей его реализации. Agile это фреймворк, он дает свободу действий и инструменты для корректирования и выстраивания процессов. Но и отвечаете за эти вещи вы сами. С DF вы просто начали делать ту часть работы, которую Agile изначально перекладывал на вас. То, что вам для этого потребовались явные указания, а не здравая логика и корректная интерпретация манифеста — не вина Agile, а проблемы ваших процессов.
Рынок динамичен, конкуренты не будут сидеть сложа руки - это аргументация бизнеса, вполне обоснованная...А проблемы - можно поправить.
//и из начала самой статьи:
Наша основная боль была в том, что мы постоянно всё переделывали... на самом деле под капотом надо было сделать еще 100500 правок, чтобы не задеть рядом стоящий функционал или полностью замкнуть кейс.
Думаю, тут комментарии излишни.
Признание проблем методологии - позволила начать внедрение DF и я в этом не вижу проблемы. Собственно, статья и говорит о том, как обойти проблемы и закрыть белые пятна.
В методологии нет проблем. Она как была в вашей конкретной реализации, так и осталась. Все ответы кричат о тотальном непонимании принципов, ценностей, ритуалов — это видно и по вашим остальным комментариям здесь. Agile требует зрелости, дисциплины, коммуникаций. Если этого нет, и никто в этом не заинтересован, то внедрить гибкую методологию не получится. Что у вас и произошло. Вы буквально повторили все классические ошибки, начиная с отказа от документации и заканчивая слепым следованием ритуалов без понимания их смысла. И на фоне этого возвращение к директивной модели с DF для вас выглядело как решением.
trixt3r Автор
06.10.2025 10:18DoR, груминг. Это гибче, чем DF. И ваш DF это по сути DoR, который вы зачем-то противопоставили Agile.
DF - это в большей степени есть форма выражения результат, проверяемого. DoR ему не противоречит, как и Agile. Тогда чем Вам не нравится DF?
И снова проблема в коммуникации. Я надеюсь, вы понимаете, что она слишком часто повторяется что в статье, что в ответе, что в дополненном ответе? Что это не случайность, а систематическая проблема.
Тут нет проблемы коммуникации - это адекватная разница целей.
Цель любого заказчика извлечение выгоды из продукта с минимальными затратами. Цель любого разработчика - реализовать продукт так, чтобы в будущем операционные затраты на поддержку и развития не вышли за рамки допустимого для заказчика, а не только выпуск. А это влечет за собой рост тех самых "минимальных затрат".
Эм. Там ноль проблем, если понять, что вы используете гибкую методологию, а не набор жестких регламентов. Вы сами определяете, какая глубина анализа нужна под конкретно ваш продукт. И это очевидно из всей философии Agile.
Так одна из проблем в материале и обозначена, что многие в гибкий методологиях команда определяет самостоятельно. И при желании любого заказчика минимизировать затраты - будут жертвовать тем, что не видится важным. Для того, чтобы доказать заказчику необходимость глубины анализа и наличия документации - нужны аргументы, которые как раз и приводятся в статье. Это - увеличение операционных затрат.
Думаю, тут комментарии излишни.
Вы подменяете в удобном свете для себя цитаты :-). Они про разное, если вчитаетесь. Первая - о том, что большая часть заказчиков закроет глаза на проблемы, которых можно было бы избежать при наличии нормальной проработке, для них будет важнее срок.
Вторая, о том, что из-за того, что мы не достаточно глубоко провели анализ и поняли это - у нас были вот эти, типовые проблемы. С которыми большая часть заказчиков будет мириться.
Кстати, интересный (неудобный) пример проблем гибких методологий - в какой-то момент, одна знакомая компания закрыла большой продукт. У заказчика поменялось видение того, как должна решаться проблема. Было потрачено полтора года работы команды из 5 человек на подсистему советов в интернет-магазинах на основе ИИ. Поменялось видение - поменялось решение. Коммуникация была на хорошем уровне, ничто не предвещало. Просто заказчик в какой-то момент осознал, что его проблема решается проще. Замечу - все ценности и артефакты соблюдались, проблема выявилась на последних этапах внедрения. Когда стало ясно, что видение было ошибочным - споткнулись на банальностях, которые можно было выявить до этих затрат. Просто формализовав результат и все критерии качества.
В методологии нет проблем. Она как была в вашей конкретной реализации, так и осталась. Все ответы кричат о тотальном непонимании принципов, ценностей, ритуалов — это видно и по вашим остальным комментариям здесь. Agile требует зрелости, дисциплины, коммуникаций. Если этого нет, и никто в этом не заинтересован, то внедрить гибкую методологию не получится. Что у вас и произошло. Вы буквально повторили все классические ошибки, начиная с отказа от документации и заканчивая слепым следованием ритуалов без понимания их смысла. И на фоне этого возвращение к директивной модели с DF для вас выглядело как решением.
Смотрите, Вы начинаете судить в удобных фактов для Вашей гипотезы, игнорирую большую часть того, что было сказано.
Первое - где Вы нашли, что документация игнорировалась? Где Вы нашли нарушение дисциплины, проблемы коммуникации? Как раз за счет последних двух - проекты в итоге и успешно уходили в релиз. Но это не отменяет, что проблема избыточных затрат была - и она никак не решается в гибких методологиях. Нет инструментов. Есть только идея, что если люди будут соблюдать ценности и активно взаимодействовать, то получится эффективно.
С точки зрения получения нужного для заказчика результатов - у гибких методологий нет равных, так как они дают промежуточные точки контроля (а это они, каким бы красивым эпитетом они не назывались бы). И их цель не минимизация рисков (считайте, издержек - они принимаются как данность), а получение максимальной ценности за вложенную стоимость.
Материал же о том, как уменьшить риски, достаточно дешевым способом.
smart_cookie_05
06.10.2025 10:18Спасибо, а то я подумала то же самое, но так круто - подробно и с выкладки из agile - не смогла бы оформить мысль, даже близко.
А вы откуда так хорошо владеете темой?
MisterKot
06.10.2025 10:18Предположу, что этот вопрос мне.
Не могу сказать, что прям хорошо владею темой — все же здесь обсуждались самые поверхностные вещи. Для лучшего понимания в своё время прочитал "Чистый Agile" от Боба Мартина, "Пользовательские Истории" от Майка Кона, "Agile-тестирование" от Лайзы Криспин и Джанет Грегори. Также знакомился с какой-то версией PMBOK, и, насколько знаю, последние редакции смещались в сторону гибких методологий. Еще было много статей, что-то у Кента Бека читал, статьи Мартина Фаулера, но точно уже не вспомню. В целом можно просто открыть список авторов Agile и искать их статьи/книги.
Много опыта дала работа по Agile, где он хорошо внедрен и там, где внедрен очень плохо — на контрасте сразу видно, что не так и как должно было бы быть.
stalker_by
06.10.2025 10:18Я очень конечно извиняюсь…но кое-кого возврата у вас все новомодное?
Манифесту Agile скоро 25, а в России он до сих пор считается новым и модным!
trixt3r Автор
06.10.2025 10:18Я Вам более того скажу, для многих производственных компаний LEAN будет чем-то инновационным. Проблема в инертности - для многих управленцев до сих пор понятие "оптимальный" и "эффективный" являются тождественными, а ведь давно есть много работ о том, что это не так. А это - базовые понятие, с методологиями всё куда хуже.
Бум гибких методологий в разработке в РФ начался примерно с бумом IT-компаний, а это по меркам рынка не так давно. Из-за этого многие пока "не приняли" того, что любая методика имеет свои слабые стороны, а "белые пятна" надо чем-то заполнять, кроме красивых идей.
Собственно, в описанном кейсе я и попытался раскрыть, как мы заполняли имеющиеся "белые пятна" и решали проблемы.
stalker_by
06.10.2025 10:18С производственными компаниями понятно, сколько нибудь внятные процессы есть только там где большие деньги, желательно западные, в остально то что осталось с советских времен.
Но вы то говорите про ИТ! Я впрыгнул в этот поезд на волне бума…в 2009 году.
В комментарии выше уже разобрали, у вас явное непонимание процессов в своей команде, плюс понимание Agile методологии как «процессов ради процессов», этакий карго-культ Agile.
Из личного опыта - то что у вас называется Documentation First, насколько я понимаю, это нормальная работа хорошего бизнес-аналитика, который при таком размере команды просто необходим.
Не критики ради, но вы взяли первый попавшийся велосипед и он вам подошел, это не значит что остальные плохие.
trixt3r Автор
06.10.2025 10:18С производственными компаниями понятно, сколько нибудь внятные процессы есть только там где большие деньги, желательно западные, в остально то что осталось с советских времен.
Знаете, я общаюсь со многими людьми, кто работает в производственных компаниях. И "с советских времен" как раз не самое плохое, что может быть - там было достаточно эффективное производство организовано, где-то даже передовое для своего времени.
Чаще всего проблема начинается там, где пытаются вносить оптимизации процесса, а не повышать эффективность.
В комментарии выше уже разобрали, у вас явное непонимание процессов в своей команде, плюс понимание Agile методологии как «процессов ради процессов», этакий карго-культ Agile.
Простите, но выше в комментарии нет какой-то внятной критики.
Так же можно вспомнить, что одно из нововведений "манифеста Agile" (2001 год) было то, что в agile-подходе приоритет отдается создание работающего продукта, а не исчерпывающей документации.
И такой приоритет отрабатывает хорошо для небольшого продукта или для нового - но с увеличением масштаба продукта, его сложности Agile без бюрократизации процесса в виде документации начинает приводить к повышению операционных затрат (а они являются одной из основных проблем, которые мешают повысить эффективность производства).
Из личного опыта - то что у вас называется Documentation First, насколько я понимаю, это нормальная работа хорошего бизнес-аналитика, который при таком размере команды просто необходим.
Не каждый бизнес осознает необходимость и важность документации, тем более техническая (а это уже за областью ответственность бизнес-аналитика).
Для бизнеса всегда будет важнее быть быстрее конкурента, а ресурсы на "поддержку" найти можно. Но это ведет к накоплению проблем.
Не критики ради, но вы взяли первый попавшийся велосипед и он вам подошел, это не значит что остальные плохие.
Странно считать подход Брукса "первым попавшимся велосипедом", но да ладно.
stalker_by
06.10.2025 10:18Про советские подходы без всякой критики, они действительно были передовыми для своего времени, не говоря уже о книге Брукса. Но серьезно обсуждать это в 2025 году - странно.
Не каждый бизнес осознает необходимость и важность документации
Звучит как "мы не смогли донести до бизнеса важность документации".
Documentation First хорошо когда документации нет вообще, собвственно во времена Брукса это было мягко говоря поголовно, да еще помноженное на используемые ЯП и подходы в разработке и управлении. Но в современных реалиях...загляните на N-лет вперед, такой жестки каркас скорее всего выродится в именно что "сначала документация потом продукт", в особенности если команда останется лично без Вас.
trixt3r Автор
06.10.2025 10:18Про советские подходы без всякой критики, они действительно были передовыми для своего времени, не говоря уже о книге Брукса. Но серьезно обсуждать это в 2025 году - странно.
Для очень многих команд - это на самом деле будет не очевидно. К сожалению, из моей практики, часто самые очевидные вещи как раз остаются без внимания и как следствие - без понимания.
Простой пример - если есть проверенное временем решение, то не без веской необходимости (бизнес-основание) делать свой "велосипед". Логично? Да. Известно всем? Вроде как тоже да, ведь очевидно. Но, на примере одной знакомой конторы. Люди не стали брать RabbitMQ для организации очередей (показалось сложно, избыточно), а написали свою реализацию на Java. Которая через двое суток от утечек "подвешивала" юнит. Быстрым решением - было просто перегружать сервер, когда никто не подключен (был коридор времени). Так он уже лет 8 перегружается...
Звучит как "мы не смогли донести до бизнеса важность документации".
Не просто документации. А в том виде, которая требуется исходя из DF. В компании, где я работаю - это не проблема, тут понимают её ценность. А вот по опыту предыдущих мест работы и моих друзей\знакомых (кто работает в отрасли) доказать бизнесу, что стоит Н времени потратить на документацию, вместо того, чтобы то же самое время потратить на реализацию и уже начать править - часто не осуществимо. DF тут удобен тем, что дает в этом случае понятный большинству заказчиков инструмент - анализ издержке без документации. Это позволяет говорить на более понятном для заказчиков язык.
Пример из моей практики в проектной компании, до текущего места работы - я встретил всего одного заказчика за 5 лет работы, который согласился на разработку документации и мало того, с готовностью принимал участие в её формировании, полностью с ней ознакомился и задавал нормальные вопросы. 99% клиентов компании, где ранее работал - просили пропускать этот этап и включать критерии сдачи в договор. Им казалось, что разработка документации - выброшенные деньги на ветер.
Documentation First хорошо когда документации нет вообще, собвственно во времена Брукса это было мягко говоря поголовно, да еще помноженное на используемые ЯП и подходы в разработке и управлении. Но в современных реалиях...загляните на N-лет вперед, такой жестки каркас скорее всего выродится в именно что "сначала документация потом продукт", в особенности если команда останется лично без Вас.
Сейчас - очень часто, документация не стало лучше. У нас появилось много средств для формирования автодокументации, проблема стала другой - теперь надо, чтобы вот то, что пишется - было осознанным, правда несло смысл. И тут - важным является соответствие документации критериям.
Да, согласен - риск вырождения подхода без контроля, его доведения до абсурда есть и будет всегда. Но - нет ничего, что нельзя было бы довести до него. Вспомните, когда популяризировалось ООП, начали появляться простейшие программы с переусложненным кодом, "зато в ООП".
Любая методология не должна возводиться в абсолют. Всегда должны быть какие-то адекватные границы применения. Собственно, сейчас мы для себя выводим их, формулируем правила и так далее... думаю, когда внедрение закончится можно будет описать этот опыт. Как миниму - будет интересный, полезный материал (может я плохо искал, но таких рекомендаций я не находил в общем доступе).
Kartun83
06.10.2025 10:18Ничего не понял. Что в заголовке считается "технологией прошлого века"?
Ещё больше не понимаю ваши процессы. Если разработчику задача приходит в виде бизнес-фичи, и он сам с большим трудом понимает и продукт и бизнес, может вам LLM нужен?
А в команде на 60 человек solution/system architect не предполагается, который бы бил палкой за сомнительные решения?
Очень рад, что вы приходите к осознанию, что стоит подумать перед тем как вносить изменения в код, и возможно даже верифицировать предлагаемые изменения.
Но поскольку вы предпочитаете жарить яичницу с помощью микроскопа, то думаю вас ждёт ещё много удивительных открытий.
trixt3r Автор
06.10.2025 10:18Ничего не понял. Что в заголовке считается "технологией прошлого века"?
Documentation First был формально описан Бруксом в книге "Мифический человекомесяц" еще в 1975 году.
Ещё больше не понимаю ваши процессы. Если разработчику задача приходит в виде бизнес-фичи, и он сам с большим трудом понимает и продукт и бизнес, может вам LLM нужен?
Проблема не в понимании конечной фичи как раз (не только в ней, правильнее сказать).
У вас есть формализованный и ожидаемый бизнес-процесс и есть очень большая система, в которой кроме явных следствий изменений есть ещё какое-то количество связей, которые "не на поверхности", а есть из-за связанности бизнес-процессов, специфики реализации и так далее. То есть, при достаточно большой системе нет носителя знаний, которые понимает все тонкости и предметные области на 100%.
Documentation First делает этап формирования документации, которая это все фиксирует - отдельным этапом и ценность, позволяет спокойно спроектировать все и согласовать как раз все, что не было "на поверхности".
А в команде на 60 человек solution/system architect не предполагается, который бы бил палкой за сомнительные решения?
Чтобы он бил палкой - как раз мы и начали применять Documentation First, только через разработку документации сначала - это можно делать не в момент реализации (когда ресурсы уже потрачены и это может вызвать дополнительные затраты на "переделать как надо"), а на этапе проработки задачи.
Очень рад, что вы приходите к осознанию, что стоит подумать перед тем как вносить изменения в код, и возможно даже верифицировать предлагаемые изменения.
Да, собственно верификация и контроль изменений до их непосредственной реализации - и есть цель применения DF.
Но поскольку вы предпочитаете жарить яичницу с помощью микроскопа, то думаю вас ждёт ещё много удивительных открытий.
Тут не совсем Вас понял.
kenbekov
06.10.2025 10:18В Agile методиках разработка начинает с написания User story. Это документ, который описывает как должна работать фича с точки зрения заказчика. И этот документ появляется еще до того как разработчик приступил к работе. На него могут ориентироваться и разарабы и тестеры. Выходит, что Agile это еще более Document First, чем то что описано в статье?
...Разработчики понимали свою конкретную задачу, но общего контекста не осознавали.
а дальше
Разработчик берется за задачу, изучает её и пишет документацию прямо в файлах проекта, оставляет комментарии по месту планируемых изменений.
Т.е. получается при написании кода разработчик не мог изучить задачу, чтобы написать правильно, а при написании документации он уже смог это сделать. В чем разница?
Мы не просто делаем фичу, нам необходимо аккуратно добавить решение новой проблемы в кодовую базу, которая уже решает задачи и имеет свои правила, ограничения и как-то влияет на данные "сбоку".
Если пренебрегать этим, то тестирование заведет 100500 ошибок ...
Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки...
Добавление нового функционала вызывает "поток" ошибок? Изменили тут, а сломалось везде? Это высокая связанность кода, плохая декомпозиция, признак слабой архитектуры. При чем тут вообще Agile? Просто, кто то в проекте должен отвечать за архитектуру и следить, чтобы вся команда была в курсе, проводя техтоки, участвуя в планнинге и парном программировании.
Субъективно, статья больше про то, как "мы переложили бизнес-анализ на разработчиков, идёт непросто, но мы не сдаёмся"
trixt3r Автор
06.10.2025 10:18В Agile методиках разработка начинает с написания User story. Это документ, который описывает как должна работать фича с точки зрения заказчика.
Это описание бизнес-процесса, фактически. И он да, есть до того как к задаче приступили. Но в ней описываются явные результаты, но нет того, что появится как результат изменений, которые происходят в системе.
Выходит, что Agile это еще более Document First, чем то что описано в статье?
Нет, потому, что он не требует формирования технической документации. Важно наличие описанного бизнес-процесса при формировании User Story (Вы много видели их с типовыми выборками и индексами в которые надо "бить" запросами?).
Для Agile работающий проект важнее хорошей документации.
MisterKot
06.10.2025 10:18Для Agile работающий проект важнее хорошей документации.
Вы намеренно игнорируете цитаты из манифеста, которые я вам указал?
Работающий продукт важнее
исчерпывающейдокументацииА у вас почему-то документация стала хорошей. Вы просто не поняли, что написано и сделали свою интерпретацию, которая расходится с Agile. И если что, Agile не говорит "делайте плохо". Он наоборот призывает делать хорошо, потому что переделывать потом будет дороже.
trixt3r Автор
06.10.2025 10:18Работающий продукт важнее
исчерпывающейдокументацииМногие вещи могут быть сделано дешевле и проще при наличии исчерпывающий (с точки зрения Agile) документации.
А у вас почему-то документация стала хорошей. Вы просто не поняли, что написано и сделали свою интерпретацию, которая расходится с Agile. И если что, Agile не говорит "делайте плохо". Он наоборот призывает делать хорошо, потому что переделывать потом будет дороже.
Я упростил термин до более простого императива. Agile не призывает делать хорошо (него нет для этого измеримых показателей), он призывает делать как нужно сейчас заказчику. Оставляя "за бортом" многие вопросы, которые могут негативно "сыграть" позже.
MisterKot
06.10.2025 10:18Я упростил термин до более простого императива.
Вы не упростили. Вы не поняли ни тогда, ни сейчас. И подменили понятие "исчерпывающий" на "хороший". И вместо того, чтобы это признать, вы пытаетесь зачем-то оправдаться, делая только хуже.
Agile не призывает делать хорошо (него нет для этого измеримых показателей), он призывает делать как нужно сейчас заказчику.
Эти слова тоже не имеют отношения к Agile. Потому что именно Agile призывает непрерывно работать вместе с заказчиком и делать именно хорошо, потому что переделывать будет намного дороже. И еще раз процитирую принцип:
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Еще скажите, что здесь явно не указано "делать хорошо", значит так делать не надо.Уже в который раз написанное вами противоречит Agile. Это невероятно показательно.
kenbekov
06.10.2025 10:18Ого! Я, кажется, только что понял, что вы называете "технической документацией". Т.е. разработчик сначала описывает словами, как должен работать код, а потом пишет этот код? Это разве не двойная работа, нет?
trixt3r Автор
06.10.2025 10:18Все верно.
Объемные решения слишком дорого переделывать, если ошибка была допущена не в самом алгоритме, а в выборе похода.
То есть, описывается общий подход, важные моменты (которые учитываются). И вот это проверяется. То есть не предлагается писать псевдокодом, а потом код - предлагается дать понятное на естественном языке описание подхода, работы решения. И проверить это - до того, как человек код напишет.
trixt3r Автор
06.10.2025 10:18Чуть дополню Ваши изменения (комментария).
Т.е. получается при написании кода разработчик не мог изучить задачу, чтобы написать правильно, а при написании документации он уже смог это сделать. В чем разница?
Изучение задачи - может быть разной по глубине. Написание технической документации дает возможность разработчику описать как он будет достигать результата и почему именно так.
Т.е. отличие в глубине проработки.
Добавление нового функционала вызывает "поток" ошибок? Изменили тут, а сломалось везде?
Поток может сформироваться по нескольким причинам:
В большом продукте мест использования Х может быть большим. Следовательно, конкретный разработчик в момент написания кода (если он не проработает этот вопрос отдельно) может что-то важное.
Есть логические объекты в любой большой системе. И изменение их данных в "одной части" может вызывать реакции в другой. Причем, реакции для менеджера проекта могут быть и не запланированными (выходят за пределы его области ответственности). Абстрактный пример: у вас есть логический объект мячик, большая система при появлении красного мячика (атрибут "цвет") показывает пользователю оповещение - это бизнес правило. Команды, которые реализуют мячики могут не участь, что в системе есть реакции именно на красные мячики - данные реакции могли реализоваться другой командой, которая могла этот сценарий даже не зафиксировать у себя.
Проблемы (1) и (2) нивелируются использованием DF. Ревьювер может проверить решение (случай 1), а продукт начинает накапливать полную техническую документацию (2).
То есть, использую DF мы получаем решение сразу 2 проблем.
Это высокая связанность кода, плохая декомпозиция, признак слабой архитектуры.
Первое, давайте признаем честно - в реальном мире без связанного кода написать программу не возможно.
Самый минимальный код уже является "связанным", так как состоит из инструкций, которые должны быть логически соединены для достижения цели. Чем сложнее бизнес-процесс (а следовательно, его реализация) - тем больше будет точек со связанным кодом. Для её понижения применяются различные подходы\архитектуры, но они не решают полностью эту проблему. В каком-то виде она все равно остается в ПО, которое сложнее "глупого" CRUD к таблице.
Стоит учитывать, что не всегда применение тех или иных архитектур может быть обосновано с точки зрения бизнеса (его критерии оптимальности отличаются от критериев разработки) - цена понижения связанности кода может быть для решение конкретной бизнес-задачи слишком высокой, поэтому - да, в любой большой системе (которая просуществовала какое-то время) появляется связанный код и это неизбежное зло.
Таким образом, для сложных систем - документация является необходимой для решения проблемы влияния участков кода друг на друга при изменениях.
Не верите? Могу как в пример сложного продукта с достаточно связанным кодом привести ядро Linux. Многие архитектурные решения принимались не потому, что не хватало компетенций - это было оптимальным решением для решения задачи.
При чем тут вообще Agile? Просто, кто то в проекте должен отвечать за архитектуру и следить, чтобы вся команда была в курсе, проводя техтоки, участвуя в планнинге и парном программировании.
Для того, чтобы следить за решениями, дорабатывать их и так далее - надо, чтобы они были формализованы как-то. В виде блок-схем, описаний - документации. Собственно, DF ставит наличие такого материала как одну из ценности продукта не только для разработчика (хотя и для него - это далеко не всегда очевидно, посмотрите на стартапы) - но и для бизнеса, дает ответ на вопрос "зачем".
Субъективно, статья больше про то, как "мы переложили бизнес-анализ на разработчиков, идёт непросто, но мы не сдаёмся"
Сегодня, на рынке нет четкого определения задачи бизнес-аналитика. Поэтому, может быть где-то формирование технической документации и является его обязанностью. Тут не буду спорить.
Но, не его обязанность знать все нюансы реализации. В нормальной ситуации он должен придти к команде разработки, объяснить задачу и дать все критерии, а команда разработки - ответить какой путь будет оптимальным для достижения цели\результата.В идеале, если у бизнес-аналитика при этом будет некая база знаний и большую часть нужной ему информации он может получить с помощью некоей базы знаний. Её роль и выполняет техническая документация.
amazingname
06.10.2025 10:18Аджайл обчыно наивно и и неявно требует команду, в которой каждый настолько хорош и настолько хорошо понимает продукт и его цели, что может создать этот продукт с нуля в одиночку, но только за большее время.
Т.е. в иделале нужна слишком дорогая команда мотивированных суперстар девелоперов или очень простой продукт, который любой мог бы сделать с нуля.
Если делелоперы не являются супер-старами или продукт не такой простой, разработка погружается в хаос.
Напротив, можно распределить компетенции и четко ставить задачи. Тогда сотрудники как винтики, могут знать мало и заниматься своим делом в комфорте. Но тогда уже тонем в микроменеджменте, потому что на том кто может ставит/осознает/котролирует задачи падает слишком много всего.
Если микроменеджмент не поспевает, или опять тонем в хаосе или буксуем.
Предлагается, как я понимаю, заставить в команде с распределением обязанностей и микроменеджментом ввести определенную активность, которая заставит сотрудников немного выходить из зоны прямых компетенций.
Или наоборот - в команде из недо-суперстаров ввести элементы микроменеджмента, чтобы частично взять их под контроль.
Если хочется вернуться к классическим практикам, то это просто. Назначаем "руководителя" направления, пусть он нарисует проект, какие доработки планируются на год, пусть защитит этот проект перед руководством, пусть в конце года отчитается что сделано, пусть объяснит руководству если все пошло по другому пути. И наконец, пусть делает с подчиненными ему людьми все что считает нужным для достижения целей, хоть аджайл, хоть расписывает задачи по плану последовательно, хоть сам выбирает всю архитектуру и все проверяет, хоть назначит на это кого-то в команде. Лишь бы преуспел.trixt3r Автор
06.10.2025 10:18Аджайл обчыно наивно и и неявно требует команду, в которой каждый настолько хорош и настолько хорошо понимает продукт и его цели, что может создать этот продукт с нуля в одиночку, но только за большее время.
Снимаю шляпу, приятно видеть человека, который понимает назначение методологии. Вангую большое количество не согласных.
Требования - просто мода. Почему-то сложилось впечатление, что гибкие методологии нацелены на создание комфортных условиях для разработчика, а не повышение гарантий для бизнеса...
Т.е. в иделале нужна слишком дорогая команда мотивированных суперстар девелоперов или очень простой продукт, который любой мог бы сделать с нуля.Если делелоперы не являются супер-старами или продукт не такой простой, разработка погружается в хаос.
Все верно. А еще увеличение количество привлеченных специалистов (как бы не дробили их на команды) все равно ведут к росту операционных затрат.
Напротив, можно распределить компетенции и четко ставить задачи. Тогда сотрудники как винтики, могут знать мало и заниматься своим делом в комфорте. Но тогда уже тонем в микроменеджменте, потому что на том кто может ставит/осознает/котролирует задачи падает слишком много всего.Если микроменеджмент не поспевает, или опять тонем в хаосе или буксуем.
Все верно
Предлагается, как я понимаю, заставить в команде с распределением обязанностей и микроменеджментом ввести определенную активность, которая заставит сотрудников немного выходить из зоны прямых компетенций.Или наоборот - в команде из недо-суперстаров ввести элементы микроменеджмента, чтобы частично взять их под контроль.
Не заставит выходить из зоны прямых компетенций, а требует формирования проверяемого результата, который можно получить при приложении инженерного подхода - то есть поиск эффективного решения.
Если хочется вернуться к классическим практикам, то это просто. Назначаем "руководителя" направления, пусть он нарисует проект, какие доработки планируются на год, пусть защитит этот проект перед руководством, пусть в конце года отчитается что сделано, пусть объяснит руководству если все пошло по другому пути. И наконец, пусть делает с подчиненными ему людьми все что считает нужным для достижения целей, хоть аджайл, хоть расписывает задачи по плану последовательно, хоть сам выбирает всю архитектуру и все проверяет, хоть назначит на это кого-то в команде. Лишь бы преуспел.
DF собственно не противоречит ни гибким методологиям, ни классическим практикам. Он позволяет как раз ответственным специалистам проверить корректность планируемых изменений и дать рекомендации (если это необходимо). Собственно, это призвано понижать операционные затраты по-итогу.
amazingname
06.10.2025 10:18Типа облегчить задачу тому кто занимается этим самым микроменеджментом, чтобы он имел дело не с непонятным кодом или неправильно работающим продуктом, а с документом как это будет работать. И сделать это административно на уровне правил, чтобы это не выглядело как недоверие между коллегами....
Вообще любой опытный разработчик договаривается на берегу прежде чем начинать делать. Или другая крайность - подход "победителей не судят". Когда сначала все криво, но если в конце то что надо, то и хорошо.
trixt3r Автор
06.10.2025 10:18Типа облегчить задачу тому кто занимается этим самым микроменеджментом, чтобы он имел дело не с непонятным кодом или неправильно работающим продуктом, а с документом как это будет работать. И сделать это административно на уровне правил, чтобы это не выглядело как недоверие между коллегами....
Кода может быть в итоге решения много, его сложно проверить. Особенно при проверке самого подхода, архитектуры. То есть - проверка на уровне проектирования.
С другой стороны, разработка документации стимулирует еще раз сесть и подумать о решении. Это закономерно приводит к осознанию объемов, проблем и реальных сроков.
Вообще любой опытный разработчик договаривается на берегу прежде чем начинать делать. Или другая крайность - подход "победителей не судят". Когда сначала все криво, но если в конце то что надо, то и хорошо.
Договаривается - да. Не факт, что это решение наиболее эффективное. "На берегу" есть вероятность чего-то не учесть. И вот это состояние между "сначала что-то не то" и "в конце то, что надо" может занимать достаточно много ресурсов. Смотря от того на сколько "что-то не то" и из-за чего.
Ozzie
06.10.2025 10:18Из изначально ложного предположения вытекает все, что угодно:
написание ПО больше напоминает сборку изделия на конвейере,
Нет, нет, и еще раз нет. Конвеер - это производственная линия, разделенная на участки, на каждом из которых специально обученные сотрудники при помощи узко специализированного инструмента выполняют крайне ограниченное число операций (в идеале - одну). При этом эти сотрудники не заменены на роботов либо по финансовым (робот дороже) соображениям, либо по совокупности причин (изделия отличаются - утром сверлим собираем седаны, после обеда - универсалы), когда проще поставить человека, чем изобретать адаптируемого робота.
Конвеер заточен в первую очередь на повторяемость.
Разработка ПО на это вообще не похожа. Разработка ПО - это именно проектно-изыскная работа. Когда инженеры проектируют изделие, которое нужно собрать, а то и придумывают конвеер для его сборки.
Попытки превратить разработку ПО в конвеер не прекращаются уже много лет. Без особого успеха.
Но это неважно. Важно другое:
То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
У вас проблемы лежат вовсе не в плоскости методологии разработки. А в коммуникации внутри компании. И, как показывает практика, в таких случаях нужно не на манифест кивать, а перечитывать Крылова.
Про "отсутствие документации" в скрам выше уже написали. И да, я лично был свидтелем "внедрения" "аджайл", где все внедрение свелось к тому, что "документацию писать не надо".
Разработчик берется за задачу, изучает её и пишет документацию прямо в файлах проекта, оставляет комментарии по месту планируемых изменений. Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка. Именно описанный сценарий — отправная точка для проверки всего остального. Он позволяет ревьюеру проверить логическую цепочку.
Если есть замечания по решению, ревьюер возвращает доброску на доработку документации с комментариями. Разработчик дорабатывает документацию. Проверка повторяется.
Сначала между первым и вторым пунктом проходит 15 минут.
Через неделю - полтора дня.
Еще через неделю ревьювер вообще перестает отвечать.
Эту статью я в пишу в сентябре 2025 года. Мы начали внедрять методологию два месяца назад.
Я был свидетелем внедрения доведенного до идеала подхода "Documentation first". Через два года "разработки" было очень много качественной, хорошо структурированной, рецензированной и подписанной документации. И было дано решение на самом верхнем уровне "а вот теперь пишем код". Через месяц написания кода весь этот сверкающий небоскреб из продуманной документации оказался карточным домиком и просто развалился.
Потому что разработка ПО, в отличие от многих других отраслей, отличается тем, что вы всегда имеете дело с неизвестным количеством неизвестных факторов. Которое невозможно предусмотреть заранее и которые выясняются только в процессе собственно разработки (и раннего тестирования). И нет, вы не сможете заранее "предусмотреть" и "выяснить" все незивестные путем "Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка."
Короче, ждем статью в сентябре 2026 года.
trixt3r Автор
06.10.2025 10:18Нет, нет, и еще раз нет. Конвеер - это производственная линия, разделенная на участки, на каждом из которых специально обученные сотрудники при помощи узко специализированного инструмента выполняют крайне ограниченное число операций (в идеале - одну). При этом эти сотрудники не заменены на роботов либо по финансовым (робот дороже) соображениям, либо по совокупности причин (изделия отличаются - утром сверлим собираем седаны, после обеда - универсалы), когда проще поставить человека, чем изобретать адаптируемого робота.
Конвеер заточен в первую очередь на повторяемость.
Разработка ПО на это вообще не похожа. Разработка ПО - это именно проектно-изыскная работа. Когда инженеры проектируют изделие, которое нужно собрать, а то и придумывают конвеер для его сборки.
Попытки превратить разработку ПО в конвеер не прекращаются уже много лет. Без особого успеха.
Производственная линия вполне может поддерживать вариативность, это не делает процесс уникальным от изделия к изделию. Творчество в разработке да, есть - но не каждая задача или проект подразумевают это. Да и большая часть задач при использовании инженерного подхода оказывается вполне себе конвеерной работой, если они правильно декомпозированы.
Я был свидетелем внедрения доведенного до идеала подхода "Documentation first". Через два года "разработки" было очень много качественной, хорошо структурированной, рецензированной и подписанной документации. И было дано решение на самом верхнем уровне "а вот теперь пишем код". Через месяц написания кода весь этот сверкающий небоскреб из продуманной документации оказался карточным домиком и просто развалился.
Любая методология может быть доведена до абсурда. Даже самая лучшая. Вы, к сожалению, были, возможно, свидетелем именно такого.
Потому что разработка ПО, в отличие от многих других отраслей, отличается тем, что вы всегда имеете дело с неизвестным количеством неизвестных факторов. Которое невозможно предусмотреть заранее и которые выясняются только в процессе собственно разработки (и раннего тестирования). И нет, вы не сможете заранее "предусмотреть" и "выяснить" все незивестные путем "Описывает алгоритмы, входящие/выходящие контракты и имеющиеся ограничения, проверки и обязательно сценарий, который решает доработка."
Вот как раз сократить количество неизвестных факторов по-хорошему DF и должен сократить. Да, что-то останется, идеального результата не будет никогда, при любой методологии. Но - применение DF и совмещение его с "гибкими" методологиями вполне дает хороший результат\эффект.
Короче, ждем статью в сентябре 2026 года.
Будет :-). Самому хочется узнать итоги этого. В начале пути всегда есть фактор идеализации, хотя бы из-за возникающих положительных результатов. Может быть - мы столкнемся с проблемами, которые покажут - применять надо очень ограниченно (или не применять вообще). Но, в любом случае - какие-то итоги будут, которые я опишу и опубликую.
Zenitchik
06.10.2025 10:18Суть в том, что разработка ПО - это разработка, а не производство. И аналоги надо искать не на заводе, а в КБ.
trixt3r Автор
06.10.2025 10:18Суть в том, что разработка ПО - это разработка, а не производство. И аналоги надо искать не на заводе, а в КБ.
Даже разработка может включать в себя вполне какой-то процент вполне себе рутинных задач. По моему опыту (быть может у меня такая выборка задач), большая часть работ кажутся "творческими" и это заканчивается при нормальном описании того, что надо сделать и как. А дальше идет вполне себе производственное выполнение типовых операций. Да, с вариативностью в последовательности - но это скорее именно вариативность, нежели разработка чего-то принципиально нового.
Zenitchik
06.10.2025 10:18Да. Но инженерная рутина - она не такая, как производственная рутина. Она другая.
После того, как составлено "нормальное описание того, что надо сделать и как" начинается, пользуясь этой аналогией, опытное производство. И по результатам ОКР описание-то может и поплыть. И его придётся править.
Ozzie
06.10.2025 10:18Производственная линия вполне может поддерживать вариативность, это не делает процесс уникальным от изделия к изделию.
Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Любая методология может быть доведена до абсурда. Даже самая лучшая. Вы, к сожалению, были, возможно, свидетелем именно такого.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные Waterfall тоже видел. С DF (кстати, почивший в начале 2000-х RUP есть этот самый DF, только вид сбоку) личная статистика другая - видел только провалы разной степени оглушительности.
Кстати, исходя из Вашей статьи (и картинки, которая должны была быть смешной), с внедрением agile у вас что-то конкретно не заладилось.
Вот как раз сократить количество неизвестных факторов по-хорошему DF и должен сократить.
И как он может это сократить, если эти факторы проявляются только в процессе разработки?
Кстати, есть еще одна вещь, которую тут пока еще не обсуждали: скорее всего, самые лучшие ваши разработчики (те самые, которые вытягивали предыдущие проекты, спасая горящие дедлайны) находятся уже в процессе выбора нового оффера.
trixt3r Автор
06.10.2025 10:18Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Видимо не понятно выразился - я не могу Вам даже сходу сказать ни одной задачи, которая была бы в разработке чего-то нового. Да, при разработке решения конкретной задачи пишется код, который решает какие-то задачи. Но сам по себе подход (если он выбран верно) вряд ли будет включать в себя что-то принципиально новое или исключительно. Продолжая метафору - у нас есть куча строительных блоков, из которых мы собираем нужное изделие. Если мы говорим о некоей большой системе - в ней скорее всего частично реализуемый процесс даже уже в какой-то части решен. То есть для современного разработчика творчество сместилось с написания кода (конкретной реализации - чаще всего типовой процесс) на применение инженерного подхода (поиск эффективной реализации в текущих условиях). Когда-то оба этих компонента разработки были творческими.
Посмотрите, простой пример. Для разработки небольшого сервиса раньше Вам требовалось решить множество задач - от реализации веб-сервера (да, я помню ещё такие проекты) и управления подключениями к БД, до бизнес-логики конкретного функционала. Сейчас большая часть этой работы рутинизирована (берем какой-нибудь Django\DRF+ORM+Redis). Происходит концентрация на той самой бизнес-логике, которая очень часто тоже является вполне типовой.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные Waterfall тоже видел. С DF (кстати, почивший в начале 2000-х RUP есть этот самый DF, только вид сбоку) личная статистика другая - видел только провалы разной степени оглушительности.
Кстати, исходя из Вашей статьи (и картинки, которая должны была быть смешной), с внедрением agile у вас что-то конкретно не заладилось.
Аналогично, даже успешно внедрял SCRUM в ряде компаний. Где-то как team-lead, где-то как приходящий консультант. Но - не всегда гибкие методологии подходят.
Нет инструмента, который себя всегда показывает хорошо. Как нет и инструмента, который однозначно себя покажет всегда плохо. К применению чего-либо надо подходить всегда с осознанием ограничений, требований и имеющегося окружения.
Почему именно у нас полноценно не получилось внедрить... быть может соберусь с духом и напишу об ограничениях, которые явно мешают внедрению гибких методологий. Сейчас они уже понятны, но в начале - было не очевидно.
Кстати, есть еще одна вещь, которую тут пока еще не обсуждали: скорее всего, самые лучшие ваши разработчики (те самые, которые вытягивали предыдущие проекты, спасая горящие дедлайны) находятся уже в процессе выбора нового оффера.
Ошибаетесь. Удалось за счет того, что в компании организована хорошая коммуникация с заказчиком, который готов был слышать о сдвигах сроков и давать корректировки по результатам - коллектив стабильно сохраняется уже очень долгое время, текучки у нас нет.
Поиск методов оптимизации мы начали для того, чтобы сделать для самих себя течение проектов более предсказуемыми (это упрощает запуск новых проектов), сократить ресурсы на поддержку (очевидно, что хорошая документация - способна этому помочь) и делать больше полезного в те же временные коридоры (плюс\минус Road Map развития известен, хочется - двигаться по нему быстрее).
Ozzie
06.10.2025 10:18Видимо не понятно выразился - я не могу Вам даже сходу сказать ни одной задачи, которая была бы в разработке чего-то нового
Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
Продолжая метафору - у нас есть куча строительных блоков, из которых мы собираем нужное изделие
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Удалось за счет того, что в компании организована хорошая коммуникация с заказчиком, который готов был слышать о сдвигах сроков и давать корректировки
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
коллектив стабильно сохраняется уже очень долгое время, текучки у нас нет.
Вы же сами сказали, что внедрение началось только летом. Сейчас все только отошли от отпусков и начала учебного года. Просто нужно немного подождать.
trixt3r Автор
06.10.2025 10:18Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
Все же сравнивать научные открытия и разработку софта - не корректно. Сильно разная доля работы с неопределенностью.
Хотя, наука вполне себе тоже поддается "шаблонизации процесса", если мы говорим о доработках уже существующих технологий. Хоть и в куда гораздо меньше степени, чем разработка.
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Вы затронули тему, которую я по работе не плохо помню (когда-то работал на внедрении учетных систем в строительных компаниях и у консалтеров). Проектная документация отличается, так как Вы будете её составлять под конкретные условия (тот же грунт), с учетом вариативности. Но творческого подхода тут не будет - это вполне себе конвеерная работа для отдела проектирования. Сборка документов из уже заранее известны блоков, по уже когда-то заготовленной информации и формулам расчета.
По крайней мере у застройщиков где я работал - были даже шаблоны документов и заготовки под регионы, где работали. Да, какая-то часть делалась полностью с нуля (заказчик захотел "уникальный" дизайн), а хороший % составлялся за счет пересчета кучи блоков. Но, отдел проектирования в этих компаниях был именно "заводом по производству проектной документации". Что-то "из ряда вон" требовалось очень редко, чаще всего даже не бралось в работу (плохо прогнозируемая прибыль).
Но это, возможно, не репрезентативная выборка.
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
Во-первых, я нигде не говорил про серебряную пулю. Этот вывод был сделан Вами. Как и почему - это часть Вашего восприятия материала.
Во-вторых, в материале рассказывается об анализе проектов, которые уже сделаны\сданы. Сейчас DF применяется на новых объемах работ, т.е. чтобы не допустить того, что было ранее. Пока - успешно.
Dinonoob
Все возвращается на круги своя.
Не подскажите , какого размера у вас команда ?
Моё убеждение - если в команде более 3 человек то без документирования ни как не обойтись.Но главное не скатиться в противоположную сторону и не забюрократизироватбь все процессы до их полного окостенения.
trixt3r Автор
У меня 60+ человек, разбитые на несколько команд, поэтому "задачи по DF" начали показывать результаты положительные относительно быстро.
Да, Вы абсолютно правы - важно найти баланс между бюрократизацией процесса и гибкостью. По-ощущениям, именно в этом месте agile-подходы и должны пприменяться\роявлять сильные стороны. Но, для каждой компании и команды, скорее всего, пропорции бюрократизации\гибкости надо выводить опытным путём (многое зависит от самих людей, предметной области, стека, ландшафта и т.п.)