Просмотр исходного текста страницы Управление изменениями в прикладном ПО уровня предприятия

;[[:Категория:Беспальчук Игорь (Статьи)|Беспальчук Игорь]]
: руководитель отдела технологического развития CUSTIS

Статья опубликована в журнале ''Intelligent Enterprise, [http://www.iemag.ru/analitics/detail.php?ID=23014 № 4 (апрель) 2011, стр 48-51] <ref> "Intelligent Enterprise , № 4 (апрель) 2011, стр.48-51. http://www.iemag.ru/numbers/index.php?YEAR_ID=1185&ID=22953</ref>

== Сложный пациент ==
Тема нашего разговора — эффективная работа с изменениями в прикладном ПО. Чтобы было интереснее, мы выберем область, в которой управление изменениями наиболее сложно и значимо. Речь пойдет о специализированном ПО, поддерживающем бизнес-процессы крупного предприятия (Enterprise Solutions). Обычно это системы, разработанные (или глубоко доработанные из шаблонного решения) сторонним поставщиком или отделом разработки на самом предприятии.

== Симптомы и жалобы ==
По сравнению со стандартными «коробочными» продуктами для офиса ПО уровня предприятия имеет ряд особенностей, которые усложняют управление изменениями.

=== Важность изменений для бизнеса ===
Первое, чем отличаются изменения в системах уровня предприятия — это их принципиальная важность для бизнеса. Очень плохо, если ограничения информационной системы станут ограничениями для развития бизнеса — это может сделать его неконкурентоспособным. Хуже всего, если информационная система в принципе не может поддержать необходимые изменения.

=== Высокая динамика изменений ===
Запросы на изменения в ПО уровня предприятия появляются постоянно, независимо от времени года и текущей ситуации на рынке. Как известно, «чтобы оставаться на месте, нужно бежать изо всех сил». Динамично меняющийся бизнес требует быстрой реакции, и изменения в ПО должны поспевать за изменениями бизнеса.

=== Дрейф требований к системе ===
В результате длительной эксплуатации, сопряженной с активными изменениями, через несколько лет функционал системы может довольно сильно измениться. Архитектура системы должна выдерживать такой «дрейф требований» и не становиться ограничением для последующих изменений.

В качестве примера могу привести опыт нашего клиента — торговой сети федерального масштаба, в которой за короткий срок изменилась форма управления снабжением розничных магазинов (с децентрализованной на централизованную).

=== Приоретизацияя запросов на изменение ===
Сложные системы уровня предприятия могут «пронизывать насквозь» всю организацию, «сшивать» все ее подразделения. При этом очень немногие представляют себе работу предприятия в целом. Руководители отдельных подразделений хорошо понимают их работу, но при этом «свои» задачи развития обычно ставят значительно выше задач смежных подразделений.

Одно из парадоксальных следствий этого явления таково: может оказаться, что некоторые запрошенные изменения, которые действительно могут повысить эффективность работы конкретного пользователя или даже целого отдела, вообще не следует реализовывать. Локальная оптимизация может ухудшить эффективность работы предприятия в целом.

В результате задача приоритизации запросов на изменение ПО зачастую становится весьма нетривиальной.

=== Миграция данных ===
Корпоративные бизнес-приложения имеют дело с большими объемами информации, хранящимися в реляционных БД. Изменения часто затрагивают не только программные коды, но и структуры данных и сами данные. А это значит, что одновременно с изменением системы бывает необходимо преобразовать и миллионы записей в базе данных. Кроме того, такие изменения затрудняют откат к предыдущей версии системы.

== Чем лечить? ==

Итак, мы рассмотрели карту нашего пациента и выяснили, что кроме обычных симптомов у него присутствует еще целый ряд осложнений. Как же нам его лечить?

Иначе говоря, как нам выстроить процесс разработки, чтобы изменения, необходимые бизнесу, реализовывались в оговоренные сроки и с высоким уровнем качества? При этом неважно, говорим ли мы о внутренней разработке на предприятии или о компании, специализирующейся на производстве ПО. В любом случае эффективное управление изменениями основывается на процессном подходе.

=== Стандартные лекарства, проверенные временем ===

Существует много стандартов и методологий, касающихся управления изменениями в ПО. При этом управление изменениями обычно рассматривают как часть более крупной дисциплины — управления конфигурацией ПО (SCM — Software Configuration Management). Все основные методологии и стандарты разработки ПО включают соответствующие разделы. Раздел, посвященный конфигурационному управлению, есть в описании унифицированного процесса разработки RUP, в модели зрелости процессов разработки CMMI, в своде знаний по инженерии ПО SWEBOK.

Так что же — искомое лекарство найдено? Берем и внедряем в нашей организации RUP или другую проверенную временем методологию разработки. Увы, все не так просто. Стандарты часто описывают очень богатую процессную модель, переполненную отдельными ролями и артефактами. Внедряя RUP «как есть», вы рискуете утонуть в огромном количестве документации и вспомогательных процессов, которые, возможно, вам на самом деле не нужны.

Есть и другой риск — за жесткой регламентированной формой очень легко потерять суть и смысл происходящего. «Мы не можем отказаться от этой спецификации, потому что в RUP написано, что она должна быть!». При таком подходе неизбежно снижается эффективность процесса, а руководство не в состоянии что-либо изменить, пока оно «зациклено» на стандарте.

Один из авторов RUP признал, что основной недоработкой этой методологии является ее недостаточная адаптация к проектам разного масштаба. Это очень важный тезис. Стандарт или тяжелую методологию следует использовать скорее как набор шаблонов, «кирпичиков» для построения вашего собственного процесса, а также как источник вопросов, о которых следует задуматься. В то же время в «стандартном» процессе могут отсутствовать элементы, которые необходимы для решения специфических проблем в вашем проекте. И такие элементы вам придется восполнять самим, из собственного опыта или из опыта коллег.

=== Экспериментальное, высокоэффективное средство ===

Говоря о работе с изменениями, невозможно обойти стороной еще один феномен сегодняшней индустрии разработки — гибкие (Agile) методологии, ведь один из девизов Agile — «Изменения приветствуются»!

За последние годы многие крупные корпорации взяли на вооружение Agile-практики и почувствовали их преимущества, в том числе в денежном выражении. Компания, в которой я работаю, одной из первых в России перешла на Scrum — самую популярную из гибких методологий на сегодняшний день.

Гибкие методологии привлекают простотой и обещаниями эффективности групповой работы. Каноническое описание Scrum умещается на 20 страничках текста. Там нет ничего лишнего: описаны минимальные необходимые правила организации процесса разработки для проектов любого масштаба и сложности. Но на деле то, что необходимо, не всегда является достаточным.

Да, для маленьких проектов тот же Scrum не потребует никаких дополнений: все шероховатости процесса будут незаметны в масштабе пары месяцев. Но чем больше и сложнее проект, тем больше требуется механизмов для того, чтобы совладать с его размером и сложностью. Так что же — Agile не пригоден для крупных проектов? Вовсе нет. Ни манифест Agile, ни методология Scrum, вопреки распространенному мнению, не запрещают разработку документации и использование жестких процедур и регламентов там, где это необходимо, — они лишь '''не требуют''' этого. Scrum дает вам «скелет» процесса, который в большом проекте сам по себе нежизнеспособен. Вы должны нарастить на него много, иногда очень много «мяса», прежде чем процесс сможет успешно работать в вашем конкретном проекте.

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

=== Синтезируем индивидуальный препарат ===

Стандарты призваны гарантировать промышленное качество результата, предсказуемость, снижение рисков проекта, использование проверенных подходов. Выбирая из стандарта наиболее важные для нас моменты, мы обеспечиваем надежность нашего процесса.

Для повышения эффективности разработки мы обращаемся к гибким методологиям и даем достаточную степень свободы рабочим группам, не забывая при этом о необходимости планирования деятельности в большом проекте.

И, наконец, учитывая особенности нашей конкретной задачи, мы вносим в процесс необходимые модификации, поддерживая их соответствующими процедурами и инструментами.

[[Файл:Синтез процесса разработки.jpg|thumb|500px|center|Синтез процесса разработки]]

В результате мы получаем свой уникальный процесс разработки (см. рис.), максимально адаптированный к решаемым задачам. В этом едином «сплаве», как правило, сложно увидеть исходные ингредиенты. Элементы процесса, «впитанные» из разных источников, взаимообогащаются и трансформируются. Главное в этом алхимическом процессе — не потерять контроль за результатом.

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

== Случай из практики ==

Для начала — коротко об истории проекта. Он стартовал в 2008 году и сам представлял собой '''одно очень большое изменение ''' (которое соответственно подчиняется всем правилам управления изменениями). В торговой сети федерального масштаба необходимо было заменить один из центральных узлов информационной системы — модуль управления товарными запасами и снабжением розничных магазинов.

Предыдущая система много лет работала в режиме 24x7 и непрерывно развивалась вслед за изменениями бизнес-процессов компании. За это время товаропоток увеличился в разы, ключевые бизнес-процессы изменились до неузнаваемости, а объем функционала системы вырос по сравнению с первоначальным в три раза. При разработке предыдущей системы никто не ожидал таких темпов развития, и когда подоспели очередные крупномасштабные сквозные изменения бизнес-процессов, стало ясно, что соответствующие правки в системе обойдутся слишком дорого из-за ее недостаточной гибкости и сопровождаемости. Было решено идти революционным путем и разработать новую систему, в большей мере соответствующую современным требованиям и масштабам бизнеса.

Если продолжать аналогию с пациентом и симптомами, то эта задача была похожа на пересадку сердца: поставки товара в магазины сродни кровоснабжению органов живого человека. Организация не может остановить свою деятельность, дожидаясь, пока айтишники заменят одну систему на другую и наладят интеграцию с десятком других систем предприятия.

В нашем случае операция прошла успешно и поставки товара в магазины не прекращались ни на один день. Внедрение новой системы происходило плавно на протяжении полугода, при этом пользователям не приходилось дублировать учет в двух системах, как это иногда происходит при внедрениях такого масштаба. Эту технологию мы называем «бережным внедрением».

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

== Инструменты хирурга: большие и маленькие ==

Итак, проект переходит в фазу длительного активного сопровождения, и теперь основное, с чем имеет дело рабочая группа, — это постоянные изменения, которые нужно вносить в систему. Большинство этих изменений сопряжены с теми сложностями, которые мы перечисляли вначале. Давайте посмотрим, каким образом в процесс разработки встроены механизмы борьбы с этими сложностями.

=== Архитектура, спроектированная совместно с заказчиком ===

Ключом к достижению необходимой гибкости системы к будущим изменениям является ее архитектура. Для информационной системы масштаба предприятия архитектура — это нечто большее, чем просто техническое решение. Это некий актив предприятия: в него вкладываются, рассчитывая получить преимущества в будущем. Поэтому неудивительно, что верхнеуровневые архитектурные решения принимаются только совместно со специалистами заказчика, исходя из их видения дальнейшего пути развития компании. Перед большими изменениями мы проводим несколько совместных совещаний, на которых обсуждаем предлагаемое решение. Архитектура системы в разных ее аспектах становится основным предметом договоренности между заказчиком и исполнителем.

=== Архитектурный рефакторинг ===

Чтобы система могла выдерживать дрейф требований, обусловленный постоянным развитием, время от времени в нее необходимо вносить достаточно крупные переделки. Эти переделки напоминают рефакторинг кода — прием из арсенала разработчиков, направленный на поддержание качества низкоуровневого дизайна программы. Без рефакторинга код программы через некоторое время теряет сопровождаемость, и вносить новые изменения становится все сложнее. В масштабах предприятия этот прием можно назвать '''архитектурным рефакторингом'''. Заказчик должен понимать, что это действие необходимо в многолетней перспективе, хотя в моменте от него и не видно ощутимой пользы.

В качестве примера могу привести такой случай. Нашу информационную систему активно используют два дивизиона компании-клиента. Система развивалась несколько лет и стала достаточно сложной, «набрала вес». Этот «вес сложности» замедляет внесение новых изменений. Увеличение мощности рабочей группы может ненадолго улучшить ситуацию, но эффективность работы все равно останется ниже, чем она была вначале.

В этой ситуации мы порекомендовали заказчику разделить систему на две в соответствии с двумя группами пользовательских ролей и бизнес-процессов из двух дивизионов. Казалось бы — зачем заказчику тратить на это деньги? Это не бесплатная и не быстрая операция, фактически — отдельный проект со своим бюджетом и сроками. Но есть понимание, что это естественный путь развития. После разделения системы каждая из двух полноценных рабочих групп сможет заниматься задачами своего дивизиона и быстрее решать их в своей системе за счет того, что она будет проще и «легче». Заказчик понял долгосрочные выгоды такого решения и согласился на проект разделения.

=== Контроль качества ===

Для контроля качества системы также применяется ряд специальных мер. На самом раннем этапе это автоматические модульные тесты, которые пишутся и поддерживаются самими разработчиками, — они позволяют сразу выявлять ряд ошибок, вносимых вместе с изменениями. Обнаруживать ошибки на ранних стадиях также помогают практики обзора кода (Code Review). Они обычны для гибких методологий разработки, и мы стараемся перенимать весь доступный опыт в этой области. Часть ошибок выявляется при ручном тестировании системы. Важно тщательно тестировать не только новый функционал, но и скрипты миграции данных с предыдущей версии системы на новую.

=== Гарантированный «накат» ===

Готовый релиз новой версии загружается в специальную систему управления «накатом» изменений, которая ведет реестр всех инсталляций программных модулей на серверах заказчика и позволяет ему самому управлять «накатом» сначала на тестовые сервера, а затем и на «боевые». В некоторых случаях обновление необходимо установить на сотни серверов в разных регионах страны. Применение автоматизированной системы гарантирует, что на всех серверах будет произведено одно и то же изменение, которое уже было проверено на тестовых инсталляциях.

=== Документация: необходимая и достаточная ===

Конечно, изменения необходимым образом документируются. Через год или два мы можем понять, почему та или иная строка программного кода была изменена, в связи с каким запросом и кто являлся его заказчиком. В системах масштаба предприятия такая возможность необходима. В то же время затраты на это документирование достаточно невелики: мелкие изменения обсуждаются прямо в трекере ведения задач, доступном как для рабочей группы, так и для заказчика. Трассировка от программного кода к трекеру позволяет в любой момент поднять это обсуждение. Для более крупных изменений разрабатываются отдельные документы (постановки). Они хранятся в базе знаний проекта, организованной по принципам Wiki.

=== Цена вопроса ===

Надо отметить, что для поддержания всех вышеперечисленных элементов процесса мы не используем каких-либо дорогостоящих инструментов, обходясь в основном бесплатными продуктами, аккуратно связанными между собой. Многие инструменты (как, например, упомянутая система «наката» изменений) разработаны нами самостоятельно ввиду отсутствия чего-либо подобного на рынке.

== Секрет здоровья ==

Подведем краткий итог. Управление изменениями должно быть организовано в компании как часть общего процесса разработки ПО. А процесс разработки зависит от масштабов и особенностей проекта, его специфических сложностей и конкретного заказчика. Готового универсального рецепта, как выстроить этот процесс эффективно, нет, и оптимальное решение — создать свой собственный, уникальный процесс, используя лучшие практики отрасли. Применение стандартов в разумном объеме позволяет обеспечить качество и надежность процесса, а гибкие методологии повышают эффективность работы команд разработчиков. Мы постарались проиллюстрировать эти принципы на примере процесса разработки ПО уровня предприятия как наиболее сложного с точки зрения управления изменениями.


= Ссылки =
<references />

[[Категория:Беспальчук Игорь (Статьи)]]
[[Категория:Intelligent Enterprise (Публикации)]]
[[Категория:2011 год (Статьи)]]

{{replicate-from-custiswiki-to-lib}}