Есть бизнес-потребность. Она выражена в виде конечного результата. При её декомпозиции на задачи для разработки есть риски потери каких-то моментов из-за проблемы неполноты информации (в реальном мире она не будет полной).
Чтобы уменьшать этот риск Брукс предложил DF. Собственно - в точках, где это надо мы его и применили. Чтобы "мутные задачи" стали понятными и полными.
Тут скорее вопрос - как при гибком подходе в целом обеспечить понимание комплексное задачи. Большинство случаев, когда люди не понимают - они утверждают, что "все понятно". Часто в больших системах задача в первых приближениях кажется проще, чем есть на самом деле.
DF как раз позволяет систематизировать знания, работу над анализом и проектированием, дает проверяемый результат.
ну надо понимать, что Agile это не фреймворк, не метод, не руководство к действию, а философия. В работе применялся какой-то метод, вроде бы основанный на Agile.Теперь они его поменяли на следующий метод, тоже основанный на Agile.
Agile - философия, поэтому в тексте идет "agile-семейств", т.е. подразумевается комплекс фреймворков, которые реализуют философию.
Почти любой гибкий фреймиворк будет содержать какое-то количество не описанных мест, которые отдаются на усмотрение самой команды. И да, при внедрении отсутствие конкретных методологических указаний - является проблемой с точки зрения "бери и применяй". Почему так сделано понятно - цель гибких методологий увеличение выгода заказчика, не команды. И тут команде дается возможность в рамках поставленных гибких ценностей выбрать методы построения производственного процесса.
Материал как раз о том, что из различных вариаций - мы выбрали DF и почему.
В приведенном примере с Васей, проблема не в понимании "ответственности в Agile". Есть реальная жизнь - в ней программист решает проблему и несет ответственность за результат того, что он делает. И это так вне зависимости какую методологию использует команда.
И да, в реальной жизни условный Вася может вполне "забить" на ответственность. В большей части компаний, которые мне известны - малое число разработчиков на самом деле готовы отвечать за результат. И это может привести к описанным проблемам. Но я пришел, к выводу - это не тот случай. Как относиться к этому выводу - Ваша субъективная оценка.
В материале и комментариях я изложил свое субъективное мнение на счет гибких методологий. Мнения у нас разошлись - это нормально, такое тоже бывает. Но не дает Вам возможность утверждать.
Странно делать выводы об распределении ответственности, когда у Вас нет ни явных, ни косвенных признаков.
Еще раз, я прекрасно понимаю какие проблемы Вам пришли в голову. Все эти вопросы были первыми на которые мы отвечали при анализе.
В рамках нашего масштаба (в нашем случае) пока лучше результаты показал именно подход DF (не отказ полный от гибкости, а применение в проблемной точки DF).
Согласна с тем, что любая практика — это инструмент, и вопрос действительно в том, как и где её применять.
Да, и вот мы для себя поняли в каких конкретных точках стоит перестать быть "гибкими" и надо использовать что-то более "бюракратическое". На мой взгляд именно "микс" идей всегда более жизнеспособен. Не будем далеко ходить - Python микс идей с точки зрения языков, он куда более применим в реальных задачах, чем "чистые" языки.
Тем не менее, когда я говорила о смешении уровней, я скорее имела в виду, что в статье фокус периодически смещается от философии Agile к конкретным проблемам инженерного процесса — и из-за этого создаётся ощущение, будто речь идёт именно о несостоятельности Agile как концепции, а не о трудностях его внедрения. К тому же само название статьи — «Тише едешь — дальше будешь: почему новомодные Agile-методологии уступают подходам прошлого века» — изначально задаёт противопоставление, поэтому материал и воспринимается в таком ключе, даже несмотря на заключение.
Если мы говорим про несостоятельность Agile как концепции, то конечно, надо понимать в разрезе чего. Но такой мысли в материале нет. Но название с одной стороны изначально и хотелось сделать более "спорным", чтобы люди вышли на диалог. В спорах - часто можно найти что-то важное. Чему-то научиться. Хотя бы даже риторике.
Полностью разделяю мысль, что Documentation First может стать мостом между дисциплиной и гибкостью. Возможно, если бы в статье чуть чётче звучало, что DF не альтернатива Agile, а его осознанное дополнение, идея воспринималась бы ещё сильнее.
Возможно. Но исходя из комментариев - люди видят то, что хотят. И кому-то даже такой тезис не понравится.
В любом случае, спасибо за интересный материал и развёрнутый ответ — тема действительно интересная. И, как мы видим, не теряет актуальности
Благодарю и Вас! Буду стараться что-то находить из своей практики интересное и полезное, публиковаться. Сам получаю удовольствие от этого)
Правильно ли я понимаю, что Ваша статья на самом деле о том, как вы решаете проблему Lack of Knowledge в команде, используя Document First?
По-русский это называется проблема неполноты информации, фундаментальная проблема.
Да, в статье и комментариях я подсветил точки в гибких методологиях, где это проблема проявляется и почему в рамках них мы не смогли найти решения. Почему взяли DF и получили положительный тренд.
Ни в статье, ни в комментариях не было утверждения об отказе в-принципе от гибких методах (кроме конкретных точек, где сейчас мы пробуем для себя внедрение DF). Как не было и того, что DF должен быть использован как единственный инструмент или является какой-то серебряной пулей.
Просто почему-то комментаторы решили, что "с гибким подходом в этой точке мы не смогли решить проблему" равно "гибкие методологии не работают". То есть фактически материал о том, какое решение мы нашли для себя, не переходя на "водопад" или что-то иное.
1) В груминге и оценке задач участвует вся команда. Как так получилось, что ВСЯ команда не знала о возможных проблемах? Кто-то же из команды должен был "поднять руку" и такой: "hold on a second..." ?
В идеальном мире, да - все верно. И если Вы работаете с системой такого размера, что весь функционал (даже смежный) всегда однозначно известен всем. Но в реальном мире такое тоже не всегда бывает (пример из жизни про сборки SPA где-то в комментариях я приводил).
В материале и комментариях уже есть ответ на вопрос, почему такая ситуация может возникнуть. И как раз DF решает эти проблемы.
2) Окей, один раз наступили на эти грабли, с кем не бывает. А ретро как же? Внедрение улучшений в процесс?
Ну так в материале и описывается то, что мы в итоге выбрали и начали применять как улучшение процесса. То, что не заработало хорошо и частично - просто осталось за рамками материала.
Мне кажется, что вы смотрите на документацию, как на outcome, a ее следует рассматривать как tool. Заказчик, безусловно, платит, чтобы получить ценный и работающий продукт, и документация является той составляющей, которая даст нужный результат.
Да, но - без достаточно комплексной документации, важная для продукта (а не для задачи) часть может быть упущена.
Вопрос - Ваш менеджмент позволяет себе приходить в команду и "рулить" задачами в спринте? Например, в этом спринте запрещают делать техдолг, т.к. есть более приоритетные бизнес задачи? Если да, то почему так происходит? Насколько бизнес доверяет команде? Насколько команда способна выдерживать цели спринта? И что для Вас есть цели спринта?
На большую часть вопросов - ответ очевиден по материалу. Он исходит из того, что у нас есть возможность выбирать какие-то подходы, предлагать решения и т.п.
Но, статья не тех проблемах, которые Вам в данном случае хочется найти. Она об желании оптимизировать операционные издержки путем применения DF. Причины их появления тоже уже не раз обозначены.
Если документация не включает в себя "большое количество важного", она априори не может быть достаточной. В Agile Команда (а не Заказчик) определяет и отвечает за то, каким способом она реализует фичу, и если ей нужна документация - окей, это те артефакты, которые будут созданы.
Если это касается фичи - да. Но доработка может повлечь к проблемам (но не обязан, да), которые не касаются фичи напрямую. И решение этих проблем мог не закладывать исполнитель (он мог о них и не знать.).
Я вам вчера посоветовал всё закинуть в LLM, чтобы она вам пояснила. Вы это сделали? Там еще был совет почитать книгу, но ее надо все же сначала а купить, а LLM доступны сразу.
Вы снова наступаете на одни и те же грабли. Вот часть ваших заблуждений только из этого сообщения (которые и объясняют провал внедрения):
Перечитайте манифест. Ну или спросите у ИИ в конце-то концов о минусах Agile и проблемах, которые могут материализоваться. Ну или поищете на Хабре, почему те или иные крупные компании отказывались от гибких методологий (были переводы, ссылки не сохранял). Замечу, большая часть того, что будет - относится к специфики методологии, а не к конкретной реализации.
Если после этого Вы не найдете того, что приводит к этой проблеме - у меня нет аргументов, человек видит в тексте только то, что он хочет.
Вчера уже сколько раз я делал акцент, что речь про исчерпывающую документацию, но вы этого в упор не замечаете и не понимаете, о чем речь, хотя разжёвано по несколько раз. Последняя попытка, может на английском понятнее: Working software over comprehensive documentation.
Комплексная документация (о которой говорит Брукс) является антипаттерном Agile. Так как она избыточная (с точки зрения решения конкретных задач) и не приносит пользы для заказчика (по крайней мере в ближайшей перспективе). Если Вы внимательно почитаете, то найдете много интересного. Как в материале, так и в манифесте.
И хватит ссылаться на манифест, вы все равно видите в нем только то, что хотите. Я читал его как в оригинале (до того, как его перевели), так и в переводе. Как и большую часть базовой литературы по гибким методологиям.
Вы просто не понимаете, что такое Agile. И, что более показательно, не хотите его понять, при том, что вам разные люди в комментариях пишут одинаковые вещи.
Заблуждение - может быть вполне у какого-то количества сторонников определенной точки зрения. Когда-то считали, что пить ртуть по определенной небесных тел - приведет к здоровью.
Для меня наличие в методологиях "белых пятен" не проявления гибкости, а проблема при её практическом применении. Если у вас другое мнение или вы не считаете это "белыми пятнами" - это Ваше мнение, Ваша правда и Ваш опыт (предполагаю, что человек ведущий такой долгий диалог должен обладать им). Но это не делает ни мое, ни ваше мнение - не правильным. Оно делает его разным, а итоги описанного мной - мы узнаем после того, как по командам практика будет применяться.
Сейчас же спор мне скорее напоминает "любой прием приводящий тебя к победе - является приемом каратэ" - можно утверждать, что это тоже часть Agile. Ведь не зря же методологии назвали "гибкими" (хотя их название исходит от гибкости для заказчика, а не разработчика).
Вы просто каждом новым комментариям оказываете медвежью услугу Тензору. После такой "презентации" внедрения процессов желающих идти к вам станет меньше. Никто не хочет работать в карго-культе, особенно, когда ответственные или приближенные к ним люди не слышат ничего, кроме своего личного мнения.
Простите, но я не считаю, что я "не слышу".
Например, мы с Вами дискутируем. Обмениваемся какими-то аргументами. Каждый со своей позицией. Если у Вас это взывает негативные эмоции - такое бывает, это Ваше право.
Я не отрицал нигде в материале, что возможно Вы (или какой-то из других комментаторов) - правы в каких-то своих утверждениях.
При этом, да, я придерживаюсь своей точки зрения. И это является нормальным. Она отстаивается мной до тех пор, пока не будет каких-то весомых аргументов, которые приведут к её изменению. Что в целом тоже логично и нормально.
Ни вы, ни я - не являемся специалистами по Agile-методологиям. Поэтому ни Ваше, ни моё мнение не может считаться каким-то весомым. Проще говоря - понимания ценностей, принципов и элементов Agile у нас с Вам отличается в уже понятных местах, но воспринимается по-разному и оценивается по-разному.
Ах, да. Про карго-культ странное сравнение. Как минимум, т.к. я ни в одном комментарии ни сказал, что "agile ни на что не годен" или "надо работать только по DF". Этот вывод был сделан Вами, после чего почему-то Вы решили опровергнуть то, чего не было ни в материале, ни в комментариях.
Ну, как бы дураку ясно, что для заказчика работающая фича важнее, чем документация.
Поэтому в режиме цейтнота, документация идёт в "технический долг".
Закрытие которого не станет важной для заказчика, пока стоимость реализации фич не станет критической (то есть исправление не станет полезным). Зачем до этого доводить и порождать большие операционные затраты, если можно сейчас затратить в разы меньше и не допустить этого?
Состав проектной документации и критерий её достаточности нигде не стандартизирован. Руководитель производства может своим решением включить документацию по конкретным решениям список необходимой проектной, и тогда множества, которые Вы назвали "достаточной" и "комплексной" документацией - полностью совпадут.
Конечно, руководитель проекта может включить любую документацию, но Agile не приветствует разработку комплексной. Так как это понижение пользы для заказчика в рамках текущего бюджета.
Прочитав Ваш комментарий, я перестал понимать в чём противоречие. Почему бы, например, не применять Alige и DF вместе как взаимодополняющие сущности?
Цель Agile (любой вариации) - это повышение гарантий заказчику получить то, что он хочет. Фактически, минимизацию рисков того, что исполнитель сделает не то (как он это сделает - Agile не регулирует, т.к. нет у него такой цели). В этом разрезе разработка комплексной документации противоречит целям заказчика, которые у него есть сейчас и при текущем бюджете.
DF же направлен на то, чтобы оптимизировать сам процесс разработки, фактически он нужен чтобы не допускать лишней работы и не потерять неявной важной работы. Перед тем как что-то будет сделано - требуется разработка комплексной документации решения (не только проектной). Т.е. по нему Вам придется зафиксировать для чего делать, что делать, как делать и как это предполагается использовать (если это переиспользуемая часть). И это "зафиксированное" должно пройти некое ревью, которое проверяет подход и полноту решения до цикла разработки. Таким образом Брукс предлагал уменьшать операционные затраты т.к. без этого есть риски оверинжиниринга, несостыковки на уровне интерфейсов, потерянной логики, неучтенных ограничений, появления лишней логики и т.п (собственно, при разработке ОС он и столкнулся со всеми этими проблемами сразу). Возможность рисков исходит из фундаментальной проблемы - неполноты информации, которая будет до тех пор, пока не появится некий источник комплексных знаний.
Справедливости ради, первое и второе является документацией по Agile (проектная документация), а вот последнее - не в полном объеме (т.к. требуется только достаточная для решения задачи документация). Решение по гибким методологиям может делаться раньше, чем будет разработана документация (лучший вариант для гибкой методологии - это написание документации в процессе реализации). По гибким методологиям считается в спринте не может быть более 5-10% времени отводится на разработку документации, DF же не ставит такого лимита. Предполагается, что издержки на формирование такой документации меньше, чем стоимость возможных рисков.
Да, DF не всегда оправдан. Скажем, если есть небольшая команда и работа идет по стартапу, то DF будет скорее мешать (он увеличивает время появления MVP, который сам заказчик ещё не представляет ещё каким должен быть). Когда же мы говорим о больших системах и\или уже существующем продукте, ошибки которого могут сказаться на издержках пользователей (а следовательно - продажах и прибыли), то анализ и проектирование всегда должны иметь материализованное выражение с измеримыми критериями и идти до реализации.
Собственно, в материале и говорится о том, что мы в точке конкретной проблемы (реализация проектного решения) стали применять DF, что не помешало продолжать над самими проектами сохранять гибкий подход, но привело к понижению операционных издержек.
Собственно, тред и масса комментариев связаны с тем, что евангелисты гибких методологий имеют свойство считать все, что приводит к позитивному эффекту или к самим agile-методологиям, или к свойствам команды (так как требования к ней сформулированы в виде не измеримых красивых идей, к которым можно прилепить любую положительно влияющую практику).
Не стоит придумывать выводы за автора, если они вам кажутся более удобными для отстаивания своей позиции :-)
Автор статьи исходит из ложной предпосылки, что в 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 тоже должна быть), а о документировании конкретного решения. Собственно последнее и делает из достаточной документации - комплексную.
Но автор очевидно смешал несколько разных уровней обсуждения — методологический, организационный и инженерный.
Это сделано намеренно. Любая практика или методология - просто инструмент. Он либо применяется по назначению, работает и т.п. или имеет проблемы.
Во-первых, Agile — не методология, а набор ценностей и принципов, из которых выросли конкретные фреймворки (Scrum, Kanban, XP и др.). Говорить о «провале Agile-методологий» некорректно — проблема не в Agile как идее, а в том, как его внедряют. Если команда показывает заказчику «div без стилей», это не издержка методологии, а отсутствие продуманного Definition of Done и нормального планирования.
Agile, в строгом смысле можно утверждать, что не является методологией - это "философия", с рядом ценностей. Методология выражается в фреймворках, которые реализуют эту философию. Поэтому и написано "agile-методологии".
Большая часть этого семейства (не готов говорить про все) будет иметь те же минусы. И любая команда, которая попытается внедрять - столкнется с белыми пятнами, которые должны быть заполнены на усмотрение команды. DF - один из способов заполнения.
В то же время, наличие белых пятен вполне объективная проблема "философии" и большей части фреймворков. Гибкие методологии ошибочно воспринимаются не как инструмент повышения гарантий заказчика, а как инструмент нормализации работы команды. А это разные цели.
Во-вторых, Documentation First сам по себе — не методология, а инженерная практика, усиливающая этап проектирования. Это вполне может быть частью Agile-процесса: никто не запрещает писать документацию перед кодом, если она помогает повысить осознанность и качество. Agile лишь предлагает не превращать документацию в самоцель, а держать баланс между скоростью и глубиной проработки.
Большую часть инженерных практик можно назвать методологией. Строго говоря, с точки зрения практической методология - это совокупность систематизированных приёмов и способов организации деятельности, применяемых в какой-либо области научного или практического знания. DF подходит под это определение, следовательно вполне может быть методологией. Либо дополняющей (если рассматривать DF как часть гибкового процесса), либо основной (если отмасштабировать, как предлагал Брукс, до масштаба проекта).
Agile занижает значимость документации и отдает на откуп решение проблемы неполноты информации исполнителю, так как цель таких (гибких) методологий - повышение гарантий\снижение рисков заказчика. И этот момент многие команды упускают. Проблема неполноты информации никуда не денется, операционные издержки от неё не решатся в процессе обсуждения (к сожалению). DF - способ оптимизации операционных затрат, один из. И тут тоже нет противоречия.
Идея Documentation First вполне здравая и может отлично работать в связке с гибкими фреймворками.
О чем даже есть в статье. Обозначены точки, где гибкость надо проявлять и в DF. Но при этом в статье нигде не написано то, что мы отказались от философии гибкости - мы за счет DF стали решать проблемы, где она не работает как инструмент (то есть, не решает наши проблемы - а их усугубляет по-факту).
Но было бы честнее говорить не о «возвращении к старым методологиям», а о восстановлении инженерной культуры внутри Agile-среды. Тогда статья звучала бы не как критика гибкости, а как призыв к осознанности и системности — чего сегодня действительно не хватает многим командам.
Agile-среда это уровень общения между заказчиком и исполнителем в первую очередь. Если выбросить красивые (и плохо работающие в реальном мире) идеи - это набор ценностей, которые делают "хорошо" заказчику и оставляют "за кулисами" работу команды. Это не плохо и тут нечего править - при общении с заказчиком надо его слушать и слышать, необходимо его погружать в проблемы (конечно, если они влияют на цену и\или скорость). Но без фанатизма.
Сам производственный процесс же должен строиться на упорядоченности, предсказуемости, осознанности и нацелен на конкретные результаты. И тут да, DF выглядит инструмент, который способен закрыть много проблем. Да, он должен идти в сочетании с гибкостью по отношению к работе с заказчиком, где-то для повышения увеличения "мобильности" самой цепочки производства. Но основой производственного процесса должен быть инженерный подход, а он прекрасно материализуется по правилам DF.
И да, статья - критика применения Agile для построения именно процесса разработки. На мой взгляд слишком большой уровень гибкости и отсутствие в философии ценностей, необходимых исполнителям (производственной цепочки) вызывает появление проблем. Особенно при работе над большими и сложными системами.
И именно вот эта критика и является призывом командам осознать цель гибких методологий и объективно взглянуть на свой производственный процесс, задуматься где и почему порождаются операционные издержки.
Типа облегчить задачу тому кто занимается этим самым микроменеджментом, чтобы он имел дело не с непонятным кодом или неправильно работающим продуктом, а с документом как это будет работать. И сделать это административно на уровне правил, чтобы это не выглядело как недоверие между коллегами....
Кода может быть в итоге решения много, его сложно проверить. Особенно при проверке самого подхода, архитектуры. То есть - проверка на уровне проектирования.
С другой стороны, разработка документации стимулирует еще раз сесть и подумать о решении. Это закономерно приводит к осознанию объемов, проблем и реальных сроков.
Вообще любой опытный разработчик договаривается на берегу прежде чем начинать делать. Или другая крайность - подход "победителей не судят". Когда сначала все криво, но если в конце то что надо, то и хорошо.
Договаривается - да. Не факт, что это решение наиболее эффективное. "На берегу" есть вероятность чего-то не учесть. И вот это состояние между "сначала что-то не то" и "в конце то, что надо" может занимать достаточно много ресурсов. Смотря от того на сколько "что-то не то" и из-за чего.
Ну так даже в передовой науке так - все новые открытия основываются на предыдущих научных работах, открытиях и явлениях. Тем не менее, что-то не слышно о попытках поставить научные открытия на конвеер.
Все же сравнивать научные открытия и разработку софта - не корректно. Сильно разная доля работы с неопределенностью.
Хотя, наука вполне себе тоже поддается "шаблонизации процесса", если мы говорим о доработках уже существующих технологий. Хоть и в куда гораздо меньше степени, чем разработка.
У вас есть проект условной многоэтажки для условий слабонесущего грунта в Питере. Есть склад с материалами и/или подрядчики, готовые их поставить в нужное время в нужном количестве.
Вам поступил заказ на постройку такой же многоэтажки. Но на скальном грунте в Карелии. Вы снарядите сваезабивную машину и полетите забивать сваи? Нет, вы будете менять проект, поскольку фундамент здания придется разрабатывать с нуля. После чего придется перерабатывать всю инженерку здания, поскольку технический подвал из-за изменений в конструкции фундамента будет отсутствовать.
И вот тут получается такая несуразица. Вроде и стеновые блоки те же. И остальные материалы. И финальный внешний вид продукта такой же. И даже потребительские качества один-в-один. А проектную документацию пришлось почти полностью перерабатывать с нуля. Как так получилось?
Вы затронули тему, которую я по работе не плохо помню (когда-то работал на внедрении учетных систем в строительных компаниях и у консалтеров). Проектная документация отличается, так как Вы будете её составлять под конкретные условия (тот же грунт), с учетом вариативности. Но творческого подхода тут не будет - это вполне себе конвеерная работа для отдела проектирования. Сборка документов из уже заранее известны блоков, по уже когда-то заготовленной информации и формулам расчета.
По крайней мере у застройщиков где я работал - были даже шаблоны документов и заготовки под регионы, где работали. Да, какая-то часть делалась полностью с нуля (заказчик захотел "уникальный" дизайн), а хороший % составлялся за счет пересчета кучи блоков. Но, отдел проектирования в этих компаниях был именно "заводом по производству проектной документации". Что-то "из ряда вон" требовалось очень редко, чаще всего даже не бралось в работу (плохо прогнозируемая прибыль).
Но это, возможно, не репрезентативная выборка.
Погодите, вы же только-только начали внедрение новой серебряной пули и уже нужно сдвигать сроки?
Во-первых, я нигде не говорил про серебряную пулю. Этот вывод был сделан Вами. Как и почему - это часть Вашего восприятия материала.
Во-вторых, в материале рассказывается об анализе проектов, которые уже сделаны\сданы. Сейчас DF применяется на новых объемах работ, т.е. чтобы не допустить того, что было ранее. Пока - успешно.
Вы определитесь, вы делаете что-то новое или просто повторяете что-то, что уже было сделано много раз. Если последнее, то зачем весь этот фестиваль, ведь можно просто взять уже имеющийся, отлаженный и проверенный временем продукт? В мире софта для этого даже конвеер строить не надо.
Видимо не понятно выразился - я не могу Вам даже сходу сказать ни одной задачи, которая была бы в разработке чего-то нового. Да, при разработке решения конкретной задачи пишется код, который решает какие-то задачи. Но сам по себе подход (если он выбран верно) вряд ли будет включать в себя что-то принципиально новое или исключительно. Продолжая метафору - у нас есть куча строительных блоков, из которых мы собираем нужное изделие. Если мы говорим о некоей большой системе - в ней скорее всего частично реализуемый процесс даже уже в какой-то части решен. То есть для современного разработчика творчество сместилось с написания кода (конкретной реализации - чаще всего типовой процесс) на применение инженерного подхода (поиск эффективной реализации в текущих условиях). Когда-то оба этих компонента разработки были творческими.
Посмотрите, простой пример. Для разработки небольшого сервиса раньше Вам требовалось решить множество задач - от реализации веб-сервера (да, я помню ещё такие проекты) и управления подключениями к БД, до бизнес-логики конкретного функционала. Сейчас большая часть этой работы рутинизирована (берем какой-нибудь Django\DRF+ORM+Redis). Происходит концентрация на той самой бизнес-логике, которая очень часто тоже является вполне типовой.
Я был неоднократным свидетелем и даже участником оглушительно успешного внердения скрам. Видел откровенно неудачные внедрения, впрочем, у этих неудач почти всегда оказывалось конкретное имя и фамилия. Успешные Waterfall тоже видел. С DF (кстати, почивший в начале 2000-х RUP есть этот самый DF, только вид сбоку) личная статистика другая - видел только провалы разной степени оглушительности.
Кстати, исходя из Вашей статьи (и картинки, которая должны была быть смешной), с внедрением agile у вас что-то конкретно не заладилось.
Аналогично, даже успешно внедрял SCRUM в ряде компаний. Где-то как team-lead, где-то как приходящий консультант. Но - не всегда гибкие методологии подходят.
Нет инструмента, который себя всегда показывает хорошо. Как нет и инструмента, который однозначно себя покажет всегда плохо. К применению чего-либо надо подходить всегда с осознанием ограничений, требований и имеющегося окружения.
Почему именно у нас полноценно не получилось внедрить... быть может соберусь с духом и напишу об ограничениях, которые явно мешают внедрению гибких методологий. Сейчас они уже понятны, но в начале - было не очевидно.
Кстати, есть еще одна вещь, которую тут пока еще не обсуждали: скорее всего, самые лучшие ваши разработчики (те самые, которые вытягивали предыдущие проекты, спасая горящие дедлайны) находятся уже в процессе выбора нового оффера.
Ошибаетесь. Удалось за счет того, что в компании организована хорошая коммуникация с заказчиком, который готов был слышать о сдвигах сроков и давать корректировки по результатам - коллектив стабильно сохраняется уже очень долгое время, текучки у нас нет.
Поиск методов оптимизации мы начали для того, чтобы сделать для самих себя течение проектов более предсказуемыми (это упрощает запуск новых проектов), сократить ресурсы на поддержку (очевидно, что хорошая документация - способна этому помочь) и делать больше полезного в те же временные коридоры (плюс\минус Road Map развития известен, хочется - двигаться по нему быстрее).
Красивая идея, на уровне лозунга.
Есть бизнес-потребность. Она выражена в виде конечного результата. При её декомпозиции на задачи для разработки есть риски потери каких-то моментов из-за проблемы неполноты информации (в реальном мире она не будет полной).
Чтобы уменьшать этот риск Брукс предложил DF. Собственно - в точках, где это надо мы его и применили. Чтобы "мутные задачи" стали понятными и полными.
Тут скорее вопрос - как при гибком подходе в целом обеспечить понимание комплексное задачи. Большинство случаев, когда люди не понимают - они утверждают, что "все понятно". Часто в больших системах задача в первых приближениях кажется проще, чем есть на самом деле.
DF как раз позволяет систематизировать знания, работу над анализом и проектированием, дает проверяемый результат.
Есть
У нас для документации свое решение.
Agile - философия, поэтому в тексте идет "agile-семейств", т.е. подразумевается комплекс фреймворков, которые реализуют философию.
Почти любой гибкий фреймиворк будет содержать какое-то количество не описанных мест, которые отдаются на усмотрение самой команды. И да, при внедрении отсутствие конкретных методологических указаний - является проблемой с точки зрения "бери и применяй". Почему так сделано понятно - цель гибких методологий увеличение выгода заказчика, не команды. И тут команде дается возможность в рамках поставленных гибких ценностей выбрать методы построения производственного процесса.
Материал как раз о том, что из различных вариаций - мы выбрали DF и почему.
Откуда такие странные выводы?
В приведенном примере с Васей, проблема не в понимании "ответственности в Agile". Есть реальная жизнь - в ней программист решает проблему и несет ответственность за результат того, что он делает. И это так вне зависимости какую методологию использует команда.
И да, в реальной жизни условный Вася может вполне "забить" на ответственность. В большей части компаний, которые мне известны - малое число разработчиков на самом деле готовы отвечать за результат. И это может привести к описанным проблемам. Но я пришел, к выводу - это не тот случай. Как относиться к этому выводу - Ваша субъективная оценка.
В материале и комментариях я изложил свое субъективное мнение на счет гибких методологий. Мнения у нас разошлись - это нормально, такое тоже бывает. Но не дает Вам возможность утверждать.
Странно делать выводы об распределении ответственности, когда у Вас нет ни явных, ни косвенных признаков.
Как-то так)
Или включить эту задачу в процесс производства, обосновав для заказчика это прогнозами издержек через Н времени.
Еще раз, я прекрасно понимаю какие проблемы Вам пришли в голову. Все эти вопросы были первыми на которые мы отвечали при анализе.
В рамках нашего масштаба (в нашем случае) пока лучше результаты показал именно подход DF (не отказ полный от гибкости, а применение в проблемной точки DF).
Да, и вот мы для себя поняли в каких конкретных точках стоит перестать быть "гибкими" и надо использовать что-то более "бюракратическое". На мой взгляд именно "микс" идей всегда более жизнеспособен. Не будем далеко ходить - Python микс идей с точки зрения языков, он куда более применим в реальных задачах, чем "чистые" языки.
Если мы говорим про несостоятельность Agile как концепции, то конечно, надо понимать в разрезе чего. Но такой мысли в материале нет. Но название с одной стороны изначально и хотелось сделать более "спорным", чтобы люди вышли на диалог. В спорах - часто можно найти что-то важное. Чему-то научиться. Хотя бы даже риторике.
Возможно. Но исходя из комментариев - люди видят то, что хотят. И кому-то даже такой тезис не понравится.
Благодарю и Вас! Буду стараться что-то находить из своей практики интересное и полезное, публиковаться. Сам получаю удовольствие от этого)
По-русский это называется проблема неполноты информации, фундаментальная проблема.
Да, в статье и комментариях я подсветил точки в гибких методологиях, где это проблема проявляется и почему в рамках них мы не смогли найти решения. Почему взяли DF и получили положительный тренд.
Ни в статье, ни в комментариях не было утверждения об отказе в-принципе от гибких методах (кроме конкретных точек, где сейчас мы пробуем для себя внедрение DF). Как не было и того, что DF должен быть использован как единственный инструмент или является какой-то серебряной пулей.
Просто почему-то комментаторы решили, что "с гибким подходом в этой точке мы не смогли решить проблему" равно "гибкие методологии не работают". То есть фактически материал о том, какое решение мы нашли для себя, не переходя на "водопад" или что-то иное.
В идеальном мире, да - все верно. И если Вы работаете с системой такого размера, что весь функционал (даже смежный) всегда однозначно известен всем. Но в реальном мире такое тоже не всегда бывает (пример из жизни про сборки SPA где-то в комментариях я приводил).
В материале и комментариях уже есть ответ на вопрос, почему такая ситуация может возникнуть. И как раз DF решает эти проблемы.
Ну так в материале и описывается то, что мы в итоге выбрали и начали применять как улучшение процесса. То, что не заработало хорошо и частично - просто осталось за рамками материала.
Да, но - без достаточно комплексной документации, важная для продукта (а не для задачи) часть может быть упущена.
На большую часть вопросов - ответ очевиден по материалу. Он исходит из того, что у нас есть возможность выбирать какие-то подходы, предлагать решения и т.п.
Но, статья не тех проблемах, которые Вам в данном случае хочется найти. Она об желании оптимизировать операционные издержки путем применения DF. Причины их появления тоже уже не раз обозначены.
Если это касается фичи - да. Но доработка может повлечь к проблемам (но не обязан, да), которые не касаются фичи напрямую. И решение этих проблем мог не закладывать исполнитель (он мог о них и не знать.).
Перечитайте манифест. Ну или спросите у ИИ в конце-то концов о минусах Agile и проблемах, которые могут материализоваться. Ну или поищете на Хабре, почему те или иные крупные компании отказывались от гибких методологий (были переводы, ссылки не сохранял). Замечу, большая часть того, что будет - относится к специфики методологии, а не к конкретной реализации.
Если после этого Вы не найдете того, что приводит к этой проблеме - у меня нет аргументов, человек видит в тексте только то, что он хочет.
Комплексная документация (о которой говорит Брукс) является антипаттерном Agile. Так как она избыточная (с точки зрения решения конкретных задач) и не приносит пользы для заказчика (по крайней мере в ближайшей перспективе). Если Вы внимательно почитаете, то найдете много интересного. Как в материале, так и в манифесте.
И хватит ссылаться на манифест, вы все равно видите в нем только то, что хотите. Я читал его как в оригинале (до того, как его перевели), так и в переводе. Как и большую часть базовой литературы по гибким методологиям.
Заблуждение - может быть вполне у какого-то количества сторонников определенной точки зрения. Когда-то считали, что пить ртуть по определенной небесных тел - приведет к здоровью.
Для меня наличие в методологиях "белых пятен" не проявления гибкости, а проблема при её практическом применении. Если у вас другое мнение или вы не считаете это "белыми пятнами" - это Ваше мнение, Ваша правда и Ваш опыт (предполагаю, что человек ведущий такой долгий диалог должен обладать им). Но это не делает ни мое, ни ваше мнение - не правильным. Оно делает его разным, а итоги описанного мной - мы узнаем после того, как по командам практика будет применяться.
Сейчас же спор мне скорее напоминает "любой прием приводящий тебя к победе - является приемом каратэ" - можно утверждать, что это тоже часть Agile. Ведь не зря же методологии назвали "гибкими" (хотя их название исходит от гибкости для заказчика, а не разработчика).
Простите, но я не считаю, что я "не слышу".
Например, мы с Вами дискутируем. Обмениваемся какими-то аргументами. Каждый со своей позицией. Если у Вас это взывает негативные эмоции - такое бывает, это Ваше право.
Я не отрицал нигде в материале, что возможно Вы (или какой-то из других комментаторов) - правы в каких-то своих утверждениях.
При этом, да, я придерживаюсь своей точки зрения. И это является нормальным. Она отстаивается мной до тех пор, пока не будет каких-то весомых аргументов, которые приведут к её изменению. Что в целом тоже логично и нормально.
Ни вы, ни я - не являемся специалистами по Agile-методологиям. Поэтому ни Ваше, ни моё мнение не может считаться каким-то весомым. Проще говоря - понимания ценностей, принципов и элементов Agile у нас с Вам отличается в уже понятных местах, но воспринимается по-разному и оценивается по-разному.
Ах, да. Про карго-культ странное сравнение. Как минимум, т.к. я ни в одном комментарии ни сказал, что "agile ни на что не годен" или "надо работать только по DF". Этот вывод был сделан Вами, после чего почему-то Вы решили опровергнуть то, чего не было ни в материале, ни в комментариях.
Закрытие которого не станет важной для заказчика, пока стоимость реализации фич не станет критической (то есть исправление не станет полезным). Зачем до этого доводить и порождать большие операционные затраты, если можно сейчас затратить в разы меньше и не допустить этого?
Конечно, руководитель проекта может включить любую документацию, но Agile не приветствует разработку комплексной. Так как это понижение пользы для заказчика в рамках текущего бюджета.
Цель Agile (любой вариации) - это повышение гарантий заказчику получить то, что он хочет. Фактически, минимизацию рисков того, что исполнитель сделает не то (как он это сделает - Agile не регулирует, т.к. нет у него такой цели). В этом разрезе разработка комплексной документации противоречит целям заказчика, которые у него есть сейчас и при текущем бюджете.
DF же направлен на то, чтобы оптимизировать сам процесс разработки, фактически он нужен чтобы не допускать лишней работы и не потерять неявной важной работы. Перед тем как что-то будет сделано - требуется разработка комплексной документации решения (не только проектной). Т.е. по нему Вам придется зафиксировать для чего делать, что делать, как делать и как это предполагается использовать (если это переиспользуемая часть). И это "зафиксированное" должно пройти некое ревью, которое проверяет подход и полноту решения до цикла разработки. Таким образом Брукс предлагал уменьшать операционные затраты т.к. без этого есть риски оверинжиниринга, несостыковки на уровне интерфейсов, потерянной логики, неучтенных ограничений, появления лишней логики и т.п (собственно, при разработке ОС он и столкнулся со всеми этими проблемами сразу). Возможность рисков исходит из фундаментальной проблемы - неполноты информации, которая будет до тех пор, пока не появится некий источник комплексных знаний.
Справедливости ради, первое и второе является документацией по Agile (проектная документация), а вот последнее - не в полном объеме (т.к. требуется только достаточная для решения задачи документация). Решение по гибким методологиям может делаться раньше, чем будет разработана документация (лучший вариант для гибкой методологии - это написание документации в процессе реализации). По гибким методологиям считается в спринте не может быть более 5-10% времени отводится на разработку документации, DF же не ставит такого лимита. Предполагается, что издержки на формирование такой документации меньше, чем стоимость возможных рисков.
Да, DF не всегда оправдан. Скажем, если есть небольшая команда и работа идет по стартапу, то DF будет скорее мешать (он увеличивает время появления MVP, который сам заказчик ещё не представляет ещё каким должен быть). Когда же мы говорим о больших системах и\или уже существующем продукте, ошибки которого могут сказаться на издержках пользователей (а следовательно - продажах и прибыли), то анализ и проектирование всегда должны иметь материализованное выражение с измеримыми критериями и идти до реализации.
Собственно, в материале и говорится о том, что мы в точке конкретной проблемы (реализация проектного решения) стали применять DF, что не помешало продолжать над самими проектами сохранять гибкий подход, но привело к понижению операционных издержек.
Собственно, тред и масса комментариев связаны с тем, что евангелисты гибких методологий имеют свойство считать все, что приводит к позитивному эффекту или к самим agile-методологиям, или к свойствам команды (так как требования к ней сформулированы в виде не измеримых красивых идей, к которым можно прилепить любую положительно влияющую практику).
Не стоит придумывать выводы за автора, если они вам кажутся более удобными для отстаивания своей позиции :-)
Где я утверждал, что Agile дает скорость? По первому, будем исходить из манефеста, а не Вашего понимания Agile (это как минимум уже какое-то восприятие, искажающее идеи опытом):
По Agile, документация менее важна, чем работающая фича. И в случае выбора - заказчик будет выбирать фичу. Т.е. в среднем по больнице в большем количестве случаев.
В Agile нет критериев качества документации, как и требования документировать решение до выполнения задачи.
Комплексная документация является потерянным артефактом в разрезе Agile, так как она не представляет высокой ценности для заказчика.
По гибким методологиям документация должна быть достаточной для решения конкретной задачи, т.е. вполне может не включать большое количество важного, т.к. это касается продукта в целом и относится к опциальными (вместе с описанием архитектуры модулей, временными решениями, очевидными вещами).
Плюс - Agile не предполагает документирование решения до его разработки, она должна писаться just-in-time в достаточном для понимания решения виде.
В целом, разработка документации в спринте не может занимать более 5-10 процентов. Это исключает включать в спринт разработку комплексной документации без написания кода.
Agile не про то, что надо писать хорошо - он про то, что надо делать так, как нужно заказчику. Качество кода как раз является ответственностью команды, которую она должна нести из идеологических причин (те самые красивые идеи).
Тесты, парное программирование, документация - это все должно быть, но их качество остается на "совести" исполнителя. Ценности по этим императивам не имеют измеримого результата (в отличии от частей, касающихся заказчика) - актуальность, доступность, полезность и поддерживаемость. И при этом - они не должны увеличивать общую стоимость проекта, пусть и в ущерб будущим операционным затратам.
Цель Agile - не получение качественного с инженерной точки зрения продукта, а получение в рамках текущего бюджета максимальной выгоды (удовлетворенности) заказчика.
DF как и любой инструмент требуется внедрять в рабочий процесс. И не только потому, что в типовой команде уровень сотрудников разный. А потому, как точки контроля результатов любого инструмента должны быть определены и являться частью общей цепочки. Тут - если документация должна быть написана до написания кода, то требуется этот процесс "шаблонизировать", интегрировать в применяемые инструменты, процессы.
Есть. Как минимум в том, что ценность комплексной документации ниже работающего кода и он может быть получен без документации вообще. И при применении Agile-методологий чаще всего она появляется в процессе написания кода или вообще после него.
DF/RDD предполагает документацию до написания кода. То есть перед тем как задача будет выполнять проводится глубокий анализ и проектирование, которые обязательно проходят ревью (чего не требует Agile, кстати).
Но да, DF/RDD может легко интегрироваться в любую гибкую методологию потому, что - это как раз те "белые пятна", которые определяет сама команда. И суть в том, что можно повысить требования к документацию и поменять местами документацию и разработку местами при решении конкретной задачи. И как итог - получить решение многих проблем, которые будут возникать в реальных команда. А не "идеальных", которые все одного уровня, одинаково мотивированы и так далее.
Нет DF внутри Agile. Сам по себе DF противоречит местами манифесту, причем достаточно существенно. Но ввиду плюсов от DF - это не существено.
Если же мы имеем нечто, что является свойством только "зрелой" команды (на самом деле, в описанных в манифестве качествах - это идеальная ситуация, да ещё и без измеримых критериев), то это уже не часть методологии. Так ка это уже "творчество" команды, которая просто заполняет "белое пятно".
Где вы видите эти выводы? Я говорю о том, что они совместимы и даже в комментариях не раз говорил, что мы сохранили гибкие подходы, но при этом начали использование DF.
Базовая же инженерная практика - какая именно? Вы много раз назвали этот термин. Если вы прод документирование конкретного решения конкретной задачи - так оно по гибким методологиям менее ценно, чем работающий код. Обратите внимание, в статье поднимается проблема не отсутствия проектной документации (и да, она по Agile тоже должна быть), а о документировании конкретного решения. Собственно последнее и делает из достаточной документации - комплексную.
Спасибо за отзыв.
Это сделано намеренно. Любая практика или методология - просто инструмент. Он либо применяется по назначению, работает и т.п. или имеет проблемы.
Agile, в строгом смысле можно утверждать, что не является методологией - это "философия", с рядом ценностей. Методология выражается в фреймворках, которые реализуют эту философию. Поэтому и написано "agile-методологии".
Большая часть этого семейства (не готов говорить про все) будет иметь те же минусы. И любая команда, которая попытается внедрять - столкнется с белыми пятнами, которые должны быть заполнены на усмотрение команды. DF - один из способов заполнения.
В то же время, наличие белых пятен вполне объективная проблема "философии" и большей части фреймворков. Гибкие методологии ошибочно воспринимаются не как инструмент повышения гарантий заказчика, а как инструмент нормализации работы команды. А это разные цели.
Большую часть инженерных практик можно назвать методологией. Строго говоря, с точки зрения практической методология - это совокупность систематизированных приёмов и способов организации деятельности, применяемых в какой-либо области научного или практического знания. DF подходит под это определение, следовательно вполне может быть методологией. Либо дополняющей (если рассматривать DF как часть гибкового процесса), либо основной (если отмасштабировать, как предлагал Брукс, до масштаба проекта).
Agile занижает значимость документации и отдает на откуп решение проблемы неполноты информации исполнителю, так как цель таких (гибких) методологий - повышение гарантий\снижение рисков заказчика. И этот момент многие команды упускают. Проблема неполноты информации никуда не денется, операционные издержки от неё не решатся в процессе обсуждения (к сожалению). DF - способ оптимизации операционных затрат, один из. И тут тоже нет противоречия.
О чем даже есть в статье. Обозначены точки, где гибкость надо проявлять и в DF. Но при этом в статье нигде не написано то, что мы отказались от философии гибкости - мы за счет DF стали решать проблемы, где она не работает как инструмент (то есть, не решает наши проблемы - а их усугубляет по-факту).
Agile-среда это уровень общения между заказчиком и исполнителем в первую очередь. Если выбросить красивые (и плохо работающие в реальном мире) идеи - это набор ценностей, которые делают "хорошо" заказчику и оставляют "за кулисами" работу команды. Это не плохо и тут нечего править - при общении с заказчиком надо его слушать и слышать, необходимо его погружать в проблемы (конечно, если они влияют на цену и\или скорость). Но без фанатизма.
Сам производственный процесс же должен строиться на упорядоченности, предсказуемости, осознанности и нацелен на конкретные результаты. И тут да, DF выглядит инструмент, который способен закрыть много проблем. Да, он должен идти в сочетании с гибкостью по отношению к работе с заказчиком, где-то для повышения увеличения "мобильности" самой цепочки производства. Но основой производственного процесса должен быть инженерный подход, а он прекрасно материализуется по правилам DF.
И да, статья - критика применения Agile для построения именно процесса разработки. На мой взгляд слишком большой уровень гибкости и отсутствие в философии ценностей, необходимых исполнителям (производственной цепочки) вызывает появление проблем. Особенно при работе над большими и сложными системами.
И именно вот эта критика и является призывом командам осознать цель гибких методологий и объективно взглянуть на свой производственный процесс, задуматься где и почему порождаются операционные издержки.
Кода может быть в итоге решения много, его сложно проверить. Особенно при проверке самого подхода, архитектуры. То есть - проверка на уровне проектирования.
С другой стороны, разработка документации стимулирует еще раз сесть и подумать о решении. Это закономерно приводит к осознанию объемов, проблем и реальных сроков.
Договаривается - да. Не факт, что это решение наиболее эффективное. "На берегу" есть вероятность чего-то не учесть. И вот это состояние между "сначала что-то не то" и "в конце то, что надо" может занимать достаточно много ресурсов. Смотря от того на сколько "что-то не то" и из-за чего.
Все же сравнивать научные открытия и разработку софта - не корректно. Сильно разная доля работы с неопределенностью.
Хотя, наука вполне себе тоже поддается "шаблонизации процесса", если мы говорим о доработках уже существующих технологий. Хоть и в куда гораздо меньше степени, чем разработка.
Вы затронули тему, которую я по работе не плохо помню (когда-то работал на внедрении учетных систем в строительных компаниях и у консалтеров). Проектная документация отличается, так как Вы будете её составлять под конкретные условия (тот же грунт), с учетом вариативности. Но творческого подхода тут не будет - это вполне себе конвеерная работа для отдела проектирования. Сборка документов из уже заранее известны блоков, по уже когда-то заготовленной информации и формулам расчета.
По крайней мере у застройщиков где я работал - были даже шаблоны документов и заготовки под регионы, где работали. Да, какая-то часть делалась полностью с нуля (заказчик захотел "уникальный" дизайн), а хороший % составлялся за счет пересчета кучи блоков. Но, отдел проектирования в этих компаниях был именно "заводом по производству проектной документации". Что-то "из ряда вон" требовалось очень редко, чаще всего даже не бралось в работу (плохо прогнозируемая прибыль).
Но это, возможно, не репрезентативная выборка.
Во-первых, я нигде не говорил про серебряную пулю. Этот вывод был сделан Вами. Как и почему - это часть Вашего восприятия материала.
Во-вторых, в материале рассказывается об анализе проектов, которые уже сделаны\сданы. Сейчас DF применяется на новых объемах работ, т.е. чтобы не допустить того, что было ранее. Пока - успешно.
Видимо не понятно выразился - я не могу Вам даже сходу сказать ни одной задачи, которая была бы в разработке чего-то нового. Да, при разработке решения конкретной задачи пишется код, который решает какие-то задачи. Но сам по себе подход (если он выбран верно) вряд ли будет включать в себя что-то принципиально новое или исключительно. Продолжая метафору - у нас есть куча строительных блоков, из которых мы собираем нужное изделие. Если мы говорим о некоей большой системе - в ней скорее всего частично реализуемый процесс даже уже в какой-то части решен. То есть для современного разработчика творчество сместилось с написания кода (конкретной реализации - чаще всего типовой процесс) на применение инженерного подхода (поиск эффективной реализации в текущих условиях). Когда-то оба этих компонента разработки были творческими.
Посмотрите, простой пример. Для разработки небольшого сервиса раньше Вам требовалось решить множество задач - от реализации веб-сервера (да, я помню ещё такие проекты) и управления подключениями к БД, до бизнес-логики конкретного функционала. Сейчас большая часть этой работы рутинизирована (берем какой-нибудь Django\DRF+ORM+Redis). Происходит концентрация на той самой бизнес-логике, которая очень часто тоже является вполне типовой.
Аналогично, даже успешно внедрял SCRUM в ряде компаний. Где-то как team-lead, где-то как приходящий консультант. Но - не всегда гибкие методологии подходят.
Нет инструмента, который себя всегда показывает хорошо. Как нет и инструмента, который однозначно себя покажет всегда плохо. К применению чего-либо надо подходить всегда с осознанием ограничений, требований и имеющегося окружения.
Почему именно у нас полноценно не получилось внедрить... быть может соберусь с духом и напишу об ограничениях, которые явно мешают внедрению гибких методологий. Сейчас они уже понятны, но в начале - было не очевидно.
Ошибаетесь. Удалось за счет того, что в компании организована хорошая коммуникация с заказчиком, который готов был слышать о сдвигах сроков и давать корректировки по результатам - коллектив стабильно сохраняется уже очень долгое время, текучки у нас нет.
Поиск методов оптимизации мы начали для того, чтобы сделать для самих себя течение проектов более предсказуемыми (это упрощает запуск новых проектов), сократить ресурсы на поддержку (очевидно, что хорошая документация - способна этому помочь) и делать больше полезного в те же временные коридоры (плюс\минус Road Map развития известен, хочется - двигаться по нему быстрее).