Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).
Для маленького проекта и маленькой команды можно заполнить эксельку и получить индикатор здоровья проекта, сделать это в одиночку за полчаса (в первый раз) или за 5 минут (последующие).
Если какая-то альфа сильно отстает от другой, это скорее всего будет означать некий проектный риск.
К примеру, если для системы уже выбрана архитектура и даже частично реализована, но мы не знаем кто будут ключевые стейкхолдеры, а тем более они в проект никак не вовлечены, у нас появляется риск, что разрабатываемая система их не удовлетворит.
Или скажем метод работы (технология) используется и работает хорошо, а для коммерческой возможности ценность неустановлена, а может и необходимость решения отсутствует — будет означать риск того, что бюджет не сойдется.
Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.
Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.
Платеж отложенный на полгода — это обычное дело и сейчас.
Банки под такие обязательства вполне себе выдают кредиты. Это называется факторинг.
Здесь отсрочка только больше будет и требование обеспечения гарантий включены, но скорее всего и это можно будет в факторинговых договорах как-то учесть.
С этим я пожалуй соглашусь, за исключением двух моментов, прошу комментировать если они выглядят спорными:
я не уверен что их вообще стоит противопоставлять — основное отличие кажется именно в том, что они указывают на разный контекст применения
если говорим "технологический процесс" мы сразу же смещаем фокус нашего разговора в сторону описания самого этого технологического процесса, в то время как у статьи основной фокус — описание структуры организации и взаимодействия ролей.
Т.е. здесь мы говорим скорее о модульности организации как следствии функциональной декомпозиции ее [какой-то части], и кажется что в этом контексте корректнее говорить об оргпроцессах/бизнес-процессах, чем о технологических. Оргпроцесс как функциональная часть организации (нас интересуют именно они) реализуется технологическим процессом (т.е. способом обеспечения ЖЦ некоего технологического объекта). Да, в статье имеется некое неоднозначное сращение этих двух аспектов, цель которого — упрощение повествования для аудитории указанной в самом начале поста. Надеюсь оно не сбило никого с толку.
Здесь можно углубиться в дискуссию о терминах и взять базой какой-нибудь BABoK, тогда более точным термином будет "бизнес-функция" (в рамках IT-организации, не обязательно в рамках бизнеса, который она обслуживает либо моделирует).
Мне лично нравится термин "оргпроцесс" как более точно отражающий суть.
Термин "бизнес-процесс" я выбрал потому что он скорее всего у читателей вызовет ассоциации с каким-то прописанным/прорисованным процессом, по которому работают люди, а "бизнес-функция" и "оргпроцесс" скорее всего окажутся непонятыми.
Возможно, связь между узлами «Количество задач в работе» и «Cycle Time» покажется контринтуитивной. Однако теория массового обслуживания объясняет, почему данная связь верна [13].
В данном случае это не совсем верно потому что несколько команд, каждая из которых работает по своему бэклогу — это не одна система, а несколько (хотя внутри каждой системы все будет верно).
Вторая причина почему закон Литтла будет применим на масштабе компании только ограниченно — он применим только для стационарных систем. Иными словами только для системы, в которой все задачи, которые попадают в бэклог будут обязательно выполнены и именно в том порядке, в котором они попали в систему.
При этом он отлично применим для количества задач, над которыми команда работает в каждый отдельный момент времени, или для общего бэклога, про который говорится в статье.
Но сама по себе идея общего бэклога очень интереснас, спасибо за статью!
Яндекс до "института" Cloud Solution Architect аля Амазон кажется еще не дошел — скорее всего придет к нему когда количество запросов от пользователей станет значительно выше чем "мощность" внутренней разработки.
В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.
Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).
Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.
Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.
Команды разработки создают и поддерживают клиентские приложения.
SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).
Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).
Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.
В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.
Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.
Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.
Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).
Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.
Это всё говорит о том, что применялся не тот подход, который я описываю, а devops "второго поколения" (я привел три условных "поколения devops" в статье).
Перечитайте блок, который начинается "По сути современный DevOps (и DevOps ближайшего будущего) и заключается в" -- судя по ответам у вас кажется ничего озвученного не было представлено.
Т.е. у тех, кто строил пользовательские сценарии для команд разработки не было квалификации строить такие сценарии? Кажется вы сами только что назвали причину неудачи в вашем случае.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки? Почему при всех названных недостатках команды разработки все равно выбирали то неудобное, что им предоставляли, а не делали вместо этого свои неэффективные, но зато понятные и удобные велосипеды? Как оценивали удобство и простоту использования этих сценариев? Кто двигал всю эту деятельность и отвечал за нее?
Не столько противоречие, сколько то, что ITIL не поднимается выше уровня сервиса/услуги (если я правильно понимаю), а в данном случае построение адаптивных самостоятельно модифицируемых сценариев - одна из ключевых активностей. Примерно по такой же причине продуктовая разработка и UX-дизайн ортогональны ITIL.
На уровне сервисов же, которые используются в этих сценариях скорее всего никакого противоречия нет.
Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).
Для маленького проекта и маленькой команды можно заполнить эксельку и получить индикатор здоровья проекта, сделать это в одиночку за полчаса (в первый раз) или за 5 минут (последующие).
Если какая-то альфа сильно отстает от другой, это скорее всего будет означать некий проектный риск.
К примеру, если для системы уже выбрана архитектура и даже частично реализована, но мы не знаем кто будут ключевые стейкхолдеры, а тем более они в проект никак не вовлечены, у нас появляется риск, что разрабатываемая система их не удовлетворит.
Или скажем метод работы (технология) используется и работает хорошо, а для коммерческой возможности ценность неустановлена, а может и необходимость решения отсутствует — будет означать риск того, что бюджет не сойдется.
Ну и т.д.
Про динамическую пересборку я не задумывался, но кажется она уложится в эту же схему. И ключевые вопросы озвученные в конце статьи останутся теми же.
Спасибо за идею!
Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.
Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.
Или вы что-то другое имели в виду?
Платеж отложенный на полгода — это обычное дело и сейчас.
Банки под такие обязательства вполне себе выдают кредиты. Это называется факторинг.
Здесь отсрочка только больше будет и требование обеспечения гарантий включены, но скорее всего и это можно будет в факторинговых договорах как-то учесть.
Мне строители-каркасники говорили, что черные саморезы лопаются при поперечных нагрузках, а желтые нет.
Спасибо за ссылку!
С этим я пожалуй соглашусь, за исключением двух моментов, прошу комментировать если они выглядят спорными:
я не уверен что их вообще стоит противопоставлять — основное отличие кажется именно в том, что они указывают на разный контекст применения
если говорим "технологический процесс" мы сразу же смещаем фокус нашего разговора в сторону описания самого этого технологического процесса, в то время как у статьи основной фокус — описание структуры организации и взаимодействия ролей.
Т.е. здесь мы говорим скорее о модульности организации как следствии функциональной декомпозиции ее [какой-то части], и кажется что в этом контексте корректнее говорить об оргпроцессах/бизнес-процессах, чем о технологических. Оргпроцесс как функциональная часть организации (нас интересуют именно они) реализуется технологическим процессом (т.е. способом обеспечения ЖЦ некоего технологического объекта). Да, в статье имеется некое неоднозначное сращение этих двух аспектов, цель которого — упрощение повествования для аудитории указанной в самом начале поста. Надеюсь оно не сбило никого с толку.
Здесь можно углубиться в дискуссию о терминах и взять базой какой-нибудь BABoK, тогда более точным термином будет "бизнес-функция" (в рамках IT-организации, не обязательно в рамках бизнеса, который она обслуживает либо моделирует).
Мне лично нравится термин "оргпроцесс" как более точно отражающий суть.
Термин "бизнес-процесс" я выбрал потому что он скорее всего у читателей вызовет ассоциации с каким-то прописанным/прорисованным процессом, по которому работают люди, а "бизнес-функция" и "оргпроцесс" скорее всего окажутся непонятыми.
Да, с coArchi все нормально — я сперва не разобрался как он работает и дума, что он в том же формате хранит данные.
Все отлично!
В данном случае это не совсем верно потому что несколько команд, каждая из которых работает по своему бэклогу — это не одна система, а несколько (хотя внутри каждой системы все будет верно).
Вторая причина почему закон Литтла будет применим на масштабе компании только ограниченно — он применим только для стационарных систем. Иными словами только для системы, в которой все задачи, которые попадают в бэклог будут обязательно выполнены и именно в том порядке, в котором они попали в систему.
При этом он отлично применим для количества задач, над которыми команда работает в каждый отдельный момент времени, или для общего бэклога, про который говорится в статье.
Но сама по себе идея общего бэклога очень интереснас, спасибо за статью!
Яндекс до "института" Cloud Solution Architect аля Амазон кажется еще не дошел — скорее всего придет к нему когда количество запросов от пользователей станет значительно выше чем "мощность" внутренней разработки.
В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.
Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).
Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.
Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.
Про роли я ответил чуть выше: https://habr.com/ru/post/657593/#comment_24208167
Какие "эти люди"?
Команды разработки создают и поддерживают клиентские приложения.
SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).
Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).
Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.
В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.
Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.
Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.
Извините, я на эту реплику отвечать не буду, как и на возможный тред, с обсуждением одной и той же темы по кругу в сотый раз.
По теме статьи по прежнему готов пообщаться.
Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).
Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.
Это всё говорит о том, что применялся не тот подход, который я описываю, а devops "второго поколения" (я привел три условных "поколения devops" в статье).
Перечитайте блок, который начинается "По сути современный DevOps (и DevOps ближайшего будущего) и заключается в" -- судя по ответам у вас кажется ничего озвученного не было представлено.
Т.е. у тех, кто строил пользовательские сценарии для команд разработки не было квалификации строить такие сценарии? Кажется вы сами только что назвали причину неудачи в вашем случае.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки? Почему при всех названных недостатках команды разработки все равно выбирали то неудобное, что им предоставляли, а не делали вместо этого свои неэффективные, но зато понятные и удобные велосипеды? Как оценивали удобство и простоту использования этих сценариев? Кто двигал всю эту деятельность и отвечал за нее?
Не столько противоречие, сколько то, что ITIL не поднимается выше уровня сервиса/услуги (если я правильно понимаю), а в данном случае построение адаптивных самостоятельно модифицируемых сценариев - одна из ключевых активностей. Примерно по такой же причине продуктовая разработка и UX-дизайн ортогональны ITIL.
На уровне сервисов же, которые используются в этих сценариях скорее всего никакого противоречия нет.