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

В 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 продукта.