Традиционный SDLC против Agile SDLC: 4 наиболее важных различия

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

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

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

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

Семь этапов жизненного цикла разработки программного обеспечения:

  1. Планирование
  2. Анализ требований
  3. Прототипирование
  4. Разработка
  5. Тестирование
  6. Реализация
  7. Обслуживание

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

Прямо сейчас вы можете спросить: «А какой мне подходит?». Чтобы понять это, давайте посмотрим на традиционный SDLC и Agile SDLC и выделим четыре наиболее важных отличия.

1. Фазы против спринтов

Единицей работы для традиционного SDLC является фаза. Фаза - это одна из семи стадий, которые мы разделили ранее, например, планирование или создание прототипа.

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

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

Гибкая интерпретация SDLC использует другую единицу работы: спринты. Спринт - это временной интервал для выполнения основной части работы. Он имеет постоянную продолжительность независимо от работы.

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

Ключевые отличия включают:

  • У этапов нет фиксированной даты начала или окончания. Спринты имеют предсказуемую дату начала и окончания.
  • В спринтах участвует вся команда. Фазам нужны только люди, необходимые для этой фазы.
  • Вы знаете, сколько этапов вам нужно в начале проекта. Вы не можете предсказать, сколько спринтов вам понадобится.
  • Влияние фиксированных календарных событий можно узнать с помощью спринтов. Например, рождественская неделя повлияет на спринт №30. Вы не можете знать, на какой фазе это повлияет, используя водопад.

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

Совет от профессионалов: кодируйте быстрее с TextExpander

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

2. Отслеживание проекта

Отследить проект, управляемый с помощью водопада, относительно просто. Любой данный проект будет находиться в одной из семи фаз в любой момент времени.

Ваша команда может работать над одним проектом на одном этапе, а другая команда - над отдельным проектом на другом.

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

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

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

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

3. Гибкость

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

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

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

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

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

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

4. Результаты, соответствующие ожиданиям

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

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

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

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

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

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

Это не черное или белое

По нашему опыту, вопрос о выборе традиционного SDLC и гибкого подхода - не черный или белый. Есть нюанс: то, что работает для одной команды и проекта, может не сработать для другой.

Четыре общих отличия - не единственные различия. Именно они оказывают наиболее значительное влияние на то, как вы управляете своим проектом. Какой из четырех, по вашему мнению, самый важный для вашей команды? Дайте нам знать об этом в комментариях.

Не торопитесь

Оставьте скучные и повторяющиеся задачи в прошлом: установите TextExpander и сосредоточьтесь на самом важном.