При старте нового проекта (или авральном подключении к существующему) руководителю нужно выполнить большое количество шагов планирования и коммуникации, чтобы работа двинулась в правильном направлении. Это можно сделать или в ватерфольном режиме, написав устав проекта, согласовав со всеми и т.д. …

Из всех тем, рассматриваемых в Team Topologies наиболее непонятная тема — это Enabling team, “модифицирующая” или “преобразующая” команда. Я буду использовать слово Модифицирующая Команда, потому что такой же перевод используется в Platen. (хотя мне лично больше нравится вариант Преобразующая Команда :-) В самой книге про нее говорится многих общих слов…

Если сравнивать “просто стикеры” в миро и Archimate, то Archimate удобнее тем, что мы в нем получаем “встроенную” валидацию типов, которую в случае стикеров приходится выполнять более явно. Скорее всего это применимо и для других формальных языков описаний (BPMN, UML и т.д.) в сравнении со “свободными” рассуждениями. С другой стороны, если понимания типов у человека нет все нотации мгновенно становятся бессмысленными. А для коммуникации нужны именно типы, пространство понятий, а не нотация.

В начале 20 века английский экономист Рональд Коуз изучал причину появления фирм на свободном рынке, и в своей статье Природа фирм он пришел к следующему: Трансакционные издержки (расходы на поиск и взаимодействие контрагентов и их контрактацию) внутри фирмы ниже, чем трансакционные издержки на рынке, и поэтому найм может оказаться дешевле…

Меня периодически спрашивают каким образом строить инфраструктуру для небольших проектов, когда в команде еще нет компетенций админа/девопс-инженера ни у руководителя или программистов, ни в в виде выделенного человека. Что при этом выбрать — выделенные сервера, облако или Kubernetes? …

Существует мнение, что тяжеловесные подходы проектирования (ITIL, TOGAF, ГОСТ34 и т.д.) несовместимы с быстрыми частыми релизами и изменениями. А следовательно, зачем их изучать? Это верно только отчасти. Во-первых вспомним всем известную методологическую максиму, которая упрощенно звучит как: “практика = дисциплина + технология”. …

Периодически поднимается тема того, чем отличается deploy от release, и на это есть элегантный ответ в недавно вышедшей новой версии стандарта IT4IT от The Open Group. Deploy — это собственно инсталляция новой версии продукта на продакшн (сюда же включают и удаление старых версий с продакшна). В этот процесс входят и…

Кажется, спустя полтора года после прочтения книги Accelerate наконец удалось кратко и компактно сформулировать в чем проблема с отчетом State Of Devops. Проблема в том, что в книге и отчете выпячивается та несомненно большая сложная часть работы по статистическим предсказаниям, которая однако по факту никому не нужна, и которая не…

Недавно вышли новые роадмапы профессионального развития на https://roadmap.sh/ и они на мой взгляд очень хорошо помогают прояснить мой предыдущий пост про то, что подход Infrastructure as Code — это особая форма разработки. Я не уверен, что согласен с названиями роадмапов, но разделение на роадмапы мне кажется очень хорошо сделанным: Software…