Agile или PMBok для разработки электроники, что лучше и есть ли единое решение?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

В 7й версии PMBok наметился уход от последовательных процессов к гибким и некоторое заимствование принципов Agile

Рис. 1. Изменения в 7й версии PMBoK (источник – pmi.org)
Рис. 1. Изменения в 7й версии PMBoK (источник – pmi.org)
Рис. 2. Agile манифест (источник - agilemanifesto.org)
Рис. 2. Agile манифест (источник - agilemanifesto.org)

Как видим, очень похоже на то, как если бы в 6ю версию PMBoK guide добавили принципы Agile. Тем не менее,  PMBoK все еще остается последовательным фреймворком, в отличие от цикличного Scrum.

Изначально кажется, что проще всего использовать PMBoK. Возможно, так оно и есть. Но какие недостатки такого подхода для разработки электроники?

Основной заключается в том, что мы должны выполнить достаточно большую подготовительную работу по написанию требований, технического задания, описать все необходимые функции (эпики) и т.п. Чаще всего, каждая дополнительная функция в разработке hardware – это в первую очередь дополнительная цена в изделии, дополнительная цена и время разработки. Наоборот, не включив нужный функционал в наше итоговое изделие мы рискуем потерять потенциального Заказчика. Поэтому в большинстве спорных ситуаций конечно мы получаем достаточно раздутый функционал и увеличение сроков разработки. Кроме того, необходимость дополнительного функционала очень часто всплывает и в процессе самой разработки. Пример: разветвление слотов PCI Express требует также и разветвления USB, поскольку они содержатся в PCIe стандарте. А это также увеличивает сроки разработки и итоговую стоимость продукта.

К чему в итоге это приводит? И приводит к тому, что мы рискуем получить идеальный (с точки зрения первоначального ТЗ), но в эти сроки уже мало кому нужный продукт.

В этом плане Scrum кажется такой волшебной таблеткой, которая исключить лишние итерации из процесса разработки продукта (product backlog). Но и здесь, особенно в России, мы наталкиваемся на определённые препятствия:

  • Не всегда заранее прогнозируемая длина спринта. Хорошо известна только для уже выполненных проектов.

  • Цикл разработки простой многослойной платы составляет более 4 недель. Давайте посчитаем. Предположим, разработка всех схем заняла одну неделю. Самый длительный процесс – изготовление печатных плат. Например изготовление High Tech печатных плат в Резонит занимает обычно 20-25 дней. Плюс 1 неделя на проверку продукта. Итого 5 недель, из которых только первая это непосредственно разработка. Поэтому мы получаем результат только через эти 5 недель. Конечно, 5 недель тоже допустимо, но все равно это намного больше рекомендованных 1-4 недель.

Поэтому наш ответ – Канбан, с цикличными включениями от Scrum.

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

Следующий шаг (спринт и т.п.) – разбить продукт на функциональные блоки. Как определить глубину такого деления? Будем придерживаться длительности одного цикла разработки в 1-2 недели. Каждый из этих блоков должен инкрементировать свой собственный функционал, либо набор функций (например GPIO expander). Для полного повторения функционала продукта при сборке пусть платы соединяются соответствующими кабелями. На этом этапе мы получаем функциональный прототип, который уже можно отдавать в работу например программистам.

Следующий шаг – сборка mvp (minimum viable product), или минимально функциональный коммерческий продукт. После этой стадии уже можно переходить к шагу оптимизации и DFM. При наличии такого запроса, одновременно с сертификацией, запуском mvp в производство и в дальнейшем поддержкой добавляем функциональные блоки и создаем новые ревизии или SKU продукта.

Источник: https://habr.com/ru/post/555708/


Интересные статьи

Интересные статьи

Вячеслав Ермолин, 5 августа 2020 г. 2020-й пугает не только пандемией. Сокращение, задержки и переносы пусковых программа орбитальных ракет затронуло все страны мира. А количество ...
Уолтер Брайт — «великодушный пожизненный диктатор» языка программирования D и основатель Digital Mars. За его плечами не один десяток лет опыта в разработке компиляторов и интерпретат...
Гибридная методология управления на основе ценностей В этой статье мы расскажем вам об Agilean («Эджайлин») как методе создания гибридных инструментов на базе Lean и Agile и шире об Agilean ка...
1С Битрикс: Управление сайтом (БУС) - CMS №1 в России по версии портала “Рейтинг Рунета” за 2018 год. На рынке c 2003 года. За это время БУС не стоял на месте, обрастал новой функциональностью...
Пост лучше всего подойдет разработчикам «one-man-company» или командам. Я расскажу, как достаточно легко и просто (при отсутствии или минимальном бюджете) попасть в топ поисковой выдачи в развиты...