Pull to refresh
9
0
Timur Batyrshin @erthad

User

Send message

Я вижу пользу от оценок в том, что тебе придется как-то декомпозировать задачу и прикинуть где что-то может пойти не так. А именно это улучшает планирование.
Т.е. оценки это не столько способ предсказания, сколько первообразная для индикатора качества декомпозиции.

Если я не ошибаюсь, это конспект доклада рассказанного на одном из недавних DevOpsConf.

Тоны учатся за полгода и дальше просто естественным образом начинают использоваться и пониматься, даже без специального интонирования. В плане произношения гораздо более сложны шипящие, которых штук 6 похожих друг на друга как две капли воды.

А в плане изучения самое большое отличие от западных языков - огромный объём домашней самостоятельной работы без которой язык не выучишь - писать и читать иероглифы и т.д. Какой-нибудь английский можно изучить чисто в процессе очных занятий с преподавателем/группой. С китайским такое невозможно.

Там смысл не зависит от порядка слов - правила ещё более жёсткие чем в английском, грамматика намного более скудная (нет времен, родов, падежей и т.д.).

Для маленького проекта и маленькой команды можно заполнить эксельку и получить индикатор здоровья проекта, сделать это в одиночку за полчаса (в первый раз) или за 5 минут (последующие).

Если какая-то альфа сильно отстает от другой, это скорее всего будет означать некий проектный риск.

К примеру, если для системы уже выбрана архитектура и даже частично реализована, но мы не знаем кто будут ключевые стейкхолдеры, а тем более они в проект никак не вовлечены, у нас появляется риск, что разрабатываемая система их не удовлетворит.

Или скажем метод работы (технология) используется и работает хорошо, а для коммерческой возможности ценность неустановлена, а может и необходимость решения отсутствует — будет означать риск того, что бюджет не сойдется.

Ну и т.д.

Про динамическую пересборку я не задумывался, но кажется она уложится в эту же схему. И ключевые вопросы озвученные в конце статьи останутся теми же.

Спасибо за идею!

Спасибо за комментарий! Да, идея о "модифицирующих командах" была введена в книге Team Topologies. Здесь я пытаюсь разобрать вариант как такие команды могли бы работать, потому что к этому у меня лично много вопросов.

Касательно вашего комментария о динамическом профиле команды — имеются в виду долгоживущие "проекты" длиной в несколько лет? Я не уверен, что команду можно сильно поменять на горизонте планирования меньше чем полгода-год, команде же не только учиться и меняться, но еще и работать нужно.

Или вы что-то другое имели в виду?

Платеж отложенный на полгода — это обычное дело и сейчас.

Банки под такие обязательства вполне себе выдают кредиты. Это называется факторинг.

Здесь отсрочка только больше будет и требование обеспечения гарантий включены, но скорее всего и это можно будет в факторинговых договорах как-то учесть.

Мне строители-каркасники говорили, что черные саморезы лопаются при поперечных нагрузках, а желтые нет.

Спасибо за ссылку!

С этим я пожалуй соглашусь, за исключением двух моментов, прошу комментировать если они выглядят спорными:

  • я не уверен что их вообще стоит противопоставлять — основное отличие кажется именно в том, что они указывают на разный контекст применения

  • если говорим "технологический процесс" мы сразу же смещаем фокус нашего разговора в сторону описания самого этого технологического процесса, в то время как у статьи основной фокус — описание структуры организации и взаимодействия ролей.

Т.е. здесь мы говорим скорее о модульности организации как следствии функциональной декомпозиции ее [какой-то части], и кажется что в этом контексте корректнее говорить об оргпроцессах/бизнес-процессах, чем о технологических. Оргпроцесс как функциональная часть организации (нас интересуют именно они) реализуется технологическим процессом (т.е. способом обеспечения ЖЦ некоего технологического объекта). Да, в статье имеется некое неоднозначное сращение этих двух аспектов, цель которого — упрощение повествования для аудитории указанной в самом начале поста. Надеюсь оно не сбило никого с толку.

Здесь можно углубиться в дискуссию о терминах и взять базой какой-нибудь BABoK, тогда более точным термином будет "бизнес-функция" (в рамках IT-организации, не обязательно в рамках бизнеса, который она обслуживает либо моделирует).

Мне лично нравится термин "оргпроцесс" как более точно отражающий суть.

Термин "бизнес-процесс" я выбрал потому что он скорее всего у читателей вызовет ассоциации с каким-то прописанным/прорисованным процессом, по которому работают люди, а "бизнес-функция" и "оргпроцесс" скорее всего окажутся непонятыми.

Да, с coArchi все нормально — я сперва не разобрался как он работает и дума, что он в том же формате хранит данные.

Все отлично!

Возможно, связь между узлами «Количество задач в работе» и «Cycle Time» покажется контринтуитивной. Однако теория массового обслуживания объясняет, почему данная связь верна [13].

В данном случае это не совсем верно потому что несколько команд, каждая из которых работает по своему бэклогу — это не одна система, а несколько (хотя внутри каждой системы все будет верно).

Вторая причина почему закон Литтла будет применим на масштабе компании только ограниченно — он применим только для стационарных систем. Иными словами только для системы, в которой все задачи, которые попадают в бэклог будут обязательно выполнены и именно в том порядке, в котором они попали в систему.

При этом он отлично применим для количества задач, над которыми команда работает в каждый отдельный момент времени, или для общего бэклога, про который говорится в статье.

Но сама по себе идея общего бэклога очень интереснас, спасибо за статью!

Яндекс до "института" Cloud Solution Architect аля Амазон кажется еще не дошел — скорее всего придет к нему когда количество запросов от пользователей станет значительно выше чем "мощность" внутренней разработки.

В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.

Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).

Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.

Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.

Про роли я ответил чуть выше: https://habr.com/ru/post/657593/#comment_24208167

Какие "эти люди"?

  • Команды разработки создают и поддерживают клиентские приложения.

  • SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).

  • Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).

  • Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.

В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.

Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.

Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.

Извините, я на эту реплику отвечать не буду, как и на возможный тред, с обсуждением одной и той же темы по кругу в сотый раз.

По теме статьи по прежнему готов пообщаться.

Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).

Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.

Information

Rating
Does not participate
Location
Казань, Татарстан, Россия
Registered
Activity