'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

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


Слайд 3

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


Слайд 4

Поехали!


Слайд 5

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


Слайд 6

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


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

Арбитр


Слайд 18

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


Слайд 19

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


Слайд 20

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


Слайд 21

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


Слайд 22

Итого…


Слайд 23

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


Слайд 24

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


Слайд 25

Источники SCRUM http://ru.wikipedia.org/wiki/Scrum. Гибкая методология разработки ПО. ГОСТ Р ИСО/МЭК 12207-99 Разработан именно для ПО. Определяет требования к организации процессов и взаимодействий на всем жизненном цикле ПО. В частности, рассматривает эксплуатацию как один из этапов. Обсуждение http://www.smartsourcing.ru http://sd-naumen.livejournal.com/


Слайд 26

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


Слайд 27

NAUMEN +7 (495) 783-0-287 www.naumen.ru sales@naumen.ru Роман Чернин rchernin@naumen.ru Спасибо за внимание! Обращайтесь к нам и нашим партнерам Узнайте о специальных предложениях у наших менеджеров!


×

HTML:





Ссылка: