Почему опоздать на авиарейс и не полететь — это не всегда плохо? Кто виноват в том, что вы опоздали на стыковку? Зачем приезжать в аэропорт заранее? Может ли полететь А380 в Астрахань? Почему интуиция не всегда работает? Неожиданности случаются — никогда не было и вот опять? Почему пассажиры хлопают пилоту после посадки?
Предположим, вы разрабатываете государственную информационную систему (ГИС) общероссийского масштаба. Проектная команда (аналитики, разработчики, тестировщики, служба поддержки, служба инфраструктуры и др.) составляет более сотни человек. Система была внедрена в опытную или в промышленную эксплуатацию. Тысячи организаций интегрировались с вашей системой и начали работать с ней, еще большее количество планирует интеграцию. Десятки тысяч организаций работают через Web-интерфейс. В системе для граждан размещается полезная информация, а также предоставляются интересные функции. Заказчик и/или пользователи требуют новых доработок. Миллионы людей по всей стране регистрируются и пользуются системой. От внешнего мира прилетают подарки в виде изменений цен на нефть, санкций, ограничений и т.д.
Представили? Так вот, именно таким проектом в настоящий момент является проект ГИС ЖКХ, о котором ранее мы начали рассказывать и теперь хотим продолжить.
Первые опыты братьев Райт
Скорее всего, если вы работаете в небольшой компании и разрабатываете “маленькие проекты”, то многие релизные процессы как таковые у вас отсутствуют. Схема работы выглядит примерно так. Вы просто прикидываете, что было бы неплохо выпустить какие-то фичи через 4-5 месяцев. Далее вы месяцок другой пишете постановки, разрабатываете разрабатываете, потом стараетесь все это хозяйство стабилизировать, чтобы выпустить новую версию ПО в эксплуатацию. Конечно, к моменту выпуска обнаруживается, что какие-то доработки никак не получается стабилизировать, где-то вскрываются недочеты в постановках, так как постановки делались давно и сейчас уже что-то поменялось, где-то оказалось, что подписались под нереальной функциональностью и др. Тем не менее, такой подход вполне себе работает, но, как правило, до тех пор, пока проектная команда небольшая и интенсивность изменений невелика (система была не введена в эксплуатацию или пилотировалась на части пользователей и т.д.). В принципе, без процессов можно масштабироваться до довольно крупных проектов — и до 20 человек и до 40 человек — все зависит от крутости отдельных личностей и их самоотверженности. Наверняка многим знакома ситуация, когда проектная команда, состоящая из крутых и отчаянных специалистов, в случаях когда уже сроки горят и почти все пропало дружно напрягалась и … “на своих плечах”, “на морально-волевых” через горы коробок из-под съеденной пиццы в итоге вытаскивала версию в эксплуатацию.
Уилбер и Орвилл Райт, вошедшие в историю как братья Райт, первыми в мире построили самолет и совершили на нем полет. Источник
Поверьте, мы тоже через это прошли (именно поэтому мы так любим теперь всевозможные безумства типа Гонки Героев, марафоны и т.п.). Но в какой-то момент мы поняли, что все имеет предел и что при реализации систем масштаба ГИС ЖКХ без внятного релизного процесса мы гарантировано получаем три основных неприятных момента:
- вами недоволен заказчик, т.к. вы не можете прогнозировать даты выпуска функциональности в эксплуатацию и постоянно срываете сроки, а если возникает непредвиденная задача, то это приводит к большим проблемам;
- качество жизни сотрудников ухудшается из-за постоянного хаоса, разборок, овертаймов и т.д.;
- вами недовольны руководители вашей же компании, т.к. затраты будут абсолютно неподконтрольными.
Опыт ЛАНИТ по развитию ГИС ЖКХ говорит нам о том, что одним из важнейших моментов для перехода на “промышленные рельсы” при реализации больших проектов является качественное построение релизного процесса. Этого, конечно, недостаточно для полного счастья, но релизный процесс лежит в основе всего, и без него у вас гарантированно все будет гораздо хуже, чем могло бы быть.
В этой статье мы опишем две главных, по нашему мнению, практики, которые лежат в основе эффективного релизного процесса в IT-системах масштаба ГИС ЖКХ:
- использование схемы регулярной поставки функциональности,
- сокращение релизного цикла.
С одной стороны, эти практики довольно хорошо известны и используются в рамках многих методологий, а также зафиксированы в Agile Manifesto. Однако они во многом противоречат интуиции, требуют определенной квалификации и навыков, а потому сложны для обоснования и встречают непонимание как у Заказчика, так и внутри проектной команды. Для их внедрения в стандарты корпоративной деятельности потребуется очень хорошее понимание “чего мы хотим добиться” и “почему именно внедрение этих практик приведет к желаемому результату”. Ниже мы рассмотрим с примерами эти практики и основные проблемы при их внедрении.
Когда мы анализировали наши внутренние процессы, связанные с управлением релизами, в голове появилась ассоциация с работой современной авиакомпании.
Регулярное авиасообщение
Авиакомпания сделала анализ рынка, спрогнозировала, какие маршруты будут иметь большой пассажиропоток и стали бы выгодны на следующий сезон, договорилась с кем нужно, получила права на нужные маршруты, запустила регулярные авиарейсы. Расписание авиарейсов известно задолго, как правило, за полгода-год. Кто конкретно полетит, авиакомпании, конечно же, неизвестно — она ориентируется на среднюю прогнозную заполняемость. Далее авиакомпания может заключить долгосрочные договоры с аэропортами, продумать, какие воздушные суда наиболее выгодно ставить на рейсы, наладить свои внутренние процедуры и т.д. Это все способствует оптимизации расходов.
Если сотруднику компании требуется поучаствовать в важном совещании в определенное время, а потом улететь в другой город на самолете, то он просто подбирает для себя авиарейсы с учетом рисков того, что совещание может затянуться, и дорожной обстановки.
У регулярного авиасообщения есть и свои минусы. Если сотрудник купил билет на рейс, но не успел, то самолет его не дожидается. Неприятно? Да. Может быть так, что сотруднику нужно улететь сегодня, а рейсы есть только завтра или вовсе только через неделю. Не очень хорошо? Да. Зато большим плюсом является то, что вы можете за полгода-год запланировать свою поездку и быть уверенным, что авиарейс состоится. Вы точно знаете, когда прилетите, и можете сообщить это время вашим близким, которые вас могут встретить, или вы можете лететь с пересадкой и не волноваться, что вы не успеете на стыковку. Ну и вообще, вдумайтесь, огромный, тяжелый железный самолет, который для 90% человечества непонятно вообще как летает, очень быстро понесет вас черт знает куда и стоить вам это будет почти как сутки-двое в поезде.
Вернемся к проекту. В ГИС ЖКХ используется регулярная поставка функциональности. Команда ЛАНИТ делает план-график релизов на 1 год, где фиксирует даты релизов так, чтобы выпуски были примерно 1 раз в месяц. Так как за год может еще все сто раз поменяться (об этом ниже), то в момент составления графика мы еще точно не знаем, какие конкретно доработки будут реализованы и выпущены в эксплуатацию.
При планировании учитывается график регламентных работ, которые требуются для инфраструктуры/службы эксплуатации. Необходимо, чтобы глобальные и разнородные изменения не накладывались друг на друга — так снижаются риски и легче держать все под контролем. Например, устанавливать новую версию ППО и одновременно апгрейдить версию СУБД или обновлять прошивку контроллеров СХД — очень плохая идея.
Принципиальный момент состоит в том, что даты релизов впоследствии не меняются. Если версия запланирована на какую-то дату, то мы должны разбиться в лепешку, но выдержать запланированный срок.
Дальше мы расскажем зачем и почему.
То, что условия для каждого релиза примерно одинаковые (длительность, команда, специфика реализуемых задач и т.д.) позволяет планировать и отладить все процедуры по подготовке и выпуску. Люди, не погруженные в производственные процессы, могут не понимать всей сложности выпуска версии на таком большом проекте как ГИС ЖКХ. Для того, чтобы версия была выпущена, нужно проделать массу операций, таких как регрессионное тестирование (может быть, несколько раз), нагрузочное тестирование, тестирование скриптов развертывания и миграции данных, проанализировать статистику функционирования (SQL-запросы, сервисы и т.д.). Ситуация усугубляется тем, что эти операции могут быть долгими, например, развертывание версии на тестовом стенде может занимать сутки. Если что-то пойдет не так, то можно легко выйти из графика. Поэтому если у вас не будет плана-графика с регулярными и примерно одинаковыми по длительности циклами, то гарантирую, что каждый выпуск будет для вас на 146% гораздо более серьезным испытанием.
План-график также нужен для того, чтобы определять сроки по исправлению дефектов и сообщать их пользователям. Мы, как правило, исправляем большинство имеющихся дефектов в рамках текущей версии. Однако часть дефектов бывает требует больше времени, или они могут возникнуть уже в конце релизного цикла, поэтому они переносятся на следующую версию. Если по каким-либо причинам (см. ниже) мы начнем сдвигать версии, то тогда пользователи автоматически получат исправления позже, что не хорошо.
План-график выпуска версий нужен также и для планирования выпуска в эксплуатацию доработок, которые имеют четкий дедлайн. Производственная команда понимает, когда именно должна быть выпущена доработка в эксплуатацию и подбирает нужный релиз, в рамках которого она выпускается. Если дата релиза будет сдвигаться, то это может привести к тому, что доработка будет выпущена с опозданием (о последствиях сдвига версии из-за важной задачи см. ниже)
Так же, как регулярное транспортное сообщение, это основа глобальной транспортной системы, релизный процесс на основе регулярной поставки функциональности — это базис для эффективного развития системы масштаба ГИС ЖКХ. Если этот процесс налажен, то на него уже можно “нанизывать” планы по реализации и поставке функциональности.
К сожалению, путь внедрения такой вроде бы полезной со всех сторон практики труден и тернист. Ниже приводятся основные ловушки, в которые может попасть команда и которые должны отслеживаться и пресекаться.
Посадка на самолет после окончания регистрации
У авиакомпаний имеется отлаженная процедура регистрации на рейс, которая в частности, включает правило о том, что пассажир должен зарегистрироваться на рейс не позднее, чем за 40 минут до вылета. Зачем нужны эти 40 минут? Они нужны для того, чтобы было достаточно времени для проверки багажа, загрузки его в самолет, для того чтобы на основании веса багажа и количества зарегистрированных пассажиров можно было рассчитать необходимое топливо, заправить самолет и т.д. Кроме того, это время нужно и для того, чтобы у пассажиров было достаточно времени, чтобы найти нужный выход/терминал. Понятно, что с грузом или пассажиром может что-то пойти не так (пассажир заблудился в аэропорту или что-то случилось с багажом) и не хватит даже этих 40 минут. Но все же время окончания регистрации — это выработанный за многие годы компромисс между тратой времени пассажира и риском нештатных ситуаций.
Если пассажир любит приезжать в аэропорт впритык к окончанию регистрации, то это просто означает, что он соглашается с повышенным риском того, что что-то случится и он не успеет на самолет. Если же авиакомпания будет идти навстречу таким людям, то это приведет к тому, что она повысит свои риски. Возможно, ей придется оплачивать специальный рейс автобуса к самолету только для этого пассажира. Возможно, в спешке при регистрации в последний момент сотрудниками аэропорта будет допущена ошибка, и багаж улетит не в тот город.
При выпуске релизов один из важнейших моментов — это критерии, которым должна удовлетворять доработка, и дедлайн, когда это должно быть сделано (по аналогии с окончанием регистрации на рейс). Выпуск версии каждый месяц означает, что если какая-то задача не готова к этому дедлайну в текущей версии ППО, то значит она переносится на следующий релиз через месяц. Часто с этим можно мириться, но особенно тяжело это сделать, когда задача очень важная, но при этом она опаздывает всего на несколько дней или недельку. Возникает очень большой соблазн нарушить дедлайн и включить еще не готовую задачу в релиз и постараться ее дожать.
Почему это плохо?
Во-первых, надо мужественно признаться и принять тот факт, что, что все “дожимания”, “а вдруг успеем” — это скорее всего прокол управления производством. Это значит, что не были заранее предприняты различные меры и ситуация была доведена до критической. Теперь ситуация будет исправляться за счет “геройств” отдельных людей или команды — овертаймы, костыли, удача и т.п. По опыту это краткосрочно может привести к решению проблемы, но если вы так будете делать постоянно, то это приводит к “выгоранию” людей и прочим очень неприятным последствиям.
Во-вторых, как и в примере с авиакомпанией, дедлайн по готовности задач — это компромисс между сроками и рисками. Если мы начинаем нарушать дедлайн, то мы повышаем риски проблем с версией — либо вся версия не будет выпущена в срок, либо будет снижено качество, и мы получим вал обращений из-за неработающей функциональности или проблемы работы под нагрузкой.
К сожалению, ситуации, когда имеется ну очень-очень важная задача и ее обязательно нужно выпустить в текущем релизе, возникают. Но главная мысль — такие ситуации не должны быть общепринятой практикой и поощряться, а наоборот признаваться проблемой и рассматриваться на “ретроспективах”.
Задержка рейса из-за VIP-пассажира
Допустим, вы купили билеты на авиарейс с пересадкой. Допустим, вы прикинули адекватное время между стыковками. Вы приехали заранее в аэропорт, прошли регистрацию, сели в самолет, отзвонились папе с мамой, и тут вам объявляют, что рейс задерживается, т.к. на него опаздывает важная правительственная делегация (конечно, вместо этого вам скажут о непогоде или дополнительных проверках :)). Вы вместе со всем самолетом ждете эту делегацию и в итоге улетаете с существенным опозданием. Прилетев в промежуточный пункт, вы обнаруживаете, что у вас осталось всего 30 минут, чтобы сориентироваться в огромном аэропорте, физически добраться до другого терминала. Может быть вы, конечно, и успеете, а может быть, вы что-то в спешке напутаете и убежите не в тот терминал или даже просто не успеете пройти все нужные процедуры. А если вы — тоже член какой-то другой правительственной организации (но просто скромный) и тоже спешите куда-то?
Таким образом, если бы авиакомпания регулярно допускала сдвиг рейсов, то тогда это приводило бы к проблемам со всех сторон. Для пассажира это означает, что ему нужно будет закладывать большее время на стыковки, пассажиры будут более склонны рисковать и приезжать впритык к окончанию регистрации. Это будет приводить к еще большему количеству конфликтов и бесполезной трате времени. Для авиакомпании это также означает, что нужно закладывать больше времени на простои в аэропорту, тем самым увеличивая затраты.
В релизном процессе, если вдруг какая-то задача никак не успевается к запланированному сроку, тоже возникает сильнейший соблазн сдвинуть весь релиз — например, на недельку. Кажется, что это легкое и хорошее решение, особенно если эта задача на контроле у Главного заказчика.
Давайте рассмотрим, к чему это все приводит в конечном итоге.
В проекте ГИС ЖКХ в рамках очередного релиза выпускается до 100 задач и еще исправления дефектов. Сдвиг релиза означает, что пользователи получат нужную им функциональность или исправления дефектов позже. Конечно, обсуждаемая задача является действительно важной, но при этом многие из остальных 99 задач тоже очень важные, но поскольку с ними все нормально, то мы про них уже забыли.
Далее. Если мы начинаем регулярно сдвигать версию, то тогда заказчик начинает терять веру в план релизов. У него заседает в голове всегда мысль, что да, конечно, следующий релиз запланирован на 10-е число, но скорее всего что-нибудь случится и будет сдвиг на неделю, а то и на две. Причины сдвигов могут быть разные, но в конце концов все они забываются и остается ощущение нестабильного и непрозрачного процесса.
К чему это приводит? К тому, что если возникает срочный дефект или задача, то заказчик не соглашается его выпустить в рамках того или иного релиза, а требует специальную версию или хотфикс. В результате мы имеем существенные дополнительные затраты.
Если мы допускаем сдвиг версии, то это ухудшает возможности по оптимизации процесса. Напротив, если процедура выпуска однообразна и регулярна, то мы имеем возможность ее совершенствовать. После выпуска версии мы проводим “ретроспективу”, где обсуждаем основные положительные и отрицательные моменты, которые случились за время итерации. С каждым повторением мы делаем какие-то улучшения, в результате накладные расходы снижаются, количество ошибок снижается, результат улучшается.
Почему большой самолет не всегда лучше
Авиакомпания может использовать разные типы самолетов на маршруте — региональные самолеты на 75-110 пассажиров (типа SSJ-100), или узкофюзеляжные самолеты на 140-180 пассажиров (типа A320, Boeing 737), или широкофюзеляжные самолеты на 200-300 пассажиров (типа A330, A340), или такие монстры как A380, способные перевезти от 525 до 853 пассажиров. Упрощенно можно считать, что авиакомпания выбирает нужный тип самолета и нужную интенсивность рейса как компромисс желания пассажира иметь, как можно больше рейсов в день и желания авиакомпании снизить расходы на перевозку одного пассажира с целью максимизировать свою прибыль.
Сейчас в мой родной город Астрахань летают как минимум три авиакомпании, делая по одному рейсу в день на региональных или узкофюзеляжных самолетах. Даже если инфраструктура аэропорта в Астрахани допускала бы прием А380 (самый большой и самый вместительный самолет компании Airbus), то для того, чтобы его загрузить, пришлось бы резко сократить интенсивность полетов, что было бы совсем неудобно для пассажиров. Если разница в стоимости не велика, то пассажиры предпочтут большее число рейсов в день.
Примерно такая же логика действует в релизном процессе. Чем меньше сроки между выпусками версии, тем лучше заказчику. Для заказчика было бы идеально, если бы релизный процесс вообще был бы полностью незаметным и прозрачным. Реализовали задачу, нажали на кнопку, и она тут же без даунтайма работает в проме. Для того, чтобы обеспечить высокую частоту выпуска версий, необходимо совершенствовать уровень автоматизации и отлаживать процессы.
Здесь в полный рост встает вопрос по поводу накладных расходов.
Действительно, выпуск версии подразумевает накладные расходы или затраты на выпуск. Например, мы проводим такие работы, как регрессионное тестирование, нагрузочное тестирование, анализ статистики функционирования, анализ скриптов развертывания и миграции данных. Логично предположить, что чем больше релизный цикл, тем меньшие накладные расходы мы имеем на единицу “полезной” выпускаемой функциональности. Получается, что производственной команде необходимо стараться увеличивать длину релизного цикла, чтобы снизить затраты. Однако этот вывод некорректен. Зависимость затрат на единицу функциональности от длины релизного цикла имеет форму, представленную на рисунке ниже (для нашего проекта, нашей команды, с текущим уровнем автоматизации, компетенций, спортивной формы, душевного равновесия, результатов выступления сборной России по футболу).
Рисунок 1. Зависимость накладных расходов на единицу продукции от длины релизного цикла (для наших условий)
Действительно, если мы захотим реализовать непрерывный релизный процесс в стиле “реализовали задачу, нажали на кнопку, все работает в проде” или выпускать версию каждую неделю, то это точно потребует от нас существенных первоначальных усилий для перестройки работы. Скорее всего это будет связано с дальнейшим повышением уровня автоматизации, а также повышением дисциплины и отладки всех процедур. Возможно, это повлечет некоторые архитектурные изменения. Мы не работали пока так, чтобы релизный цикл достаточно долгое время составлял две недели или меньше, поэтому поведение кривой в указанном диапазоне — это мое предположение, которое основывается на опыте выпуска небольших промежуточных версий и хотфиксов.
В районе трех-четырехнедельного цикла мы скорее всего имеем локальный минимум по затратам на единицу продукции, а дальше с ростом длины релизного цикла затраты начинают резко расти. Об этом ниже.
Дополнительный груз — дополнительное топливо
Предположим, авиакомпания берет на борт дополнительный груз. Это не будет для нее бесплатно, так как потребует как минимум дополнительное топливо. К сожалению, в авиации случались печальные случаи, когда из-за жадности или глупости допускался перевес, что приводило к авиакатастрофам.
Если мы выпускаем релиз каждые три-четыре недели, то это требует выполнения определенных процедур для выпуска каждой версии — это два цикла регрессионного тестирования, нагрузочное тестирование, тестирование скриптов развертывания и миграции данных (об этом детальнее напишем в отдельной статье). Ошибочно полагать, что при увеличении цикла до двух месяцев, например, нам потребуется для выпуска выполнить те же самые работы. Дело в том, что если цикл большой, то в него попадает больше изменений. Это в свою очередь вызывает рост потенциальных проблемных мест — в сложной системе этот рост если не экспоненциальный, то точно (из-за взаимного влияния изменений) нелинейный. На самом деле, мы уже сейчас видим, что нам для четырехнедельного цикла не хватает одной итерации регрессионного тестирования. По факту в рамках первого регресса мы выявляем некоторое количество дефектов, исправляем их, а объем изменений оказывается таким, что требуется провести еще один “финальный” регресс. Этот финальный регресс у нас уже более компактный, проходит существенно быстрее и без проблем, но он все же требуется. Если бы мы перешли на двухнедельный релизный цикл, то скорее всего мы смогли бы обойтись только одним регрессом. С другой стороны, если мы увеличиваем цикл до 1,5-2 месяцев, то для стабилизации нам требуется уже не 1,5 регресса, а два-три.
Стюардесса в салоне нового лайнера объявляет о том, что находится в самолете:
— На первой палубе — багаж, на второй — бар, на третьей — поле для гольфа, на четвертой бассейн.
И добавляет:
— А теперь, господа, пристегнитесь. Сейчас со всей этой фигней мы попробуем взлететь.
Если еще дальше удлиняем релиз, то объем изменений и риски по ним увеличатся настолько, что процесс стабилизации уже перестанет быть сходящимся. Наш самолет уже скорее всего не взлетит со всеми этими бассейнами и полями для гольфа.
Никогда не было и вот опять
Выпуск релиза подразумевает довольно сложную инфраструктуру. Для выпуска используется несколько тестовых стендов, настраивается система контроля версий, сборочный конвейер и т.д. Поэтому мы стараемся организовывать нашу работу так, чтобы у нас в каждый момент времени готовился только один релиз. Если вдруг получается так, что нужно поддерживать несколько релизов, то это существенно повышает расходы. Поэтому мы всячески стараемся этого избегать.
Для начала надо признать, что незапланированные и срочные задачи случаются. Поэтому когда это возникает, то желательно, чтобы она была выпущена в промышленную эксплуатацию сразу, как только задача будет готова. Если релизные цикл длинный, то тут вас ждет сюрприз!
Допустим, у вас релизный цикл — четыре месяца. Вероятность того, что окажется так, что как раз в ближайшие дни планируется к выпуску релиз, крайне малы. В этом случае, вам необходимо делать специальную версию для данной задачи, готовить релиз и выпускать его в пром. Это дополнительные затраты. Даже если так получилось, что как раз на днях выпускается версия. В этом случае, скорее всего тем, что вы втиснете дополнительную задачу, вы нарушите план подготовки к выпуску. Возможно, что это приведет к тому, что вы захотите сдвинуть версию. На мой взгляд, последствия этого еще хуже, чем делать специальную версию.
Если же, напротив, вы выпускаете релиз каждые две недели, то задачу можно попробовать включить в текущую версию или на худой конец в следующую. В этом случае, от момента готовности задачи до ее выпуска пройдет в худшем случае 4 недели, а скорее всего 2-3. Это чаще всего вполне приемлемо. А это означает, что вы скорее всего обойдетесь без дополнительных затрат на инфраструктуру.
В зависимости от того, насколько часто у вас могут возникать изменения, тем больше преимуществ вы получите от короткого релизного цикла.
На проектах масштаба ГИС ЖКХ незапланированные срочные изменения возникают достаточно регулярно. Признание этого факта требует некоторых усилий (да что уж там скрывать — большого мужества), т.к. здесь мы тоже в некотором роде вступаем в противоречие с интуицией и нежеланием работать с рисками. Дело в том, что если рассмотреть какой-то конкретный риск, который может привести к необходимости сделать специальную версию, то его вероятность скорее всего окажется микроскопической. Если в прошлом месяце не было никаких доработок в связи с изменением законодательства или какими-то вновь вскрывшимися региональными особенностями, то мы ничего подобного не ожидаем и в следующем месяце. Поэтому делается вывод — что раз вероятности каждого из событий малы, то ничего вообще и не произойдет. Однако это неправильный вывод. Дело в том, что вероятность того, что реализуется хотя бы один риск, равна сумме вероятностей реализации каждого из отдельных рисков. Поэтому если принять во внимание масштаб всего, что происходит даже за один месяц релизного цикла (количество ключевых сотрудников, принимающих участие в подготовке версии, решений, которые принимаются, количество внешних систем, с которыми ГИС интегрируется, сложность инфраструктуры, сложность предметной области и т.д.), то эта вероятность уже вполне себе может быть существенной. Например, даже с релизным циклом в один месяц у нас, начиная с января 2018 по май 2018 года, уже три раза возникали без преувеличения сверхважные и сверхсрочные задачи, которые надо было сделать ASAP и которые требовали специальной версии. Что уж говорить про релизный цикл в 4-5 месяцев! Если бы мы выпускались каждые 5 месяцев, то скорее всего к этим двум спецверсиям добавилось бы еще 2-3 промежуточные версии, что делает релизные циклы более 1-1,5 месяцев совсем экономически нецелесообразными в наших условиях.
Поэтому релизные процессы, которые позволяют гибко реагировать на изменения, — это большое благо на проектах масштаба ГИС ЖКХ.
Хлопаем пилоту только после посадки!
Каждая недоделанная доработка несет в себе риски для выпуска версии. Нельзя верить на слово производственным менеджерам, какие бы честные глаза у них не были! Лучше верить фактам.
По нашему опыту, более-менее можно вздохнуть спокойно только тогда, когда доработка полностью протестирована и исправлены все критические дефекты. После этого основные производственные риски уже, как правило, сняты. Но до тех пор, пока этого не случилось, нельзя исключать развитие событий, при которых что-то пойдет не так, и доработка начнет угрожать выпуску версии. Сколько раз мы верили на слово, что вот завтра доработка будет дотестирована и проблем не будет, а потом случались проблемы.
Если доработка сделана частично или полностью, но отложена, то скорее всего, когда вы вернетесь к ней через полгодика, то обнаружите, что она уже не работает, в системе все поменялось и нужно разбираться заново. Поддержание актуальности отложенной доработки — это дополнительные бесполезные расходы, которых также лучше избегать.
Мало того, из-за сложности предметной области ГИС ЖКХ всегда остаются риски того, что при проектировании были заложены неоптимальные решения или не учтены какие-то региональные особенности. Многие моменты могут быть выявлены только при опытно-промышленной эксплуатации. Это еще один аргумент за то, чтобы делать релизный цикл короче и выпускать доработки быстрее в эксплуатацию. Вы быстрее получите обратную связь, быстрее апробируете свои решения и сможете быстрее сделать то, что действительно нужно заказчику и рынку. Если релизный цикл длинный, то это наоборот провоцирует делать избыточную функциональность, что повышает риск потратить много сил на то, что потом окажется неправильным или ненужным.
Экипаж прощается с пассажирами
Мы рассмотрели основные практики управления релизами, которые для нас оказались основополагающими. Это регулярная поставка функциональности и уменьшение релизного цикла. Несмотря на широкую известность, к сожалению, эти практики на деле не совсем очевидны и в чем-то противоречат интуиции, поэтому часто натыкаются на препятствия при их внедрении.
В рамках ГИС ЖКХ данные практики внедрены, успешно функционируют долгое время и показывают хороший результат. Мы добились того, что план-график релизов строго соблюдается, процедура подготовки к выпуску версии стала более контролируемой и проходит на порядок спокойнее и штатно, мы можем гибко реагировать на изменения.
Конечно, указанными в статье рекомендациями жизнь не ограничивается. За бортом осталось много интересных нюансов и ситуаций, например:
- что делать, если пассажир зарегистрировался, сдал багаж, а потом ушел в запой в дьютифри и пропустил посадку,
- что делать, если груз не помещается в самолеты, используемые на регулярных рейсах,
- как конкретно должны быть устроены процедуры регистрации, проверки и т.д.
Об этом можно будет поговорить в следующий раз.
Было бы интересно услышать ваше мнение. Вы согласны с приведенными в статье утверждениями и рекомендациями? Как у вас устроено управление релизами на крупных проектах? Легко ли проходило внедрение?
Автор: Savochkin
