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

[yarigpopov]

Очень поверхностно. Доводы взяты с потолка.

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

первое и последнее упоминание слова Канбан в статье.

[lantech07]

Так статья ведь и не про Канбан. Не делать же из-за этого технические повторения слова Канбан.

[HappyGroundhog]

Когда же уже перестанут считать PMBoK "последовательным"… Во-первых, в Agile приложении 6 есть минимум 4 разных гибридных цикла из итеративного, инкрементального и предиктивного ("стандартного") цикла разработки с подробными советами как и где какой лучше применять. Есть даже гибридные варианты предиктивного общего цикла с вкраплениями внутри итеративных подходов.

Вообще очень рекомендую посмотреть хоть раз вот это видео https://youtu.be/GC7pN8Mjot8 и перестать считать предиктивный цикл PMBoK водопадом, а лучше всего, потом еще и прочитать Agile часть 6. В 7 издании действительно обещают отойти от групп процессов и красиво вписать Agile в общую канву, а не приложением, как сейчас. А вот мешать Канбан со Скрамом без понимания зачем и почему взят каждый артефакт я крайне не рекомендую… Цель Канбана это сервисный подход и он идеален, например, в хелпдеске, когда у вас нет конкретного цикла поступления задач. Длина спринта в 4 недели в скраме взята исключительно для гибкости, чтобы иметь возможность быстро реагировать на изменения рынка. Если у вас цикл изготовления платы занимает 5 недель, то вы осознанно не можете быстрее вносить изменения. Я слабо представляю себе скрам в разработке электроники. "Ой, конкуренты выпустили плату с разъемом питания на рынок, нам срочно нужна такая!", "Ой, продукт овнер выяснил, что теперь рынку требуется еще и PCI-E слот, нам тоже нужно". Я участвовал в крупных проектах с разработкой плат и там обычно было просто 3-4 итерации, когда собираются по максимуму требования, делается пилот, потом обкатывается и вносятся правки в плату. Итеративный скрам подход я тут слабо представляю...

[lantech07]

Чистый скрам действительно мало подойдет. Но тут скорее про совместную работу с программистами, саппортами и продажниками. Вот здесь итеративный подход может быть удобен. В стиле «мы тут добавили новую функцию, протестируйте». Новой функцией может быть например автобифуркация разных версий райзеров или что-то подобное. В сложном продукте как материнская плата или тем более сервер не всегда сразу понятно какой функционал будет нужен, а такими шагами мы улучшаем обратную связь и понимание что нужно а что добавлено просто так по инерции.
За видео спасибо, посмотрю.