Что такое дизайн ревью
Design Review vs Design by Committee
Мне в основном очень нравятся архитекторы в Microsoft. Некоторые более, чем другие, а некоторые — совершенно замечательные.
Одного из совершенно замечательных зовут Дэвид Блайс (David Blythe), и он архитект в Windows в области графики. Дядька раньше дизайнил OpenGL в SGI, писал по нему книжку, а сейчас вот работает в том числе над Direct3D. Дядька совершенно монструозный и замечательный. Я с ним говорил минут 20 и просветлился больше, чем за два предыдущих месяца. Читал его гуидлайны про API design и опять же радовался.
Отрывок на сегодня:
«DESIGN BY COMMITTEE. Avoid design by committee. There should be a single person with final say in the design… and this person should have good architectural experience and instincts.»
Я еще не умею писать так лаконично, поэтому придется в многабукф.
Вот мне очень нравится Design Review и я всем его советую. Это когда перед тем как кодать что-то, надо об этом рассказать команде или еще кому, у кого есть время и понимание происходящего. Тебе обязательно наговорят кучу фидбека, вспомнят 10 тонких мест, о которых ты не подумал и предложат альтернатив. И часто окажется, что первая идея дизайна не идеальна, а может и вторая. Или неплоха, но нужно додумывать.
Если их фичи на тебя завязаны, то еще и посмотрят и прикинут как вы будете интегрироваться. Так как Design Review взаимный, то и ты будешь знать о той стороне. Кроме того, и знания людей о проекте расширяются и начинают больше пересекаться, и код твой понимать проще, и Code Review становится гораздо более осмысленным занятием.
Хорошо бы после этого обсуждения еще и записать основные принятые решения и почему. Конечно, с какой вам лично хочется детальностью, от детального Design Spec до коротенькой странички «overview and key decisions».
Точно так же, количество формальности в этом всем может быть совершенно разного порядка. От регулярных митингов до «Мужики, давайте заобсудим мою новую херовину».
Все это крайне полезно и обязательно нужно делать. Коллективный разум заруливает и побеждает.
И у этого всего только один catch — коллективное обсуждение не должно означать коллективных решений. Коллективный разум очень хорошо думает, но очень плохо принимает решения. Всегда должен быть один человек, который имеет право выбрать из предложенных альтернатив и их за и против. Понимая всю картину, осознавая все возможности, сказать «а вот с этим мы будем жить», «мы выбираем вот такой трейдофф», в конце концов, сказать «а вот на это мы положим хер».
Иначе — превратится в коллективную безответственность и бесконечные споры. Я это прямо видел своими глазами, и не я один.
Design Review — это очень хорошая и правильная вещь. Принцип Avoid Design by Committee ее дополняет, а никак не перечеркивает. Отзывы нужно слушать, понимать, и если возникает альтернатива лучше твоей первой идеи, не бояться брать эту альтернативу. То есть — коллективный разум таки действительно рулит. Решение, которое ты примешь не рассказав и не посоветовавшись — будет хуже. Но тем не менее, принимать решение — только тебе самому.
design review
анализ проекта
Документированная, всесторонняя и систематическая проверка проекта с целью оценки его возможности выполнять требования к качеству, выявлять проблемы и определять способы их решения.
Примечание
Анализ проекта может проводиться на любом этапе процесса проектирования, но в любом случае он должен быть осуществлен по завершении процесса.
[ИСО 8402-94 ]
Тематики
Обобщающие термины
пересмотр конструкции
—
[Л.Г.Суменко. Англо-русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.]
Тематики
3.10 анализ проекта (design review): Документально оформленный, комплексный и систематизированный процесс проверки проектной документации с целью оценки способности продукции удовлетворять установленным требованиям, позволяющий выявлять проблемы и предлагать пути их решений.
1 В настоящем стандарте основой для анализа проекта являются функциональные требования.
2 При разработке проекта оказания услуг также может быть проведен анализ проекта.
Полезное
Смотреть что такое «design review» в других словарях:
Design Review — was a publication of the Wellington Architectural Centre. The Centre was founded in 1946, and began the first architectural school in Wellington (1947) and the first town planning school in New Zealand (1949). The Centre was unique at the time of … Wikipedia
Design review — This article is about the general concept of design reviews. For Design Reviews in DoD and NASA, see Design review (US Government). A design review is a milestone within a product development process whereby a design is evaluated against its… … Wikipedia
Design Review Based on Failure Mode — (DRBFM) is a tool originally developed by the Toyota Motor Corporation. This tool was developed based on the philosophy that design problems occur when changes are made to existing engineering designs that have already been proven successful.… … Wikipedia
Design review (US Government) — This page refers to the system engineering principle, for the magazine, see: Design Review (publication) In the United States military and NASA s engineering design life cycle, a phase of design reviews are held for technical and programmatic… … Wikipedia
Design Review (publication) — This article is about the magazine, for the military and government engineering design life cycle, see: Design review. Design Review was a publication of the Wellington Architectural Centre. The Centre was founded in 1946, and began the first… … Wikipedia
Design Review Based on Failure Mode — Versagenserfassungsgestützte Konstruktionsänderung bzw. Design Review Based on Failure Mode (DRBFM) ist eine Entwicklungsmethode, die den Entwicklungsprozess eines Prozesses/Produktes begleitet. Sie wird im Rahmen des Qualitätsmanagements zur… … Deutsch Wikipedia
Critical Design Review — Unter Critical Design Review oder abgekürzt CDR (deutsch: entscheidende Entwurfsprüfung) versteht man die letztgültige Planungskontrolle eines Projektes vor der Umsetzung. Es bildet einen wichtigen Meilenstein im Projektablauf, und ist oft auch… … Deutsch Wikipedia
System Design Review — A System Design Review (SDR) is a scheduled review, of many government contractor relations, which ensures continuous involvement throughout a program. The SDR is defined in the Air Force s MIL STD 1521.The SDR is a technical review conducted to… … Wikipedia
Design history file — is a compilation of documentation that describes the design history of a finished medical device. The design history file, or DHF, is part of regulation introduced in 1990 when the U.S. Congress passed the Safe Medical Devices Act, which… … Wikipedia
Design for manufacturability — (also sometimes known as design for manufacturing) (DFM) is the general engineering art of designing products in such a way that they are easy to manufacture. The basic idea exists in almost all engineering disciplines, but of course the details… … Wikipedia
AutoCAD LT
Autodesk® Design Review – это бесплатная программа, используемая для создания и просмотра файлов DWF. DWF — это открытый, публикуемый и защищенный формат файлов, разработанный Autodesk, который позволяет объединять, публиковать и совместно использовать разнообразные данные 2D и 3D проектирования.
Design Review позволяет всем сотрудникам, работающим над проектом или производством, просматривать, печатать, измерять и помечать файлы DWF, DWG, DXF, PDF, а также файлы растровых изображений, содержащие 2D- и 3D-объекты. Программа Design Review полностью интегрирована с AutoCAD®, Inventor® и Revit® и позволяет легко обеспечить совместное использование чертежей, моделей, карт и проектных данных с участниками рабочей группы, клиентами, консультантами, подрядчиками, партнерами, поставщиками и другими заинтересованными лицами, у которых могут отсутствовать программы для проектирования или навыки работы с ними.
Для совместного использования проектных данных в Design Review можно отправить проект по электронной почте, опубликовать на веб-сайте, во внутренней сети или записать на физический носитель, например на DVD-диск. Программу Design Review можно бесплатно загрузить по адресу http://www.autodesk.com/designreview-download. Программу можно распространить по внутренней сети или развернуть в составе образа корпоративного компьютера (при условии, что она распространяется целиком, согласно положениям лицензионного договора).
Файлы DWF и DWFx
Файл DWF можно использовать для организации подшивок, моделей, анимаций, результатов анализа методом конечных элементов (МКЭ) и информации карт, а также других связанных с проектом файлов в одном файле с высокой степенью сжатия. Вместе с Design Review файлы DWF позволяют оптимизировать совместную работу путем четкой передачи информации, такой как изменения или исправления проекта, и при этом сокращают затраты на печать и отправку, связанные с передачей бумажных документов расширенной рабочей группе.
Подобно файлам Adobe® PDF, файлы DWF не подлежат изменению, чем напоминают распечатки. Однако в отличие от файлов PDF файлы DWF сохраняют подробную информацию о проекте и масштаб и поэтому являются более удобными для архитекторов, инженеров и проектировщиков.
Последняя версия формата файлов DWF, т. е. DWFx, разработана на основе спецификации XML Paper Specification (XPS) корпорации Microsoft. DWFx упрощает передачу проектных данных рецензентам, которые не могут установить программное обеспечение.
Файлы DWFx можно быстро открыть и распечатать с помощью бесплатной программы Microsoft XPS Viewer. В отличие от файлов DWF файлы DWFx содержат дополнительную информацию для отображения проектных данных в программе Microsoft XPS Viewer. По этой причине размер файлов DWFx превышает размер соответствующих файлов DWF.
В настоящее время приложение Microsoft XPS Viewer не поддерживает листы, содержащие 3D-объекты, объекты, защищенные паролем, свойства объекта, объекты с ограничениями или координаты карт с привязкой к местности. В программе Microsoft XPS Viewer при попытке просмотра листов файлов DWFx, содержащих любой из этих неподдерживаемых элементов, появляется предупреждение с просьбой загрузить Design Review для просмотра файла DWFx.
Рабочий процесс цифрового проектирования
Как правило, файлы DWF формируются при создании чертежа или модели в таких программах Autodesk, как AutoCAD, Inventor и Revit. Перед публикацией файла DWF автор определяет, какие элементы (модель, листы, слои, блоки, именованные виды и т. п.) включаются в публикуемый файл DWF. Определив содержимое, он публикует исходный файл в формат DWF, а затем отправляет DWF группе рецензентов для проверки цифрового проекта.
Цифровой рабочий процесс можно повторять неограниченное количество раз в соответствии с итеративным характером процесса проектирования и проверки.
Active Design Review. Как согласовать архитектуру и не разругаться
Привет, Хабр! Меня зовут Олег Сало, я ведущий архитектор MTS Digital в центре IT-продуктов клиентского опыта B2C. Уже достаточно давно я занимаюсь разработкой и проектированием корпоративных информационных систем, в основном в области CRM и Customer Experience.
Сегодня я бы хотел рассказать про такую интересную технику, как Active Design Review, как мы ее попробовали применить у нас в компании и что из этого вышло.
Где проблема?
Типичная ситуация, с которой мы как архитекторы сталкиваемся — это «я придумал какую-то архитектуру, какое-то решение (solution для бизнес-проблемы, архитектуру какой-нибудь распределённой системы, модель данных, архитектурный гайдлайн и т.п.) и хочу его внедрить, хочу, чтобы оно заработало и им начали пользоваться».
Тут есть как минимум две сложности:
Учесть интересы задействованных команд.
Если то, что я спроектировал, реализует множество команд — важно уметь прийти к общему мнению. Между исполнителями, смежными командами, представителями IT-Governance (если они есть). Нужно учесть особенности компонентов решения, направления развития команд и продуктов, правила и ограничения, принятые в компании и т.п.
Убедиться в работоспособности решения.
Ошибки проектирования, как известно, самые дорогие, а выявить их очень сложно, особенно на этапе, когда у нас есть только идея, а конкретной реализации, которую можно было бы протестировать, нет.
Какие варианты решения?
Минусы в том, что часто вообще всех причастных в одной комнате в одно время не соберешь (у каждого свои срочные задачи, спринты горят, календарь забит, «давайте уже после праздников»), да и на доске всё не нарисуешь — все-таки нужен какой-то документ, в котором решение будет описано со всех сторон. А ещё обязательно появится кто-то, кто скажет «вы меня не звали, а я вообще-то против. Мой сервис не учли, решение так себе, ничего не заработает».
Второй вариант, с которым знакомы все, кто работал в большой компании — это классическое согласование документа. Всё описываем в документе/статье в конфлюенсе и просим всех причастных прокомментировать. Здесь плюс, что есть конкретный артефакт (документ), есть история согласований, но минусов куда больше. Тут и рецензенту очень тяжело ничего не забыть, и автору решения сложно свести воедино все комментарии. Ну и не забываем про того самого человека, который не читал, но не согласен. К тому же, такой подход попахивает формализмом.
Active Design Review — а попробуй сделать!
Есть и третий вариант, он называется Active Design Review. Описание этой техники есть в относительно старой научной работе 1985 года. Смысл техники в том, что вопросы задает не тот, кто рецензирует решение, а тот, кто это решение придумал и пытается согласовать. Работает это так.
Сначала готовим формальное описание решения (да, без документа/статьи/схемы тут не обойдётся).
Затем определяем фокус-группу: это все, кого потенциально затронет архитектурное решение.
Потом смотрим на решения или ответы и вносим правки.
Для себя мы сделали примерно так же, только мы использовали практические кейсы. То есть сделали описание архитектуры, придумали кейсы-задания для рецензентов и, не рассказывая ничего о материале, не пытаясь обосновать решение, просто дали людям кейсы, чтобы они их решали. И попробовали собрать их замечания по результатам решения.
Наш регламент, который мы для себя приняли в Active Design Review:
максимально широкий круг участников (есть возможность открытого входа);
максимум публичности внутри команды/компании (освещаем где только можно);
участникам рассказываем только то, где посмотреть само описание;
не обсуждаем архитектуру и не отвечаем ни на какие вопросы до решения кейсов.
Мы публиковали все в Confluence, завели чатик в Telegram и проводили небольшие синки по 30 минут для решения актуальных проблем.
Применяем Active Design Review на практике
На ревью мы выносили достаточно специфическую вещь: концептуальную модель данных клиентского домена. При обсуждении таких штук как модель данных, которую будет использовать вся компания, да ещё и в таком сильно связанном со всеми домене как Customer, всегда у каждого есть что сказать Соответственно, сделать её непротиворечивой и собрать по ней замечания очень сложно. Картинка здесь исключительно для примера, она сильно эволюционировала после ADR.
В качестве фокус-группы мы взяли solution-архитекторов, разрабатывающих сервисы, которые связаны с этим доменом, enterprise-архитекторов и всех желающих. Старались быть максимально публичными, мероприятие пиарили.
Задачи, кейсы, которые мы предлагали решить, мы поделили на три группы.
Реалистичные кейсы — задачи, с которыми сталкиваемся сейчас (обслуживание B2C, обслуживание B2B, продажи и т.д.). Задача — понять, как использовать эту модель на реальном кейсе, в реальных существующих сервисах.
Кейсы на расширение — это то, что у нас на горизонте (например, появление нового вида продукта). Задача — понять как модель поведет себя при развитии нашего ландшафта.
Сам кейс — это описание определенной ситуации на обычном человеческом языке, на котором, как правило, и выставляют бизнес-требования. К кейсу даём такие задания: описать эту ситуацию в терминах предложенной модели данных и спроектировать,конкретный сервис/процесс с использованием этой модели. Вот пример самого кейса и задания.
А вот какое решение предложил один из участников. В нем указаны сущности в терминах предлагаемой модели, которые будут затронуты при реализации бизнес-требования, и нарисована диаграмма последовательностей, описывающая, как будет работать конкретный сервис и указаны CRUD-операции над сущностями.
А что в итоге?
В итоге, в первую очередь, мы получили вовлеченность. Если бы эту картинку с КМД я просто заслал тем же людям на e-mail, уверен, что большинство получателей просто проигнорировали бы её. А тут коллеги активно участвовали в обсуждении и действительно погрузились в материал.
Работа над ошибками
Скажу и про ошибки, которые мы допустили, и каких можете избежать вы, если будете пользоваться техникой Active Design Review.
Выделение ресурсов. Решение задачек всё-таки требует больше времени, чем написание комментариев и у многих просто не получалось выделить нужный временной ресурс. Чтобы это реально работало, нужно несколько раз провести ADR, чтобы для себя и для компании понять, сколько времени эксперты тратят на решение таких задачек и согласовать выделение этого времени заранее.
Живое общение. В современных условиях это довольно сложно, но всё-таки здорово. Наша практика была до пандемии, но мы не встретились ни разу очно, хотя лучше все-таки один-два раза это сделать. Причем оригинальная методика как раз это рекомендует.
Обработка результатов. Нужно формализовать способ обработки и документирования принятых решений. Это самая важная зона развития, которую мы и у себя будем прокачивать, потому что я уверен, что мы эту технику будем дальше применять. Тем, кто заинтересовался ADR, рекомендую сразу подумать на эту тему, потому что в нашем случае к модели данных прилетело огромное количество замечаний и нестыковок, которые, по идее, нужно было учесть.
Вроде бы результат ревью понятен, очевидно, что «здесь надо переделать». Но обсуждение вопроса «как надо переделать» затянулось на продолжительное время и вышло за границы Active Design Review. Чтобы такого не было, нужно заранее продумывать подход, как результаты ADR обрабатывать и готовиться, что результатов будет много.
Но самое главное, что приносит эта методика, на мой взгляд — это радость. В процессе ADR коллеги погрузились в тему модели данных, разбирались в сущностях, связях и в том, как мы их видим едино в компании, решали задачи, рисовали кейсы, сиквенсы, разбирали их. Это было действительно продуктивно и весело. А элемент веселья, как мне кажется — только способствует плодотворной работе, особенно такой рутинной, как согласование архитектурного документа.
Gaperton’s blog
Design Review и его роль
D>>кто-нибудь использует такую процедуру как Code review? Как это происходит? вы реально выделяете час времени в неделю, садитесь с командой и начинаете стебаться друг над другом.
B>3 дня назад мне делали. общий обьем — что-то около 3к строк (всего).
B>человек затратил около 2-х недель, что бы вычитать весь мой код.
B>сидели 2 часа в компании с еще одним, в митингруме с проектором — отвечал на вопросы. вроде отбился.
Нормальный средний темп кодревью, при котором реально найти ошибки — примерно 200 строк кода в час. Плюс-минус, потому, что средний.
3к строк будет примерно 15 часов чистого времени. При условии 4-х часов чистого времени в день (полная загрузка) имеем дня 4, вообще-то. То есть, кодревью выполнялось скорее медленно. Если ревьювер при этом еще и не нашел в коде багов (критерий эффективности ревью, ваще на нем ошибки положено ловить) — это отрицательная работа. От такого code review пользы немного.
Медленно и неэффективно оно может быть по разным причинам. Например:
1) Человек, кто проводит код ревью, не проводил ранее дизайн ревью этого же кода. Лечится либо kick-off meeting перед началом ревью (что считается необходимым для экспертизы материала такого объема), где автор объясняет, что тут ваще происходит, и как оно ваще работает. Либо, что гораздо эффективнее во всех смыслах, введением отдельного дизайн-ревью, где автор докладывает, как он собирается решать задачу, до того, как пишет основную массу кода. Для дизайн ревью в простейшем случае сойдет устный доклад у маркерной доски. И те же люди, кто проводил дизайн ревью, потом выполняют код ревью.
2) Человек вообще не специалист в данной теме — маловероятно, что он найдет какие-либо ошибки кроме пунктуации, эстетики, и соблюдения стандарта кодирования. Подобные ошибки, к слову, ловятся в темпе побыстрее чем 200 строк в час.
3) Давайть на ревью такие большие фрагменты кода — фашызм. Надо стараться бить на части. Опять же, проводя до этого дизайн ревью, чтобы люди были в курсе.
Вообще, дизайн ревью необходимы для того, чтобы сделать code review более эффективными на практике. Почему:
1) Они снижают затраты на code review, и совокупные затраты на все review.
2) Ошибка, которая может быть обнаруженная на дизайн ревью, в исправлении почти бесплатна, и является напротив — наиболее дорогой ошибкой, будучи найденной на код ревью.
3) Надо учесть социальный фактор. Бывает так, что на кодревью выясняется, что весь подход к решению задачи неправильный, и делать по хорошему надо не так. Однако, автор уже написал дохрена кода! Во-первых, ревьюверы чувствуют себя виноватыми, и им тяжело сказать человеку, что надо все выбросить, и переделать. Во-вторых, человеку самому грустно и обидно это делать. Поэтому, такой код имеет все шансы пройти кодревью, и таки оказаться в репозитории. Если не проводить design review, подобная ситуация будет возникать регулярно.
4) Design review позволяют привить культуру предварительного проектирования в масштабе компании, и являются, кроме того, единственным способом как-то контроллировать закрытие задачи «проектирование».
И 5-е. Пожалуй, самое существенное. Введение design review имеет радикальный положительный эффект на сроки разработки и их предсказуемость в условиях наличия новых, неопытных сотрудников, в условиях присутствия значительной базы существующего кода. Проверено.
Подобные сотрудники тратят достаточно много времени на то, чтобы разобраться с существующим кодом, и найти правильный способ решения своих задач. Часто выясняется, что их подходы неверны, что приводит к затягиванию сроков из-за того, что они сами постоянно переделывают свою работу, или молча тупят, либо — к потоку дефектов в соседнем коде, индуцированным их действиями. Они повышают хрупкость кода и вносят баги со странными симптомами, которые потом ловятся опытными сотрудниками.
Введя обязательное design review, вы бьете подход к проблеме на два этапа, проскочить которые нельзя. 1 — «я понимаю, что и как я собираюсь сделать», и 2 — «я делаю». Делая это, вы выносите источник неопределенности в первый этап, который строго ограничиваете временными рамками, и сотрудник делает доклад о выбранном подходе к решению проблемы. Он должен описать изменения с точностью до класса. Его доклад слушают 1-2 опытных разработчика, и ищут ошибки. По показаниям — проводя ликбез в виде кратких лекций по архитектуре и принципам устройства системы, если это необходимо (правильное решение задачи проектирования является как бы практическим заданием к лекции — так автоматически само собой получается).
Ну, и еще это отличный способ, помогающий от отмазок ленивых сотрудников, ссылающихся на сложность своей темы и задач.
Данный способ показал себя как наиболее эффективное комплексное решение для адаптации новых сотрудников. Эффект от одного этого процесса в процентном отношении к прочим мерам настолько велик, что ими можно пренебречь, не тратя зря силы. И все равно будет хорошо.