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

Разработка программного обеспечения (ПО) – это комплексный последовательный подход к созданию программных продуктов и приложений. Качество и конкурентоспособность продукта во многом зависят от того, насколько эффективным будет выстроен процесс управления разработкой. Если весь жизненный цикл был пройден успешно, то на выходе потребители получают продукт, соответствующий пользовательским требованиям.

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

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

Жизненный цикл разработки программного обеспечения.

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

Среди всех методов организации процесса разработки одним из самых популярных является Software Development Life Cycle (SDLC). Данная концепция позволяет осуществлять комплексное управление всеми этапами создания программного продукта. Благодаря этому разработчики могут обеспечить достойное качество ПО, а также его надежность и соответствие запросам конечных пользователей.

SDLC выделяет основные этапы жизненного цикла разработки. Ниже рассмотрим каждый из них.

Планирование.

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

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

Анализ требований.

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

В завершении этого этапа команда имеет подробный документ со всеми требованиями к программному продукту, которых необходимо достичь в установленные сроки.

Проектирование и дизайн.

Чтобы буквально представить то, каким будет продукт, необходимо создать его прототип. Для этого разрабатывается его архитектура. На ее основе разработчики будут понимать, какие компоненты будет содержать система, какие алгоритмы должны выполняться разными функциями, каким будет пользовательский интерфейс и т.д.

Это также подразумевает создание дизайн–макета пользовательского интерфейса и составления технической спецификации.

Разработка.

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

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

Тестирование и интеграция.

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

Обнаруженные недостатки, узкие места, баги и прочее, отправляется на доработку команде разработки. Это происходит до тех пор, пока ошибки не перестают быть критичными и не могут серьезно влиять на эффективность программного продукта или приложения.

Поддержка.

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

Каждый из перечисленных этапов очень важен. В целом они повторяются в различных моделях и методологиях разработки с учетом собственных нюансов. То есть где–то они выполняются строго последовательно, а где–то могут происходить параллельно, чтобы сократить жизненный цикл разработки.

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

Сейчас рассмотрим именно модели, которые объединяют под собой различные схожие подходы к разработке по общим признакам.

Последовательная модель.

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

Это самая старая модель разработки программных продуктов, которая возникла ещё в 1970-х годах, и она не перестает быть актуальной для некоторых видов проектов. Рассмотрим её плюсы и минусы.

Преимущества.

• Четкость и предсказуемость действий.

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

• Нет сложностей с пониманием того, что и как делать.

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

• Подходит крупным проектам с высоким уровнем контроля бюджета.

Заказчик четко обозначает стоимость проекта ещё до начала работ, и это не просто так. Это значит, что здесь исключены внесения изменений, которые увеличат бюджет. Есть четкое понимание того, каким должен быть конечный продукт и то, какое количество средств на это понадобится. В гибких методах разработки такое невозможно.

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

• Не требуется постоянное участие заказчика в каждом этапе разработки.

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

Недостатки.

• Отсутствие гибкости в случае возникновения новых условий и требований.

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

• Высокий уровень рисков, которые возникают из–за переработок.

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

• Исполнитель жестко ограничивает бюджет и постоянно его контролирует.

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

• Нельзя применять в проектах, в которых часто меняются требования.

Если бизнес заведомо находится в переменчивых условиях, которые нельзя не учитывать при создании программного продукта или приложения, то водопадная система здесь не подходит. Она не позволит оперативно вносить изменения и не повышать при этом уровень рисков.

• Заказчик мало участвует в разработке, поэтому возникают сложности с согласованием.

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

Более современной моделью разработки программного обеспечения является итеративная модель. Она учитывает недостатки каскадной модели, поэтому в процессе работы над проектом допустима гибкость. Это возможно за счет того, что весь жизненный цикл разбит на короткие итерации.

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

Ниже рассмотрим основные плюсы и минусы итеративного подхода к разработке ПО.

Преимущества.

• Данная модель снижает возникновение рисков за счет того, что большинство ошибок и проблем удается обнаружить на ранних этапах, то есть ещё до того, как они станут критическими. Команда фокусируется только на актуальных задачах и не отвлекается на посторонние, которые сейчас не нуждаются во внимании. Это позволяет углубиться в процесс и не пропустить важных деталей.

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

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

• Возможен выпуск продукта на рынок с его минимальной ценностью (MVP), что делает его более конкурентным в определенных условиях. Поднять его ценность возможно за счет обновлений ПО, что даже выгоднее, потому что эти изменения вносятся с учетом полевых исследований. То есть продукт получается максимально близким к требованиям, которые были обозначены на этапе планирования.

Недостатки.

• Риск того, что архитектура может посыпаться. В начале она формируется на основе первоначальных требований к продукту, но если возникает необходимость внести изменения, то они могут вызвать противоречия в системе. Это может отразиться на производительности и привести к появлению множества багов и узких мест.

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

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

Это следующая модель разработки, которая следует после итерационной. По сути, это совокупность гибких методологий Agile, например, таких как Kanban и SCRUM. Это разные подходы, но они имеют общие признаки. Это и объединяет их в гибкую модель разработки.

В ее основе также находятся итерации, которые ещё больше вовлекают заказчика и его заинтересованных лиц в процесс разработки программного продукта. То есть ему доступны все промежуточные результаты проекта. Разумеется, он имеет возможность на них повлиять.

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

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

Преимущества.

• В рамках итерации решаются только актуальные задачи, которые помогут реализовать модуль качественно. И даже если вдруг по результатам тестирования обнаружены какие–то ошибки, то они будут исправляться уже в следующей итерации. Таким образом, удается контролировать прогресс выполнения проекта и равномерно распределять нагрузку на специалистов. Что в свою очередь снижает риск влияния человеческого фактора, возникшего из–за усталости.

• Продукт постоянно улучшается, из–за чего растет его качество, соответствие требованиям и в конечном итоге конкурентоспособность на рынке. Юзеры получают позитивный пользовательский опыт, который по большей части их удовлетворяет. Все это возможно благодаря получению постоянной обратной связи. Предложить улучшения могут члены команды разработки, заказчик и его заинтересованные лица, а также сами пользователи.

• Несмотря на то, что на начальном этапе формируется определенное техническое задание и требования к продукту, допустимы отступления, если они позволят сделать ПО лучше. Главное обосновать эти подвижки и доказать их эффективность.

Недостатки.

• Важно перед тем, как внедрить очередное улучшение, удостовериться, что от него действительно будет польза. В первую очередь, совершенствовать ключевые функции, которые оказывают огромное влияние на производительность и эффективность продукта. Иначе есть риск не сократить жизненный цикл разработки, а наоборот сильно его увеличить. Не особенно важные улучшения можно оставить для обновлений продукта в будущем.

• При организации работы над особенно сложным и крупным проектом может потребоваться привлечение нескольких команд разработки. Это не только увеличит расходы, но и может привести к трудностям с выстраиванием коммуникаций между подразделениями.

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