В последние годы набирают популярность методы ускоренной разработки ПО типа DevOps и Agile. Некоторые эксперты полагают, что скорость оборачивается проблемами с безопасностью. CTO разработчика баз данных Datical Роберт Ривз опровергает их опасения на портале Enterprisers Project.

Принято считать, что медленное движение гораздо безопаснее быстрой езды. Это подтверждает исследования страховщиков. Собранная ими статистика говорит о том, что повышение скоростных ограничений увеличивает количество случаев со смертельным исходом. Однако, если проводить аналогии, увеличение скорости не влияет на разработку софта. Более того, между скоростью и безопасностью образовалась ложная дихотомия. То, что они полярные противоположности — заблуждение. За время эволюции у человечества сложилось много других ложных представлений, например то, что у языка пять вкусовых зон или что человек задействует только 10% потенциала мозга.

Компания DevOps Research and Assessment (DORA) год за годом проводит исследования, которые говорят о высокой степени корреляции между успехом первого развертывания ПО и всеми последующими. Другими словами, если одни и те же процедуры проделывать по многу раз, то растет не только скорость их выполнения, но и качество. Военнослужащие — хороший пример. Они проводят постоянные учения, которые приближены к реальным событиям, и считаются основой военной подготовки. Принимая в них участие, военнослужащие постоянно повышают свои навыки, наращивают «мышечную память». По мнению армейского командования, постоянные тренировки придают солдатам уверенность и слаженность действий, которые необходимы в военное время.

Нужно взять на вооружение те же принципы и при выпуске ПО. Рассмотрим три выгоды, которые приносит ускоренная разработка.

1. Все показатели ориентируются на развертывания

DORA разработала четыре показателя для оценки процесса выпуска корпоративного ПО: частота развертывания, время для внесения изменений, средняя продолжительность восстановительных работ и показатель устранения ошибок. Стоит обратить внимание, что все эти показатели ориентированы на то, когда и при каких обстоятельствах ПО будет готово к коммерческой эксплуатации. Метрики DORA учитывают производственные развертывания, тогда как развертывание и тестирование среды разработки не учитывается. Реалистичности добавляет то, что в них предусмотрен показатель для выявления частоты ошибок в коде. Последний позволит ИТ-команде понять, как быстро она корректирует курс. Взяв на заметку эти метрики, компании смогут оценить скорость разработки, чтобы, как минимум, не отставать от своих конкурентов.

2. Месячных релизов — недостаточно

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

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

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

3. Скорость легче поддерживать, чем набирать

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

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

Выводы

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

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

Версия для печати (без изображений)