Найти в Дзене
ИнКата

Definition of Done в Разработке Аппаратного Продукта

Прежде чем углубиться в Definition of Done, давайте вспомним некоторые ключевые термины, связанные с этой темой. Термин DoD возник в рамках методологии Agile, используемой для управления проектами. В Agile проекты делятся на короткие циклы (спринты), в течение которых команда выполняет определенное количество задач. Для каждого спринта важно знать, когда задача или часть работы действительно завершена. Здесь на помощь приходит DoD. В разработке аппаратных продуктов DoD так же важно, как и в разработке программного обеспечения, по нескольким причинам: Definition of Ready и Definition of Done – это важные концепции в разработке, особенно в контексте аппаратных продуктов. Они звучат похоже, но имеют разные значения. DoR определяет условия, которые должны быть выполнены для начала выполнения задачи. Оно помогает команде убедиться, что задача готова к выполнению. В то время как DoD определяет, когда задача считается полностью завершенной, обеспечивая соответствие работы всем стандартам и тр
Оглавление

Прежде чем углубиться в Definition of Done, давайте вспомним некоторые ключевые термины, связанные с этой темой.

  • Scrum: Одна из методологий Agile, использующая короткие циклы разработки, называемые спринтами, и сосредоточенная на постоянном улучшении.
  • Бэклог: Список всех задач, идей и требований, которые необходимо выполнить в проекте. Например, в проекте умных часов бэклог может включать такие задачи, как "дизайн корпуса", "выбор дисплея", "создание прототипа" и "тестирование на водонепроницаемость".
  • Definition of Ready (DoR): Набор критериев, определяющих, когда задача готова к началу выполнения. Для задачи "дизайн корпуса" DoR может включать утвержденный базовый дизайн, наличие всех необходимых инструментов и материалов, а также согласование с инженерной командой.
  • Спринт: Короткий, фиксированный период (обычно 2-4 недели), в течение которого команда работает над определенным набором задач. В течение спринта команда может работать над такими задачами, как "дизайн корпуса" и "выбор дисплея".
  • User Story (Пользовательская история): Краткое, простое описание функции или требования с точки зрения конечного пользователя. Пользовательские истории представляют собой отдельные части функциональности, которые команда может завершить в течение одного спринта. В проекте умных часов пользовательская история может звучать так: "Как пользователь, я хочу, чтобы умные часы измеряли мой пульс, чтобы я мог следить за своим здоровьем."
  • Эпик: Крупная, высокоуровневая задача или инициатива, которая часто разбивается на несколько пользовательских историй и задач. Эпики охватывают значительные части функциональности продукта и могут требовать нескольких спринтов для завершения. В проекте умных часов эпик может быть "Разработка системы мониторинга здоровья", который включает множество меньших задач и пользовательских историй, таких как "Создание датчика сердечного ритма", "Интеграция шагомера" и "Разработка приложения для анализа данных".
  • Инкремент: Завершенная часть работы, которая может быть интегрирована в продукт и представлена заинтересованным сторонам. После завершения и проверки задачи "дизайн корпуса" корпус интегрируется в прототип умных часов для дальнейших испытаний.

Суть Definition of Done (DoD)

Термин DoD возник в рамках методологии Agile, используемой для управления проектами. В Agile проекты делятся на короткие циклы (спринты), в течение которых команда выполняет определенное количество задач. Для каждого спринта важно знать, когда задача или часть работы действительно завершена. Здесь на помощь приходит DoD.

В разработке аппаратных продуктов DoD так же важно, как и в разработке программного обеспечения, по нескольким причинам:

  • Стоимость изменений: Производственные решения часто необратимы и дороги. Например, если печатная плата или корпус устройства изготовлены с ошибкой, их исправление требует переделки и дополнительных затрат на новые материалы и производство.
  • Сложность исправлений: В разработке медицинских устройств, таких как кардиостимулятор, тестирование включает длительные и сложные испытания на безопасность и надежность. Важным аспектом является проведение различных тестов на электрическую безопасность, включая тесты на электростатический разряд и электромагнитную совместимость, которые проверяют устойчивость устройства к внешним электромагнитным полям и его способность не мешать работе других устройств. Исправление ошибки может потребовать повторного изготовления устройства. В разработке веб-приложений ошибки можно быстро обнаружить и исправить с помощью автоматизированных тестов и систем CI/CD (Continuous Integration/Continuous Deployment).
  • Последовательные и взаимозависимые этапы: В разработке аппаратного обеспечения ошибки на этапе проектирования могут повлиять на все последующие этапы, требуя переделки не только чертежей, но и уже произведенных компонентов. В разработке видеоигр различные команды могут параллельно работать над графикой, игровым процессом и сетевыми функциями. Хотя ошибки в одном модуле могут затронуть другие части проекта, такие зависимости обычно менее значительны, и исправления можно внести без полной переработки всех компонентов.
  • Требования к производству и логистике: В разработке сложных систем, таких как медицинские устройства или авиационное оборудование, требуется координация цепочек поставок, процессов сборки, логистики и дистрибуции. Каждый этап производства требует строгого соблюдения стандартов качества и безопасности, что увеличивает сложность и время, необходимое для устранения ошибок. Между тем, в разработке программного обеспечения, такого как облачные сервисы, обновления и новые версии могут быть автоматизированы, что позволяет быстро вносить изменения и исправления без необходимости в физической логистике.
  • Риски для безопасности: В разработке системы управления автомобилем (например, ABS) ошибки могут привести к авариям и угрожать жизни водителей и пассажиров. Поэтому DoD включает строгие тесты и проверки на безопасность. В разработке банковского программного обеспечения ошибки могут иметь серьезные последствия, такие как утечки данных или финансовые потери, но жизни людей не подвергаются опасности.

