Пятничный вброс довольно-таки очевидных вещей, все равно никто не читает требования)
tl;dr Acceptance criteria, epic story, product owner - это костыли плохо продуманной системы, сделанной из серединки.
Long read Есть 3 типа требований (сверху вниз) - бизнес-требования (зачем нам система вообще), на их основании пишутся пользовательские (user) требования (что я как какой-то юзер хочу от системы), на их основании пишутся требования к решению (функциональные и нефункциональные - какие функции и как должна реализовать система).
Есть Agile, который был придуман 17-ю "независимыми практиками нескольких методик программирования " (с) Wikipedia 20 лет назад, которые хотели побыстрее, здесь и попроще. И рядышком вываливается такой промежуточный артефакт как User story - это очень простенький формат пользовательских требований. Не бизнес-требований и не требований к решению - а пользовательских, тупо середина. "Обещание разговора", да. Он не описывает сценариев, он не дает связей. Он просто дает точечную пользовательскую хотелку без любой привязки к контексту. Нет привязки - вот и гибкость, которая agile. Типа.
Программист может использовать ТОЛЬКО требования к решению. Если он использует пользовательские требования, то он все равно сочиняет (в голове/на блокнотике) на их основании требования к решению и использует сочиненные. Сочиненные вещи плохо формализуются, тяжело трансферятся другим членам команды и невероятно сложно суппортятся годик спустя.
User story - это пользовательское требование. И по ней программить нельзя. Конец идиллии и начало костылей. Собственно:
Давайте добавим Acceptance criteria - это собственно и есть требования к решению. Но как их формализовать? Особенно если это нефункциональные требования, которые применяются ко всему решению (безопасность, например)? Никак, давайте сочинять форматы (не сработает, юзер стори - это локальная штука).
Хоть какой-то контекст нужен, а то тут вздернешься в куче этих точечных хотелок. Начинаем продавать гибкость и получать хоть какую-то управляемость - epic story (а потом вниз еще сабтаски прорастают, а еще в спринтах давайте цели ставить, а давайте не ставить, а давайте стабилизационный спринт сделаем!) - и вот наша гибкость превращается в элегантные бруки (и еще roadmap vs backlog grooming, ага).
Пишем все больше, основополагающие принципы и общие вектора развития все нужнее - вот и здравствуйте, бизнес-требования, которых нет в аджайле. Поэтому берем документ Vision&Scope и меняем на человека Product owner. Как он скажет - так и будет. И скрестим пальцы насчет автобуса. А мысли ему всем советом директоров согласовывать и утверждать будем. И подписи ставить.
А ну и давайте теперь вспомним как собственно саму User story пишут то, особенно после "so". И кому она вообще нужна, эта текстовка.)
А гивен/вен/зен - это вообще Геркин для тестировщиков. Который описывает один шаг одного сценария. А в нормальном сценарии их штук 8 надо. И еще ж альтернативные сценарии есть. И эксепшены.
"Agile это фрэймворк, а не закон! Кастомизируй под нужды!". И при этом в джире дефолтные ишью тайпы - сторя и таска. Так и живем.
Ну как же. Суть цикла статей, насколько я понял — поиск замены слоеным нейросетям.
Автор в конце говорит о пачке переплетенных возбуждающихся от контакта или proximity цилиндров. Понятно, что цилиндры форматом хранения и обработки не сделаешь, но судя по всему эта конструкция редуцируется до направленного графа. Направленный — потому что возбужденный цилиндр уже возбужден.
Вот я и спрашиваю, угадал?
Я про то и говорю, пожирающая пустота. Чтоб края галактики обсасывало и обгрызало. Попал в пустоту — помер. Находишься недалеко — ресурсов на гиперпрыжок собрать тяжело — почти все обсосано. Заодно и полет к центру галактики сразу обоснованным стал бы.
Играм нужен конфликт.
Ну если сделать врага неумолимым и появляющимся абсолютно везде, куда бы ты не улетел — то да, этого бы хватило для ограничения. Другой разговор, что при этом бесконечность генерируемого космоса теряет смысл — какая разница, куда лететь, если везде плохо? Разве что ради смены картинки. Как в майнкрафте.
Не помню точно, но вроде я в KSP видел строго одну солнечную систему.
Orbiter вроде тоже только одной звездой ограничен.
Space Engine — не игра. И я подозреваю, что и не станет — тот же прикол, что и в NMS — бесконечное количество звезд. Разве что наложить сверху квест попрыгать по определенным звездам. Т.е. наложить ограничение.
<Не играл, но осуждаю>
Нету конфликта в игре. Нету ограничения. Процедурная генерация ни при чем.
В старой элите есть таргоиды.
В майнкрафте ночка джазу добавляет (в creative режиме не играют, а пробуют редстоун).
В дьябле прорваться к дьябле через всю игру сквозь горы монстры — вполне себе ограничение.
В Spore конфликт постоянно подсовывали, особенно когда амебой плаваешь. Можно было тупо в ее одну играть — доказательство.
Проблема в космосе.
Он как бы по умолчанию безграничен и не дает завязаться конфликту. Поэтому во всех космосимах его искусственно ограничивают (исключая старую элитку, но там другой прикол). Ева, X-серия, косморейнджеры — у всех карта ограничена — и некуда бежать. Плюс сверху перчат перманентным врагом — всякие там хааки и таргоиды, в Еве — ганкеры.
А тут всегда убежать можно, да и врага, насколько я понял, нету.
Надо было как всегда — карту резать, переливая ресурсы и человекочасы в генерацию всяких там красивостей типа поясов у планет и зверушек вменяемых. И врага вводить — какую-нибудь пожирающую пустоту хотя бы.
</Не играл, но осуждаю>
За 65days обидно только, красавы как всегда, а тут такое…
Когда я начинал пробовать Математику, тоже напоролся на это.
Но у них отличный оффлайн хелп со встроенными статьями и туторами.
По-моему, у Математики просто нет явной кривой обучения (что прикольно) — сразу после Ctrl-N можно в начале чистого листа написать любую (ну почти) функцию («волшебное слово»), задать ей параметры и нажать Shift-Enter и тебе что-то ответят.
Обычно же все не так — ты долго и упорно подготавливаешь почву, а потом уже юзаешь кусок из середины кривой обучения (сначала инклюды, переменные, боилерплейт, а потом уже, например, передача данных по инфракрасному порту).
Как оказалось, в Математике принцип тот же. И переменные лучше заранее объявить. А вот боилеркод просто тупо размазывается в виде паттернов замен, маппингов, фолдингов и т.п. вокруг главной логики.
Я бы посоветовал начать изучать с начала — с синтаксиса и семантики списков и функций над ними. Математика пляшет вокруг списков. Ну а потом поставить себе задачу (например, нарисовать карту с координатами созвездия Гидры в цилиндрической проекции и нарезать ее на листы формата А4 для распечатки и наклеивания на стену, размеры которой задаются перед началом расчета) и вперед.
Имхо, ессно.
P.S. А все эти гламурненькие примеры — они то да, что-то выдают со старта, но результат их работы малоюзаем обычно.
Инструкция средней (допустим) детализации, содержащая:
Описание изготовления микроскопа.
Описание изготовления поляризатора.
Описание формата хранения данных (стартуя, как я понимаю, с описания двоичной системы счисления, проходя сквозь алфавиты и письменность как минимум английского языка и заканчивая собственно концепцией тегов (например)).
При всем при этом технология инструкции позволяет, как предполагается, обходится без всего этого.
Я думаю, очевидно, кто выиграет в такой войне форматов.
Проблема в другом: инструкция должна прожить столько же, сколько и архив. Но при этом, согласно требованиям, она должна быть легко читаема. А архив читается сложно, ведь нужна инструкция. Почему бы тогда не сделать архив на технологии инструкции?
Соответственно:
1. Либо у нас набор шкал, состоящий из базовых, полученных при рождении от природы и наращивающийся в процессе получения опыта.
2. Либо у нас каталог сущностей, данный нам в какой-то атомарный момент времени и пополняющийся опять же в процессе получения опыта.
Так?
У меня в плане и разбор атрибутов. Буду надеяться, результат превзойдет ваш.
Без сарказма желаю удачи.
Теги — это как-то совсем из другой области.
Попробую развернуть. Заранее извиняюсь за придуманные на ходу термины.
Вопрос, собственно, в «концепте». Введенное здесь понятие «концепта» мне видится и интересным, и основным. И, насколько я понял, это эдакий «неделимый» и «ключевой» признак сущности. Однако, примеры концептов, приведенные вами, не сказать, чтобы неделимы (собственно, оборачивая концепт в иерархию, причем с обоих сторон, вы его вполне себе делите).
Квантовая механика говорит нам, что искать неделимые частицы — это неблагодарное занятие.
Я бы определил концепт как уникальное (относительно других, представленных в данном наборе) сочетание значений «базовых шкал». Значение базовой шкалы — это то, что можно воспринять базовым сенсором человека (не будем себе врать) — глазом там, или ухом. Горячий, тихий, фиолетовый, вонючий. Может быть и понятийная шкала (выведенная из сенсорных) — «количество», «высота», «живость», «моральность». И, таким образом, из набора кортежей «шкала: значение» и получаются — и теги, и концепт. И вирус так обработать можно. И разные восприятия (мерседес как концепт роскоши для бедных и концепт машины у богатых) можно учесть — путем настройки шкал.
Рискну покритиковать. 1. Род, вид, тип — это все синонимы класса. В свое время по работе сталкивался с необходимостью давать именно разные названия для атрибутов, работа стопорнулась, когда остальная команда начала спрашивать безостановочно: «А вот такое то свойство/признак/особенность — это вид/род/тип/класс сущности или что?» Зарезолвил в общем виде переделкой типов/родов/видов в конструкции вида «Признак: %название признака%».
Отсюда: я бы не стал оперировать «родом/видом/типом». Все равно это просто разные уровни классификационного дерева, которое, в свою очередь, я не очень люблю потому, что: 2. Приверженность к иерархическим структурам тоже меня настораживает. Опять же, невозможно классифицировать ВСЁ по ограниченному набору возможных значений признака. Всегда будет пачка сущностей под классификацией «другое».
Пример (используя вашу статью): какова «категория» у вируса? Если попытаться вывернуться вводом значения «носитель генетической информации», то нужно будет делать понятие «подкатегории» со значениями «живой носитель генетической информации»/«неживой носитель». «Посох», «Плутон» и другие — про то же. Это также к вопросу из пункта 1.
Конструктив. На мой неискушенный взгляд, здесь очень сильно проглядывают теги (возможно, с подчинениями) и именованные связи.
Конечно, надо же начинать сопротивляться)
Пятничный вброс довольно-таки очевидных вещей, все равно никто не читает требования)
tl;dr Acceptance criteria, epic story, product owner - это костыли плохо продуманной системы, сделанной из серединки.
Long read
Есть 3 типа требований (сверху вниз) - бизнес-требования (зачем нам система вообще), на их основании пишутся пользовательские (user) требования (что я как какой-то юзер хочу от системы), на их основании пишутся требования к решению (функциональные и нефункциональные - какие функции и как должна реализовать система).
Есть Agile, который был придуман 17-ю "независимыми практиками нескольких методик программирования " (с) Wikipedia 20 лет назад, которые хотели побыстрее, здесь и попроще. И рядышком вываливается такой промежуточный артефакт как User story - это очень простенький формат пользовательских требований. Не бизнес-требований и не требований к решению - а пользовательских, тупо середина. "Обещание разговора", да. Он не описывает сценариев, он не дает связей. Он просто дает точечную пользовательскую хотелку без любой привязки к контексту. Нет привязки - вот и гибкость, которая agile. Типа.
Программист может использовать ТОЛЬКО требования к решению. Если он использует пользовательские требования, то он все равно сочиняет (в голове/на блокнотике) на их основании требования к решению и использует сочиненные. Сочиненные вещи плохо формализуются, тяжело трансферятся другим членам команды и невероятно сложно суппортятся годик спустя.
User story - это пользовательское требование. И по ней программить нельзя. Конец идиллии и начало костылей. Собственно:
Давайте добавим Acceptance criteria - это собственно и есть требования к решению. Но как их формализовать? Особенно если это нефункциональные требования, которые применяются ко всему решению (безопасность, например)? Никак, давайте сочинять форматы (не сработает, юзер стори - это локальная штука).
Хоть какой-то контекст нужен, а то тут вздернешься в куче этих точечных хотелок. Начинаем продавать гибкость и получать хоть какую-то управляемость - epic story (а потом вниз еще сабтаски прорастают, а еще в спринтах давайте цели ставить, а давайте не ставить, а давайте стабилизационный спринт сделаем!) - и вот наша гибкость превращается в элегантные бруки (и еще roadmap vs backlog grooming, ага).
Пишем все больше, основополагающие принципы и общие вектора развития все нужнее - вот и здравствуйте, бизнес-требования, которых нет в аджайле. Поэтому берем документ Vision&Scope и меняем на человека Product owner. Как он скажет - так и будет. И скрестим пальцы насчет автобуса. А мысли ему всем советом директоров согласовывать и утверждать будем. И подписи ставить.
А ну и давайте теперь вспомним как собственно саму User story пишут то, особенно после "so". И кому она вообще нужна, эта текстовка.)
А гивен/вен/зен - это вообще Геркин для тестировщиков. Который описывает один шаг одного сценария. А в нормальном сценарии их штук 8 надо. И еще ж альтернативные сценарии есть. И эксепшены.
"Agile это фрэймворк, а не закон! Кастомизируй под нужды!". И при этом в джире дефолтные ишью тайпы - сторя и таска. Так и живем.
Извините. )
Так-то да, согласен.
Автор в конце говорит о пачке переплетенных возбуждающихся от контакта или proximity цилиндров. Понятно, что цилиндры форматом хранения и обработки не сделаешь, но судя по всему эта конструкция редуцируется до направленного графа. Направленный — потому что возбужденный цилиндр уже возбужден.
Вот я и спрашиваю, угадал?
С трудом продравшись сквозь описание железной части, все же вангую направленный граф. Угадал? :)
Играм нужен конфликт.
Orbiter вроде тоже только одной звездой ограничен.
Space Engine — не игра. И я подозреваю, что и не станет — тот же прикол, что и в NMS — бесконечное количество звезд. Разве что наложить сверху квест попрыгать по определенным звездам. Т.е. наложить ограничение.
Так что да, ограничивают.
Нету конфликта в игре. Нету ограничения. Процедурная генерация ни при чем.
В старой элите есть таргоиды.
В майнкрафте ночка джазу добавляет (в creative режиме не играют, а пробуют редстоун).
В дьябле прорваться к дьябле через всю игру сквозь горы монстры — вполне себе ограничение.
В Spore конфликт постоянно подсовывали, особенно когда амебой плаваешь. Можно было тупо в ее одну играть — доказательство.
Проблема в космосе.
Он как бы по умолчанию безграничен и не дает завязаться конфликту. Поэтому во всех космосимах его искусственно ограничивают (исключая старую элитку, но там другой прикол). Ева, X-серия, косморейнджеры — у всех карта ограничена — и некуда бежать. Плюс сверху перчат перманентным врагом — всякие там хааки и таргоиды, в Еве — ганкеры.
А тут всегда убежать можно, да и врага, насколько я понял, нету.
Надо было как всегда — карту резать, переливая ресурсы и человекочасы в генерацию всяких там красивостей типа поясов у планет и зверушек вменяемых. И врага вводить — какую-нибудь пожирающую пустоту хотя бы.
</Не играл, но осуждаю>
За 65days обидно только, красавы как всегда, а тут такое…
Но у них отличный оффлайн хелп со встроенными статьями и туторами.
По-моему, у Математики просто нет явной кривой обучения (что прикольно) — сразу после Ctrl-N можно в начале чистого листа написать любую (ну почти) функцию («волшебное слово»), задать ей параметры и нажать Shift-Enter и тебе что-то ответят.
Обычно же все не так — ты долго и упорно подготавливаешь почву, а потом уже юзаешь кусок из середины кривой обучения (сначала инклюды, переменные, боилерплейт, а потом уже, например, передача данных по инфракрасному порту).
Как оказалось, в Математике принцип тот же. И переменные лучше заранее объявить. А вот боилеркод просто тупо размазывается в виде паттернов замен, маппингов, фолдингов и т.п. вокруг главной логики.
Я бы посоветовал начать изучать с начала — с синтаксиса и семантики списков и функций над ними. Математика пляшет вокруг списков. Ну а потом поставить себе задачу (например, нарисовать карту с координатами созвездия Гидры в цилиндрической проекции и нарезать ее на листы формата А4 для распечатки и наклеивания на стену, размеры которой задаются перед началом расчета) и вперед.
Имхо, ессно.
P.S. А все эти гламурненькие примеры — они то да, что-то выдают со старта, но результат их работы малоюзаем обычно.
При всем при этом технология инструкции позволяет, как предполагается, обходится без всего этого.
Я думаю, очевидно, кто выиграет в такой войне форматов.
1. Либо у нас набор шкал, состоящий из базовых, полученных при рождении от природы и наращивающийся в процессе получения опыта.
2. Либо у нас каталог сущностей, данный нам в какой-то атомарный момент времени и пополняющийся опять же в процессе получения опыта.
Так?
Без сарказма желаю удачи.
Попробую развернуть. Заранее извиняюсь за придуманные на ходу термины.
Вопрос, собственно, в «концепте». Введенное здесь понятие «концепта» мне видится и интересным, и основным. И, насколько я понял, это эдакий «неделимый» и «ключевой» признак сущности. Однако, примеры концептов, приведенные вами, не сказать, чтобы неделимы (собственно, оборачивая концепт в иерархию, причем с обоих сторон, вы его вполне себе делите).
Квантовая механика говорит нам, что искать неделимые частицы — это неблагодарное занятие.
Я бы определил концепт как уникальное (относительно других, представленных в данном наборе) сочетание значений «базовых шкал». Значение базовой шкалы — это то, что можно воспринять базовым сенсором человека (не будем себе врать) — глазом там, или ухом. Горячий, тихий, фиолетовый, вонючий. Может быть и понятийная шкала (выведенная из сенсорных) — «количество», «высота», «живость», «моральность». И, таким образом, из набора кортежей «шкала: значение» и получаются — и теги, и концепт. И вирус так обработать можно. И разные восприятия (мерседес как концепт роскоши для бедных и концепт машины у богатых) можно учесть — путем настройки шкал.
Вот так мне тут видятся теги.
1. Род, вид, тип — это все синонимы класса. В свое время по работе сталкивался с необходимостью давать именно разные названия для атрибутов, работа стопорнулась, когда остальная команда начала спрашивать безостановочно: «А вот такое то свойство/признак/особенность — это вид/род/тип/класс сущности или что?» Зарезолвил в общем виде переделкой типов/родов/видов в конструкции вида «Признак: %название признака%».
Отсюда: я бы не стал оперировать «родом/видом/типом». Все равно это просто разные уровни классификационного дерева, которое, в свою очередь, я не очень люблю потому, что:
2. Приверженность к иерархическим структурам тоже меня настораживает. Опять же, невозможно классифицировать ВСЁ по ограниченному набору возможных значений признака. Всегда будет пачка сущностей под классификацией «другое».
Пример (используя вашу статью): какова «категория» у вируса? Если попытаться вывернуться вводом значения «носитель генетической информации», то нужно будет делать понятие «подкатегории» со значениями «живой носитель генетической информации»/«неживой носитель». «Посох», «Плутон» и другие — про то же. Это также к вопросу из пункта 1.
Конструктив. На мой неискушенный взгляд, здесь очень сильно проглядывают теги (возможно, с подчинениями) и именованные связи.