"User story" и подобные продуктовые инкременты можно представить в виде ЧТЗ.
Есть ТЗ на систему в целом, и ЧТЗ на отдельные функции.
Проблема "продуктов" в том, что на момент разработки продукта либо функции мы сами далеко не всегда понимаем что именно мы хотим разработать, а поэтому мы не можем прописать требования. И проектирование сценариев и разработка часто идут одновременно со сбором требований.
По этой причине и суть ТЗ, кажется превращается из собственно задания на разработку в некий чеклист, который нужно так или иначе учесть при разработке.
Я вижу пользу от оценок в том, что тебе придется как-то декомпозировать задачу и прикинуть где что-то может пойти не так. А именно это улучшает планирование. Т.е. оценки это не столько способ предсказания, сколько первообразная для индикатора качества декомпозиции.
Тоны учатся за полгода и дальше просто естественным образом начинают использоваться и пониматься, даже без специального интонирования. В плане произношения гораздо более сложны шипящие, которых штук 6 похожих друг на друга как две капли воды.
А в плане изучения самое большое отличие от западных языков - огромный объём домашней самостоятельной работы без которой язык не выучишь - писать и читать иероглифы и т.д. Какой-нибудь английский можно изучить чисто в процессе очных занятий с преподавателем/группой. С китайским такое невозможно.
Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).
Для маленького проекта и маленькой команды можно заполнить эксельку и получить индикатор здоровья проекта, сделать это в одиночку за полчаса (в первый раз) или за 5 минут (последующие).
Если какая-то альфа сильно отстает от другой, это скорее всего будет означать некий проектный риск.
К примеру, если для системы уже выбрана архитектура и даже частично реализована, но мы не знаем кто будут ключевые стейкхолдеры, а тем более они в проект никак не вовлечены, у нас появляется риск, что разрабатываемая система их не удовлетворит.
Или скажем метод работы (технология) используется и работает хорошо, а для коммерческой возможности ценность неустановлена, а может и необходимость решения отсутствует — будет означать риск того, что бюджет не сойдется.
Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.
Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.
Платеж отложенный на полгода — это обычное дело и сейчас.
Банки под такие обязательства вполне себе выдают кредиты. Это называется факторинг.
Здесь отсрочка только больше будет и требование обеспечения гарантий включены, но скорее всего и это можно будет в факторинговых договорах как-то учесть.
С этим я пожалуй соглашусь, за исключением двух моментов, прошу комментировать если они выглядят спорными:
я не уверен что их вообще стоит противопоставлять — основное отличие кажется именно в том, что они указывают на разный контекст применения
если говорим "технологический процесс" мы сразу же смещаем фокус нашего разговора в сторону описания самого этого технологического процесса, в то время как у статьи основной фокус — описание структуры организации и взаимодействия ролей.
Т.е. здесь мы говорим скорее о модульности организации как следствии функциональной декомпозиции ее [какой-то части], и кажется что в этом контексте корректнее говорить об оргпроцессах/бизнес-процессах, чем о технологических. Оргпроцесс как функциональная часть организации (нас интересуют именно они) реализуется технологическим процессом (т.е. способом обеспечения ЖЦ некоего технологического объекта). Да, в статье имеется некое неоднозначное сращение этих двух аспектов, цель которого — упрощение повествования для аудитории указанной в самом начале поста. Надеюсь оно не сбило никого с толку.
Здесь можно углубиться в дискуссию о терминах и взять базой какой-нибудь BABoK, тогда более точным термином будет "бизнес-функция" (в рамках IT-организации, не обязательно в рамках бизнеса, который она обслуживает либо моделирует).
Мне лично нравится термин "оргпроцесс" как более точно отражающий суть.
Термин "бизнес-процесс" я выбрал потому что он скорее всего у читателей вызовет ассоциации с каким-то прописанным/прорисованным процессом, по которому работают люди, а "бизнес-функция" и "оргпроцесс" скорее всего окажутся непонятыми.
Возможно, связь между узлами «Количество задач в работе» и «Cycle Time» покажется контринтуитивной. Однако теория массового обслуживания объясняет, почему данная связь верна [13].
В данном случае это не совсем верно потому что несколько команд, каждая из которых работает по своему бэклогу — это не одна система, а несколько (хотя внутри каждой системы все будет верно).
Вторая причина почему закон Литтла будет применим на масштабе компании только ограниченно — он применим только для стационарных систем. Иными словами только для системы, в которой все задачи, которые попадают в бэклог будут обязательно выполнены и именно в том порядке, в котором они попали в систему.
При этом он отлично применим для количества задач, над которыми команда работает в каждый отдельный момент времени, или для общего бэклога, про который говорится в статье.
Но сама по себе идея общего бэклога очень интереснас, спасибо за статью!
Яндекс до "института" Cloud Solution Architect аля Амазон кажется еще не дошел — скорее всего придет к нему когда количество запросов от пользователей станет значительно выше чем "мощность" внутренней разработки.
Спасибо за разбор, интересно!
Есть причины почему для дописывания не добавить пару классов в саму структуру Rails-приложения? Кажется это было бы проще чем писать обвязку на go? .
Почему IDEF0, а не Archimate?
"User story" и подобные продуктовые инкременты можно представить в виде ЧТЗ.
Есть ТЗ на систему в целом, и ЧТЗ на отдельные функции.
Проблема "продуктов" в том, что на момент разработки продукта либо функции мы сами далеко не всегда понимаем что именно мы хотим разработать, а поэтому мы не можем прописать требования. И проектирование сценариев и разработка часто идут одновременно со сбором требований.
По этой причине и суть ТЗ, кажется превращается из собственно задания на разработку в некий чеклист, который нужно так или иначе учесть при разработке.
Почему просто не взять asciidoc?
Всем привет, я решил свой прогноз развернуть подробнее, выложил его сюда: http://timurb.ru/kb/kuda-idet-devops/
Я вижу пользу от оценок в том, что тебе придется как-то декомпозировать задачу и прикинуть где что-то может пойти не так. А именно это улучшает планирование.
Т.е. оценки это не столько способ предсказания, сколько первообразная для индикатора качества декомпозиции.
Если я не ошибаюсь, это конспект доклада рассказанного на одном из недавних DevOpsConf.
Тоны учатся за полгода и дальше просто естественным образом начинают использоваться и пониматься, даже без специального интонирования. В плане произношения гораздо более сложны шипящие, которых штук 6 похожих друг на друга как две капли воды.
А в плане изучения самое большое отличие от западных языков - огромный объём домашней самостоятельной работы без которой язык не выучишь - писать и читать иероглифы и т.д. Какой-нибудь английский можно изучить чисто в процессе очных занятий с преподавателем/группой. С китайским такое невозможно.
Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).
Для маленького проекта и маленькой команды можно заполнить эксельку и получить индикатор здоровья проекта, сделать это в одиночку за полчаса (в первый раз) или за 5 минут (последующие).
Если какая-то альфа сильно отстает от другой, это скорее всего будет означать некий проектный риск.
К примеру, если для системы уже выбрана архитектура и даже частично реализована, но мы не знаем кто будут ключевые стейкхолдеры, а тем более они в проект никак не вовлечены, у нас появляется риск, что разрабатываемая система их не удовлетворит.
Или скажем метод работы (технология) используется и работает хорошо, а для коммерческой возможности ценность неустановлена, а может и необходимость решения отсутствует — будет означать риск того, что бюджет не сойдется.
Ну и т.д.
Про динамическую пересборку я не задумывался, но кажется она уложится в эту же схему. И ключевые вопросы озвученные в конце статьи останутся теми же.
Спасибо за идею!
Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.
Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.
Или вы что-то другое имели в виду?
Платеж отложенный на полгода — это обычное дело и сейчас.
Банки под такие обязательства вполне себе выдают кредиты. Это называется факторинг.
Здесь отсрочка только больше будет и требование обеспечения гарантий включены, но скорее всего и это можно будет в факторинговых договорах как-то учесть.
Мне строители-каркасники говорили, что черные саморезы лопаются при поперечных нагрузках, а желтые нет.
Спасибо за ссылку!
С этим я пожалуй соглашусь, за исключением двух моментов, прошу комментировать если они выглядят спорными:
я не уверен что их вообще стоит противопоставлять — основное отличие кажется именно в том, что они указывают на разный контекст применения
если говорим "технологический процесс" мы сразу же смещаем фокус нашего разговора в сторону описания самого этого технологического процесса, в то время как у статьи основной фокус — описание структуры организации и взаимодействия ролей.
Т.е. здесь мы говорим скорее о модульности организации как следствии функциональной декомпозиции ее [какой-то части], и кажется что в этом контексте корректнее говорить об оргпроцессах/бизнес-процессах, чем о технологических. Оргпроцесс как функциональная часть организации (нас интересуют именно они) реализуется технологическим процессом (т.е. способом обеспечения ЖЦ некоего технологического объекта). Да, в статье имеется некое неоднозначное сращение этих двух аспектов, цель которого — упрощение повествования для аудитории указанной в самом начале поста. Надеюсь оно не сбило никого с толку.
Здесь можно углубиться в дискуссию о терминах и взять базой какой-нибудь BABoK, тогда более точным термином будет "бизнес-функция" (в рамках IT-организации, не обязательно в рамках бизнеса, который она обслуживает либо моделирует).
Мне лично нравится термин "оргпроцесс" как более точно отражающий суть.
Термин "бизнес-процесс" я выбрал потому что он скорее всего у читателей вызовет ассоциации с каким-то прописанным/прорисованным процессом, по которому работают люди, а "бизнес-функция" и "оргпроцесс" скорее всего окажутся непонятыми.
Да, с coArchi все нормально — я сперва не разобрался как он работает и дума, что он в том же формате хранит данные.
Все отлично!
В данном случае это не совсем верно потому что несколько команд, каждая из которых работает по своему бэклогу — это не одна система, а несколько (хотя внутри каждой системы все будет верно).
Вторая причина почему закон Литтла будет применим на масштабе компании только ограниченно — он применим только для стационарных систем. Иными словами только для системы, в которой все задачи, которые попадают в бэклог будут обязательно выполнены и именно в том порядке, в котором они попали в систему.
При этом он отлично применим для количества задач, над которыми команда работает в каждый отдельный момент времени, или для общего бэклога, про который говорится в статье.
Но сама по себе идея общего бэклога очень интереснас, спасибо за статью!
Яндекс до "института" Cloud Solution Architect аля Амазон кажется еще не дошел — скорее всего придет к нему когда количество запросов от пользователей станет значительно выше чем "мощность" внутренней разработки.