Создаем каталог услуг для управления ИТ-услугами
Чтобы получить максимальную отдачу от каталога услуг, убедитесь, что у вас есть все ключевые компоненты.
Примеры реальных задач, истории успеха и решения из жизни
Чтобы получить максимальную отдачу от каталога услуг, убедитесь, что у вас есть все ключевые компоненты.
Выводы и заключительные размышления на тему, как подойти к вопросу измерения производительности разработчиков.
Чтобы разобраться с тем, как оценивать производительность и эффективность работы разработчиков, нужно узнать плюсы и минусы существующих подходов и разобраться с тем, какое влияние на бизнес оказывает программная инженерия.
Мы продолжаем рассматривать сложную, но интересную и актуальную тему измерения производительности разработчиков ПО, и сравниваем возможности по измерению работы таких отделов с другими отделами.
Измерение производительности разработчиков – сложная задача, встающая перед руководителями ИТ. Обычные измерения усилий и выходов, применимые для других отделов, могут негативно повлиять на культуру разработки. В данном случае необходимо применять другие подходы.
Практический опыт расследования причины инцидента в компании Advenita, превратившийся увлекательный детектив и позволивший сделать важные выводы на будущее.
Как организовать поддержку в ИТ – это вопрос, с которым сталкиваются почти все организации, вне зависимости от того, являются они внутренним поставщиком услуг или внешним. Да, это задача не из легких.
Работа над дефектами – известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова “работа над”, а не “управление” – из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
CustDev, CJM, USM, MAU/DAU, продуктовые команды, настоящие дорожные карты, ускорение в разы – это всё не про Enterprise. Или нет?
Разговоры про ускорение разработки программного обеспечения ведутся уже много лет. Насколько ожидания оправданы? Можно ли ускориться, и как сильно? И главное – что для этого нужно?
Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы.