lytdybr

Сегодня была огромная дискуссия на тему "неужели требования благорастворились в воздусях" у меня в чате блога, с https://t.me/ailev_blog_discussion/16539 (это первая сегодняшняя реплика, но сам разговор идёт уже несколько дней, прерываясь только на обсуждение проблем "невзлёта IoT" и ненужности Яндекс.Алисы). Я по итогам этой дискуссии вписал сегодня четыре вордовых страницы в текст учебника, ещё раз пройдясь по некоторым аргументам, ибо с первого раза они не воспринимаются, надо несколько раз обратить внимание, чтобы подсветить то мышление, из которого появляются возражения -- что там кроется за теми или иными формулировками, а обычно там кроется "водопад". Одна страничка из этих четырёх, чтобы было понятно о чём речь. Я склоняюсь, чтобы в учебнике системного мышления заменить «требования» на «описание чёрного ящика» как более нейтральное по отношению к форме рабочих продуктов, его документирующих. Если оставлять слово «требования», то начинаются споры на ровном месте: сам термин, похоже, отражает второе поколение системного мышления, а для третьего поколения нужно смотреть не только на описание системы, но и на развитие/эволюцию описания вместе с развитием/эволюцией системы. А «развитие требований» как-то «не звучит», требования наборот – ожидается, что они «стабилизируются»! Поэтому от слова уходим, споры на ровном месте (каждый понимает под «требованиями» что-то своё) не нужны, это «ложный друг переводчика». Почему бы описание системы как чёрного ящика не оставить как «требования»? Тут возникают много соблазнов: -- Считать, что это описание в деонтической (долженствования), а не доксической (предположение, вера) модальности. Нет, это не «требования», а «гипотеза». Нельзя говорить «вы должны, ах нет, уже не должны, но нет, мы опять поменяли, что вы должны – вы должны, но уже другое». Перестали говорить «X должен быть 10», но «я сейчас верю, что X будет 10, а завтра посмотрим, давайте проверим догадку/гипотезу». -- Ошибочно считать, что это не альфа «описание», а привычный рабочий продукт «спецификация требований» -- и далее, как обычно, подтягивается вся традиционная идеология водопада, где «изменение спецификации требований – это долго, дорого, плохо». -- Сплошь и рядом «требования» -- это описание системы в языке разработчиков (не «игрок должен быть зарегистрирован за три минуты», а «данные пользователя должны быть получены с интерфейса за три минуты»). Такие описания как сценарии использования не так чтобы гарантируют, что описания будут в предметном языке, но позволяют ещё и ещё раз обратить на это внимание и уж точно описать функциональность, а не только конструктивность. И тут ещё одна подвижка: попытка «интерфейсы» (конструктивное описание) заменить словом «контракты», в котором упор опять-таки делается на функциональность (взгляд от надсистемы на систему с точки зрения того, «зачем это всё», а не «что во что втыкается»). -- Спецификации требований сегодня представляют собой документы со смесью описаний функциональности, архитектурных характеристик, архитектурных решений и всего чего угодно. Нет «требований», значит нет «спецификации требований» и можно отдельно говорить обо всех этих разных видах описаний. В частности, можно проконтролировать, чтобы описание было именно описанием поведения системы, а не просто описанием системы в статике. Для этого и «сценарии», хорошо подходящие для описания поведения. Подойдут use cases, сценарии (use case текстом), storyboards (картинки заставляют сделать grounding в физический мир) и т.д.: всё, где есть поведение. Всякие языки для TDD пишутся как business rules (в том числе Gherkin) и они вполне подойдут, это те же use cases, только без картинок и с возможностью проверки. -- Архитектурные характеристики попадут в состав требований (как какие-нибудь «нефункциональные требования» или «требования качества»), но они сейчас обсуждаются отдельно и с ними работают через метрики. Это предметы интереса/concerns и предпочтения, и вообще работа с ними (не такая, как с "требованиями!) происходит не у прикладных разработчиков (которые имеют дело с subdomain обычно), а у архитекторов. А вот то, что из этих concerns были раньше «требования» делается записями архитектурных решений и отслеживается в архитектурных тестах/fit functions (об этом подробней в следующем разделе). -- Если оставить «требования» и они будут поняты как «спецификация», то информация теряется и возникает соблазн посадить ещё «прокладку» между специалистами предметной области и разработчиками из инженеров по требованиям. Возникает проблема испорченного телефона, она же проблема многократного перевода. Вот пост участника СМС24 по итогам закончившегося вчера курса. В посте интересное слово "расПОЖАРизация" проекта: https://blog.system-school.ru/2022/08/08/promezhutochnyj-rezultat/. "... в числе результатов курса, еще есть маленькое «кое-что», в виде «расПОЖАРизации» бывшего самым сложным проекта, на 12 человек своих и 600 человек заказчика. Сложность в этом проекте для меня, была кроме размеров и быстрого роста команды и в потере части компетенций по управлению и в предметной области, в связи со смертью бывшего директора этой компании. Но… в этом проекте стало спокойно так, что непонятно что об этом говорить. Эту «распожаризацию» — я еще не нашла как «потрогать», не было у меня слова «управления конфигурацией работ». А вот то, как эту проблему я называла до узнавания этого слова — я не могу вспомнить. Без вспоминания — сложно выделить до/после. А без до/после, путь к «распожаризации» описать могу, только как «я быстро-быстра делала, как написано в учебнике»". Все склоняются к тому, что мне надо проводить СМС25, не меняя названия курса ("Системный менеджмент и стратегирование 2022"), но добавив один день для учёта добавившегося в курс учебника системной инженерии (системный менеджмент -- это по факту приложение системной инженерии к предприятию). Запись откроем в ближайшие дни, даты планирую такие: СМС25.0 (установка на один час) -- 18 сентября 2022 СМС25.1 -- 2 октября 2022 СМС25.2 -- 16 октября 2022 СМС25.3 -- 30 октября 2022 СМС25.4 -- 13 ноября 2022 СМС25.5 -- 27 ноября 2022 СМС25.6 -- 11 декабря 2022 СМС25.7 -- 25 декабря 2022 Алгоритмика интересна тем, что если кто ещё не подходил к задаче с целью что-то оптимизировать, то можно смело ожидать разгона на несколько порядков. В этот раз разогнали текстовые игры на три порядка (они нужны, чтобы тренировать RL-агентов, для них игровой агент должен реагировать быстро): https://syncedreview.com/2022/08/08/microsoft-arizona-us-textworldexpress-simulates-text-games-at-1m-sps-a-speedup-of-3-orders-of-magnitude/. Не так чтобы я интересовался именно этими текстовыми играми, но в последнее время меня очень привлекают ситуации улучшения (ускорения, удешевления, упрочнения и т.д.) чего-то x10, x100, x1000. Это как раз оно. Я вот задумался, а есть ли что-то вокруг меня, что можно было бы вот так -- эть, и x10. Обычно при оптимизации образования получается x4, и даже это очень трудно демонстрировать. Но очень хотелось бы хоть в чём-нибудь получить x10. Просто, чтобы было. У конкурентов ты можешь выиграть и на x0.3 (на 30%, тогда будут готовы рискнуть), но при x10 это уже не "выигрыш у конкурентов", а "подрыв рынка", disruption. Это другой уровень выигрыша в конкуренции, это уже эволюционная история, это интересно.