Сорванные дедлайны 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, и сегодня прекрасно справляется с проблемами.
Наш эксперимент продолжается. Посмотрим, какие результаты будут через полгода. Обязательно поделюсь итогами в новой статье в блоге Тензора.
Комментарии (72)
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 для вас выглядело как решением.
Смотрите, Вы начинаете судить в удобных фактов для Вашей гипотезы, игнорирую большую часть того, что было сказано.
Первое - где Вы нашли, что документация игнорировалась? Где Вы нашли нарушение дисциплины, проблемы коммуникации? Как раз за счет последних двух - проекты в итоге и успешно уходили в релиз. Но это не отменяет, что проблема избыточных затрат была - и она никак не решается в гибких методологиях. Нет инструментов. Есть только идея, что если люди будут соблюдать ценности и активно взаимодействовать, то получится эффективно.
С точки зрения получения нужного для заказчика результатов - у гибких методологий нет равных, так как они дают промежуточные точки контроля (а это они, каким бы красивым эпитетом они не назывались бы). И их цель не минимизация рисков (считайте, издержек - они принимаются как данность), а получение максимальной ценности за вложенную стоимость.
Материал же о том, как уменьшить риски, достаточно дешевым способом.
MisterKot
06.10.2025 10:18Отвечу на оба комментария здесь. Ваша позиция предельно ясна, но она основывается на ряде фундаментальных заблуждений, которые вы последовательно повторяете.
Коммуникацию должен обеспечить какой-то инструмент. Мы работаем не в идеальном мире с идеальными людьми...
Инструменты коммуникации в Agile — дейли, демо, груминг, ретро и прочие ритуалы, если команда считает их необходимыми. Также он призывает к постоянному взаимодействию с заказчиками. Если в рамках этих инструментов команда не может прийти к общему пониманию и зафиксировать результат, то это не проблема инструмента, а неумение им пользоваться.
Ссылаться снова на "неидеальный мир" выглядит как попытка снять с себя ответственность за выстраивание процесса.
Если любой инструмент не имеет конкретно обозначенного результата, с измеримыми критериями - его не будет.
Это фундаментальное непонимание инструментов, процессов, результатов и что из них когда работает.
Потому, что наша задача "обсудить и когда-нибудь придти к решению".
Нет, это ваша задача. И это ваша же проблема, что у вас такой подход. Вы не владеете инструментами коммуникации и не понимаете, какие артефакты должны быть на выходе. В чем, собственно, и признаетесь, хотя не понимаете этого.
Обозначенные подходы решают проблемы коммуникации, но не решают проблему полноты информации. И не решат. Хотя бы потому, что носитель знаний в условно завтра уже может не работать...
Вы снова описываете проблему, который зрелый Agile решает по определению.
Это проблема не коммуникации как таковой, а видения и восприятия.
...
Общение, без фиксации его результат приведет только к тому, что кто-то будет понимать то о чем договорились по-своему, а не так как требуется в итоге. И это нормально, так как у людей как минимум разный контекст.
И снова вы не понимаете, как пользоваться коммуникацией. Для вас это, видимо, общение без фиксации. А в Agile это работает совсем не так. В реальном мире, кстати, тоже. Для совсем ленивых уже нейронки составляют саммари беседы. Если вы не можете ограничить скоуп проблем на митингах и зафиксировать договоренности и результаты, то при чем тут Agile? Я сейчас описываю какие-то банальные и очевидные вещи, которые делались еще лет 10 назад минимум и каждый участник процесса понимал важность этого. При этом это было вне зависимости от методологии, потому что это здравый смысл, но у вас в сообщении он вырезан.
Нет противоречит. Но, как сказано в манифесте от 2001 года работающий функционал лучше полной\хорошей технической документации.
В манифесте написано:
Работающий продукт важнееисчерпывающейдокументации. Не "полной", не "хорошей", а "исчерпывающей" — это против бюрократии и документа ради документа, а не против необходимой документации. И не "лучше", а "важнее" — это о приоритетах, а не о замене. И эта ценность не является разрешение на создание технического долга и отказа от необходимости документировать.Также в Agile нет ничего про скорость. Ни в ценностях, ни в принципах. Agile не говорит, что ПО будет разрабатываться быстрее, он не дает таких гарантий и обязательств. Более того, по гибким методологиям релиз полного продукта скорее всего будет позже, чем по каскадной модели. Но за счет ранних поставок и гибкости выпущенная часть функционала может помочь бизнесу закрывать свои цели, а не ждать полного релиза.
Бизнес готов жертвовать здесь и сейчас качеством документации ради скорости релиза фичи.
А это просто непонимание, что делать хорошо сразу будет намного дешевле, чем переделывать потом.
Замечу, вы сейчас подгоняете уже Agile под практику DF, так как сложно отрицать очевидный плюс от осознанного проектирования с фиксацией результат в виде документации.
Правда, это противоречит одному из принципов Agile - работающий код важнее полной\хорошей документации.
Это прекрасно. Вы, видимо, серьезно считаете, что DF настолько уникален, что никто не додумался сначала проработать документацию, а потом писать код? Я расстрою, но в реальном мире в зрелых командах, работающих по Agile (и не только), так делают с самого начала и никто не говорит про DF. Это просто здравый смысл, чтобы самим потом было легче работать — не заказчику с кодом работать, не ему его тестировать.
В моем сообщении нет "подгонки", есть лишь правильное прочтение манифеста. Вы читаете его как разрешение на отказ от документации. А моя трактовка выше. Но, что показательно, вы упорно раз за разом неверно понимаете эту ценность.
И пропишу явно уже сотый раз — написание документации не противоречит Agile.
Мне нравятся ценности Agile
Ага, особенно про документацию. Видите ли, все ценности и принципы работают вместе. Если вы от них отходите, что гибкие методологии позволяют, это уже будет какая-то отдельная интерпретация.
Извините, но Вы пытаетесь все свести к одной единственной проблеме и инструменты. Так не работает.
В данном случае из всего написанного вами четко прослеживается проблема коммуникаций. Про это написал не только я. Может пора уже задуматься?
Вот Вы сами же и привели пример, почему DF обеспечивает коммуникацию. Бизнес и разработка должны работать вместе, а у работы должен быть проверяемый результат. Но принимать участие в процессе разработки 8 часов, закрыв на свои задачи глаза - не может большая часть заказчиков.
Я вам пишу про одно, а вы интерпретируете как вам удобно. О чем это снова говорит? О проблемах с коммуникацией. И как иллюстрация непонимания — вы пишите про какие-то 8 часов, считая, видимо, что всё это время должно быть общение с заказчиком. И снова вопрос возникает — как с такими знаниями можно было пытаться что-то внедрить? Вы же ни одной ценности и принципа нормально донести не сможете. Сейчас вот вы нашли DF. Через год что-то еще. Но первопричины так и остались.
Коммуникация без формализации в виде какого-то результата (документа) приведет к слишком большим затратам заказчика. Ведь нет некоего источника знаний о том, что надо сделать.
И вот пример чудовищного непонимания.
Так получилось, что человек, который реализовал скрипты сборки SPA попал на очень длительный срок в больницу... Проблема решилась бы, будь документация...
И вот тоже упорное непонимания важности документации. Из раза в раз вы считаете, что можно без нее, как и в описанной истории. Но нет, нельзя без нее. И команда, которая попала в ту ситуацию, если бы работала по Agile с полным его пониманием, в ней бы не оказалась, а так виновата только команда, а не методология.
Про "демо", простите - опять же, вы немного лукавите. Забываю о неудобной в данном случае ценности, что любая итерация должна быть полезна для бизнеса.
Вы просто не понимаете, что такое "бизнес-ценность". И снова у вас демо это как повод отчитаться перед заказчиком. Демо это не "любая" итерация. Это один из ритуалов для обратной связи и синхронизации. На демо, еще раз повторюсь, должен показываться готовый к релизу функционал, а не "мы сделали зеленую кнопку, не увольняйте".
А то, что вы пишите — неумение декомпозировать, чтобы на выходе получить небольшой, но функциональный для бизнеса продукт или его часть. В зрелых командах есть специалисты, которым это под силу такое разбиение. И снова забываете, что Agile — про гибкость, но устраиваете какую-то обязаловку по результатам, напрочь упуская все преимущества этой методологии.
Собственно, у нас разница в восприятии Agile - для вас гибкая разработка есть совместное "творчество", для меня это процесс производства с повышенными гарантиями нужного результата. На мой взгляд первое возможно, но до тех пор пока продукт не стал большим и ошибки в его логике не приводят к издержкам клиентов. И DF как раз позволяет повысить полезность коммуникации.
Ваш взгляд — разработка это конвейер. Agile-взгляд — разработка это непредсказуемый процесс R&D.
А то, что вы пишите, не имеет отношения к Agile. У нас нет разницы в восприятии — у вас просто нет знаний в этой области, хотя вы упорно пытаетесь доказать обратное, демонстрируя каждый раз еще большие пробелы и методологическую пропасть.
Вместо часовых споров о решении - формализация функции полезности архитектором доработки, описание решение и ревью с предметными обсуждениями. Вместо постоянного вовлечения заказчика по одним и тем же вопросам - материализация ответов в виде документа.
Еще раз, я не отрицаю важности коммуникации (этот тезис нравится Вам), я говорю то, что результатом любой коммуникации должен стать некий проверяемый результат. И этот результат - техническая документация.
И снова все мимо Agile. Если вы спорите без результата, то вы неправильно наладили процесс коммуникации, т.к. в команде нет понимания, что она должна сделать. Если вы постоянно вовлекаете заказчика, значит вы снова не смогли наладить процесс коммуникации между ним и командой. Если у вас нет результата коммуникации, то вы снова не поняли, как пользоваться этим инструментом.
Абсолютно каждое предложение является примером непонимания гибких методологий и уже в который раз подсвечивается одна и та же проблема.
В статье этого и нет. Есть описание проблем, которые никак не решаются в гибких методологиях (это отдается на откуп команде)...
недостаток Agile как раз в том, что он хорошо решает только часть проблем, а часть - оставляет "на усмотрение команды".
То, что вы считаете недостатком, является преимуществом и сутью Agile — доверием к профессионализму и самоорганизации команды. Фреймворк дает свободу. Если команда не знает, что с ней делать и "ищет маму", которая даст четкие регламенты, то это не проблема фреймворка. Это проблема зрелости и компетенции команды. Напомню принцип:
Над проектомдолжны работать мотивированные профессионалы. Чтобы работа была сделана,создайте условия, обеспечьте поддержку и полностью доверьтесь им.По Agile большей ценностью является не разбор техдолга, а релиз функционала. Коммуникация в том то и дело, что налажена - но она не решает проблемы техдолга, не решает проблем отсутствия полного набора нужной информации. И не может - хотя бы потому, что все привлеченные могут и не знать о чем-то (как пример с SPA интернет-магазина), нет конкретных инструментов.
Это опасное и неверное утверждение. В Agile есть все инструменты — ретро, беклог, практики из экстремального программирования, беклог продукта, DoD. Зрелая команда и владелец продукта понимают, что игнорирование техдолга сегодня приведет к прекращению поставки ценности завтра. И они выделяют на это время в спринтах.
DF позволяет закрыть эти проблемы, которые гибкие методологии оставляют как раз на усмотрение команды.
И снова мимо. Более того, этап технического проектирования можно спокойно записать в DoD. А то, как вы описываете DF — закрывает ваши пробелы инженерной дисциплины и самоорганизации. И да, ваша попытка внедрить DF выглядит именно как первый попавшийся велосипед, как вам справедливо написали.
DF - это в большей степени есть форма выражения результат, проверяемого. DoR ему не противоречит, как и Agile. Тогда чем Вам не нравится DF?
Мне не "не нравится DF". Мне не нравится, что вы его позиционируете как внешнее средство для проблем Agile. При этом вы не понимаете, что эти проблемы сами же и создали. Практика нормального подхода к документации есть изначально в Agile при работе зрелой команды. А у вас же провалено внедрение Agile, потому что вы не поняли, как его применять и зачем, но увидели одну точечную проблему и нашли для нее точечный инструмент. Перефразирую — для меня очевидно, что документация является частью процесса разработки в Agile. Для вас это наоборот.
Тут нет проблемы коммуникации - это адекватная разница целей.
Цель любого заказчика извлечение выгоды... Цель любого разработчика - реализовать продукт...
У вас одна роль хочет быстро, а другая хочет качественно, а третья домой пораньше пойти. Что это? Это именно проблема коммуникации, потому что у каждого своя цель, а не одна общая. Вы еще спорите зачем-то. Чтобы вы понимали, как выглядят ваши слова — "у нас нет проблем в общении, просто мы не общаемся".
Так одна из проблем в материале и обозначена, что многие в гибкий методологиях команда определяет самостоятельно
Это преимущество гибких методологий, которое описано в принципах. С другой стороны получается, что вы, зная такую особенность, и что она вам не подходит, все равно внедряли. Очень умно! Чем больше пишите, тем хуже выставляете себя и компанию.
Вы подменяете в удобном свете для себя цитаты :-). Они про разное, если вчитаетесь. Первая - о том, что большая часть заказчиков закроет глаза на проблемы, которых можно было бы избежать при наличии нормальной проработке, для них будет важнее срок.
Я не работаю у вас и могу называть вещи своими именами, а не выставлять в удобном свете провал внедрения методологии, а потом упорно всем пытаться показать в комментариях, что Agile не торт.
Суть в том, что те цитаты являют собой замкнутый круг причины и следствия. И то, что вы отделяете одно от другого, очень грустно. Зрелая команда может сказать "нет" плохим решениям. А вы пытаетесь показать, что это неизбежно.
Кстати, интересный (неудобный) пример проблем гибких методологий - в какой-то момент, одна знакомая компания закрыла большой продукт. У заказчика поменялось видение того, как должна решаться проблема. Было потрачено полтора года работы команды из 5 человек на подсистему советов в интернет-магазинах на основе ИИ. Поменялось видение - поменялось решение. Коммуникация была на хорошем уровне, ничто не предвещало. Просто заказчик в какой-то момент осознал, что его проблема решается проще. Замечу - все ценности и артефакты соблюдались, проблема выявилась на последних этапах внедрения. Когда стало ясно, что видение было ошибочным - споткнулись на банальностях, которые можно было выявить до этих затрат. Просто формализовав результат и все критерии качества.
Это не "неудобный" для Agile пример. Это идеальный пример того, как не надо делать Agile. Если команда за полтора года, а это примерно 36 двухнедельных спринтов, работала над продуктом и только на последних этапах получила обратную связь от заказчика, что видение было ошибочным, значит в процессе не было ни одной реальной итерации с поставкой ценности и получением обратной связи. Просто что-то делали по водопаду с двухнедельными отрезками. Отличный пример карго-культа.
Смотрите, Вы начинаете судить в удобных фактов для Вашей гипотезы, игнорирую большую часть того, что было сказано.
А давайте посмотрим на факты, которые вы сами изложили?
Первое - где Вы нашли, что документация игнорировалась?
Вы не писали прямо "мы забили на документацию", хотя во всех ответах ниже про ценности вы именно на это очень жирно намекаете.
Но вот цитаты, которые показывают ваше отношение к документации:
Проблема: Разработчики понимали свою конкретную задачу, но общего контекста не осознавали.
Причина: То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
Признание: в начале проекта мы жалели времени на детальное продумывание задачи
Осознание: нам не избежать разработки документации
Личный опыт: прошел все пять стадий принятия того, что свои задачи я должен также документировать, пусть и в виде промежуточных документов.
Последствия игнорирования: Первый результат: пока не понимаем необходимый объем документации, который нужно делать при таком подходе.
Вывод: Документация — это потерянный артефакт в мире гибких методологий.
Где Вы нашли нарушение дисциплины, проблемы коммуникации?
Проблемы коммуникации:
Разработчики понимали свою конкретную задачу, но общего контекста не осознавали
То, что казалось очевидным менеджеру, далеко не всегда учитывали программисты.
и потом получали "волейбол": разработчики отдавали задачи тестировщикам, те возвращали им обратно… и так снова и снова, долго и мучительно
Они исходят не от заказчика, который о них может не помнить или банально не знать, а от реализации
Проблемы дисциплины:
в начале проекта мы жалели времени на детальное продумывание задачи
мы постоянно всё переделывали
Фича создаст поток ошибок и правок, которые надо "дожать" в короткие сроки
чем более "гибким" становился подход, тем сильнее проявлялись узкие места.
мы постоянно всё переделывали
Начинаются доброски "в последний вагон" перед релизом
Мы планируем итерацию, а не пытаемся решить всю задачу, следовательно, пренебрегаем анализом дополнительных требований к ней
Но эти примеры — ерунда по сравнению с тем, что вы сами писали в комментариях.Нет инструментов. Есть только идея, что если люди будут соблюдать ценности и активно взаимодействовать, то получится эффективно.
И еще раз — инструментов достаточно. Просто для этого надо понимать, что такое Agile, чего в данном конкретном случае не было вообще.
С точки зрения получения нужного для заказчика результатов - у гибких методологий нет равных, так как они дают промежуточные точки контроля (а это они, каким бы красивым эпитетом они не назывались бы). И их цель не минимизация рисков (считайте, издержек - они принимаются как данность), а получение максимальной ценности за вложенную стоимость.
И опять вы упорно не хотите понять, что демо — это не для контроля. Как и упорно игнорируете факт, что с заказчиком должно быть общение. Чисто логически — при регулярном общении с заказчиков нет смысла в контроле в виде демо, потому что он и так в курсе в любой день. Более того, заказчику могут дать доступ к тестовому стенду, где он может сам смотреть, как меняется продукт буквально в любой момент времени и тут же давать обратную связь — это отлично работает в рамках Agile в реальном мире. Но так как вы не знаете, что такое Agile, то для вас это элементы контроля. С таким подходом, где команда может организоваться и работать сама, ваше понимание расходится полностью.
Материал же о том, как уменьшить риски, достаточно дешевым способом.
Нет, материал о том, как команда, провалив внедрение Agile из-за непонимания его ценностей и отсутствия инженерной дисциплины, вернулась к привычной директивной модели, выставив гибкую методологию крайней.
И сейчас, вместо того, чтобы писать ответ, лучше ознакомьтесь с книгой Боба Мартина. Она читается за вечер. Объективно — ничего нового вы уже не напишете, лучше своими комментариями не сделаете. Так посвятите время самообразованию и вдумчиво ознакомьтесь с книгой "Чистый Agile".
В крайнем случае закиньте статью и все переписки в LLM, она вам пояснит.
Если бы написали про попытку внедрения Agile, про то, как сами ее провалили и почему, и как в итоге пришли к выводу, что вам больше подходит DF, хотя это не методология и вообще непонятно, что у вас в итоге сейчас, то такая статья была бы намного лучше, честнее, интереснее, но увы, имеем что имеем.
Zenitchik
06.10.2025 10:18Прочитав Ваш комментарий, я перестал понимать в чём противоречие. Почему бы, например, не применять Alige и DF вместе как взаимодополняющие сущности?
MisterKot
06.10.2025 10:18Автор статьи исходит из ложной предпосылки, что в Agile документацией можно пренебречь. Равно как и то, что Agile дает скорость — это классические заблуждения. Из-за чего ожидаемо вытекает немало проблем. Он приходит к выводу, что
Документация — это потерянный артефакт в мире гибких методологий...
и "находит" решение
Documentation First призван устранить недостатки гибких методологий\фреймворков, снизить риски за счет бюрократизации в нужных местах.
И тут две фундаментальные ошибки — сначала с потерянным артефактом, затем с призванием DF.
Сам подход с документацией не нов, раньше он назывался RDD (Readme Driven Development) и другими именами. Но его появление в команде, работающей якобы по Agile, это не что-то новое, а сигнал, что Agile был внедрен как карго-культ, без понимания сути.
Зрелая команда с развитой инженерной культурой не нуждается в том, что ей "внедряли" DF. Для нее предварительный анализ, проектирование и написание необходимой документации — это не отдельный подход, а здравый смысл, часть процесса разработки ПО, без которого не написать качественный код. А весь Agile именно про то, что нужно писать хорошо, нужно писать тесты, нужно заниматься парным программированием. Всё это создает циклы ревью и улучшений итогового продукта.
Поэтому, отвечая на вопрос — противоречия между Agile и DF/RDD нет.
Это не взаимоисключающие вещи. Agile это фреймворк, DF это инженерная практика, которая естественным образом уже есть внутри этого фреймворка (опять же, в зрелых командах, которые понимают, что они делают).
Проблема, которая возникла в статье, возникла не потому, что Agile и DF/RDD не совместимы, а потому, что команда автора изначально выкинули из своего процесса базовую инженерную практику, а потом героически ее вернула под новым названием, свалив при этом вину на Agile.
trixt3r Автор
06.10.2025 10:18Не стоит придумывать выводы за автора, если они вам кажутся более удобными для отстаивания своей позиции :-)
Автор статьи исходит из ложной предпосылки, что в Agile документацией можно пренебречь. Равно как и то, что Agile дает скорость — это классические заблуждения. Из-за чего ожидаемо вытекает немало проблем. Он приходит к выводу, что
Где я утверждал, что Agile дает скорость? По первому, будем исходить из манефеста, а не Вашего понимания Agile (это как минимум уже какое-то восприятие, искажающее идеи опытом):
По Agile, документация менее важна, чем работающая фича. И в случае выбора - заказчик будет выбирать фичу. Т.е. в среднем по больнице в большем количестве случаев.
В Agile нет критериев качества документации, как и требования документировать решение до выполнения задачи.
И тут две фундаментальные ошибки — сначала с потерянным артефактом, затем с призванием DF.
Комплексная документация является потерянным артефактом в разрезе Agile, так как она не представляет высокой ценности для заказчика.
По гибким методологиям документация должна быть достаточной для решения конкретной задачи, т.е. вполне может не включать большое количество важного, т.к. это касается продукта в целом и относится к опциальными (вместе с описанием архитектуры модулей, временными решениями, очевидными вещами).
Плюс - Agile не предполагает документирование решения до его разработки, она должна писаться just-in-time в достаточном для понимания решения виде.
В целом, разработка документации в спринте не может занимать более 5-10 процентов. Это исключает включать в спринт разработку комплексной документации без написания кода.
Зрелая команда с развитой инженерной культурой не нуждается в том, что ей "внедряли" DF. Для нее предварительный анализ, проектирование и написание необходимой документации — это не отдельный подход, а здравый смысл, часть процесса разработки ПО, без которого не написать качественный код. А весь Agile именно про то, что нужно писать хорошо, нужно писать тесты, нужно заниматься парным программированием. Всё это создает циклы ревью и улучшений итогового продукта.
Agile не про то, что надо писать хорошо - он про то, что надо делать так, как нужно заказчику. Качество кода как раз является ответственностью команды, которую она должна нести из идеологических причин (те самые красивые идеи).
Тесты, парное программирование, документация - это все должно быть, но их качество остается на "совести" исполнителя. Ценности по этим императивам не имеют измеримого результата (в отличии от частей, касающихся заказчика) - актуальность, доступность, полезность и поддерживаемость. И при этом - они не должны увеличивать общую стоимость проекта, пусть и в ущерб будущим операционным затратам.
Цель Agile - не получение качественного с инженерной точки зрения продукта, а получение в рамках текущего бюджета максимальной выгоды (удовлетворенности) заказчика.
DF как и любой инструмент требуется внедрять в рабочий процесс. И не только потому, что в типовой команде уровень сотрудников разный. А потому, как точки контроля результатов любого инструмента должны быть определены и являться частью общей цепочки. Тут - если документация должна быть написана до написания кода, то требуется этот процесс "шаблонизировать", интегрировать в применяемые инструменты, процессы.
Поэтому, отвечая на вопрос — противоречия между Agile и DF/RDD нет.
Есть. Как минимум в том, что ценность комплексной документации ниже работающего кода и он может быть получен без документации вообще. И при применении Agile-методологий чаще всего она появляется в процессе написания кода или вообще после него.
DF/RDD предполагает документацию до написания кода. То есть перед тем как задача будет выполнять проводится глубокий анализ и проектирование, которые обязательно проходят ревью (чего не требует Agile, кстати).
Но да, DF/RDD может легко интегрироваться в любую гибкую методологию потому, что - это как раз те "белые пятна", которые определяет сама команда. И суть в том, что можно повысить требования к документацию и поменять местами документацию и разработку местами при решении конкретной задачи. И как итог - получить решение многих проблем, которые будут возникать в реальных команда. А не "идеальных", которые все одного уровня, одинаково мотивированы и так далее.
Это не взаимоисключающие вещи. Agile это фреймворк, DF это инженерная практика, которая естественным образом уже есть внутри этого фреймворка (опять же, в зрелых командах, которые понимают, что они делают).
Нет DF внутри Agile. Сам по себе DF противоречит местами манифесту, причем достаточно существенно. Но ввиду плюсов от DF - это не существено.
Если же мы имеем нечто, что является свойством только "зрелой" команды (на самом деле, в описанных в манифестве качествах - это идеальная ситуация, да ещё и без измеримых критериев), то это уже не часть методологии. Так ка это уже "творчество" команды, которая просто заполняет "белое пятно".
Проблема, которая возникла в статье, возникла не потому, что Agile и DF/RDD не совместимы, а потому, что команда автора изначально выкинули из своего процесса базовую инженерную практику, а потом героически ее вернула под новым названием, свалив при этом вину на Agile.
Где вы видите эти выводы? Я говорю о том, что они совместимы и даже в комментариях не раз говорил, что мы сохранили гибкие подходы, но при этом начали использование DF.
Базовая же инженерная практика - какая именно? Вы много раз назвали этот термин. Если вы прод документирование конкретного решения конкретной задачи - так оно по гибким методологиям менее ценно, чем работающий код. Обратите внимание, в статье поднимается проблема не отсутствия проектной документации (и да, она по Agile тоже должна быть), а о документировании конкретного решения. Собственно последнее и делает из достаточной документации - комплексную.
Zenitchik
06.10.2025 10:18Ну, как бы дураку ясно, что для заказчика работающая фича важнее, чем документация.
Поэтому в режиме цейтнота, документация идёт в "технический долг".
проблема не отсутствия проектной документации (и да, она по Agile тоже должна быть), а о документировании конкретного решения. Собственно последнее и делает из достаточной документации - комплексную.
Состав проектной документации и критерий её достаточности нигде не стандартизирован. Руководитель производства может своим решением включить документацию по конкретным решениям список необходимой проектной, и тогда множества, которые Вы назвали "достаточной" и "комплексной" документацией - полностью совпадут.
trixt3r Автор
06.10.2025 10:18Ну, как бы дураку ясно, что для заказчика работающая фича важнее, чем документация.
Поэтому в режиме цейтнота, документация идёт в "технический долг".
Закрытие которого не станет важной для заказчика, пока стоимость реализации фич не станет критической (то есть исправление не станет полезным). Зачем до этого доводить и порождать большие операционные затраты, если можно сейчас затратить в разы меньше и не допустить этого?
Состав проектной документации и критерий её достаточности нигде не стандартизирован. Руководитель производства может своим решением включить документацию по конкретным решениям список необходимой проектной, и тогда множества, которые Вы назвали "достаточной" и "комплексной" документацией - полностью совпадут.
Конечно, руководитель проекта может включить любую документацию, но Agile не приветствует разработку комплексной. Так как это понижение пользы для заказчика в рамках текущего бюджета.
Zenitchik
06.10.2025 10:18Закрытие которого не станет важной для заказчика
никогда. Никогда оно не станет важно для заказчика. Это внутренняя задача подрядчика, которую придётся закрывать за свой счёт.
trixt3r Автор
06.10.2025 10:18никогда. Никогда оно не станет важно для заказчика. Это внутренняя задача подрядчика, которую придётся закрывать за свой счёт.
Или включить эту задачу в процесс производства, обосновав для заказчика это прогнозами издержек через Н времени.
MisterKot
06.10.2025 10:18Я вам вчера посоветовал всё закинуть в LLM, чтобы она вам пояснила. Вы это сделали? Там еще был совет почитать книгу, но ее надо все же сначала а купить, а LLM доступны сразу.
Вы снова наступаете на одни и те же грабли. Вот часть ваших заблуждений только из этого сообщения (которые и объясняют провал внедрения):
Комплексная документация является потерянным артефактом в разрезе Agile, так как она не представляет высокой ценности для заказчика.
Agile не про то, что надо писать хорошо - он про то, что надо делать так, как нужно заказчику
По Agile, документация менее важна, чем работающая фича.
Вчера уже сколько раз я делал акцент, что речь про исчерпывающую документацию, но вы этого в упор не замечаете и не понимаете, о чем речь, хотя разжёвано по несколько раз. Последняя попытка, может на английском понятнее:
Working software over comprehensive documentation.Далее цитаты:
Плюс - Agile не предполагает документирование решения до его разработки
Цель Agile - не получение качественного с инженерной точки зрения продукта
перед тем как задача будет выполнять проводится глубокий анализ и проектирование, которые обязательно проходят ревью (чего не требует Agile, кстати).
Сам по себе DF противоречит местами манифесту, причем достаточно существенно
Вы просто не понимаете, что такое Agile. И, что более показательно, не хотите его понять, при том, что вам разные люди в комментариях пишут одинаковые вещи.
Вы просто каждом новым комментариям оказываете медвежью услугу Тензору. После такой "презентации" внедрения процессов желающих идти к вам станет меньше. Никто не хочет работать в карго-культе, особенно, когда ответственные или приближенные к ним люди не слышат ничего, кроме своего личного мнения.
trixt3r Автор
06.10.2025 10:18Я вам вчера посоветовал всё закинуть в LLM, чтобы она вам пояснила. Вы это сделали? Там еще был совет почитать книгу, но ее надо все же сначала а купить, а LLM доступны сразу.
Вы снова наступаете на одни и те же грабли. Вот часть ваших заблуждений только из этого сообщения (которые и объясняют провал внедрения):
Перечитайте манифест. Ну или спросите у ИИ в конце-то концов о минусах Agile и проблемах, которые могут материализоваться. Ну или поищете на Хабре, почему те или иные крупные компании отказывались от гибких методологий (были переводы, ссылки не сохранял). Замечу, большая часть того, что будет - относится к специфики методологии, а не к конкретной реализации.
Если после этого Вы не найдете того, что приводит к этой проблеме - у меня нет аргументов, человек видит в тексте только то, что он хочет.
Вчера уже сколько раз я делал акцент, что речь про исчерпывающую документацию, но вы этого в упор не замечаете и не понимаете, о чем речь, хотя разжёвано по несколько раз. Последняя попытка, может на английском понятнее:
Working software over comprehensive documentation.Комплексная документация (о которой говорит Брукс) является антипаттерном Agile. Так как она избыточная (с точки зрения решения конкретных задач) и не приносит пользы для заказчика (по крайней мере в ближайшей перспективе). Если Вы внимательно почитаете, то найдете много интересного. Как в материале, так и в манифесте.
И хватит ссылаться на манифест, вы все равно видите в нем только то, что хотите. Я читал его как в оригинале (до того, как его перевели), так и в переводе. Как и большую часть базовой литературы по гибким методологиям.
Вы просто не понимаете, что такое Agile. И, что более показательно, не хотите его понять, при том, что вам разные люди в комментариях пишут одинаковые вещи.
Заблуждение - может быть вполне у какого-то количества сторонников определенной точки зрения. Когда-то считали, что пить ртуть по определенной небесных тел - приведет к здоровью.
Для меня наличие в методологиях "белых пятен" не проявления гибкости, а проблема при её практическом применении. Если у вас другое мнение или вы не считаете это "белыми пятнами" - это Ваше мнение, Ваша правда и Ваш опыт (предполагаю, что человек ведущий такой долгий диалог должен обладать им). Но это не делает ни мое, ни ваше мнение - не правильным. Оно делает его разным, а итоги описанного мной - мы узнаем после того, как по командам практика будет применяться.
Сейчас же спор мне скорее напоминает "любой прием приводящий тебя к победе - является приемом каратэ" - можно утверждать, что это тоже часть Agile. Ведь не зря же методологии назвали "гибкими" (хотя их название исходит от гибкости для заказчика, а не разработчика).
Вы просто каждом новым комментариям оказываете медвежью услугу Тензору. После такой "презентации" внедрения процессов желающих идти к вам станет меньше. Никто не хочет работать в карго-культе, особенно, когда ответственные или приближенные к ним люди не слышат ничего, кроме своего личного мнения.
Простите, но я не считаю, что я "не слышу".
Например, мы с Вами дискутируем. Обмениваемся какими-то аргументами. Каждый со своей позицией. Если у Вас это взывает негативные эмоции - такое бывает, это Ваше право.
Я не отрицал нигде в материале, что возможно Вы (или какой-то из других комментаторов) - правы в каких-то своих утверждениях.
При этом, да, я придерживаюсь своей точки зрения. И это является нормальным. Она отстаивается мной до тех пор, пока не будет каких-то весомых аргументов, которые приведут к её изменению. Что в целом тоже логично и нормально.
Ни вы, ни я - не являемся специалистами по Agile-методологиям. Поэтому ни Ваше, ни моё мнение не может считаться каким-то весомым. Проще говоря - понимания ценностей, принципов и элементов Agile у нас с Вам отличается в уже понятных местах, но воспринимается по-разному и оценивается по-разному.
Ах, да. Про карго-культ странное сравнение. Как минимум, т.к. я ни в одном комментарии ни сказал, что "agile ни на что не годен" или "надо работать только по DF". Этот вывод был сделан Вами, после чего почему-то Вы решили опровергнуть то, чего не было ни в материале, ни в комментариях.
msolyakov
06.10.2025 10:18По гибким методологиям документация должна быть достаточной для решения конкретной задачи, т.е. вполне может не включать большое количество важного
Если документация не включает в себя "большое количество важного", она априори не может быть достаточной. В Agile Команда (а не Заказчик) определяет и отвечает за то, каким способом она реализует фичу, и если ей нужна документация - окей, это те артефакты, которые будут созданы.
trixt3r Автор
06.10.2025 10:18Если документация не включает в себя "большое количество важного", она априори не может быть достаточной. В Agile Команда (а не Заказчик) определяет и отвечает за то, каким способом она реализует фичу, и если ей нужна документация - окей, это те артефакты, которые будут созданы.
Если это касается фичи - да. Но доработка может повлечь к проблемам (но не обязан, да), которые не касаются фичи напрямую. И решение этих проблем мог не закладывать исполнитель (он мог о них и не знать.).
msolyakov
06.10.2025 10:18И решение этих проблем мог не закладывать исполнитель (он мог о них и не знать.)
1) В груминге и оценке задач участвует вся команда. Как так получилось, что ВСЯ команда не знала о возможных проблемах? Кто-то же из команды должен был "поднять руку" и такой: "hold on a second..." ?
2) Окей, один раз наступили на эти грабли, с кем не бывает. А ретро как же? Внедрение улучшений в процесс?
trixt3r Автор
06.10.2025 10:181) В груминге и оценке задач участвует вся команда. Как так получилось, что ВСЯ команда не знала о возможных проблемах? Кто-то же из команды должен был "поднять руку" и такой: "hold on a second..." ?
В идеальном мире, да - все верно. И если Вы работаете с системой такого размера, что весь функционал (даже смежный) всегда однозначно известен всем. Но в реальном мире такое тоже не всегда бывает (пример из жизни про сборки SPA где-то в комментариях я приводил).
В материале и комментариях уже есть ответ на вопрос, почему такая ситуация может возникнуть. И как раз DF решает эти проблемы.
2) Окей, один раз наступили на эти грабли, с кем не бывает. А ретро как же? Внедрение улучшений в процесс?
Ну так в материале и описывается то, что мы в итоге выбрали и начали применять как улучшение процесса. То, что не заработало хорошо и частично - просто осталось за рамками материала.
msolyakov
06.10.2025 10:18В идеальном мире, да - все верно. И если Вы работаете с системой такого размера, что весь функционал (даже смежный) всегда однозначно известен всем. Но в реальном мире такое тоже не всегда бывает (пример из жизни про сборки SPA где-то в комментариях я приводил).
Дело совсем не в идельном мире. Навскидку:
Сколько команд работают над продуктом?
Как синхронизируются команды? Используете что-то из SAFe, например?
Как управляете зависимостями м-ду компонентами? Как уменьшаете связанность?
Насколько развито автоматизированное интеграционное тестирование?
trixt3r Автор
06.10.2025 10:18Еще раз, я прекрасно понимаю какие проблемы Вам пришли в голову. Все эти вопросы были первыми на которые мы отвечали при анализе.
В рамках нашего масштаба (в нашем случае) пока лучше результаты показал именно подход DF (не отказ полный от гибкости, а применение в проблемной точки DF).
trixt3r Автор
06.10.2025 10:18Прочитав Ваш комментарий, я перестал понимать в чём противоречие. Почему бы, например, не применять Alige и DF вместе как взаимодополняющие сущности?
Цель Agile (любой вариации) - это повышение гарантий заказчику получить то, что он хочет. Фактически, минимизацию рисков того, что исполнитель сделает не то (как он это сделает - Agile не регулирует, т.к. нет у него такой цели). В этом разрезе разработка комплексной документации противоречит целям заказчика, которые у него есть сейчас и при текущем бюджете.
DF же направлен на то, чтобы оптимизировать сам процесс разработки, фактически он нужен чтобы не допускать лишней работы и не потерять неявной важной работы. Перед тем как что-то будет сделано - требуется разработка комплексной документации решения (не только проектной). Т.е. по нему Вам придется зафиксировать для чего делать, что делать, как делать и как это предполагается использовать (если это переиспользуемая часть). И это "зафиксированное" должно пройти некое ревью, которое проверяет подход и полноту решения до цикла разработки. Таким образом Брукс предлагал уменьшать операционные затраты т.к. без этого есть риски оверинжиниринга, несостыковки на уровне интерфейсов, потерянной логики, неучтенных ограничений, появления лишней логики и т.п (собственно, при разработке ОС он и столкнулся со всеми этими проблемами сразу). Возможность рисков исходит из фундаментальной проблемы - неполноты информации, которая будет до тех пор, пока не появится некий источник комплексных знаний.
Справедливости ради, первое и второе является документацией по Agile (проектная документация), а вот последнее - не в полном объеме (т.к. требуется только достаточная для решения задачи документация). Решение по гибким методологиям может делаться раньше, чем будет разработана документация (лучший вариант для гибкой методологии - это написание документации в процессе реализации). По гибким методологиям считается в спринте не может быть более 5-10% времени отводится на разработку документации, DF же не ставит такого лимита. Предполагается, что издержки на формирование такой документации меньше, чем стоимость возможных рисков.
Да, DF не всегда оправдан. Скажем, если есть небольшая команда и работа идет по стартапу, то DF будет скорее мешать (он увеличивает время появления MVP, который сам заказчик ещё не представляет ещё каким должен быть). Когда же мы говорим о больших системах и\или уже существующем продукте, ошибки которого могут сказаться на издержках пользователей (а следовательно - продажах и прибыли), то анализ и проектирование всегда должны иметь материализованное выражение с измеримыми критериями и идти до реализации.
Собственно, в материале и говорится о том, что мы в точке конкретной проблемы (реализация проектного решения) стали применять DF, что не помешало продолжать над самими проектами сохранять гибкий подход, но привело к понижению операционных издержек.
Собственно, тред и масса комментариев связаны с тем, что евангелисты гибких методологий имеют свойство считать все, что приводит к позитивному эффекту или к самим agile-методологиям, или к свойствам команды (так как требования к ней сформулированы в виде не измеримых красивых идей, к которым можно прилепить любую положительно влияющую практику).
msolyakov
06.10.2025 10:18разработка комплексной документации противоречит целям заказчика, которые у него есть сейчас и при текущем бюджете
Мне кажется, что вы смотрите на документацию, как на outcome, a ее следует рассматривать как tool. Заказчик, безусловно, платит, чтобы получить ценный и работающий продукт, и документация является той составляющей, которая даст нужный результат.
Вопрос - Ваш менеджмент позволяет себе приходить в команду и "рулить" задачами в спринте? Например, в этом спринте запрещают делать техдолг, т.к. есть более приоритетные бизнес задачи? Если да, то почему так происходит? Насколько бизнес доверяет команде? Насколько команда способна выдерживать цели спринта? И что для Вас есть цели спринта?
trixt3r Автор
06.10.2025 10:18Мне кажется, что вы смотрите на документацию, как на outcome, a ее следует рассматривать как tool. Заказчик, безусловно, платит, чтобы получить ценный и работающий продукт, и документация является той составляющей, которая даст нужный результат.
Да, но - без достаточно комплексной документации, важная для продукта (а не для задачи) часть может быть упущена.
Вопрос - Ваш менеджмент позволяет себе приходить в команду и "рулить" задачами в спринте? Например, в этом спринте запрещают делать техдолг, т.к. есть более приоритетные бизнес задачи? Если да, то почему так происходит? Насколько бизнес доверяет команде? Насколько команда способна выдерживать цели спринта? И что для Вас есть цели спринта?
На большую часть вопросов - ответ очевиден по материалу. Он исходит из того, что у нас есть возможность выбирать какие-то подходы, предлагать решения и т.п.
Но, статья не тех проблемах, которые Вам в данном случае хочется найти. Она об желании оптимизировать операционные издержки путем применения DF. Причины их появления тоже уже не раз обозначены.
msolyakov
06.10.2025 10:18Да, но - без достаточно комплексной документации, важная для продукта (а не для задачи) часть может быть упущена.
Правильно ли я понимаю, что Ваша статья на самом деле о том, как вы решаете проблему Lack of Knowledge в команде, используя Document First?
trixt3r Автор
06.10.2025 10:18Правильно ли я понимаю, что Ваша статья на самом деле о том, как вы решаете проблему Lack of Knowledge в команде, используя Document First?
По-русский это называется проблема неполноты информации, фундаментальная проблема.
Да, в статье и комментариях я подсветил точки в гибких методологиях, где это проблема проявляется и почему в рамках них мы не смогли найти решения. Почему взяли DF и получили положительный тренд.
Ни в статье, ни в комментариях не было утверждения об отказе в-принципе от гибких методах (кроме конкретных точек, где сейчас мы пробуем для себя внедрение DF). Как не было и того, что DF должен быть использован как единственный инструмент или является какой-то серебряной пулей.
Просто почему-то комментаторы решили, что "с гибким подходом в этой точке мы не смогли решить проблему" равно "гибкие методологии не работают". То есть фактически материал о том, какое решение мы нашли для себя, не переходя на "водопад" или что-то иное.
msolyakov
06.10.2025 10:18Да, в статье и комментариях я подсветил точки в гибких методологиях, где это проблема проявляется и почему в рамках них мы не смогли найти решения.
Нету таких точек в гибких методологиях. Но есть реальная проблема в понимании масштаба отвественности в Agile - что условный Вася, как часть команды, ответственнен не за кусок кода, который он написал, а за результат бизнеса, который этот код сделал (или не сделал).
Если зону отвественности Васи ограничивать Васиным же кодом - критерии приемки будут, условно, чтобы тесты на этом куске кода прошли. Это удобно для Васи, но это не Agile. Если же мы говорим за ответственность Васи за весь продукт, то сразу возникают вопросы скажем, совместимости модулей. И вопрос с прояснением этих неизвестных возникает сам собой как часть задачи и потребует ответа - в противном случае Вася зафейлится.
Но т.к., по всей видимости, у каждого девелопера на Вашем проекте зона его ответственности - его код, вам пришлось добавить еще одну зону ответственности - документацию. Регламент попробуй оспорь - поэтому и работает.
trixt3r Автор
06.10.2025 10:18Откуда такие странные выводы?
В приведенном примере с Васей, проблема не в понимании "ответственности в Agile". Есть реальная жизнь - в ней программист решает проблему и несет ответственность за результат того, что он делает. И это так вне зависимости какую методологию использует команда.
И да, в реальной жизни условный Вася может вполне "забить" на ответственность. В большей части компаний, которые мне известны - малое число разработчиков на самом деле готовы отвечать за результат. И это может привести к описанным проблемам. Но я пришел, к выводу - это не тот случай. Как относиться к этому выводу - Ваша субъективная оценка.
В материале и комментариях я изложил свое субъективное мнение на счет гибких методологий. Мнения у нас разошлись - это нормально, такое тоже бывает. Но не дает Вам возможность утверждать.
Странно делать выводы об распределении ответственности, когда у Вас нет ни явных, ни косвенных признаков.
Как-то так)
smart_cookie_05
06.10.2025 10:18Спасибо, а то я подумала то же самое, но так круто - подробно и с выкладки из agile - не смогла бы оформить мысль, даже близко.
А вы откуда так хорошо владеете темой?
MisterKot
06.10.2025 10:18Предположу, что этот вопрос мне.
Не могу сказать, что прям хорошо владею темой — все же здесь обсуждались самые поверхностные вещи. Для лучшего понимания в своё время прочитал "Чистый Agile" от Боба Мартина, "Пользовательские Истории" от Майка Кона, "Agile-тестирование" от Лайзы Криспин и Джанет Грегори. Также знакомился с какой-то версией PMBOK, и, насколько знаю, последние редакции смещались в сторону гибких методологий. Еще было много статей, что-то у Кента Бека читал, статьи Мартина Фаулера, но точно уже не вспомню. В целом можно просто открыть список авторов Agile и искать их статьи/книги.
Много опыта дала работа по Agile, где он хорошо внедрен и там, где внедрен очень плохо — на контрасте сразу видно, что не так и как должно было бы быть.
Cordekk
06.10.2025 10:18ну надо понимать, что Agile это не фреймворк, не метод, не руководство к действию, а философия. В работе применялся какой-то метод, вроде бы основанный на 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 применяется на новых объемах работ, т.е. чтобы не допустить того, что было ранее. Пока - успешно.
Zenitchik
06.10.2025 10:18Но, отдел проектирования в этих компаниях был именно "заводом по производству проектной документации". Что-то "из ряда вон" требовалось очень редко, чаще всего даже не бралось в работу (плохо прогнозируемая прибыль).
Когда я был маленьким, нам в институте на информатике рассказывали по одно вагоностроительное предприятие. Так там сборочно-сварочное производство вагона никогда не требовало чего-то "из ряда вон", и всегда его можно было свести к комбинации существующих вариантов. Так вот, они написали на Excel и VBA программу, которая им по проекту вагона сразу директивку выдавала.
Dinonoob
Все возвращается на круги своя.
Не подскажите , какого размера у вас команда ?
Моё убеждение - если в команде более 3 человек то без документирования ни как не обойтись.Но главное не скатиться в противоположную сторону и не забюрократизироватбь все процессы до их полного окостенения.
trixt3r Автор
У меня 60+ человек, разбитые на несколько команд, поэтому "задачи по DF" начали показывать результаты положительные относительно быстро.
Да, Вы абсолютно правы - важно найти баланс между бюрократизацией процесса и гибкостью. По-ощущениям, именно в этом месте agile-подходы и должны пприменяться\роявлять сильные стороны. Но, для каждой компании и команды, скорее всего, пропорции бюрократизации\гибкости надо выводить опытным путём (многое зависит от самих людей, предметной области, стека, ландшафта и т.п.)