Определение жизненного цикла разработки

Question

Как определить процесс разработки программного обеспечения для разработки программного обеспечения, какие ключевые факторы следует учитывать при принятии решения о том, какой процесс разработки следовать (например, Agile, WaterFall, Spiral ...).

Answer 1

На это решение влияет множество факторов, в том числе «технические»:

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

и социальные:

• пользователи, желающие сотрудничать с командой в гибком стиле
• что такое культура, "нормальный способ ведения дел" в организации
• насколько менеджмент (и разработчики) открыты для новых идей, могут ли они быть убеждены в новых подходах (с вескими аргументами и доказательствами)
• это команда, находящаяся в коллективе или физически отделенная

Обратите внимание, что последние являются, по крайней мере, таким же, если не большим, важными факторами, как первые!

Технические факторы

Характер и размер вашего проекта сильно ограничивают частоту публикации новых выпусков, что, в свою очередь, влияет на вашу гибкость. Например. некоторые проекты с открытым исходным кодом могут выпускаться так часто, как вы пожелаете, в то время как согласно Джоэлю , программное обеспечение для термоусадочной пленки не следует обновлять чаще, чем каждые 1,5 года.

По мере роста команды, общение становится более формальным, и команда становится менее гибкой. Кроме того, чем важнее проект, тем более строгим и формальным становится процесс.

Социальные факторы

Если ваши пользователи не хотят или не могут напрямую сотрудничать с вашей командой, ловкость ограничена. Если управление застряло с традиционным мышлением и методами, ловкость снова ограничена. То же самое для физически разделенной команды.

---

Суть в том, что вам не нужно выбирать процесс раз и навсегда. Кроме того, имена и модные аббревиатуры не так важны, как то, что ваша команда действительно делает изо дня в день. Вы можете делать Waterfall или RUP в гибком стиле, а также эффективно превращать XP или SCRUM в жесткий, формальный процесс. В хорошем проекте процесс постоянно пересматривается, дорабатывается и совершенствуется в зависимости от ситуации и потребностей команды. Начните с чего-то, что кажется достаточно хорошим (и настолько простым, насколько это возможно), затем регулярно проводите ретроспективные встречи, чтобы собрать отзывы о том, что идет хорошо, что пошло не так, и что можно улучшить.

Answer 2

Есть несколько методов на выбор, но нет одного определенного метода (хотя это было бы неплохо). В нашей среде мы используем Agile. Это имеет смысл для нас из-за ряда факторов:

• Типичные временные ограничения (хотя каждый проект не одинаков, способ определения временных ограничений довольно постоянен)
• Ресурсы развития
• Какой тип взаимодействия с клиентом вы можете иметь (отзывчивый или нет)
• Руководящие принципы организации (например, ожидают ли они определенного артефакта документа до начала проекта и имеют ли они требования к тому, что находится в этом артефакте)
• Бюджет (опять же не всегда один и тот же, но последовательный в методе определения бюджета)

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

Самая большая вещь, которую я бы порекомендовал: не зацикливайтесь на процессе, просто постройте некоторые замечательные вещи и позвольте процессу начать улучшаться. Хотя мы используем гибкие методы, для нас это своего рода смесь.

Надеюсь, это поможет, я уверен, что будут ответы получше, чем мои: -)

Answer 3

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

Все эти факторы имеют тенденцию тяготеть друг к другу в грубых противоположных полюсах.

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