Что такое хороший план разработки программного обеспечения? [закрытый]

Артефакт: План разработки программного обеспечения

План разработки программного обеспечения - это всеобъемлющий, составной артефакт, который собирает всю информацию, необходимую для управлять проектом. Он включает в себя количество артефактов, созданных во время начальный этап и поддерживается на протяжении всего проекта.

План разработки программного обеспечения содержит

1. План решения проблем
2. План приемки продукта
3. План измерения
4. План управления рисками
5. План обеспечения качества

Рекомендации: План разработки программного обеспечения

«План [разработки программного обеспечения] - это достаточно подробное описание всех действий, которые вам необходимо предпринять».

Который, как правило, не может существовать.

Если у вас действительно есть все требования полностью поняты, и у вас есть все вопросы технологии полностью , вы можете написать такой документ.

Если, однако, вы что-то делаете новый - то, что пользователи еще не установили, - или вы используете какую-либо новую технологию, вы не можете предоставить даже «разумно» подробное описание действий, которые вам необходимо предпринять.

Вы можете предоставить обзор, в котором кратко изложено то, что вам нужно сделать. Но по мере того, как вы исследуете требования, пользователи будут открывать для себя что-то, узнавать и изменять свое мнение. Пересмотр плана. По мере того, как вы исследуете технологию, разработчики будут открывать, изучать и пересматривать план.

Это не может быть так сложно - люди делают это все время.

Аудитория плана - руководство. Менеджеры хотят «разумно» подробное описание всех действий. По мере того как пользователи и разработчики узнают о требованиях и технологии, детали меняются. Это делает "разумный" тест очень и очень трудным для удовлетворения. Когда детали меняются постоянно, какой уровень детализации считается «разумным»?

Изменения в план могут (и происходят) ежедневно. Большинство менеджеров не хотят вносить ежедневные изменения в план. Таким образом, слишком много деталей становится «неразумным». Чтобы создать план, который не меняется очень часто, он действительно должен представлять собой сводку действий. Единственная работоспособная версия «Плана разработки программного обеспечения» - это ряд целей, определенных - не в терминах действий - в терминах функциональности, которая будет предоставлена ​​пользователям.

Короче говоря, люди делают это плохо все время. За 30 с лишним лет разработки программного обеспечения (в основном в качестве военного субподрядчика) есть фантазии о планировании, которые просто не подтверждаются фактами. Проекты отменяются с "достаточно подробными" планами, чрезмерно подробными планами и вообще без плана.

Действительно, план часто является основной причиной отмены. Почему? С «достаточно подробным» списком действий любое обучение означает, что план неверен. Поскольку план расходится с фактическим исполнением, что-то должно быть не так. Бросить монету. Если вы считаете, что исполнение неправильное, отмените проект за несоблюдение плана. Если вы считаете, что план неверен, исправьте план, чтобы он соответствовал реальному миру. Чем более детализирован план, тем больше он кажется «правильным» и с большей вероятностью его исполнение будет сочтено ошибочным.

Итог .

План разработки программного обеспечения может быть фантастическим документом, написанным как часть методологии разработки «водопада», в которой все виды вещей заранее определены и изменяются (от обучения до команда прогрессирует) наказывается.

ИЛИ

План разработки программного обеспечения - это диаграмма срабатывания Agile , которая просто показывает, какие спринты необходимо завершить. «Разумный» уровень детализации на самом деле довольно низкий - это просто резюме. И это меняется во время каждой ретроспективы спринта.

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

ИЛИ

План разработки программного обеспечения - это Agile-диаграмма выгорания , которая просто показывает, какие спринты нужно завершить. «Разумный» уровень детализации на самом деле довольно низкий - это просто резюме. И это меняется во время каждой ретроспективы спринта.

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

ИЛИ

План разработки программного обеспечения - это Agile-диаграмма выгорания , которая просто показывает, какие спринты нужно завершить. «Разумный» уровень детализации на самом деле довольно низкий - это просто резюме. И это меняется во время каждой ретроспективы спринта.

План разработки программного обеспечения - это особый тип плана проекта. Хотя WBS важен, это только малая часть.

Комплексный план проекта должен включать:

1. План объема работ (содержит WBS)
2. План графика
3. План затрат
4. План качества
5. ] Кадровый план
6. Коммуникационный план
7. План рисков
8. План закупок.

Более подробную информацию о каждом из этих планов можно найти в

Своде знаний по управлению проектом.

Более подробные инструкции см. Код завершен 2 .

что я считаю, что в разработке программного обеспечения проект должен быть разделен на две части

1. Управление программным обеспечением
2. Разработка программного обеспечения

В управлении проектами все дополнительные возможные вещи, такие как цель компании, проект планирование, мониторинг проекта, оценка, резервирование расписания, отслеживание дефектов и т. д.

В разработке проекта жизненный цикл проекта будет поддерживаться как полный водопад