Картирование потока создания ценности
В этом ролике мы расскажем о основных принципах описания или картирования потоков создания ценности, преимущества и ошибки при выполнении этой работы.
Современные идеи организации эффективной разработки программного обеспечения и развёртывания релизов.
В этом ролике мы расскажем о основных принципах описания или картирования потоков создания ценности, преимущества и ошибки при выполнении этой работы.
В последнее время в обсуждении одной модной темы часто натыкаюсь на непонимание (или неприятие?) одного и того же важного момента.Тема – кардинальное преобразование организации, ведущее к появлению способности быть успешной в конкурентной быстро меняющейся бизнес-среде. Здесь для краткости можно было бы написать «цифровая трансформация», «business agility» и т.п. Но мы же здесь все приличные люди 😊 А момент вот какой.Все понимают (во всяком случае соглашаются с тем), что в среде с высокой степенью неопределённости/вариативности для обеспечения быстрой работы производственной системы кроме всего прочего нужна организация потока. Вытягивающая система, WIP-лимиты, всё, как написано в книжках про построение быстрого, равномерного потока. Большинство…
Все больше компаний реструктурируют свои классические команды разработчиков и берут курс на DevOps. Чтобы успешно справиться с переходом, они часто привлекают внешних консультантов к очень сложному рабочему процессу. Существует пять предварительных условий для преодоления связанных с этим трудностей.
Одним из самых сложных моментов при написании статей о DevOps и ITIL является поиск идеальных фраз для их определения. Они не только означают разные вещи для разных людей и организаций, но и применяются и используются совершенно по-разному.
Тема цифровой трансформации интересует многих, но не многие до конца понимают в чем суть этого понятия, как и когда ее лучше проводить, зачем, что для этого потребуется, сколько это стоит… И главный вопрос – а стоит ли ее Вам проводить?
27 октября в 11:00 (МСК) Cleverics проведет открытый онлайн-урок “Продуктовый подход в ИТ в традиционных компаниях”. Приглашаем всех желающих на это бесплатное мероприятие, регистрация обязательна.
То новое, что мы обсуждали на учебных курсах ещё несколько лет назад, теперь стало привычным и общепринятым. Видимо, то, что мы обсуждаем сегодня, имеет шансы стать новой нормой через несколько лет.
Работа над дефектами – известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова “работа над”, а не “управление” – из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
Когда я впервые услышал термин DevOps, от своих коллег я понял примерно следующее: «Процесс развёртывания приложения в любой среде (dev/QA/prod) называется DevOps. Просто ещё один синоним эксплуатации». Как начинающий программист, я подумал: “Ок, здорово! Ещё одно модное словечко, поразившее в ИТ-индустрию». Люди, которые имеют некоторое представление о DevOps, знают, как я ошибался!
Какие дополнительные метрики можно использовать для анализа скорости работы поддержки? Автор статьи с DevOps.com останавливается на пяти в дополнение к MTTR/MTRS.
Быстрая разработка часто завязана на использование ПО с открытым кодом. Это увеличивает сложность цепочек зависимостей. Нужно что-то делать, чтобы снизить риски. Потребуется действительно беспрецедентный уровень контроля не только над тем, что разрабатываем сами, но и над тем, что мы используем.