Таким образом, существуют веские экономические причины для оптимизации вашей работы в поставке новых идей на рынок. Это относится ко всем идеям – и к воплощенным в программном обеспечении (например, новая функция на сайте), и к тем, которые никак не относятся к нему, например изменение цен или новые маркетинговые ходы. В современных компаниях при реализации многих из этих идей полагаются на программное обеспечение, но, как вы узнаете в данной главе, эти процессы выходят далеко за рамки простой оптимизации команды разработчиков программного обеспечения. Если мы нацелены создать эффективный поток, мы должны заглянуть за пределы функционирования технологических команд и рассмотреть всю организационную систему.
Рассмотрение инфраструктуры потока
Для начала давайте поговорим о некоторых технологических приемах, которые современные команды применяют для создания инфраструктуры потока. Мы будем опираться на эти знания, чтобы оценить, как бизнес-команды работают в этой новой среде «непрерывного всего».
ОЦЕНКА ДВИЖЕНИЯ DEVOPS: ТЕХНИЧЕСКАЯ ОСНОВА ПОТОКА
Одной из интересных вещей, появившихся в мире технологий за последние десять лет, является направление DevOps (акроним от англ. «development» – разработка и «operations» – операции) – набор идей и процессов, которые позволяют командам выпускать надежное программное обеспечение быстро и с меньшими рисками, чем прежде. DevOps – технический и инфраструктурный уровень того, о чем мы говорили на протяжении всей книги, поэтому стоит потратить несколько минут на основные концепции этого направления и оценку влияния, которое оно оказывает на организации.
Для большинства людей за пределами технологической индустрии «программные операции» являются невидимой и неясной функцией. Однако за операциями стоят люди, которые создают и поддерживают операционную среду, в которой работают программные сервисы и продукты. Они настраивают серверы, сети и базы данных, устанавливают и поддерживают программное обеспечение, которое обеспечивает работоспособность всей инфраструктуры, справляется с перебоями, и (что наиболее важно для обсуждения) задействуют новые версии для программного обеспечения, создаваемого командами по разработке продуктов.
Как мы уже выяснили, на самых ранних этапах цифровой эпохи программное обеспечение создавалось и предоставлялось в последовательном процессе, который напоминал работу сборочной линии. Одни люди задавали направление развития программного обеспечения, другие разрабатывали его, третьи проектировали, кто-то тестировал, и, наконец, операционные сотрудники начинали использовать его. Но по мере того, как разработчики в основе процесса перешли к использованию гибких методов и начали выпускать все меньшие части кода, процессы, связанные с разработкой программного обеспечения, оказались под давлением.
Представьте, что вы являетесь тестировщиком обеспечения качества. Вы привыкли получать добротное новое программное обеспечение примерно каждый месяц. Это означает, что у вас есть много времени на проверку, прежде чем прибудет новое программное обеспечение. А теперь представьте, под каким давлением вы окажетесь, когда разработчики начнут поставлять вам программное обеспечение каждые две недели или каждый день, а может, и много раз за день. Единственный способ успевать за всем – это изменить ваш процесс, рабочий поток и инструменты. Вы начинаете использовать ваш ранний опыт сотрудничества, новые стратегии тестирования и автоматизированные тесты. Суть не в том, что надо работать усерднее и быстрее. Дело в использовании автоматизации. Речь идет о фундаментальном изменении подхода к обеспечению качества.
То же самое произошло и с операционными рабочими потоками. В условиях менее частых выпусков программного обеспечения команды довольствовались медленными неавтоматизированными процессами. Запуск нового программного обеспечения можно было запланировать на вечер пятницы, чтобы избежать любого риска для систем, использующихся в рабочее время. Неважно, что этот запуск в пятницу вечером мог затянуться на выходные: если они закончат к утру понедельника, это все еще будет считаться достаточно быстрым.
Как только выпуски стали более частыми, операции по запуску перестали за ними не поспевать. Операционные команды также начали автоматизировать свои процессы, менять рабочий поток и оптимизировать сотрудничество с разработчиками. Эти новые подходы – суть идеологии DevOps, и они привели к феноменальным изменениям. Компании когда-то были рады выпускать новое программное обеспечение несколько раз в год, но сейчас мы видим компании, которые приняли подходы DevOps и, выпускают новое программное обеспечение несколько раз в день.