Обсуждение

А в чём разница между "модульными" и "компонентными" описаниями?

Более-менее подробно у меня это в учебнике прописано (хотя там модульных диаграмм я не привёл, по забывчивости) -- http://techinvestlab.ru/systems_engineering_thinking Вот тут про это есть https://www.youtube.com/watch?v=jDgGohE-_qs, и вот тут https://www.youtube.com/watch?v=y5Th_7aVMl4, и на слайдах вот тут немножко: http://www.slideshare.net/ailev/alevenchuk-complexity-in-engineering

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

А можно как-то компактно, без изучения не относящихся к делу материалов? Я бы в двух словах так сказал, переводя ваши же слайды и используя жизненный опыт: модуль = рассмотрение элемента системы с точки зрения отношения "часть-целое", элемент компактной организации системы. компонент = описание элемента системы с точки зрения логического описания его функциональности ("делает то"), элемент компактного описания функциональности системы. Теперь, пытаюсь осмыслить в контексте этого ваше понимание "product backlog". В Scrum: "Product Backlog Product Backlog - это приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе. Product Backlog включает в себя use cases, defects, enhancements, technologies, stories, features, issues, и т.д.. Product backlog также включает задачи, важные для команды, например "провести тренинг", "добить всем памяти" Backlog содержит ссылки и на модули, и на компоненты. Он включает в себя и user stories, и use cases, и issues. Каким же образом вы его противопоставляете narrative? (Который, в свою очередь, всего лишь является линейной записью user stories / use cases / issues, вместо нагруженно-сетевой структуры product backlog) И то, и другое, ничего не говорит ни про модули, ни про компоненты. Система и там и там вполне может описываться и в терминах "что делает" и "из чего состоит". (И кстати, никакой User Story Mapping не заставляет реализовывать систему, полностью повторяя метафоры заказчика -- просто рассматривайте подобные процедуры как способ выжать из заказчика максимум информации, не делая его мозгам больно) P.S. И уж кто бы говорил про использование стандартного языка, увлекаясь слово- и термино-творчеством ("многерица", "смычка")

Вот именно из-за "компактно, без изучения не относящихся к делу материалов" и происходит путаница. Компоненты и модули -- это части воплощения системы. А всякие описания -- это описания системы. Они могут быть, и чаще всего бывают, гибридными (содержащими и описания компонент, и описания модулей). Модули и компоненты чаще всего соотносятся в технических системах как 1:1, но это не всегда соблюдается. И так далее, и так далее... "Многерица" и "смычка" у меня, кстати, ни разу не термины. И стандартный язык -- я не понимаю, что такое. Например, у Косякова сотоварищи в учебнике модули-по-Гарлану-сотоварищи называются компонентами, зато компоненты-по-Гарлану-сотоварищи называются функциональными элементами. В ТРИЗ+ компоненты обсуждаются явно, а для модулей вообще нет специального названия (хотя там центральная идея именно модульный синтез!). К словам я не придираюсь, у меня заход совсем другой. Так что разобраться с этим клубком разных приёмов мышления быстро-быстро в режиме комментов не получится. У меня на эту часть обычно двухдневный тренинг идёт, и даже за два дня людям трудно освоить этот материал. Ибо каждая одна идея проста, но их некоторое количество нужно освоить, а вот сочетания уже не так просты, и в реальном мире эта теория не сразу бросается в глаза (например, "физическое тело" -- сам концепт не такой простой, если просто стоять где-нибудь посреди болота и пытаться найти вокруг "физические тела").

