Об DevOps и архитектуру

Об менеджерское и инженерное рассмотрение процесса разработки [2/2]

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

Итак, если рассмотреть особенности этих двух ролевые позиций - менеджера и инженера, то сразу становится ясна причина по которой звучат разные фантастические призывы вокруг DevOps, что мол "devops-инженер должен наладить взаимодействие между разными командами"  —  если смотреть на вещи как и прежде, с позиции менеджера, вполне закономерно будет казаться именно это. При этом, первый более-менее внятный ответ на вопрос в чем именно будет состоять «налаживание взаимодействия» кажется было дано лишь в подходе Team Topologies, и именно в нем снова начали говорить о «контрактах» между командами, до этого были достаточно пространные (с т.з. менеджера) слова про «коллаборацию» и «работу на общую цель», т.е. опять таки решение инженерное. UPD: скорее следующее будет не так, см обсуждение: Но раз у нас происходит разворот от менеджмента к инженерии, это налаживание взаимодействия (с т.з. корректировки обязанностей и контроля их выполнения) скорее становится новой задачей как раз таки менеджера (и это уже будет какой-то другой вид менеджера, например, scrum-мастер или менеджер потока). Инженерной же задачей здесь будет организация собственно технологического процесса, и этот технологический процесс будет затрагивать не только собственно конвеер CI/CD, но и фазы архитектурного проектирования и анализа. Как я писал чуть раньше, эту самую инженерную задачу скорее всего будет формулировать руководитель разработки. Devops-инженер же будет реализовывать по этому заданию конкретные компоненты сквозного процесса - подобно тому как разработчики реализуют бизнес-функциональность приложения по спеке/набору user stories от владельца продукта.

И еще один момент. Глядя на это же самое обстоятельство нельзя ставить знак "равно" между ITIL и DevOps. ITIL - дисциплина для менеджеров, даже несмотря на то, что в 4й версии его авторы изо всех сил постарались сделать его инженерным. Глядя же, например, на DevOps-топологии мы явно видим, что все топологии где идет речь о разграничении ответственности (т.е. о менеджерском взгляде на вещи) считаются антипаттерном для DevOps.

Telegram

Об DevOps и архитектуру

В продолжение предыдущего поста и обсуждения в комментариях, давайте попробуем разобраться почему происходит описанное в нем, а именно почему исчезает "ориентация на результат", или почему в компании нет "высокой проектной культуры".
Для этого рассмотрим…

www.tgoop.com/devops_architecture/56

865 viewsTimur Batyrshin, edited  May 12, 2024 at 15:55

Об менеджерское и инженерное рассмотрение процесса разработки [2/2]

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

Итак, если рассмотреть особенности этих двух ролевые позиций - менеджера и инженера, то сразу становится ясна причина по которой звучат разные фантастические призывы вокруг DevOps, что мол "devops-инженер должен наладить взаимодействие между разными командами"  —  если смотреть на вещи как и прежде, с позиции менеджера, вполне закономерно будет казаться именно это. При этом, первый более-менее внятный ответ на вопрос в чем именно будет состоять «налаживание взаимодействия» кажется было дано лишь в подходе Team Topologies, и именно в нем снова начали говорить о «контрактах» между командами, до этого были достаточно пространные (с т.з. менеджера) слова про «коллаборацию» и «работу на общую цель», т.е. опять таки решение инженерное. UPD: скорее следующее будет не так, см обсуждение: Но раз у нас происходит разворот от менеджмента к инженерии, это налаживание взаимодействия (с т.з. корректировки обязанностей и контроля их выполнения) скорее становится новой задачей как раз таки менеджера (и это уже будет какой-то другой вид менеджера, например, scrum-мастер или менеджер потока). Инженерной же задачей здесь будет организация собственно технологического процесса, и этот технологический процесс будет затрагивать не только собственно конвеер CI/CD, но и фазы архитектурного проектирования и анализа. Как я писал чуть раньше, эту самую инженерную задачу скорее всего будет формулировать руководитель разработки. Devops-инженер же будет реализовывать по этому заданию конкретные компоненты сквозного процесса - подобно тому как разработчики реализуют бизнес-функциональность приложения по спеке/набору user stories от владельца продукта.

И еще один момент. Глядя на это же самое обстоятельство нельзя ставить знак "равно" между ITIL и DevOps. ITIL - дисциплина для менеджеров, даже несмотря на то, что в 4й версии его авторы изо всех сил постарались сделать его инженерным. Глядя же, например, на DevOps-топологии мы явно видим, что все топологии где идет речь о разграничении ответственности (т.е. о менеджерском взгляде на вещи) считаются антипаттерном для DevOps.

BY Об DevOps и архитектуру