Кратко о методологиях разработки ПО: Waterfall, Lean и Feature Driven Development

В нашем прошлом материале ^[1] мы писали о методологиях разработки программного обеспечения, которые помогают оптимизировать рабочие процессы. Тогда речь шла о Scrum, канбан и экстремальном программировании. Сегодня мы расскажем о Waterfall, FDD и Lean — оценим плюсы и минусы подходов и взглянем на опыт организаций, которые их используют, чтобы помочь вашим компаниям оптимизировать процессы.

^[2]
/ Flickr / Hamza Butt ^[3] / CC ^[4]

Waterfall

Waterfall, или каскадная модель, — традиционная методология, которая существует ^[5] с 1970 года. В ней разработку проекта разбивают на этапы: от анализа системных требований до выпуска продукта.

Каждый шаг — отдельная фаза разработки ПО, и команда должна ^[6] завершить одну фазу, прежде чем переходить к следующей. В «чистой» реализации Waterfall возвращаться на предыдущий этап запрещено — можно «плыть только по течению», чтобы пройти полный цикл разработки. Пользователи Quora сравнивают ^[7] эту модель с поездом, который движется от станции к станции и не может повернуть назад.

Изначально автор Waterfall Винстон Ройс (Winston Royce) привел ^[8] каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведет к ошибкам и выпуску некачественных продуктов. Однако потом в своей статье ^[9] он довел методологию «до ума», отметив обратные связи и переходы от тестирования к написанию кода и др.

По данным исследования PMI ^[10], 12% компаний используют методологию Waterfall на постоянной основе, а 40% респондентов утверждают, что часто к ней обращаются. А по данным ^[11] LiquidPlanner, каскадную модель используют 25% организаций.

Количество этапов в Waterfall варьируется от компании к компании, но общий подход выглядит следующим образом ^[6]:

• Создание концепции. Первая фаза жизненного цикла разработки ПО (SDLC ^[12]) включает в себя анализ затрат и результатов и оценку масштабов проекта.
• Подготовка. Набор команды, определение целей и задач.
• Анализ. Изучение объема работ и требований.
• Дизайн. Создание прототипа и согласование его с заказчиком.
• Разработка/написание кода. Создание ПО на основе утвержденного прототипа.
• Тестирование. Готовый продукт тестируют.
• Реализация. Продукт выходит на рынок.
• Техническое обслуживание. Устранение выявленных недочетов и поддержка.

Среди преимуществ методологии можно выделить ^[6] чёткую структуру и предсказуемый рабочий процесс. Это позволяет легко оценить затраты и прикинуть сроки выполнения до начала проекта. Резиденты Quora утверждают ^[13], что такие тонкости важны для финансовых и страховых компаний или компаний, которые разрабатывают «железо».

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

Однако есть и недостатки. Клиенты часто не знают, чего они действительно хотят, пока не взглянут на прототип. А по Waterfall нужно определять все требования заранее, поэтому есть риск что-то упустить. Исследование процесса разработки сайта компании Ericsson AB показало ^[14], что каскадная модель привела к путанице, и 26% изначальных требований оказались бесполезными.

Однако главный недостаток Waterfall — внесение изменений. Продукт тестируют в конце жизненного цикла, и может быть слишком поздно, чтобы что-то править. Именно стоимость внесения изменений побудила компанию Toyota задуматься о переходе на другую методологию разработки.

По словам ^[15] Сатоси Исии (Satoshi Ishii), главного руководителя проектов компании, исправление дефектов, обнаруженных после производства, обходится ^[16] в 1000–10000 раз дороже. Поэтому в Toyota решили отказаться от Waterfall и перейти к Lean, который мы рассмотрим далее.

Lean

Термин означает ^[17] «бережливая разработка». Его корни уходят ^[18] глубоко в историю компании Toyota и её подходов к решению задач. В компании вносят только те изменения, которые приносят пользу, требуют минимум затрат и отнимают не более 30% запланированного времени. Это помогло японской компании научиться переключать конвейеры на производство другой модели за считаные часы, в то время как другим автопроизводителям требовались недели.

