У меня (уже когда я статьи писал) возникла версия, что в экзешник засовывали то, что чаще встречается - для "хэширования", но потом я тоже склонился к версии с хвостами.
Про авиапушку - я тоже налетал уже несколько сотен часов и только тогда узнал о том, как переключаться на ракеты. Узнал я после того, как в ярости (уже не помню из-за чего) начал стучать по клавиатуре.
Ну вот я как сейчас помню файл centurio.exe, который запускался и что-то пищало даже в динамик, но на экране было черным-черно. И это было не исключение)
Пятничный вброс довольно-таки очевидных вещей, все равно никто не читает требования)
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 цилиндров. Понятно, что цилиндры форматом хранения и обработки не сделаешь, но судя по всему эта конструкция редуцируется до направленного графа. Направленный — потому что возбужденный цилиндр уже возбужден.
Вот я и спрашиваю, угадал?
Я про то и говорю, пожирающая пустота. Чтоб края галактики обсасывало и обгрызало. Попал в пустоту — помер. Находишься недалеко — ресурсов на гиперпрыжок собрать тяжело — почти все обсосано. Заодно и полет к центру галактики сразу обоснованным стал бы.
Играм нужен конфликт.
Ну если сделать врага неумолимым и появляющимся абсолютно везде, куда бы ты не улетел — то да, этого бы хватило для ограничения. Другой разговор, что при этом бесконечность генерируемого космоса теряет смысл — какая разница, куда лететь, если везде плохо? Разве что ради смены картинки. Как в майнкрафте.
Это их официальный термин)
Но я по тем же причинам в голове называю это "мид-поли".
У меня (уже когда я статьи писал) возникла версия, что в экзешник засовывали то, что чаще встречается - для "хэширования", но потом я тоже склонился к версии с хвостами.
А еще мне нравилось, когда включаешь разворот на месте, выключаешь его, а вертолет еще немного по инерции доворачивается
Оказывается, я не один такой)
Мне вот как-то больше понравился ImHex по итогу, но фломастеры всегда фломастеры.
Справедливое замечание) Поправил картинки.
И спасибо за отзыв)
Про авиапушку - я тоже налетал уже несколько сотен часов и только тогда узнал о том, как переключаться на ракеты. Узнал я после того, как в ярости (уже не помню из-за чего) начал стучать по клавиатуре.
Ну вот я как сейчас помню файл centurio.exe, который запускался и что-то пищало даже в динамик, но на экране было черным-черно. И это было не исключение)
Спасибо за оценку, продолжение будет завтра)
Конечно, надо же начинать сопротивляться)
Пятничный вброс довольно-таки очевидных вещей, все равно никто не читает требования)
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 цилиндров. Понятно, что цилиндры форматом хранения и обработки не сделаешь, но судя по всему эта конструкция редуцируется до направленного графа. Направленный — потому что возбужденный цилиндр уже возбужден.
Вот я и спрашиваю, угадал?
С трудом продравшись сквозь описание железной части, все же вангую направленный граф. Угадал? :)
Играм нужен конфликт.