Что-то листаю ваши слайды, там понятия "компонент" и "модуль" гуляют как хотят. Layered organization вы зачем-то смешиваете с модульностью (хотя layer из 7-layered OSI scheme никакого чёрного ящика с интерфейсом не подразумевает -- это логическая схема, а не физическая), а на электронной схеме у вас почему-то располагаются "электронные модули". Дальше, в ИТ "module" -- независимо размещённый компонент (а не независимо сконструированный!). Итого, module -- это подмножество понятия "компонент/компонента", которое указывает на отдельное физическое размещение данного компонента. "Black-boxes with functions, available via interfaces" -- это "блок". По-английски, я бы это перевёл это использование как "component". Но не "module", потому что не факт, что эти black-boxes являются независимо размещаемыми. Вы можете на это возразить, что black-box не может состоять из других black-box, также как и module не пересекаются друг с другом. На это я отвечу, что а) black-box -- временная абстракция, её можно добавлять и убирать, система от этого не меняется. Поэтому, что в рамках одного описания является black-box, в рамках другого описания не будет им являться -- составляя ту или другую иерархию. b) module может состоять из других module, образуя "модульную организацию". с) это свойство "не самопересекаемость" не является ключевым свойством понятия "module". Да и вообще, путаница между этими всеми понятиями возникает из-за небрежности в использовании всех этих понятий, и как следствие, в силу разницы их коннотаций в сознании разных людей. Нужно ли ввести строгие различия между данными понятиями? Вопрос открыт, но я сомневаюсь, что у вас или кого-либо ещё получится это сделать. Разве что всем мозг перепрошить. Потому что нету точного объёма ни у одного из этих понятий. А теперь подумайте, как смотрится теперь ваше небрежное "да тут разница как между компонентами и модулями, че, так трудно что-ли всем это один раз рассказать" в этом посте, когда оба понятия не имеют точного объёма. Да, очень трудно всем рассказать, если даже одному человеку не получается взять и в двух словах рассказать, а приходится объяснять на примерах: "вот это модули на этой схеме, а вот на этой компоненты".

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

Мы недавно обсуждали этот вопрос про модули и компоненты на заседании русского отделения INCOSE -- http://incose-ru.livejournal.com/53586.html C целевой системой vs. обеспечивающей системой те же трудности в определении и понимании. Эти все понятия "становятся", этот процесс становления предметной области занимает время. Конечно, у понятий естественного языка у всех дребезг в их значениях -- на то он и естественный язык, а не формальный. Но замечать похожие рассуждения в разных предметных областях, даже если они выражены очень разными словами -- это не только сухие нейронные сетки умеют, но и мокрые ;) Мозг перепрошить всем не получится, конечно, но мои ученики демонстрируют неплохую прыткость в рассуждениях об инженерных проектах в целом -- по сравнению с не моими учениками сходной степени образованности и подготовки. И это "выученное", а не просто проявленные природные способности.

