[Перевод] Улучшение дизайн-ревью в Google
Дизайн-ревью — один из важнейших этапов в жизненном цикле разработки ПО. В нем заинтересованные стороны оценивают эффективность проекта, обнаруживают дорогостоящие ошибки и выявляют несоответствия, недостатки. Для повышения скорости разработки важно получить одобрение проекта как можно быстрее.
Далее мы обсудим, как проводится дизайн-ревью в Google, а также предложим новое структурированное и автоматизированное решение, которое сократит время. Основываясь на данных 141 625 документов последних 4 лет, можно сказать, что наше решение проблемы сократит время ревью на 25% и обеспечит преимущества при постоянном использовании. Также подкрепим слова данными, которые демонстрируют успех нашего решения, обсудим факторы, влияющие на скорость дизайн-ревью, предложим стратегии для их преодоления и поделимся уроками, полученными в ходе использования нашего подхода.
Введение
Дизайн-ревью — один из важнейших начальных этапов в жизненном цикле разработки ПО. В нем заинтересованные стороны оценивают эффективность проекта, обнаруживают дорогостоящие ошибки, выявляют несоответствия шагов разработки [1] — [3].
Дизайн-ревью широко распространен в IT-индустрии: 70% опрошенных сообщили о применении подхода в своей работе. [4] В Goggle также широко применяется подход. Проектные документы обычно пишут в Google Docs [5]. Заинтересованные стороны, включая утверждающих, добавляют в документ свои email-адреса [6]. Данный процесс не структурирован, не автоматизирован и имеет ряд недостатков, которые снижают скорость дизайн-ревью. Авторы и проверяющие не могут легко отслеживать свои ревью, отсутствие уведомлений об изменении документа удлиняет процесс ревью, договоренности и одобрения не записываются автоматически.
В этой статье мы предлагаем обобщенную технику для структурирования и автоматизации дизайн-ревью посредством использования интегрированных инструментов разработчика. Предоставляем данные, основанные на четырехлетнем опыте Google, демонстрируем, как тысячи инженеров улучшили процесс ревью и резюмируем уроки, полученные в процессе.
Дизайн-ревью в Google
Дизайн-ревью широко распространен в Google. Несмотря на наличие множества инструментов, Google Docs [5] чаще всего применяется для разработки документации.
Рисунок 1. Заинтересованные лица добавляются в Google Docs. Человек на Рисунке (a) уведомляет о начале работы, а на Рисунке (b) — о необходимости одобрения документа. Утверждающий принимает документы с помощью галочки справа вверху.
После создания документа автор добавляет заинтересованных лиц, указывает их почтовые адреса в комментариях к документу [6] (см. Рисунок 1). Человек, который отмечен в комментарии, получает на почту уведомление об этом. Далее он добавляет комментарий к документу и после обсуждения одобряет его [6].
Изменения в документе могут быть не только до, но и после одобрения заинтересованными лицами. В нем могут быть неразрешенные комментарии даже после всех полученных одобрений.
В этом рабочем процессе есть недостатки, причем как для автора, так и для утверждающего лица.
Во-первых, тяжело отличить электронные письма друг от друга, что мешает утверждающим отслеживать изменения в документах.
Во-вторых, автор создает отдельный комментарий для каждого утверждающего, поэтому ему необходимо вручную проверять статус каждого комментария.
В третьих, в комментарии указывается человек, которому нужно прочитать и запомнить текст, чтобы понять, является ли он утверждающим. Это лишняя психологическая нагрузка.
Наконец, после утверждения документа часто добавляется дополнительная информация для автора. В результате заинтересованным лицам может быть не понятен статус документа. Это создает дополнительные трудности для автора и утверждающего. Для их решения используются другие каналы связи, например, внутренний чат.
Эти недостатки были выявлены с помощью опроса Google «Исследование удовлетворенности инженеров» (англ. Engineering Satisfaction Survey). Он помог понять потребности инженеров Google. Дизайн-ревью в течение нескольких лет является серьезной проблемой для авторов и утверждающих, так как замедляет скорость разработки ПО.
Улучшение дизайн-ревью с помощью DAC
Для устранения проблем, описанных ранее, мы разработали продукт Design Approval Companion (DAC). Он состоит из нескольких компонентов.
А. Таблица утверждающих с расширением DAC для Google Docs
Так как большинство разработчиков используют Google Docs, мы разработали внутреннее расширение DAC для Google Docs [8]. Оно дает возможность авторам создавать документы с минимальными дополнительными усилиями.
Рисунок 2. Проверяющий добавляется в документ, используя #approver в комментарии.
Автор устанавливает расширение DAC, создает документ для ревью, указывает в комментарии проверяющего, добавляя #approver в текст комментария (как на Рисунке 2). Далее проверяющий утверждает документ.
Расширение DAC периодически сканирует все комментарии в документе, идентифицирует проверяющих по тегу #approver. Далее генерирует в начале документа таблицу, где содержатся проверяющие и статус (Рисунок 3). Данная таблица обновляется автоматически.
Рисунок 3. Автогенерируемая и автообновляемая таблица утверждающих. Она создается из Google Docs-комментариев, содержащих тег #approver в описании, и показывает статус каждого утверждающего.
Она устраняет некоторые недостатки, описанные ранее: авторы видят статусы утверждающих, проверяющие видят, ждут ли их авторы, все видят актуальный статус документа.
Кроме того, вместо нового инструмента все используют ту же среду, к которой они привыкли, что способствует простоте понимания и внедрению процесса. Наконец, расширение DAC универсально, причем как для пользователей Google Docs, так и аналогичных продуктов, которые позволяют построить взаимодействие с помощью комментариев между людьми.
Б. Напоминания DAC с помощью Chrome уведомлений
Все разработчики Google используют расширение Event Notifier, которое уведомляет их о различных событиях, например, код ревью и баги, и сохраняет эти события в виде списка [9].
Рисунок 4. Уведомления в Chrome, которые присылаются утверждающим и авторам при изменениях в документах.
Мы встроили расширение DAC-авторам и утверждающим в Event Notifier. На Рисунке 4 представлены три вида уведомлений:
уведомляет о том, что нужно проверить документ;
уведомляет о том, что один из утверждающих проверил документ;
уведомляет о том, что документ всеми утвержден.
Эти уведомления решают несколько проблем:
позволяют авторам и утверждающим работать сообща;
обеспечивают централизованное отслеживание исходящих и входящих изменений в дизайн-ревью;
способствуют повышению скорости разработки.
Кроме того, уведомления можно настроить для разных браузеров, c аналогичными расширениями Chrome [9].
В. Трекер-ревью DAC, встроенный в документ
Google-команды обычно отслеживают проектные документы во время еженедельных совещаний. Это делается для проверки статусов [4], просмотра изменений и ошибок, которые необходимо устранить. Вручную поддержание актуальной информации по данным вопроса требует много усилий со стороны членов команды.
Рисунок 5: g3doc-виджет для автоматического заполнения и отображения списка проектных документов и их статусов.
Для документации Google применяет внутренний инструмент g3doc [10, часть 10] [11]. Он используется командами для широкого круга задач. Например, хранение документации пользователя, внутренней документации, описание архитектуры системы. g3doc поддерживает встраиваемые виджеты. Например, инструменты, которые позволяют встроить в документацию отображение в реальном времени данных из других систем Google.
Мы строили виджет DAC в g3doc для автоматического заполнения и отображения всех проектных документов, созданных членами команд с отображением статусов (как показано на Рисунке 5). Это позволило избежать ручного труда во время совещаний.
Оценка и полученные уроки
В этой части приводится статистика использования разных компонентов DAC на момент написания этой статьи (июнь 2023 год), улучшения, которые произошли в процессе дизайн-ревью за четыре года использования в разных странах, а также уроки, усвоенные на основе данных и опросов.
А. Удобство использования и внедрения
Таблица 1. Статистика использования компонентов DAC.
В Таблице 1 представлена статистика использования компонентов DAC. 61 716 разных пользователей установили расширение DAC в Google Docs, 99 942 получили хотя бы одно уведомление Event Notifer из DAC,115 разных команд использовали DAC как виджет в g3doc для отслеживания дизайн-ревью.
Таблица 2. Cтатистика использования расширения DAC для Google Docs.
В Таблице 2 представлена статистика использования расширения DAC для Google Docs.
41 030 различных авторов использовали расширение DAC в 251 517 проектных документах. 141 652 документа были полностью одобрены всеми утверждающими. Авторы — представители 279 офисов Google в 20 часовых поясах и в 48 странах. Добавлено 74 796 разных утверждающих из 294 офисов Google в 20 часовых поясах и в 52 странах. На каждый документ приходится в среднем 2,6 утверждающих.
DAC имеет несколько важных функций, которые предотвращают разногласия между авторами и утверждающими:
DAC прост в применении и требует только использования тега #approver в комментариях;
устанавливать расширение для Google Docs нужно только авторам документов;
DAC интегрирован в критически важные рабочие процессы пользователей и не требует изучения новых инструментов или процессов;
все в процессе дизайн-ревью автоматизировано, кроме мест, в которых необходимо взаимодействие между людьми.
Хотя мы не рекламировали DAC и не заставляли команды использовать его, он быстро обрел популярность. Основываясь на показателях внедрения и опросах пользователей, которые будут рассмотрены в следующих разделах, инженеры предпочли структурированный и автоматизированный процесс ревью.
Полученный урок:
Авторы и утверждающие предпочитают структурированный и автоматизированный процесс дизайн-ревью, когда это возможно.
Б. Базовое тематическое исследование
Дизайн-ревью состоит из нескольких связанных шагов:
разработка документа;
добавление утверждающих;
обновление документа после проверки утверждающими;
одобрение документа утверждающими.
Главная цель DAC — сокращение времени, которое инженеры затрачивают на дизайн-ревью. Чтобы отследить достижение поставленной цели, мы определяем время утверждения (time-to-approval) в качестве интересующего показателя.
Time-to-approval (TTA) — общая продолжительность времени с момента создания документа до полного утверждения.
Таблица 3. Статистика базового тематического исследования.
Перед созданием DAC мы опросили 44 автора документов из 16 команд. С их помощью проанализировали 108 ревью, которые были созданы без DAC.
Мы попросили участников нашего исследования вручную собрать информацию о документах, которые были проверены утверждающими. Затем вычислили промежуток времени между созданием документа и полным его утверждением, чтобы найти его TTA. Основываясь на нашем анализе, среднее значение показателя получилось 963 часа.
В. Использование DAC улучшает TTA
После проведенного исследования мы реализовали DAC и собрали статистику использования в Google на протяжении четырех лет.
Таблица 4. Статистика использования DAC в документах.
Согласно Таблице 4:
141 652 документа было утверждено с использованием DAC;
медианное значение документов, созданное одним автором, равно 2;
среднее значение документов созданное одним автором, равно 3,47:
медианное значение TTA — 722.
При использовании DAC TTA сократилось на 25%.
Полученный урок:
Использование автоматизации в процессе ревью, которая интегрирована в рабочий процесс, значительно повышает скорость утверждения документов.
Г. Постоянное использование DAC еще больше увеличивает TTA
Мы предположили, что постоянное использование DAC при проведении дизайн-ревью увеличит скорость работы по некоторым причинам:
Таблица 6. Медианное значение TTA документа, созданного одним пользователем, с течением времени.
DAC четко отображает статусы документов, причем как для авторов, так и для утверждающих;
при использовании DAC накапливается пользовательский опыт, что способствует более эффективной работе;
интеграция рабочих процессов снижает напряжение между заинтересованными лицами и постоянно напоминаем им об их обязанностях.
Для оценки гипотезы мы проанализировали документы, созданные с помощью DAC, расположив их в хронологическом порядке. То есть мы анализируем первый документ, созданный автором, второй документ, созданный этим же автором, а также N-й документ, созданный этим автором. Таким образом разбиваем работу пользователя на сегменты. Используя их, мы наблюдаем за TTA в последующих документах автора, как показано в таблице 6, где в каждом сегменте анализируется не менее 1000 документов.
На графике 6 видно, что среднее время утверждения первого документа при использовании DAC — 977 часов, что близко к уровню до использования (963). Скорее всего, это связано с тем, что пользователи еще не знакомы с функционалом DAC.
Значение TTA в последующих документах, созданных тем же пользователем, демонстрирует значительное улучшение. Учитывая, что среднее значение документов, создаваемых одним пользователем, равно 3,47 (из Таблицы 4), значение TTA для N=4 на Рисунке 6 составляет 684 часа. По сравнению с N=1, это дает разработчикам возможность в среднем на 29% ускорить дизайн-ревью. Пользователи, которые продолжают использовать DAC, с каждым разом улучшают показатель TTA, что доказывает наше предположение.
Полученный урок:
По мере привыкания к новому процессу дизайн-ревью, TTA со временем улучшается.
Д. DAC обеспечивает дополнительные преимущества
В этом разделе мы покажем результаты опроса, проведенного нами среди 7 руководителей высшего звена, чьи подразделения постоянно используют DAC, то есть имеют минимум 150 различных авторов в каждом подразделении, где на каждого приходится не менее 10 документов.
Мы задавали руководителям открытые вопросы, почему их подразделения используют DAC и какие преимущества им это дает. Ниже представлены некоторые выдержки из общения с ними.
«Нам очень нравятся автоматизация и интеграция рабочих процессов в DAC. Это упростило процесс дизайн-ревью в нашем подразделении».
«Я разрабатывал документ для […], и он был одобрен несколькими людьми. Было круто, что все, кто использовал DAC, видел его статус».
«В нашем проекте […] задействовано множество людей и команд из разных мест и часовых поясов. Отсутствие ясности, кто является утверждающим, а кто уже утвердил документ, не только сильно замедляло работу, но и создавало напряжение, провоцировало конфликты. DAC позволил нам почувствовать, что мы одна, сплоченная команда».
«В нашем подразделении много проектов, которые требуют долгой поддержки. Мы используем DAC для уверенности, что все нововведения задокументированы и одобрены».
Основываясь на ответах, можно сделать вывод, что использование DAC дает преимущества для команд, которым необходимо наблюдать за изменениями в документации.
Полученный урок:
Автоматизация дизайн-ревью приносит пользу пользователям: улучшает порядок проверки, коммуникацию между заинтересованными сторонами, дисциплинирует пользователей и обеспечивает психологический комфорт.
Е. Чем больше проверяющих, тем больше TTA
Таблица 7. Медианное значение TTA в зависимости от числа проверяющих.
Основываясь на исследовании и опросах, инженеры пришли к выводу, что чем больше проверяющих в документе, тем больше времени затрачивается на обсуждение документа. Есть вероятность, что они будут в разных часовых поясах, а это приведет к задержкам. На Рисунке 7 мы построили график изменения TTA в зависимости от количества утверждающих. Он доказывает это явление.
Кроме того, инженеры заявили, что они добавляют утверждающих постепенно (волнами), чтобы предотвратить задержки. Это подтверждается выдержками ниже
«Мы используем налаженный процесс дизайн-ревью, который строго следует порядку: Цюрих, Сан-Франциско, Саннивейл, Цюрих и, наконец, Нью-Йорк. Мы используем DAC, чтобы добавлять утверждающих в таком порядке».
«Добавление всех утверждающих одновременно ужасно. DAC помогает нам контролировать этот процесс и медленно расширять список участвующих».
Полученный урок:
Большое количество утверждающих увеличивает значение TTA. Один из способов избежать задержек — это поэтапно добавлять в документ заинтересованных лиц, начиная с членов команды.
Суровая действительность
Во-первых, мы разрабатывали DAC для дизайн-ревью документов, и у нас нет способа контролировать использование расширения пользователями.
Во-вторых, у людей нет руководства, как выбирать утверждающих и сколько их должно быть.
В-третьих, на этапе базового тематического исследования могли быть допущены ошибки по причине человеческого фактора.
В-четвертых, мы не проводили эксперимента между участниками базового тематического исследования и пользователями DAC, поэтому результаты могут быть неоднозначными.
В-пятых, мы не контролируем жизненный цикл проекта. Некоторые проекты могут останавливаться и возобновляться позже. Это может вносить неточности в TTA.
Связанные работы
Дизайн-ревью дает преимущества на ранних стадиях проекта [12] — [15]. Инженеры тратят на обучение сотрудников [16] и совещания большое количество времени [17].
Инструкции [1] и проверки [2] предлагаются в качестве полезных механизмов работы. Также были предложены методы анализа архитектуры ПО для предотвращения ошибок на ранней стадии. Это анализ архитектуры на основе сценариев [18], trade-off анализ [19], промежуточные ревью [3], анализ изменчивости архитектурного уровня [20], [21], а также реинжиниринг архитектуры на основе сценариев [22]. Недавно было предложено использовать виртуальную реальность в качестве инструмента для дизайн-ревью [23].
Проектные документы, созданные в Google, обычно охватывают различные аспекты систем, включая системные представления, сценарии [24] и архитектуру [25].
Существуют продукты для утверждения документов [26]–[28], где авторы просят утверждающих одобрить их. По сравнению с подходом, описанным в данной
работе, у этих продуктов есть два основных недостатка. Во-первых,
они требуют, чтобы пользователи использовали отдельный продукт. Во-вторых, они, как правило, требуют, чтобы на этапе утверждения в документ не вносились изменения, следовательно, не подходят для проектов, которые нужно непрерывно редактировать на этапе утверждения.
Заключение
В этой статье мы обсудили дизайн-ревью, как этот процесс организован в Google, рассмотрели проблемы, предложения по автоматизации, которые значительно улучшили рабочий процесс и обсудили полученные уроки за 4 года.
Согласно нашим выводах, разработчики предпочитают использовать автоматизированный процесс дизайн-ревью. Он повышает скорость работы. Продолжительное использование данного метода еще больше повышает скорость ревью, помогает коммуницировать заинтересованным лицам друг с другом, обеспечивает психологический комфорт.
Благодарности
Мы благодарим людей, которые помогли создать DAC: Greg Dooley, Shondell Baijoo, Xavier Decoret, Trung Phan, Tony Zhao, Jason Lunn, Wentao Zhang, Maxim Goldin, Pedro Nunes, Vivek Parikh
Мы также благодарим внутренних рецензентов Google и анонимных рецензентов комитета ASE.
Список литературы
[1] E. Yourdon, Structured walkthroughs. Yourdon Press, 1989.
[2] M.E. Fagan, «Design and code inspection to reduce errors in program development,» IBM Systems Journal, 1976.
[3] P.C. Clements, «Active reviews for intermediate designs,» Carnegie Mellon University Software Engineering Institute, Pittsburgh, PA, USA, Tech. Rep. CMU/SEI-2000-TN-009, 2000. [4] M. Ciolkowski, O. Laitenberger, and S. Biffl, «Software reviews, the state of the practice,» IEEE software, vol. 20, no. 6, pp. 46–51, 2003.
[5] «Google docs: Online document editor,» https://www.google.com/docs/about, 2023, [Online; Accessed: 2023- 06–01].
[6] «Google docs: Use comments, action items, & emoji reactions,» https://bit.ly/3q2rqeb, 2023, [Online; Accessed: 2023–06–01].
[7] L. Cheng, E. Murphy-Hill, M. Canning, C. Jaspan, C. Green, A. Knight, N. Zhang, and E. Kammer, «What improves developer productivity at google? code quality,» in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 2022, pp. 1302–1313.
[8] «Google docs: Extending google docs with add-ons,» https://bit.ly/3Ow7Iln, 2023, [Online; Accessed: 2023–06–01].
[9] «Chrome web store — extensions,» https://bit.ly/3opZAYU, 2023, [Online; Accessed: 2023–06–01].
[10] T. Winters, T. Manshreck, and H. Wright, Software engineering at google: Lessons learned from programming over time. O«Reilly Media, 2020.
[11] R. MacNamara, «Do docs better: Practical tips on delivering value to your business through better documentation.» USENIX Association, Jun. 2018.
[12] G. Abowd, L. Bass, P. Clements, R. Kazman, and L. Northrop, «Recommended best industrial practice for software architecture evaluation.» Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst, Tech. Rep., 1997.
[13] B.W. Boehm, «Verifying and validating software requirements and design specifications,» IEEE software, vol. 1, no. 1, p. 75, 1984.
[14] B. Boehm and V.R. Basili, «Defect reduction top 10 list,» Computer, vol. 34, no. 1, pp. 135–137, 2001.
[15] M. Fagan, «Design and code inspections to reduce errors in program development,» Software pioneers: contributions to software engineering, pp. 575–607, 2002.
[16] B. Curtis, H. Krasner, and N. Iscoe, «A field study of the software design process for large systems,» Communications of the ACM, vol. 31, no. 11, pp. 1268–1287, 1988.
[17] S. Sonnentag, «Excellent software professionals: Experience, work activities, and perception by peers,» Behaviour & Information Technology, vol. 14, no. 5, pp. 289–299, 1995. [18] R. Kazman, L. Bass, G. Abowd, and M. Webb, «Saam: A method for analyzing the properties of software architectures,» in Proceedings of 16th International Conference on Software Engineering. IEEE, 1994, pp. 81–90.
[19] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, and J. Carriere, «The architecture tradeoff analysis method,» in Proceedings. Fourth IEEE International Conference on Engineering of Complex Computer Systems (Cat. No. 98EX193). IEEE, 1998, pp. 68–78. [20] P. Bengtsson and J. Bosch, «Architecture level prediction of software maintenance,» in Proceedings of the Third European Conference on Software Maintenance and Reengineering (Cat. No. PR00090). IEEE, 1999, pp. 139–147. [
21] P. Bengtsson, N. Lassing, J. Bosch, and H. van Vliet, «Architecture-level modifiability analysis (alma),» Journal of Systems and Software, vol. 69, no. 1–2, pp. 129–147, 2004.
[22] P. Bengtsson and J. Bosch, «Scenario-based software architecture reengineering,» in Proceedings. Fifth International Conference on Software Reuse (Cat. No. 98TB100203). IEEE, 1998, pp. 308–317.
[23] J. Wolfartsberger, «Analyzing the potential of virtual reality for engineering design review,» Automation in Construction, vol. 104, pp. 27–37, 2019.
[24] C.-H. Lung, S. Bot, K. Kalaichelvan, and R. Kazman, «An approach to software architecture analysis for evolution and reusability,» in Proceedings of the 1997 conference of the Centre for Advanced Studies on Collaborative research. Citeseer, 1997, p. 15.
[25] P.C. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, «A practical method for documenting software architectures,» 2002. [Online]. Available: http://repository.cmu.edu/compsci/671/
[26] «Get approvals on files in google drive,» https://support.google.com/drive/answer/9387535, 2023, [Online; Accessed: 2023–06–01].
[27] «Create and test an approval workflow with power automate,» https://learn.microsoft.com/en-us/power-automate/modern-approvals, 2023, [Online; Accessed: 2023–06–01].
[28] «Docusign,» https://www.docusign.com, 2023, [Online; Accessed: 2023- 06–01].
