Наша команда состоит как из инженеров по программному обеспечению, так и из инженеров по аппаратному обеспечению. Команда программного обеспечения использует управление проектами Scrum, а команда аппаратного обеспечения использует водопад.
Приоритет наших требований к программному обеспечению меняется довольно часто, поэтому для нас имеет смысл оставаться в Agile. Приоритет наших требований к оборудованию довольно статичен и медлителен, поэтому для нас снова имеет смысл придерживаться водопада.
Сложность заключается в интеграции аппаратного и программного обеспечения. Существуют ли какие-либо методологии для детерминированной синхронизации этих двух противоположных стилей управления проектами?
Некоторое время я работал в DO-178B, и раньше мы назначали вехи, когда группы разработчиков программного и аппаратного обеспечения интегрировались и получали предварительную обратную связь (выявляли отклонения от требований, новые требования и т. д.). Однако мы ищем методологии, которые включают более тесные петли обратной связи.
TL;DR Вы должны использовать Scrum в обеих командах.
придерживаться водопада имеет смысл для нас
Нет никакой пользы в том, чтобы команда аппаратного обеспечения занималась водопадом. На самом деле, это относится к любой команде. Выбор между ним и agile-методами — это не просто приоритет требований. Зачем вам придерживаться процесса с длительными сроками выполнения, большими накладными расходами и коротким временем выхода на рынок, если вы можете избежать этого?
то, что мы делали раньше, это назначали вехи, когда команды программного и аппаратного обеспечения интегрировались
В Scrum команда регулярно производит работающие, потенциально готовые к поставке инкременты продукта. Когда у вас есть две команды, работающие в Sprint параллельно, их общее определение готовности также должно охватывать интеграцию.
Конец каждого спринта — это веха, о которой вы говорите. Если комбинированный вывод удовлетворяет определению готовности, выполняется синхронизация.
Однако мы ищем методологии, которые включают более тесные петли обратной связи.
Еще больше причин полностью отказаться от водопада :) Разве вы не хотели бы, чтобы ваша команда по аппаратному обеспечению создавала что-то ценное через месяц, а не через год?
Также имеет смысл использовать одну и ту же методику во всех своих проектах — это, как минимум, упростит обучение. Вы можете использовать любой другой гибкий подход с аппаратной командой, но это разнообразие не принесет вам никакой пользы.
Перевод вашей аппаратной команды на Scrum, безусловно, поможет. Однако, как сказал Стив МакКоннелл:
...если вы на 100 процентов согласитесь с какой-то одной методологией, вы увидите весь мир с точки зрения этой методологии. В некоторых случаях вы упустите возможность использовать другие методы, более подходящие для решения вашей текущей проблемы.
Итак, давайте предположим, что водопад отлично работает для вашего аппаратного проекта, и вам просто нужно синхронизировать их.
Я бы рекомендовал использовать план выпуска в качестве точки зависимости. Подобно тому, как Apple объявляет о выходе нового выпуска iPhone, ваша команда по аппаратному обеспечению должна объявить о новом выпуске оборудования. В вашем случае вам повезло, что вы заранее знаете список функций.
Команда разработчиков, в свою очередь, должна соответствующим образом планировать выпуски. Необходимо пройти 1-2 резервных спринта, если выпуск аппаратной команды задерживается.
Томас Оуэнс
рвонг