Управление изменениями в сложных информационных системах Вебинар, 28 октября 2010 Роман Чернин компания NAUMEN

Не каждое изменение есть улучшение, Но каждое улучшение является изменением Разные мотивации За разработку и эксплуатацию (поддержку) чаще всего отвечают разные подразделения, а иногда и разные компании. Продаются фичи, а в процессе эксплуатации "вылезают" другие вопросы Надежность / отсутствие багов Масштабируемость / требования к инфраструктуре Гибкость / скорость внесения изменений Архитектура / скорость локализации ошибок О чем поговорим

План 1.Общее понимание «изменений» 2.Заказчик всегда прав? 3.Разработка с учетом эксплуатации 4.Контроль качества

Голосование 1 Вы были на наших вебинарах по тематике ITSM ранее? 1.Да, в текущем году 2.Да, но давно это было 3.Нет, это первый

Поехали!

Коротко о главном Изменения – неотъемлемая и наиболее опасная часть жизни любой системы Цель процесса управления изменениями обеспечение внесения изменений в IT-инфраструктуру в соответствии со стандартизованными процедурами, для эффективного проведения изменений и минимизации рисков внесения изменений на функционирование инфраструктуры (ITILv2). Базовые требования к внесению изменений изменение согласовано, т.е. известно, кто какие изменения должен согласовывать изменение оттестировано, т.е. есть тесты и документация есть план Б (возврат к предыдущей версии), т.е. предыдущая версия вообще есть! Изменение = Риск

Классификация изменений Форма выполнения (workflow) 1.Проекты 2.Стандартные изменения 3.Срочные (экстренные) Масштаб имеет значение 1.Деньги/трудоемкость 2.Бизнес риски 3.Технические риски

Что должно быть в Системе 1.Прием и классификация запросов на изменения. 2.Гибкие жизненные циклы и маршруты согласования 3.Информирование пользователей о планах изменений, в частности о периодах недоступности сервисов 4.Связь с CMDB и Релизами 5.Связь с инцидентами 6.Связь с проблемами 7.Связь с системами управления проектами и разработкой

Голосование 2 Как у вас организована работа с изменениями 1. Как придется 2. Регламентированы и согласуются в бумажном виде 3. Регламентированы и автоматизированы 4. Другое (поясните в чате)

Миф серебряной пули…

Заказчик и изменения Нужен «владелец» продукта Право сказать "нет" Релизная политика: багфиксы, минорные изменения, крупные проекты Не все нужно строить "на века". Коммуникации Торговля за функции. Частая ситуация - разрозненные требования и приоритеты, нет возможности принимать "авторитарные" решения Быстрая оценка доработок За все нужно платить. Не всегда удается сделать систему сразу надежной, быстрой, функциональной, красивой и т.д. Быстро, дешево, качественно: выбирайте любые два

Разработка не должна быть…

Голосование 3 Вы представляете 1. Блок эксплуатации 2. Блок разработки/развития 3. Заказчик 4. Другое (поясните в чате)

Участие эксплуатации в разработке Разработка с учетом эксплуатации Эксплуатационные требования при выборе ПО. При чем это должно быть что-то более конкретное нежели "доступность три девятки" и "работа 3000 пользователей". нужно предусматривать планы по изменчивости функциональности, время жизни ПО, кол-во специалистов для поддержки и т.д. Ответственный за эксплуатацию - в команде проекта еще на этапе внедрения Должно оставаться время на нефункциональные улучшения

Участие разработки в эксплуатации Обратная связь Не "что конкретно поправить", а "какую задачу решить" Правило McDonald's Факты а не обобщения Разработка ориентированная на клиента Максимально близкая к рабочей тестовая среда Право на рефакторинг Стоимость поиска и исправления ошибок растет со временем

Что может помочь? Не экономьте на инфраструктуре разработки Системы автоматизированного тестирования, непрерывной интеграции, документация снижают стоимость изменений Непосредственно разработка - меньшая часть затрат на реализацию изменения Иногда совпадение нескольких факторов приводит к действительно неожиданным (и зачастую более серьезным чем можно было бы ожидать) последствиям Человеческий фактор – ключевой, из-за чего возникают ошибки. роботы не ошибаются:)

Основные принципы Agile Итерационный подход Регулярное планирование Командная работа с привлечением заказчиков Проблемы выявляются, обсуждаются и решаются Ретроспектива (что сделано, что будет сделано, какие проблемы)

Арбитр

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

Несколько слов про NAUMEN

NAUMEN Сделано в полную силу… И это работает! Российская компания, партнеры в России и СНГ, своя команда внедрения Более 200 внедрений Naumen Service Desk на территории СНГ в отраслях: Поддержка до 24х7 на русском языке Широкая линейка продуктов Ритейл Финансы Телеком Промышленность ИТ и сервисные компании Гос органы и ВУЗы

Лицензирование Naumen Service Desk Организационная структура и учет контрагентов Запросы (инциденты и сервисные запросы) Проблемы Сервисы и соглашения Задачи (наряды на работы) Регламентные работы Отчетность Модуль администрирования и управления справочной информацией Cерверная лицензия не зависит от количества пользователей, и предоставляет право на использование следующих модулей системы: Импорт данных Web-Сервисы База знаний и модуль сценарийных анкет (Помощник) Обработка почты Поддержка цифровых сертификатов Интеграция с LDAP-сервером Интеграция с системами мониторинга и инвентаризации (Microsoft MOM, SCOM, SMS, LANDesk) Интерфейс для PDA. Лицензия на управление конфигурациями и изменениями Узнайте о специальных предложениях у наших менеджеров!

Итого…

Еще раз остановимся на главном Взаимное вовлечение и обеспечение обратной связи позволит избегать конфликтов и обеспечить кач-во для конечного заказчика Размер инвестиций в инфраструктуру и технологию разработки зависит от требований к надежности создаваемого ПО и его жизненного цикла При оценке стоимости изменения учитывать прежде всего стоимость внедрения, а не реализации «на рабочем месте разработчика» Могут помочь правильные KPI кол-во ошибки/функционал время доставки доработки (изменения) до заказчика % документированных изменений % покрытия тестами

Одна цитата из рабочей переписки В новой версии должно быть хотя бы на одну ошибку меньше, но при этом, ни на одну фичу больше. Фича - не синоним слова "хорошо", любая фича - изменение поведения системы, в хорошую сторону или плохую - это дело субъективной оценки пользователя, и под это изменение клиент должен перестроить свое поведение. Мы не должны вынуждать его делать это. Он должен делать это сам, осознанно, и переходить на другой, нежели в комплекте поставки набор функций, только добровольно и явно проявляя на то свою волю. Выход каждого релиза должен быть доведен до клиентов, с описанием изменений.

Источники SCRUM Гибкая методология разработки ПО. ГОСТ Р ИСО/МЭК Разработан именно для ПО. Определяет требования к организации процессов и взаимодействий на всем жизненном цикле ПО. В частности, рассматривает эксплуатацию как один из этапов. Обсуждение

Голосование 4 Ваше мнение о содержании прошедшего вебинара? 1.Было интересно и актуально, хочу узнать больше 2.Мало конкретики про автоматизацию 3.Тема не интересна 4.Другое (поясните в чате)

NAUMEN +7 (495) Роман Чернин Спасибо за внимание! Обращайтесь к нам и нашим партнерам Узнайте о специальных предложениях у наших менеджеров!