Чтобы собрать данные, каждый год мы отправляли приглашения по нашим спискам рассылки и использовали социальные сети, включая Twitter, LinkedIn и Facebook. Наши приглашения были адресованы техническим специалистам, особенно тем, кто знаком с парадигмами разработки и доставки ПО, а также с DevOps. Мы призывали наших читателей приглашать друзей и коллег, которые тоже могли быть заняты в области разработки и доставки программного обеспечения, чтобы помочь нам расширить охват аудитории. Это называется «выборка по методу снежного кома», и мы поговорим о том, почему это был подходящий метод сбора данных для этого исследовательского проекта, в Главе 15 «Данные для проекта».
Данные для нашего проекта были получены из опросов. Мы использовали опросы, потому что это лучший способ собрать большой объем данных из тысяч организаций за короткий промежуток времени. Детальное обсуждение того, почему хорошие исследования могут быть проведены на основе опросов, а также шагов, которые мы предприняли для обеспечения достоверности и точности собранных данных, см. в Части II, которая охватывает научную основу и методологию исследования, лежащие в основе книги.
А вот краткий обзор исследования и того, как оно развивалось на протяжении нескольких лет.
2014 ГОД: ЗАКЛАДЫВАЯ ОСНОВЫ. ЭФФЕКТИВНОСТЬ ДОСТАВКИ ПО И ОРГАНИЗАЦИОННАЯ ЭФФЕКТИВНОСТЬ
Наши исследовательские цели в течение первого года состояли в том, чтобы заложить основу для понимания разработки и доставки программного обеспечения в организациях. Вот некоторые ключевые вопросы.
● Что значит доставка программного обеспечения и можно ли ее измерить?
● Влияет ли доставка ПО на организации?
● Имеет ли значение культура и как мы ее измеряем?
● Какие технические практики представляются важными?
Мы были приятно удивлены многими результатами в первый год. Мы обнаружили, что разработка и доставка программного обеспечения могут быть измерены статистически значимым образом и что успешные компании делают это постоянно с помощью методов, которые значительно лучше, чем у многих других компаний. Мы также обнаружили, что скорость и стабильность движутся вместе и способность организации создавать программное обеспечение положительно влияет на прибыльность, производительность и долю рынка. Мы увидели, что культура и технические практики имеют значение, и нашли способ их измерить. Об этом мы расскажем в первой части этой книги.
Группа также пересмотрела способ измерения большинства данных, перейдя от простых вопросов «да/нет» к вопросам по шкале Ликерта (в которых респонденты выбирают из спектра вариантов от «категорически не согласен» до «полностью согласен»). Это простое изменение в вопросах позволило команде собрать больше нюансов – оттенки серого вместо черно-белого. Это позволило провести более детальный анализ. Почему авторы решили использовать опросы для этого исследовательского проекта и почему вы можете доверять их данным, мы обсудим в Главе 14 «Зачем использовать опрос».
2015 ГОД: РАСШИРЕНИЕ РАБОТЫ И УГЛУБЛЕНИЕ АНАЛИЗА
Подобно технологическим преобразованиям и росту бизнеса, проведение исследований – это итерации, постепенные улучшения и переоценка важных результатов. Вооружившись нашими выводами за первый год, мы поставили в качестве целей на второй год пересмотр и подтверждение некоторых ключевых результатов исследования (например, что доставка программного обеспечения может быть определена и измерена статистически значимым образом и что она влияет на эффективность организации), а также расширение модели исследования.
Ниже представлены некоторые из вопросов исследования.
● Можем ли мы повторно подтвердить, что доставка программного обеспечения влияет на эффективность работы организации?
● Влияют ли технические методы и автоматизация на доставку программного обеспечения?
● Влияют ли методы бережливого управления на доставку программного обеспечения?
● Влияют ли технические методы и методы бережливого управления на те аспекты работы, которые оказывают воздействие на человеческие ресурсы, например, беспокойство, связанное с развертыванием кода и профессиональным выгоранием сотрудников?
Еще раз мы получили великолепные подтверждения по некоторым вопросам и ряд сюрпризов. Наши гипотезы подтвердились, расширив рамки работы, проделанной нами в прошлом году. Эти результаты вы можете найти в Части I.
2016 ГОД: РАСШИРЕНИЕ НАШЕГО ВЗГЛЯДА НА ТЕХНИЧЕСКИЕ МЕТОДЫ И ИЗУЧЕНИЕ НЕЧЕТКОГО ВНЕШНЕГО ИНТЕРФЕЙСА
На третьем году мы вновь опирались на основное ядро нашей модели и расширили ее, чтобы изучить значение дополнительных технических методов (таких как безопасность, магистральная разработка и управление тестовыми данными). Вдохновленные беседами с коллегами, работающими в области управления продуктами, мы еще расширили наше исследование, чтобы увидеть, можем ли мы измерить влияние текущего перехода от традиционных методов управления проектами к использованию принципов бережливого производства в управлении продуктами. Мы углубили наши изыскания, чтобы включить качественные измерения, такие как ошибки, доработки и восстановление безопасности. Наконец, мы включили дополнительные вопросы, чтобы попробовать понять, как технические методы влияют на человеческий капитал: индекс чистой лояльности сотрудников (eNPS) и приверженность работе – факторы, которые, как предполагается, должны уменьшать выгорание.
Ниже представлены вопросы нашего исследования.
● Помогает ли интеграция безопасности в разработку и доставку программного обеспечения этому процессу или замедляет его?
● Способствует ли магистральная разработка улучшению доставки программного обеспечения?
● Является ли бережливый подход к управлению продуктами важным аспектом разработки и доставки программного обеспечения?
● Способствуют ли хорошие технические практики повышению лояльности сотрудников?
2017 ГОД: ДОБАВЛЯЕМ АРХИТЕКТУРУ, ИЗУЧЕНИЕ РОЛИ ЛИДЕРОВ И ИЗМЕРЕНИЕ УСПЕХА В НЕКОММЕРЧЕСКИХ ОРГАНИЗАЦИЯХ
На четвертом году исследования мы перешли к вопросам о том, как проектируются системы и как архитектура влияет на способность команд и организаций доставлять программное обеспечение и формировать ценность. Мы также расширили наше исследование, чтобы включить в него измерение ценностей, которые выходят за рамки рентабельности, производительности и доли рынка, что позволяет анализу обращаться к некоммерческой аудитории. В исследовании этого года также изучалась роль лидеров для оценки влияния трансформационного лидерства в организациях.
Ключевые вопросы четвертого года нашего исследования.
● Какие архитектурные практики способствуют повышению эффективности доставки программного обеспечения?
● Как трансформационное лидерство влияет на доставку программного обеспечения?
● Влияет ли доставка программного обеспечения на некоммерческие результаты?
ВЫВОД
Мы надеемся, что, читая эту книгу, вы, как технический специалист и технологический лидер, откроете для себя важные элементы для улучшения своей организации, начиная прежде всего с доставки программного обеспечения. Именно благодаря улучшению нашей способности доставлять программное обеспечение организации могут быстрее предоставлять нужный функционал, при необходимости адаптироваться, реагировать на изменения в требованиях безопасности, а также использовать быструю обратную связь для привлечения новых клиентов и удовлетворения существующих.
В следующих главах мы определим ключевые возможности, определяющие эффективность доставки программного обеспечения (и определим, что такое эта эффективность), и кратко коснемся ключевых моментов каждой из них. Часть I книги представляет результаты наших исследований, Часть II
Сноски
1
Здесь и далее коммит (от англ. commit) – сохранение, фиксация изменений в программном коде. – Прим. ред.
2
Shift Left – устойчивый термин, обычно означающий привлечение команды тестировщиков на ранней стадии разработки ПО. Здесь и далее – встраивание информационной безопасности в процессы разработки и доставки ПО вместо выделения ее в отдельную фазу. – Прим. ред.
3
Важно отметить, что «Отчет о состоянии DevOps» был запущен еще до 2014 года. В 2012 году команда в Puppet Inc. пригласила Джина принять участие во второй итерации исследования, которое он разрабатывал, чтобы лучше понять малоизвестный феномен под названием DevOps: как он был принят и какие преимущества от него увидели организации. Puppet Inc. была ярым сторонником и драйвером движения с момента, когда идея DevOps начала формироваться после первых конференций DevOpsDays, обсуждений в Twitter и плодотворной беседы Джона Олспоу и Пола Хаммонда. Затем Джин пригласил Джеза присоединиться к исследованию, и вместе они собрали и проанализировали 4000 опросников со всего мира, что сделало его самым крупным исследованием в своем роде.