В начале статьи есть мотивация от технического лида про качество. А далее у нас куча параграфов про продукт и качество продукта. С достаточно поверхностным упоминанием технического долга. Как будто не человек писал, а ChatGPT. Много умных слов, а смысла нет.
Технический лид с вами говорит про техническое качество, а не про продуктовое. Услышьте его. Не надо стремление к техническому совершенству команды разработки подменять циклическим развитием продукта. Это две разные стороны одной медали.
Тогда надо еще и бирюзовость вообще исключать из подходов в рамках статьи. Классический фиолетовый подход согласно спиральной динамики компаний. Его, кстати, частенько можно спутать с зеленым именно по причине кажущейся свободы и экологичности внутри. Только вот проблема, что цели у них разные. Фиолетовые просто хотят сохранять уклад и привычное течение бизнеса.
Кстати раз уж про цвета заговорили. Вы ведь в курсе, что бирюзовые компании - это скорее маркетингово-консалтинговый миф, нежели реальные единорожьи истории?
Если бы в начале статьи было написано, что это история про консалтинг и 23 человека, читало бы намного меньше людей этот лонгрид. А где гарантия того, что за всем этим повествованием нет еще миллиона скрытых фактов? К сожалению, больше похоже на pr, чем на честное желание показать, что в нашем мире есть открытые и прозрачные способы самоуправления.
Со стороны выглядит, что мы говорим про бирюзу красными словами...
Извините. Но у вас все с ног на голову перевернуто. Повозка управляет человеком.
DevOps - методология о постановке процесса поставки ценности. Характеризуется тремя путями:
1.Построение пайпа поставки
2.Организация петель обратной связи
3.Культура экспериментирования и обучения
Автоматизация - один из множества инструментов достижения. Он важен, но очень часто фокус на нем убивает всю идею методологии. Если же его ставить во главу всего, получаем карго-культ, с адептами, которые делают работу, ради работы, а не ради цели к которой она должна привести.
Важно помнить, что настоящего хирурга хирургом делает не наличие скальпеля или даже умение им пользоваться, а обширные знания в медицине подкрепленные практическим опытом.
Процитирую вас. Если мы имеем дело с кросс-функциональными самоорганизованными командами, на самом деле выделение отдельной компетенции в отдельном человеке — это глупо. Если все или большинство в команде понимают, что такое девопс — это очень хорошо. Так что ситуация, которую вы описываете, намного больше девопс, чем когда целые отделы девопс спецов набирают.
Про масштабы писали в комментариях. Для работы нескольких команд есть "надстройки" над agile-фреймворками. LeSS, к примеру. Это лучшее решение, чем отдельный человек-"синхронизатор" в каком-то вопросе. Правда внедрять все это — большая работа.
Это не совсем то. В скраме есть три роли. Владелец продукта, скрам-мастер и девелопер. Под понятие девелопера подпадают все участники команды. Не забываем про кросс-функциональность к которой стремятся в скрам командах.
Хотя с другой стороны, если бы девопс внедрялся аналогично было бы намного лучше.
Не суть совсем. Я просто ответил в вашем треде.
Но опять же. Смотря что мы понимаем под пайплайном. У девопса по сути из более-менее сформулированных моментов. Это как раз "три пути". Первый как раз — построение линии поставки.
Ну да. Это один из вариантов. Возглавить. В моем случае в самом начале моего пути, года 4-5 назад, когда я только пришел в на новую для себя должность девопс-инженер (да я тоже не существующий специалист )) ), это возглавлял на тот момент PO нашего стартапа. Был ли он сам тогда девопс-инженером — нет. Двигал ли он девопс практики — да! Еще как. Сам того тогда до конца возможно не понимая.
А про возглавить. Очень спорный момент. Вся гибкая разработка строится на горизонтальных командах. Но это уже совсем другая история.
Полностью с вами согласен. Вот только к пониманию простой мысли, написанной вами, весь рынок идет ужасно кривым путем. Кого только девопсом не называют, лишь бы соответствовать трендам. И это все очень печально.
У меня, например, пайплайны в основном разработчики сейчас выстраивают и используют. Причем в нескольких продуктовых командах. И владеют и используют. Вот только скажи им, что они девопс-инженеры, похлопают по плечу и скажут — харе троллить. Мы мол разработчики, которые работают с использованием девопс-практик.
А мне только и остается, что стараться синхронизировать их знания, на их же митапах, чтобы практики в зоопарк не превращались. Людей-то много.
На тренингах по скраму есть понятие копипаст скрам. Это как раз когда менеджера проекта берут, основные атрибуты добавляют, а мысли и идеологии не придерживаются. Так что да. Бывают пооекты, где менеджер есть, а проекта в полном понимании нет.
Как раз таки и пытаюсь вам объяснить, что выстраивание процесса — это коллективное действие. Один человек не может вместо коллектива этим заниматься. Максимум, что он может — это обучать этот коллектив. Находить единомышленников, работать в направлении внедрения девопс практик. Находить совместно с колегами нужные инструменты. Внедрять их тоже, но опять же понимая зачем это все нужно и доносить это понимание или приобретать с остальными вместе.
Если вам удобно такого человека называть девопс-инженером. То почему бы и нет. Просто термин так себе по-моему. И рынком уже сильно скомпроментирован, к моему сожалению.
Про разработчика согласен — спокойно может быть человеком, который продвигает девопс в компаниях.
Про девопс-инженера. Выстраивание процессов — это совместная работа нескольких подразделений. Не может этим заниматься один человек.
Точнее, к сожалению, последнее время так многие как раз и стараются поступать. Берут себе девопс-инженера и такие давай. Выстраивай. И что может этот человек. Настроить ci. Написать деплой. Обложить прод мониторингом. Роли, которые он выполняет в этот момент я перечислял выше.
Но если зайти с другим подходом. Когда несколько команд с лидером, назовем его PO. Собираются. Нам надо ускорить разработку. Нам надо выкатывать фичи чаще. Как мы можем построить свою работу для этого? Хм. Ну давайте разбираться с гибкими методологиями разработки. Давайте пройдем обучение по одному из фреймворков (скрам, канбан). Давайте поймем суть 3-х путей. Выстроим линию поставки, наделаем петель обратной связи, будем шарить знания и не будем искать виноватых. Давайте будем все стремиться делиться компетенциями, чтобы говорить совместно на одном языке.
В первом случае человек есть, а девопса как такового нет. Копи-паста бездумная.
Во втором — человека нет. А девопс есть. Ну или можно сказать, что все там девопс-инженеры, и опс, и дев, и тестировщик, и PO, и т.д. Но их можно тогда называть и agile-инженерами, и еще как-то.
Когда я повторяю эту фразу про методологию, я не стремлюсь кого-то обидеть. Я просто хочу обратить внимание рынка на второй вариант.
Вы все очень сильно расширяете. Думаю надо довести все окончательно до абсурда и прийти выводу, что художник — человек. Ну и что человека нет. И знаете. Тут на границе с абсурдом я с вами полностью согласен. И не придраться ни к чему совсем. Вы правы.
Спасибо большое, за расширение кругозора. Слово инженер заиграло новыми красками для меня.
Полезены ли все эти рассуждения. По мне так они еще более запутывают и так, к сожалению, замученое рынком направление. Так что, я предпочту воздержаться от такого подхода. И остаться при своем мнении.
Мы работаем в изменяющейся отрасли. Об этом нельзя забывать. Сейчас знание докер, зачастую может принести больше денег бизнесу, чем знание того как устроена виртуальная память.
А через несколько лет все изменится еще сильнее. И мы должны это понимать и принимать.
Был бы тут umputun он бы наверное сказал — "вот она смерть сисадмина, о которой я уже не первый год говорю!" Вот только по мне так это скорее перерождение профессии.
Ну тут скорее хайп порождает зп, а не наоборот. На самом деле — если компании, которая занимается разработкой, реально удается найти грамотного спеца. Который владеет не только инструментарием, но и хотя бы общий язык может со всеми участниками процесса найти. Не говорю уж о чем-то большем. Там один обычно не вывозит, даже в небольших компаниях. То такая компания получает реальное преимущество над остальными. И деньги там платятся далеко не просто так.
Странное сравнение с андройд-разработчиком. Если брать методологию. То более корректный пример был бы со скрам-мастером. Там правда человек который следит за соответствием интерпритации (скрам) такой методолгии как agile. Но все же. Вы когда-нибудь встречали скрам-инженера? Я нет.
Девопс-евангелист — тоже довольно расплывчатая роль. Но более простая для понимания. Это человек, который работает с разработчиками, продакт-менеджерами и владельцами проекта. В направлении изменения процессов разработки. Построению взаимодействия всех заинтересованных отделов и бизнеса. Выправлениям целей. И прочее-прочее. Если продолжать аналогию со скрам-мастером — это как раз этакий центр обучения методологии. К сожалению только вот нет у него такой классной штуки как манифест в скраме. Есть только довольно расплывчатые 3 пути.
Знаете. Я не хочу обидеть тех кто считает себя devops-инженерами. В том числе потому, что уже года 4-5 как, так или иначе именуюсь этим термином. Но сам себе врать не хочу. Девопс — это не человек. Это больше про процессы. Про построение взаимодействий и т.д.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Радует только, что разработчики с которыми я работаю чаще понимают, что это не так.
Ну да. Тут непростой вопрос. Методолгия часто довольно рпсплывчатая штука. Есть большой набор книг на эту тему. Есть бережливое производство. Есть "три пути" девопс. Но нет четкости в имплементации. Именно поэтому sre-инженеры есть. Там гугл постарался наделить их недостающими в методологии подходами. Хотя понятие sre рынок сейчас тоже коверкает как только хочет.
В начале статьи есть мотивация от технического лида про качество. А далее у нас куча параграфов про продукт и качество продукта. С достаточно поверхностным упоминанием технического долга. Как будто не человек писал, а ChatGPT. Много умных слов, а смысла нет.
Технический лид с вами говорит про техническое качество, а не про продуктовое. Услышьте его. Не надо стремление к техническому совершенству команды разработки подменять циклическим развитием продукта. Это две разные стороны одной медали.
Тогда надо еще и бирюзовость вообще исключать из подходов в рамках статьи. Классический фиолетовый подход согласно спиральной динамики компаний. Его, кстати, частенько можно спутать с зеленым именно по причине кажущейся свободы и экологичности внутри. Только вот проблема, что цели у них разные. Фиолетовые просто хотят сохранять уклад и привычное течение бизнеса.
Кстати раз уж про цвета заговорили. Вы ведь в курсе, что бирюзовые компании - это скорее маркетингово-консалтинговый миф, нежели реальные единорожьи истории?
Если бы в начале статьи было написано, что это история про консалтинг и 23 человека, читало бы намного меньше людей этот лонгрид. А где гарантия того, что за всем этим повествованием нет еще миллиона скрытых фактов? К сожалению, больше похоже на pr, чем на честное желание показать, что в нашем мире есть открытые и прозрачные способы самоуправления.
Со стороны выглядит, что мы говорим про бирюзу красными словами...
Извините. Но у вас все с ног на голову перевернуто. Повозка управляет человеком.
DevOps - методология о постановке процесса поставки ценности. Характеризуется тремя путями:
1.Построение пайпа поставки
2.Организация петель обратной связи
3.Культура экспериментирования и обучения
Автоматизация - один из множества инструментов достижения. Он важен, но очень часто фокус на нем убивает всю идею методологии. Если же его ставить во главу всего, получаем карго-культ, с адептами, которые делают работу, ради работы, а не ради цели к которой она должна привести.
Важно помнить, что настоящего хирурга хирургом делает не наличие скальпеля или даже умение им пользоваться, а обширные знания в медицине подкрепленные практическим опытом.
Процитирую вас. Если мы имеем дело с кросс-функциональными самоорганизованными командами, на самом деле выделение отдельной компетенции в отдельном человеке — это глупо. Если все или большинство в команде понимают, что такое девопс — это очень хорошо. Так что ситуация, которую вы описываете, намного больше девопс, чем когда целые отделы девопс спецов набирают.
Про масштабы писали в комментариях. Для работы нескольких команд есть "надстройки" над agile-фреймворками. LeSS, к примеру. Это лучшее решение, чем отдельный человек-"синхронизатор" в каком-то вопросе. Правда внедрять все это — большая работа.
Это не совсем то. В скраме есть три роли. Владелец продукта, скрам-мастер и девелопер. Под понятие девелопера подпадают все участники команды. Не забываем про кросс-функциональность к которой стремятся в скрам командах.
Хотя с другой стороны, если бы девопс внедрялся аналогично было бы намного лучше.
Насильно мил не будешь.
Не суть совсем. Я просто ответил в вашем треде.
Но опять же. Смотря что мы понимаем под пайплайном. У девопса по сути из более-менее сформулированных моментов. Это как раз "три пути". Первый как раз — построение линии поставки.
Ну да. Это один из вариантов. Возглавить. В моем случае в самом начале моего пути, года 4-5 назад, когда я только пришел в на новую для себя должность девопс-инженер (да я тоже не существующий специалист )) ), это возглавлял на тот момент PO нашего стартапа. Был ли он сам тогда девопс-инженером — нет. Двигал ли он девопс практики — да! Еще как. Сам того тогда до конца возможно не понимая.
А про возглавить. Очень спорный момент. Вся гибкая разработка строится на горизонтальных командах. Но это уже совсем другая история.
Полностью с вами согласен. Вот только к пониманию простой мысли, написанной вами, весь рынок идет ужасно кривым путем. Кого только девопсом не называют, лишь бы соответствовать трендам. И это все очень печально.
У меня, например, пайплайны в основном разработчики сейчас выстраивают и используют. Причем в нескольких продуктовых командах. И владеют и используют. Вот только скажи им, что они девопс-инженеры, похлопают по плечу и скажут — харе троллить. Мы мол разработчики, которые работают с использованием девопс-практик.
А мне только и остается, что стараться синхронизировать их знания, на их же митапах, чтобы практики в зоопарк не превращались. Людей-то много.
На тренингах по скраму есть понятие копипаст скрам. Это как раз когда менеджера проекта берут, основные атрибуты добавляют, а мысли и идеологии не придерживаются. Так что да. Бывают пооекты, где менеджер есть, а проекта в полном понимании нет.
Как раз таки и пытаюсь вам объяснить, что выстраивание процесса — это коллективное действие. Один человек не может вместо коллектива этим заниматься. Максимум, что он может — это обучать этот коллектив. Находить единомышленников, работать в направлении внедрения девопс практик. Находить совместно с колегами нужные инструменты. Внедрять их тоже, но опять же понимая зачем это все нужно и доносить это понимание или приобретать с остальными вместе.
Если вам удобно такого человека называть девопс-инженером. То почему бы и нет. Просто термин так себе по-моему. И рынком уже сильно скомпроментирован, к моему сожалению.
Ответил Вам выше. В другом треде.
Про разработчика согласен — спокойно может быть человеком, который продвигает девопс в компаниях.
Про девопс-инженера. Выстраивание процессов — это совместная работа нескольких подразделений. Не может этим заниматься один человек.
Точнее, к сожалению, последнее время так многие как раз и стараются поступать. Берут себе девопс-инженера и такие давай. Выстраивай. И что может этот человек. Настроить ci. Написать деплой. Обложить прод мониторингом. Роли, которые он выполняет в этот момент я перечислял выше.
Но если зайти с другим подходом. Когда несколько команд с лидером, назовем его PO. Собираются. Нам надо ускорить разработку. Нам надо выкатывать фичи чаще. Как мы можем построить свою работу для этого? Хм. Ну давайте разбираться с гибкими методологиями разработки. Давайте пройдем обучение по одному из фреймворков (скрам, канбан). Давайте поймем суть 3-х путей. Выстроим линию поставки, наделаем петель обратной связи, будем шарить знания и не будем искать виноватых. Давайте будем все стремиться делиться компетенциями, чтобы говорить совместно на одном языке.
В первом случае человек есть, а девопса как такового нет. Копи-паста бездумная.
Во втором — человека нет. А девопс есть. Ну или можно сказать, что все там девопс-инженеры, и опс, и дев, и тестировщик, и PO, и т.д. Но их можно тогда называть и agile-инженерами, и еще как-то.
Когда я повторяю эту фразу про методологию, я не стремлюсь кого-то обидеть. Я просто хочу обратить внимание рынка на второй вариант.
Вы все очень сильно расширяете. Думаю надо довести все окончательно до абсурда и прийти выводу, что художник — человек. Ну и что человека нет. И знаете. Тут на границе с абсурдом я с вами полностью согласен. И не придраться ни к чему совсем. Вы правы.
Спасибо большое, за расширение кругозора. Слово инженер заиграло новыми красками для меня.
Полезены ли все эти рассуждения. По мне так они еще более запутывают и так, к сожалению, замученое рынком направление. Так что, я предпочту воздержаться от такого подхода. И остаться при своем мнении.
Мы работаем в изменяющейся отрасли. Об этом нельзя забывать. Сейчас знание докер, зачастую может принести больше денег бизнесу, чем знание того как устроена виртуальная память.
А через несколько лет все изменится еще сильнее. И мы должны это понимать и принимать.
Был бы тут umputun он бы наверное сказал — "вот она смерть сисадмина, о которой я уже не первый год говорю!" Вот только по мне так это скорее перерождение профессии.
Ну тут скорее хайп порождает зп, а не наоборот. На самом деле — если компании, которая занимается разработкой, реально удается найти грамотного спеца. Который владеет не только инструментарием, но и хотя бы общий язык может со всеми участниками процесса найти. Не говорю уж о чем-то большем. Там один обычно не вывозит, даже в небольших компаниях. То такая компания получает реальное преимущество над остальными. И деньги там платятся далеко не просто так.
Странное сравнение с андройд-разработчиком. Если брать методологию. То более корректный пример был бы со скрам-мастером. Там правда человек который следит за соответствием интерпритации (скрам) такой методолгии как agile. Но все же. Вы когда-нибудь встречали скрам-инженера? Я нет.
Девопс-евангелист — тоже довольно расплывчатая роль. Но более простая для понимания. Это человек, который работает с разработчиками, продакт-менеджерами и владельцами проекта. В направлении изменения процессов разработки. Построению взаимодействия всех заинтересованных отделов и бизнеса. Выправлениям целей. И прочее-прочее. Если продолжать аналогию со скрам-мастером — это как раз этакий центр обучения методологии. К сожалению только вот нет у него такой классной штуки как манифест в скраме. Есть только довольно расплывчатые 3 пути.
Знаете. Я не хочу обидеть тех кто считает себя devops-инженерами. В том числе потому, что уже года 4-5 как, так или иначе именуюсь этим термином. Но сам себе врать не хочу. Девопс — это не человек. Это больше про процессы. Про построение взаимодействий и т.д.
А когда очередной раз слышишь, что девопс — это инструменты — docker, kuber, ansible, jenkins, gitlab-ci, etc и дополнительно умение работать с облаками. Становится грустно.
Радует только, что разработчики с которыми я работаю чаще понимают, что это не так.
Ну да. Тут непростой вопрос. Методолгия часто довольно рпсплывчатая штука. Есть большой набор книг на эту тему. Есть бережливое производство. Есть "три пути" девопс. Но нет четкости в имплементации. Именно поэтому sre-инженеры есть. Там гугл постарался наделить их недостающими в методологии подходами. Хотя понятие sre рынок сейчас тоже коверкает как только хочет.