Портал №1 по управлению цифровыми
и информационными технологиями

Обучение
по ITIL 4, ITSM, PRINCE2
Деловые
игры
Новые экзамены
по ITSM
Реестр ESM- и ITSM-систем в России 2024

DevOps

Современные идеи организации эффективной разработки программного обеспечения и развёртывания релизов.

Как поощрять Agile-команды?

Организации, стремящиеся стать гибкими, должны также обратить внимание и на формирование новой системы бонусов и стимулов, нацеленных на обеспечение и поддержку Agile-подходов. Независимо от того, насколько хорошо был спроектирован и осуществлён переход на новые методы работы, если будут продолжать действовать стимулы из “прошлой жизни”, способствующие прежнему же поведению, то сотрудники организации будут склонны вести себя “по-старому”. Автор заметки, Майк Кон (Mike Cohn), один из соавторов и основателей Scrum и Scrum Alliance,  называет это организационной гравитацией. Если культура организации не изменится в достаточной степени, чтобы стать другой – гибкой – организационная гравитация вернёт её в то состояние, в котором она пребывала…

Три причины растущей популярности DevOps

Первые упоминания о DevOps появились где-то в 2010 году. Примерно с этого момента времени энтузиасты начали активно интересоваться новой темой. Если заглянуть в Google Trends, то можно увидеть вот такой график популярности термина “DevOps” за последние 5 лет: А вот график за последние 15 лет: Как вы можете заметить, интерес к DevOps, стартовавший примерно в 2010 году, неуклонно рос и продолжает расти. При этом в начале 2019 года можно отметить резкий его всплеск . Конечно, стоит учитывать, что Google Trends – это не точные данные плюс закрытый исходный код самой платформы. И интерес к DevOps, измеряемый средствами Google, не является…

Кто отвечает за конвейер развёртывания?

Нужно очень сильно отстать от жизни (примерно лет на 5-7, что по нынешним временам приравнивается к вечности), либо иметь крайне веские аргументы, чтобы не использовать для доставки готового кода до среды эксплуатации конвейер развёртывания (в народе часто именуемый конвейером CI/CD, что в данном случае непринципиально). Техническая сторона вопроса – как построить конвейер – в большинстве случаев понятна, если не очевидна. Инструментов море, идеология ясна, собрать конвейер можно в простых случаях за час, в сложных – за пару недель. Организационная же сторона вопроса не так проста, как кажется. Кто должен/может его создать? Кто обеспечит функционирование? Кто починит, когда сломается? Кто будет…

Существует ли эффект Даннинга-Крюгера?

Многие слышали об этом эффекте. По легенде, менее компетентные люди склонны завышать собственную самооценку, в то время как более компетентные люди скорее будут её занижать. Соответственно, принимаемые решения могут быть неадекватны обстоятельствам по причине когнитивного искажения. Данное наблюдение сопровождается дополнительными свойствами. К примеру, декларируется, что эффекту подвержены практически все люди, вопрос только в степени искажения. Люди низкой квалификации неспособны осознавать свои ошибки, в силу той самой низкой квалификации. Людям с большим количеством знаний в определённой предметной области бывает непонятно, почему для остальных всё так сложно, ведь “на самом деле” всё довольно просто. Наверное, какая-то часть описания данного эффекта соответствует действительности….

Не кричите друг на друга (пожалуйста), или как подружить DevOps и ITIL

В своей недавней статье Paul Wilkinson делится рядом интересных наблюдений, сделанных во время деловой игры MarsLander, в которой приняли участие две “идеологические группы”. В статье они называются “DevOps and ITIL stakeholders”. Как развивалась игра и какими рекомендациями сопровождает описание автор, вы можете познакомиться в первоисточнике. Мы же хотели бы познакомить вас с основными “результатами на вынос” – то есть с выводами, которые сделали сами участники тренинга, выводами, которые участники “взяли с собой”, чтобы постараться применить в своей повседневной работе. Важный акцент в деловой игре MarsLander сделан на выстраивании эффективного сотрудничества. Именно поэтому тон рассуждениям участников, когда они обсуждали целевой характер…

