Это очень общая модель процесса инкрементального улучшения системы. В зависимости от условий конкретной организации она может быть дополнена различными элементами. Например, можно предусмотреть ежедневные короткие собрания всей команды развития для обмена информацией кто что делает, как это предписывает scrum. Также предложенная модель не отдает явное предпочтение тем или иным механизмам мотивации сотрудников, эти вопросы также должны решаться при внедрении процесса в конкретной организации.
Рассмотрим теперь процесс значительного изменения информационной системы при помощи выпуска релизов (рис. 6.9).
Данный процесс также строится вокруг приоретизированной очереди заявок на изменение или устранение дефектов, которая является входом для процесса инкрементальных изменений. Может сложиться такая ситуация, когда некое множество заявок целесообразно реализовывать одним пакетом, например, потому, что их взаимное влияние очень велико и независимая разработка невозможна. Подобная ситуация может сложиться также при обновлении технологической платформы, на которой построена система, при значительном добавлении новой функциональности и т.п. В этом случае представитель заказчика (напомним, что это владелец приложения или владелец процесса) и руководитель группы развития системы могут принять решение о выпуске новой версии (или релиза) системы. Они определяют границы релиза, т.е. множество заявок, которые он будет закрывать, и сроки его реализации. Отметим, что при планировании релиза крайне желательно оценить его потенциальный эффект и сложность реализации в соответствии с методом, предложенным в Главе 4.
Системные архитекторы в этом случае рассматривают релиз целиком и декомпозируют его на отдельные задания для разработчиков. По мере завершения разработки производится тестирование интеграции и функциональности вновь создаваемых модулей. Для этого целесообразно развернуть специальную тестовую среду, повторяющую окружение промышленной системы. К такому тестированию могут быть привлечены и ключевые пользователи. Когда внутреннее тестирование релиза завершается, он переносится в промышленную систему, о чем уведомляются пользователи, заявки которых реализованы в данном обновлении. Они также должны подтвердить удовлетворение их требований.
Отметим, что подготовка нового релиза выполняется параллельно с процессом инкрементальных изменений, причем одновременно в разработке может находиться несколько релизов, которые будут выпускаться последовательно.
Модель скользящих слоев
В этом разделе мы вернемся к обсуждению вопроса правильной организации технологической платформы, на которой может быть построена адаптивная информационная система.
Самый простой путь к обеспечению адаптивности не только информационной, но и любой другой системы, это разделение ее на относительно слабо связанные модули, которые могут развиваться независимо. Поэтому проблема проектирования и управления модульными системами с адаптивным поведением является центральной в исследованиях по теории организации. Однако, как заметили Сендил Этирадж и Дэниел Левинтол[121], при этом, собственно, вопросу оптимального выделения модулей уделяется мало внимания. Проектировщики сложных систем имеют дело с четырьмя видами решений:
1. разделение системы на «правильное» количество модулей;
2. «правильное» отображение параметров проектирования на модули;
3. «правильная» организация взаимодействия элементов внутри модуля;
4. «правильная» организация интерфейсов между модулями.
Общего решения этой задачи для систем любого вида, видимо, не существует. Тем не менее, в некоторых областях человеческой деятельности достигнут определенный успех в формализации разделения системы на модули. В частности, в строительстве и архитектуре существует концепция скользящих слоев (shearing layers), выдвинутая британским архитектором Фрэнком Даффи, основное внимание в своих работах уделяющим гибкому использованию рабочего пространства. Широкую известность этот подход получил после выхода книги Стюарта Бренда «Как обучается здание: что происходит после того, как оно построено»[122].