Методология управления проектом для программного обеспечения и проекта обработки звука в реальном времени [закрыто]

Я начинаю проект с друзьями из колледжа, и мы хотим создать команду аудиоинженеров и разработчиков программного обеспечения. У нас есть опыт разработки приложений, реализации фильтров и потоковой передачи аудио (беспроводной и USB), но теперь мы хотим разработать приложения для потоковой передачи и обработки звука в реальном времени на смартфонах с использованием USB-аксессуаров и беспроводных аксессуаров. Нам нужно провести много исследований, тестирования и разработки этих приложений и функций.

Например, мы хотим разработать функцию шумоподавления, когда кто-то работает в офисе. Учитывая, что у нас наушники с микрофонами. Звук захватывается микрофонами и передается на смартфон, в смартфоне звук обрабатывается (в этом случае шум подавляется), а затем отправляется обратно в наушники.

Какие методологии вы рекомендуете мне для управления разработкой функций такого рода?

Методологии проекта обычно выбираются не на основе разрабатываемых вами функций, а на основе характера и хода работы, опыта работы с различными методологиями в организации, аппетита персонала, включая руководство, для поддержки различных методов и множество другие мягкие факторы. Управление проектами — это «просто» практика облегчения процесса реализации способами, которые имеют смысл для организации. Что вы хотите, чтобы ваша методология реализации дала вам и организации?

Ответы (1)

Вы должны взглянуть на Канбан. Это удивительно просто.

У вас будет «незавершенная работа», записанная в виде простых напоминаний о том, чтобы что-то сделать (мы называем это историей), которую вы как группа расставляете по приоритетам, добавляя новые истории в незавершенную работу, когда захотите. Затем вы можете отслеживать ход выполнения, перемещая элементы по таблице из трех столбцов — готовые к выполнению, выполняемые и завершенные. Вы перемещаете элементы из невыполненной работы в первый столбец, когда все согласны с тем, что работа должна быть выполнена, вы перемещаете их в следующий столбец, когда над ним кто-то работает, и в последний столбец, когда работа завершена. Постарайтесь ограничить незавершенную работу двумя элементами на человека, а затем поиграйте с этим числом по мере продвижения и привыкните к процессу.

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

Как правило, рекомендуется ограничить WIP одним элементом на разработчика, пока у вас не будет достаточно данных/опыта, чтобы изменить его. Помогает людям сосредоточиться на выполнении своей текущей работы.
Обычно вы начинаете с того, что люди берутся за работу всякий раз, когда у них есть свободное время от текущей задачи. Учитывая, что некоторое время на каждую историю часто тратится заблокированным, типичный разработчик часто будет иметь 3 или 4 истории одновременно. То есть, как правило, WIP-лимита на первых порах нет. Ограничения WIP обычно вводятся только после того, как команда начала ощущать негативное влияние их отсутствия, что обычно происходит где-то в течение 3-6 месяцев. Минимум, который я видел, чтобы команды использовали, — это 2 незавершенных истории — 1 приведет к непродуктивному простою, если у вас нет другого способа справиться с блокировками.
Я буду честен. Звучит ужасно. Я просто не могу себе представить, чтобы в «Активе» было больше 1 истории одновременно. Слишком много переключения контекста. Я думаю, может быть, вы подумали, что я имел в виду 1 общий WIP? Я имел в виду 1 на столбец на доске. (Что, очевидно, слишком много в долгосрочной перспективе, но хорошее место для начала.)