Ответственность заказчика

На этой неделе на портале были опубликованы две заметки, вызвавшие внутренние дискуссии в коллективе. Первая о вреде жонглирования приоритетами задач, которые уже были приняты в работу, за авторством Олега Скрынника. Вторая, о роли и месте тимлида в хорошей продуктовой команде Павла Капусткина. Безопасность vs Эффективность Обе эти публикации оперируют терминами общей эффективности командной работы. Из каждой из них можно сделать вывод о том, что искусственные ограничения разного рода очевидно вредят общему командному результату. Этот вывод подтверждается и результатами научных исследований, проведенных в разных странах (легко найти в сети). Материалы доказывают, что наличие финансовых или организационных ограничений негативно влияет на инновационность…

ITIL Intermediate: Release, control, validation – много счастливых релизов

Основная причина, по которой необходимо обратить внимание на модуль Intermediate – Release, Control and Validation – сводится к одному слову: DevOps. DevOps стал новейшим способом описания совместной работы Agile и бережливого производства (Lean), но подход ITIL: Release, Control and Validation (RCV) содержат многие процедурные элементы непрерывной интеграции, непрерывной доставки (CI/CD) и создания ценности DevOps. Для профессионала ITIL важно понимать, где находятся эти точки соприкосновения. Разработка программного обеспечения с использованием таких практик, как DevOps и Agile, говорит о релизе, управлении и контроле версий, понимая, что релиз, в этапе “Преобразование” жизненного цикла услуг ITIL, затрагивает некоторые важные области: • Контроль предоставления продуктов…

Роль Agile-лидеров сейчас важна как никогда прежде

В наш бешено рвущийся вперёд век организации имеют дело с изменениями, происходящими в значительно ускоренном темпе. Мало кто может избежать этого всеохватывающего влияния, и многим нужно переосмыслить свои прежние подходы, чтобы успешно развиваться в этой новой динамичной среде – там, где Agile-лидеры чувствуют себя как рыба в воде. Традиционно, изменения в компаниях инициировались сверху. Кому-то из высшего руководства приходила в голову отличная идея и этот кто-то задавался вопросом: «Как получить поддержку этой идеи у всех в компании?». Но такой подход не только слишком часто терпел неудачу, он вообще больше не имеет смысла в сегодняшней рабочей среде, где сотрудники нового поколения…

Повышение приоритета как (неработающий) способ ускорения работ

Мы это видим довольно регулярно. Не только видим, но и принимаем участие в обсуждении или принятии решения: “смотрите, задача АВС уже очень долго находится в работе, давайте повысим её приоритет, чтобы, наконец-то, устранить проблему”. Согласитесь, это вполне привычный способ управления. Беда в том, что он очень деструктивен и зачастую приносит больше вреда, чем пользы. Для дальнейших рассуждений необходимо сделать два предположения: Задача, приоритет которой повышается, не единственная в очереди. Работы много; точно больше, чем ресурсов в данный момент. В большинстве случаев оба предположения верны и дела обстоят именно так. Эти два пункта позволяют нам смотреть на ситуацию как на систему,…

DevOps: лошади и единороги

В своей свежей статье Paul Wilkinson делится с нами немного юмористическим “классификатором компаний”, прокладывающих свой путь к “состоянию DevOps” или только планирующих в него перейти. Кто хочет стать “единорогом“? Найдите себя (текущего или будущего) в этом списке. И постарайтесь быть объективными. Классификация, предложенная автором, появилась не случайно. На её создание автора натолкнули вопросы, стоящие перед компаниями, представители которых принимали участие в бизнес-симуляции “Проект Феникс – DevOps на практике“. Многие из них пытались оценить текущий или перспективный уровень своих DevOps-практик, опираясь на какую-то понятную классификацию. Итак, вот она! Работает “по запросу” Движется наугад Цель не ясна Слепо следует рекомендациям “хороших практик”…

 
DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;