Применили методологию Lean для разработки Мэри (Mary Poppendieck) и Том Поппендик (Tom Poppendieck). Они написали книгу ^[19] «Lean Software Development». Дополнительную информацию также можно найти на их сайте ^[20], посвящённом Lean.

По данным исследования PMI ^[10], 8% компаний постоянно используют принципы Lean, а 26% часто к ним обращаются. Принципы ^[21] Lean:

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

Среди плюсов методологии выделяют быстрый релиз продукта. Джо Фоли (Joe Foley), менеджер подразделения Intel Fab Operations в Лейкслипе, утверждает ^[22], что 5 лет назад компании требовалось 14 недель, чтобы начать производство новых чипов. Благодаря принципам Lean этот процесс теперь занимает 10 дней.

При этом, когда команда следует принципам бережливой разработки, она не просто выполняет задачи, а стремится ^[18] сделать продукт с наименьшим количеством ошибок. В своём исследовании ^[23] компания ВВС обнаружила, Lean повышает скорость разработки ПО на 37% и снижает количество багов на 24%.

Также, согласно исследованию ^[24] Lean Business Report, в числе десяти преимуществ подхода указано снижение стоимости проектов — 27% IT-компаний уменьшили затраты за счет внедрения принципов Lean.

Однако они подходят не всем. Команда GlobalLuxSoft отмечает ^[18], что бережливую разработку стоит применять, только если к проекту подключены опытные разработчики, так как обучение на ходу оказывается невозможным и ставит создание продукта под угрозу.

Все принимаемые решения должны подкрепляться аналитическими данными и результатами мониторинга процессов, иначе команда рискует погрузиться в слишком большое количество изменений и забыть о главной цели проекта. Здесь можно обратиться к опыту Toyota: жесткий контроль со стороны не позволяет ^[25] разработчикам отклоняться от приоритетных задач.

/ Flickr / Sebastian Sikora ^[26] / CC ^[4]

Feature Driven Development

Feature driven development ^[27] (FDD) — методология, которая объединяет лучшие практики и сосредотачивает внимание разработчиков на функциональных элементах (features), полезных с точки зрения клиента. По этой ^[28] ссылке можно найти примерную схему алгоритма разработки по FDD. Согласно исследованиям ^[10], 11% компаний постоянно используют Feature Driven Development, а 31% прибегает к использованию этой методологии время от времени.

Создатель FDD — Джефф де Лука (Jeff De Luca), впервые предложил ^[29] методологию в 1997 году, когда искал оптимальное решение по разработке программного обеспечения для банка в Сингапуре. Тогда он предоставил комбинацию из 5 процессов:

• Разработка общей модели. Команда разработчиков делится на группы создаёт модели для отдельных задач. Затем выбирается одна из предложенных моделей или их сочетание.
• Создание списка функций ^[30]. Когда команда разработала общую модель, она определяет полезные для клиента функции.
• Планирование. Здесь важно учитывать нагрузку на группу, риски и другие аспекты, чтобы предотвратить возникновение критических проблем.
• Дизайн и разработка. На основе данных первого процесса, менеджер проекта выбирает группу функций, которые команда должна реализовать за определённый срок.
• Реализация. После того как команда разработала и протестировала код и модули, она приступает к созданию ПО. На этот и предыдущий этап уходит ^[29] 75% усилий команды разработчиков.

Успех проекта напрямую зависит от опыта и знаний ведущего программиста. В FDD он играет все главные роли: руководителя, наставника, аналитика и так далее. При этом методология создана ^[31] для долгосрочных проектов, поэтому, как отмечают ^[32] резиденты Stack Overflow, применять её для небольших задач просто нет смысла.

Однако есть и плюсы. Постоянное составление отчетов о проделанной работе на всех уровнях помогает ^[33] отслеживать прогресс и результаты. Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять клиенту информацию в любое время. А один из резидентов Stack Overflow утверждает ^[34], что главный плюс FDD — возможность в любой момент оценить отстаёт ли проект от графика или продвигается быстрее.

Как уже было отмечено, FDD используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает ^[35] риск нежелательных «сюрпризов».

P.S. О чем еще мы пишем в нашем корпоративном блоге:

Автор: it-guild

Источник ^[41]