Вот когда начинаются обсуждения про банкет - они опасно близко подходят к правилам хабра. Скажу только, что во Франции и Германии отличная социалка, но и налоги там ух. И дальше уже не стоит вскрывать эту тему)
Я не очень хорош в истории профсоюзов (настоящих), но общие наметки примерно помню. Про реальность - собственно, режим 8x5 аля офисный планктон, а не 16x7 аля английские докеры в середине 19 века - это вроде как заслуга как раз профсоюзов. По поводу поработать после старта пенсии - опять же, можно обсуждать не только старт пенсии, но и ее размер, посмотрите на ту же Францию. Про все остальное - отвечу в том же ключе, в пост-СССР люди часто не понимают, что такое настоящий профсоюз - и почему его очень не любят владельцы бизнесов.
Я писал длинный коммент, но решил написать покороче. Ваша статья не про то, что писать ТЗ по шаблону - неудобно (ограниченно). Вы про шаблон там вообще не пишите. Ваша статья про то, как Вы прорабатываете требования к каким-то аспектам несложной системы, взятым из воздуха. И именно к взятию из воздуха у меня и претензии. Особенно к человеку, который "не рассказал, а обучил" 2 тыщи людей бизнес-требованиям и всему такому. Но если Вы считаете, что так - верно, то ок, это Ваше право)
Только небольшой вопросик. После двух тысяч людей, которым Вы лично рассказали про разработку требований в целом, плюс бизнес- и пользовательские требования в частности, Вы пишете явно обучающую (ну или хотя бы показывающую пример) статью, в которой эти требования не упоминаются, зато есть "микро-ограничения функций". Какого эффекта должна была достичь эта статья?
Итак, это воскресенье и это время пофлудить, потому что никто не читает воскресный хабр.
Во-первых, не дыры, а отверстия.
Я все листал и все ждал, что в какой-то момент автор напишет - "видите, если все делать задом наперед - то будет трэш и угар, давайте уже сделаем передом назад". Но так и не дождался. В конце я увидел только "Микро-ограничения функций" и "Макро-ограничения". Предполагаю, что в данном случае "ограничения среднего размера" не понадобились. И я ведь так весь день ерничать могу.
Все описанное ниже - строго на основании текста статьи ТОЛЬКО.
Автор говорит как бы правильно, но потому что он старается и вертит головой во все стороны, чтоб не упустить ничего. А не потому, что он знает, что делает. И это не ремесло получается, а искусство, а так жыть нельзя. И автору об этом в первом же комменте указали кстати.
Передом назад - это вот так, как я дальше пишу.
АБСОЛЮТНО ЛЮБАЯ система - это костыль, который помогает сделать что-то. И если не понять, чему этот костыль помогает, то его все еще можно имплементировать. Просто им не будут пользоваться, потому что "а зачем мне эта штука"? А если понять, зачем он делается, то вот мы и получили бизнес-требования (ака БТ) - ответы на вопросы "что", "зачем" и "сколько". И только из них становится ясно, кто по итогу будет пользоваться этим костылем. И узнать у этих людей (порой (но очень редко) это будут не люди, кстати) случаи, в которых этот костыль поможет - и зафиксировать их. В б-гомерзких сторях или в православных юз-кейсах или еще как-то. И назвать их "пользовательские требования" (ПТ). И они всегда и это вообще неочевидно - следствие БП. И только поняв, сценарии юзания этого костыля (это все те же ПТ) - писать уже крнкретно требования к способу воплощения костыля в жизнь так, чтоб он под эти сценарии по итогу подпал. И это называется "требования к решению" (ТР). И они - прямое следствие ПЕ, которые сами - следствие БТ. А ТР могут быть про то, а) что костыль должен уметь (функциональные требования, ФТ) и б) как он должен это уметь (нефункциональные требования, НФТ). ФТ + НФТ = ТР.
Т.е., в сути своей предыдущий абзац звучит так:
БТ -> ПТ -> ТР. И это без шуток часто открытие для юниоров и неосведомленных
ТР = ФТ + НФТ. Это, в принципе, минимальный набор, формирующий ТЗ. Но это ТЗ без возможости доработки. Потому что доработка потребует ПТ, а их тут нет, как видно. И вот так - правильно. И этот подход всегда один и тот же. И это именно то самое ремесленничество. Новый проект? Пришел на дискавери, вызнал БТ, сформировал пул будущих юзеров, узнал у них ПТ, сочинил ФТ. Потом у всех поспрашивал и сформировал НФТ. Конец. Все всегда одинаково.
Ну и с высоты сказанного, о чем написал автор. По всему тексту размазаны ПТ, причем пользователь - это автор ("Суперкорень нам вряд ли завтра пригодится", "Как мы понимаем сейчас, интерфейс вполне может быть как минимум голосовым, если не тактильным по Брайлю" и т.п.) и НФТ, и у них то как раз нормальный источник - все подряд ("Калькулятор должен работать на устройствах Redmi 9A (32 Гб)", "Калькулятор должен выполнять вычисления над выражениями с надёжностью не меньше, чем 98%", "у Google Play есть собственные рекомендации и ограничения"). А в резюмирующей главе - ФТ (это которые функции с микро-ограничениями) и НФТ (которые макроограничения). БТ в статье нет. По итогу автор выдал-таки ТЗ, но потому что старался, а не потому знал как надо.
И я бы написал, почему автор тут ни в чем не виноват, но этот коммент и так уже больше страницы высотой. Но если кто захочет - говорите, напишу)
У меня (уже когда я статьи писал) возникла версия, что в экзешник засовывали то, что чаще встречается - для "хэширования", но потом я тоже склонился к версии с хвостами.
Про авиапушку - я тоже налетал уже несколько сотен часов и только тогда узнал о том, как переключаться на ракеты. Узнал я после того, как в ярости (уже не помню из-за чего) начал стучать по клавиатуре.
Ну вот я как сейчас помню файл 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 это фрэймворк, а не закон! Кастомизируй под нужды!". И при этом в джире дефолтные ишью тайпы - сторя и таска. Так и живем.
Тому, кому не нравится гугл?
Тому, кому нравится (почему-то) huawei?
Тому, кто знает про https://microg.org/?
Или это риторический вопрос?)
Вот когда начинаются обсуждения про банкет - они опасно близко подходят к правилам хабра. Скажу только, что во Франции и Германии отличная социалка, но и налоги там ух. И дальше уже не стоит вскрывать эту тему)
Я не очень хорош в истории профсоюзов (настоящих), но общие наметки примерно помню.
Про реальность - собственно, режим 8x5 аля офисный планктон, а не 16x7 аля английские докеры в середине 19 века - это вроде как заслуга как раз профсоюзов.
По поводу поработать после старта пенсии - опять же, можно обсуждать не только старт пенсии, но и ее размер, посмотрите на ту же Францию.
Про все остальное - отвечу в том же ключе, в пост-СССР люди часто не понимают, что такое настоящий профсоюз - и почему его очень не любят владельцы бизнесов.
Пенсию в 55?
Ок, приношу глубочайшие извинения
Я писал длинный коммент, но решил написать покороче. Ваша статья не про то, что писать ТЗ по шаблону - неудобно (ограниченно). Вы про шаблон там вообще не пишите. Ваша статья про то, как Вы прорабатываете требования к каким-то аспектам несложной системы, взятым из воздуха. И именно к взятию из воздуха у меня и претензии. Особенно к человеку, который "не рассказал, а обучил" 2 тыщи людей бизнес-требованиям и всему такому. Но если Вы считаете, что так - верно, то ок, это Ваше право)
Рад, что сумел доставить Вам удовольствие)
Только небольшой вопросик. После двух тысяч людей, которым Вы лично рассказали про разработку требований в целом, плюс бизнес- и пользовательские требования в частности, Вы пишете явно обучающую (ну или хотя бы показывающую пример) статью, в которой эти требования не упоминаются, зато есть "микро-ограничения функций". Какого эффекта должна была достичь эта статья?
Итак, это воскресенье и это время пофлудить, потому что никто не читает воскресный хабр.
Во-первых, не дыры, а отверстия.
Я все листал и все ждал, что в какой-то момент автор напишет - "видите, если все делать задом наперед - то будет трэш и угар, давайте уже сделаем передом назад". Но так и не дождался. В конце я увидел только "Микро-ограничения функций" и "Макро-ограничения". Предполагаю, что в данном случае "ограничения среднего размера" не понадобились. И я ведь так весь день ерничать могу.
Все описанное ниже - строго на основании текста статьи ТОЛЬКО.
Автор говорит как бы правильно, но потому что он старается и вертит головой во все стороны, чтоб не упустить ничего. А не потому, что он знает, что делает. И это не ремесло получается, а искусство, а так жыть нельзя. И автору об этом в первом же комменте указали кстати.
Передом назад - это вот так, как я дальше пишу.
АБСОЛЮТНО ЛЮБАЯ система - это костыль, который помогает сделать что-то. И если не понять, чему этот костыль помогает, то его все еще можно имплементировать. Просто им не будут пользоваться, потому что "а зачем мне эта штука"? А если понять, зачем он делается, то вот мы и получили бизнес-требования (ака БТ) - ответы на вопросы "что", "зачем" и "сколько". И только из них становится ясно, кто по итогу будет пользоваться этим костылем. И узнать у этих людей (порой (но очень редко) это будут не люди, кстати) случаи, в которых этот костыль поможет - и зафиксировать их. В б-гомерзких сторях или в православных юз-кейсах или еще как-то. И назвать их "пользовательские требования" (ПТ). И они всегда и это вообще неочевидно - следствие БП. И только поняв, сценарии юзания этого костыля (это все те же ПТ) - писать уже крнкретно требования к способу воплощения костыля в жизнь так, чтоб он под эти сценарии по итогу подпал. И это называется "требования к решению" (ТР). И они - прямое следствие ПЕ, которые сами - следствие БТ. А ТР могут быть про то, а) что костыль должен уметь (функциональные требования, ФТ) и б) как он должен это уметь (нефункциональные требования, НФТ). ФТ + НФТ = ТР.
Т.е., в сути своей предыдущий абзац звучит так:
БТ -> ПТ -> ТР. И это без шуток часто открытие для юниоров и неосведомленных
ТР = ФТ + НФТ. Это, в принципе, минимальный набор, формирующий ТЗ. Но это ТЗ без возможости доработки. Потому что доработка потребует ПТ, а их тут нет, как видно. И вот так - правильно. И этот подход всегда один и тот же. И это именно то самое ремесленничество. Новый проект? Пришел на дискавери, вызнал БТ, сформировал пул будущих юзеров, узнал у них ПТ, сочинил ФТ. Потом у всех поспрашивал и сформировал НФТ. Конец. Все всегда одинаково.
Ну и с высоты сказанного, о чем написал автор. По всему тексту размазаны ПТ, причем пользователь - это автор ("Суперкорень нам вряд ли завтра пригодится", "Как мы понимаем сейчас, интерфейс вполне может быть как минимум голосовым, если не тактильным по Брайлю" и т.п.) и НФТ, и у них то как раз нормальный источник - все подряд ("Калькулятор должен работать на устройствах Redmi 9A (32 Гб)", "Калькулятор должен выполнять вычисления над выражениями с надёжностью не меньше, чем 98%", "у Google Play есть собственные рекомендации и ограничения"). А в резюмирующей главе - ФТ (это которые функции с микро-ограничениями) и НФТ (которые макроограничения). БТ в статье нет. По итогу автор выдал-таки ТЗ, но потому что старался, а не потому знал как надо.
И я бы написал, почему автор тут ни в чем не виноват, но этот коммент и так уже больше страницы высотой. Но если кто захочет - говорите, напишу)
Спасибо за наводку, это как минимум интересно)
И, собственно, как я и говорил - идея-то на поверхности, но это нужно 3,5 человекам)
Подправил картинку
Это их официальный термин)
Но я по тем же причинам в голове называю это "мид-поли".
У меня (уже когда я статьи писал) возникла версия, что в экзешник засовывали то, что чаще встречается - для "хэширования", но потом я тоже склонился к версии с хвостами.
А еще мне нравилось, когда включаешь разворот на месте, выключаешь его, а вертолет еще немного по инерции доворачивается
Оказывается, я не один такой)
Мне вот как-то больше понравился 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 это фрэймворк, а не закон! Кастомизируй под нужды!". И при этом в джире дефолтные ишью тайпы - сторя и таска. Так и живем.
Извините. )