DoD vs. DoR

-2

Definition of Ready и Definition of Done – это важные концепции в разработке, особенно в контексте аппаратных продуктов. Они звучат похоже, но имеют разные значения.

DoR определяет условия, которые должны быть выполнены для начала выполнения задачи. Оно помогает команде убедиться, что задача готова к выполнению. В то время как DoD определяет, когда задача считается полностью завершенной, обеспечивая соответствие работы всем стандартам и требованиям.

DoR применяется перед началом работы над задачей и действует как фильтр, проверяя готовность задачи. DoD применяется после завершения работы над задачей и оценивает полноту выполнения работы. DoR сосредотачивается на подготовке, включая требования, ресурсы, доступность и ясность задачи, тогда как DoD сосредотачивается на завершении, включая тестирование, качество, документацию и интеграцию.

Например, в проекте по разработке печатной платы для устройства IoT, задача "Разработать управляющую плату для датчика температуры" готова к началу (DoR), если:

  • есть четкое описание задачи,
  • определены требования,
  • все компоненты доступны,
  • утверждены критерии приемки,
  • задача оценена в 30 часов.

Она считается завершенной (DoD), когда:

  • плата спроектирована и изготовлена,
  • проведены все тесты (функциональные, термические),
  • плата проверена на соответствие стандартам,
  • документация обновлена,
  • плата интегрирована в прототип устройства.

Различие между DoD и Критериями Приемки (AC)

-3

В разработке аппаратных продуктов также важно понимать разницу между DoD и Критериями Приемки. Оба помогают управлять качеством и ожиданиями, но они имеют разные цели и применяются на разных уровнях детализации.

DoD – это набор общих критериев, которые должны быть выполнены, чтобы задача (например, пользовательская история или элемент бэклога) считалась завершенной. DoD обычно применяется ко всему продукту или проекту и включает стандарты качества, тестирование и интеграцию.

Ключевые характеристики DoD:

  • Общие для всех задач: Применяются ко всем задачам в проекте.
  • Обеспечение качества: Включает тестирование, обзор кода, документацию и интеграцию.
  • Финальная стадия: Определяет, когда задача считается полностью завершенной.

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

Ключевые характеристики Критериев Приемки:

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

Пример задачи: Разработка печатной платы для устройства IoT

Определение Завершенности (DoD) для всех плат в устройстве:

  • Плата спроектирована и изготовлена.
  • Плата прошла электрические тесты.
  • Плата прошла функциональные и прочностные тесты.
  • Документация (чертежи, схемы, спецификации) обновлена.
  • Плата интегрирована в прототип устройства и протестирована в реальных условиях.
  • Проверено соответствие стандартам IPC.

Критерии Приемки для платы, отвечающей за передачу данных:

  • Плата должна работать в температурном диапазоне от -20 до +50°C.
  • Плата должна обеспечивать бесперебойную связь по Wi-Fi на расстоянии до 30 метров.
  • Все компоненты должны быть размещены и припаяны в соответствии с проектной документацией.

Примечание к последнему пункту

В примере мы включили последний пункт в Критерии Приемки, хотя во время разработки и прототипирования он может быть как частью DoD (для всех печатных плат в проекте), так и Критериями Приемки. В этом примере плата передачи данных будет принята только если "Все компоненты размещены и припаяны в соответствии с проектной документацией". Возможно, для других плат в устройстве допускаются некоторые модификации или перемычки, используемые разработчиками во время прототипирования.

В заключение,

DoD – это критически важный аспект методологии Agile, который обеспечивает качество и полноту выполнения задач в рамках проекта. В разработке аппаратного обеспечения, как и в программном обеспечении, хорошо определенное DoD помогает минимизировать затраты на исправление ошибок и увеличивает вероятность успешного завершения проекта.

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

Особенно важно правильно определить DoD в разработке аппаратного обеспечения, где ошибки могут быть дорогими и сложными для исправления. Это связано с необратимостью производственных решений, сложностью тестирования, строгими требованиями к производству и логистике, а также высокой степенью ответственности за безопасность конечных пользователей.

Таким образом, DoD не только помогает улучшить процесс разработки, но и обеспечивает высокое качество и безопасность конечного продукта, будь то умные часы, медицинское устройство или система управления автомобилем.