Когда я впервые услышал термин DevOps, от своих коллег я понял примерно следующее: «Процесс развёртывания приложения в любой среде (dev/QA/prod) называется DevOps. Просто ещё один синоним эксплуатации». Как начинающий программист, я подумал: “Ок, здорово! Ещё одно модное словечко, поразившее в ИТ-индустрию». Люди, которые имеют некоторое представление о DevOps, знают, как я ошибался!
Недавно меня пригласили помочь команде, с которой я уже работала два года назад. Это отличная зрелая команда с хорошо отстроенным рабочим процессом. Но в последнее время поставка заметно замедлилась и начали возникать сбои.
Я была сильно удивлена, когда обнаружила несколько простых дисфункций, которые зрелой команде ничего не стоило выловить самостоятельно. Это заставило меня поразмышлять, почему так происходит? Почему команда с отлаженным рабочим процессом и прекрасными профессиональными навыками может деградировать, вместо того чтобы непрерывно улучшать свои показатели?
Что делать на доске канбан с задачей, по которой требуется переделка?
Какие бы решения вы ни принимали в своей организации, они должны основываться на данных. Со временем у вас появится глубокое понимание вашего процесса и производительности. Перестаньте полагаться на догадки – аналитика станет вашим надежным советчиком для предсказуемого успеха.
В этой статье мы рассмотрим, как можно использовать аналитику для понимания данных, выявления проблем и повышения эффективности процесса.
Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями – как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
К нам на курсы по гибким управленческим подходам приходят разные люди, но некоторые вопросы возникают практически у всех групп. Эта статья про важную связку таких вопросов – почему мы хотим именно кратного ускорения поставки, и где его можно найти.
При обсуждении взаимодействия ИТ-службы (будь то внутреннее ИТ-подразделение в организации или сторонняя ИТ-организация) с контрагентами, довольно часто происходит блуждание в, казалось бы, трёх соснах. Как обозначить одну сторону этих взаимоотношений, обычно вопросов не возникает – «ИТ» или «поставщик ИТ-услуг» (вслед за ITIL’овским «IT service provider»). А вот для обозначения второй могут использоваться разные слова: «заказчик», «бизнес», «потребитель», «клиент», «пользователь» (реже «покупатель» и т.д.). Причём, когда в обсуждении участвуют несколько коллег, да ещё с опытом работы в разных компаниях, ситуация напоминает знаменитое столпотворение. С «пользователями» разбираемся довольно быстро – это те, кто пользуется ИТ-услугами; user-ы в привычном для ИТ-специалистов смысле слова….
В последнее время в разговорах довольно часто воспроизводится в сущности один и тот же шаблон: … – У нас Agile. – А в чём заключается? – Ну, мы используем в работе канбан. – Каким образом? – Все задачи на стене висят (в колонках «Надо сделать», «Делаем», «Сделано»). … Т.е. некоторые ставят знак равенства в следующих парах «Agile = Канбан» (что не так) и «Канбан = таск-трекер» (что не совсем так). Вот, и получается, висит на стене табличка с задачами – стало быть, Agile. И если с первым уравнением/неравенством обычно разбираемся довольно быстро, то второе требует больше времени. В принципе «всё…
Рассмотрим два из трёх принципов, которые, по мнению Gene Kim, определяют DevOps. Они сформулированы в его статье «Три пути: Принципы, поддерживающие DevOps» («The Three Ways: The Principles Underpinning DevOps») и подробно описаны им в книге «The DevOps Handbook». Так называемые второй и третий пути DevOps: создание постоянного быстрого потока обратной связи, что позволяет максимально рано выявлять проблемы и устранять их максимально быстро, не допуская передачи дефекта по потоку создания ценности (в сторону эксплуатации/потребления) и предотвращая повторения проблем (рис.1 [с сайта itrevolution.com, Copyright © 2017 IT Revolution]) создание креативной культуры высокого доверия, поддерживающей экспериментирование и извлечение уроков как из успеха, так…