Определённости словам в языке мало что добавит. Это так даже в математике (например, якобианом называют то определитель, то саму матрицу -- https://ru.wikipedia.org/wiki/%D0%AF%D0%BA%D0%BE%D0%B1%D0%B8%D0%B0%D0%BD). Agile IMHO (как и многие другие инженерии) потихоньку бредёт к принятию системного подхода. При этом, конечно, и сам системный подход тоже потихоньку меняется, развивается. В учебничке, я думаю, вы уже прочли, что различение модульного и компонентного разбиений системы уже есть (хотя и в чуть разной терминологии) в большинстве инженерных подходов и зафиксировано в самой разной литературе. Agile начинал с совместного инженерного и менеджерского рассмотрения, потом ушёл на чисто менеджерские (http://ailev.livejournal.com/1183548.html). Но от инженерных-то задач не уйдёшь! Конечно, и product backlog и user story map это какие-то гибридные описания: в явном виде в agile на этом уровне архитектурной работы и планирования работ не различают модули и компоненты и не обсуждают их соответствие друг другу. Тем не менее, как я написал в посте, есть два разных разговора: один из них про "из чего будет состоять наш продукт, как его мы будем делать" -- и так формируется product backlog. При этом, конечно, по определению меньше внимания уделяется вопросу "из чего будет состоять наш продукт, чтобы он работал" -- и дальше там нужно обсуждать интерфейсы и модули. И вот для этого и используется прежде всего user story map и сдвижка в DDD. Это функциональные описания, функциональные требования. И мне кажется, что если это недоговаривать, то product backlog и user story map будут одними и теми же гибридными карточками, только немного по-разному перетасованными. Но цель-то у авторов user story map и DDD другая, обсудить они хотели бы другие вопросы! Поэтому я и сожалею, что они прямо не говорят о двух разных видах описаний. Конечно, эти два вида описаний только самое начало. Ещё есть размещение, ещё есть различение в описании вещей (objects) и связанных с ними изменений (activities), есть описание сигналов, но это всё потом. Надо начать хотя бы с различения FunctionalPhysicalObject и Inanimate PhysicalObject (если в терминах ISO 15926 -- это разделение ведь практически везде в инженерии есть). Дальше можно было бы возвращаться к обсуждению backlog и говорить, что там объекты предпочтительно другого типа, нежели в user story map. И в user story map предпочтительно другого типа. Но соотношение между ними может быть 1:1, и названия похожи, так что разницу мало кто заметит. И user story map может хитрым образом переходить на какую-нибудь kanban доску, где тот же product backlog уже. Гибридность использования user story должна быть обсуждена явно, это нормальное архитектурное обсуждение. Когда речь идёт о сложных инженерных задачах, разделение функционального и физического обсуждения становится общим местом. И требование задержки обсуждения на функциональном перед тем как начинать обсуждать физическое тоже становится общим местом. User story map всё это делает, но больше "интуитивно" и без особого объяснения, почему ими предлагаемое решение вдруг хорошо работает. Вот вы требуете какой-то определённости и формализма, но поглядите, насколько отсутствует формализм в описаниях user story map и как тщательно явно оговаривается, что никакого там формализма нет! Ибо почему-то осмысление и точная терминология кажутся лидерам agile чем-то стесняющим творчество. Ну, увы.

Вы неправильно определяете цель user stories и DDD. Этим подходом решается проблема вытащить требования и описания в максимально возможном объёме на естественном языке и поддерживать их (что часто является серьёзной проблемой), а не использовать эти понятия для конструирования системы. Поэтому не должно быть соответствия 1-к-1 между user stories и полученной системой. Любая дополнительная формализация тут будет вредить, потому что формализация так или иначе завязывается на реализацию или какие-то абстрактные понятия и потом мешает эти понятия сменить. Ведь если использовать эти понятия -- то придётся в электронном радио вводить "ручку настройки частоты радио" только потому что она была в обычном радио. В этом нет смысла. Но в том, чтобы детально понимать, какие проблемы хочет решить заказчик и как он их решает сейчас, и не заставлять его говорить в терминах реализации, смысл есть. В DDD цитируется Patton: "Story mapping keeps us focused on users and their experience, and the result is a better conversation". (опущу часть про продукт). Понимаете? Практика заставляет поддерживать два разных языка. Один внутренний для реализации системы, один для более глубокого понимания заказчика. Языки разные, т.к. цели у них разные. Более того, в большой профессиональной команде, где я работал давным давно, были отдельно "business analyst" и "system analyst" и имели они дело каждый со своим языком. Я считаю это хорошей практикой.

Я вполне это всё понимаю, и про "язык" тоже. Обратите внимание, я всё время подчёркиваю, что описывается использующая система главным образом, и её терминология. А то, что требования стейкхолдеров и требования к системе это разные требования -- это, вроде, понятно и обжалованию не подлежит. И чем user story от use case отличается (с чьей перспективы ведётся рассказ) это я тоже понимаю. В системной инженерии даже выделяют не два языка, а N языков, ибо есть самые разные concerns у самых разных стейкхолдеров -- и на каждый интерес нужно отвечать описанием на каком-то удобном для этого языке.

Если вы всё правильно понимаете, почему вы тогда делаете такие странные выводы?

Потому что область моего понимания шире, я кроме agile ещё и с другими направлениями мысли знаком. Я, кстати, покупал оригинальные книжки по XP буквально через пару-тройку месяцев после их выхода (в начале двухтысячных) и пробовал это всё в своей фирме (у меня тогда человек тридцать пять работало, делало веб-движок и вебсайты). То есть я не первый день со всем этим разбираюсь, и до сих пор регулярно читаю http://infoq.com/. Но, повторюсь, с тех давних пор я ещё много чего узнал (впрочем, и до этих пор тоже узнанного хватало -- мне всё-таки 57 лет уже, и первые программы я написал в 1975, а в промышленной разработке софта участвовал с 1980. А потом и не только софта). В онтологиях есть такая проблема: ontology revision -- когда какое-то небольшое новое прихваченное знание заставляет существенно пересматривать всю онтологию. Так и тут: моё прихваченное за последний пяток лет новое знание заставляет и на agile по-другому смотреть, не так, как эти добрые люди смотрят на себя изнутри тусовки, и не так, как смотрят на них традиционные "водопадчики". И это новое знание, увы, не передашь в режиме комментов в ЖЖ, равно как в этом режиме не передашь и классическое знание-понимание agile. Это проблема, конечно -- https://wiki.lesswrong.com/wiki/Inferential_distance