водопадная модель жизненного цикла проекта так же называется
Методологии разработки: Waterfall
Общая концепция подхода была представлена доктором Уинстоном Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывает компетентными сотрудниками, документируется и передаётся дальше.
Хотя популярность модели Водопада за последние годы ослабела, природа последовательного процесса, используемого в методе водопада, интуитивно ближе разработчикам, и потому доминирует в IT.
Как падает вода
Модель, предложенная Ройсом, предельно проста и понятна. Она состоит из 7 блоков, каждый из которых охватывает свою область ответственности.
Не везде и не на каждом предприятии данная модель актуальна. Задолго до того, как ПО начало разрабатываться в каждом офисном здании, разработкой программного обеспечения занимались крупные предприятия, где в первую очередь были важны сроки и точность соблюдения ТЗ, а уже во вторую – правильность и полнота принятых решений на каждом из этапов.
Именно поэтому часто ошибочно за каскадную модель принимается процесс разработки, в котором взаимодействие между этапами в обратном порядке исключено без директивных причин. Да и сами этапы часто дробятся в угоду многочисленным контролирующим органам, или объединяются из-за смежных профессий разработчиков.
Мы также сократим указанную модель до 6 блоков, объединив операции «Инсталляция» и «Поддержка» в одну – «Развертывание». Теперь взглянем на исполняемые функции:
Требования. Проще говоря, на этом этапе создаётся вся входная документация, согласно которой будет вестись разработка. В первую очередь, анализируются требования и пожелания заказчика, затем это проецируется на возможности компании и состояние рынка. В результате получается некий документ, где описывается, что должно делать ПО, но не как и с помощью каких инструментов.
Проектирование. На этом этапе согласовывается логика работы ПО. Здесь всё ещё не принимаются конкретные решения по реализации, но уже описывается функционирование всех разделов приложения. На выходе разработчики уже представляют, сколько по времени и кадровому составу может занять проект.
Конструирование. Здесь уже речь идёт о конкретных инструментах для реализации идей: согласовываются требования к дизайну, языки программирования, уровни данных, сервисы и т. д. Описанный в предыдущем разделе скелет логики обрастает «мясом», впервые формируется внешний облик готового продукта.
Воплощение. Исполнительский этап, на который, как правило, приходится большая часть разработки. Если классическая модель допускает свободное взаимодействие с предыдущими этапами, то на практике допускается лишь внесение незначительных правок в «Конструирование».
Тестирование. На этом этапе QA, бета- и все другие тестеры обнаруживают и сообщают о проблемах в приложении. Данный этап чаще всего вызывает необходимый повтор предыдущей фазы кодирования, чтобы устранить критические неполадки. Если результатом тестирования становятся частые доработки кода, это вызывает возврат к этапу конструирования.
Развертывание. Когда приложение создано, его можно предъявлять заказчику и выпускать на волю. Так как данный этап включает ещё и поддержку, поэтому взаимодействие с предыдущими фазами неизбежно.
Преимущества каскадной модели
В последние годы модель водопада уступает свои лидирующие позиции более гибким методологиям. Это связано с общей динамикой в IT, когда за разработку ПО отвечают команды из 5-9 человек, а дедлайн может быть легко сдвинут из-за наращивания функциональности.
Тем не менее, каскадная модель всё ещё актуальна для крупных проектов и организаций. И вот почему:
Недостатки каскадной модели
В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:
Получается, что каскадная методология – прекрасное решение точки зрения сроков и отчётности, но очень слабое в плане качества. Поэтому сегодня её рекомендуется использовать только в трёх случаях:
Несмотря на то, что эти 3 пункта всё реже встречаются в реальной практике, каскадная модель ещё долго будет популярна и востребована из-за чёткой организации. А значит любой профессиональный разработчик должен понимать её основные принципы и быть готовым существовать в рамках этой схемы.
Мы продолжаем знакомиться с различными методологиями разработки ПО. Сегодня речь пойдёт о самой популярной из них – Waterfall, или каскадной методологии.
Общая концепция подхода была представлена доктором Уинстоном Ройсом ещё в 1970 году. В его основе лежит логическая последовательность шагов, которые должна быть предприняты на протяжении жизненного цикла разработки ПО. Каждый этап согласовывает компетентными сотрудниками, документируется и передаётся дальше.
Хотя популярность модели Водопада за последние годы ослабела, природа последовательного процесса, используемого в методе водопада, интуитивно ближе разработчикам, и потому доминирует в IT.
Как падает вода
Модель, предложенная Ройсом, предельно проста и понятна. Она состоит из 7 блоков, каждый из которых охватывает свою область ответственности.
Не везде и не на каждом предприятии данная модель актуальна. Задолго до того, как ПО начало разрабатываться в каждом офисном здании, разработкой программного обеспечения занимались крупные предприятия, где в первую очередь были важны сроки и точность соблюдения ТЗ, а уже во вторую – правильность и полнота принятых решений на каждом из этапов.
Именно поэтому часто ошибочно за каскадную модель принимается процесс разработки, в котором взаимодействие между этапами в обратном порядке исключено без директивных причин. Да и сами этапы часто дробятся в угоду многочисленным контролирующим органам, или объединяются из-за смежных профессий разработчиков.
Мы также сократим указанную модель до 6 блоков, объединив операции «Инсталляция» и «Поддержка» в одну – «Развертывание». Теперь взглянем на исполняемые функции:
Требования. Проще говоря, на этом этапе создаётся вся входная документация, согласно которой будет вестись разработка. В первую очередь, анализируются требования и пожелания заказчика, затем это проецируется на возможности компании и состояние рынка. В результате получается некий документ, где описывается, что должно делать ПО, но не как и с помощью каких инструментов.
Проектирование. На этом этапе согласовывается логика работы ПО. Здесь всё ещё не принимаются конкретные решения по реализации, но уже описывается функционирование всех разделов приложения. На выходе разработчики уже представляют, сколько по времени и кадровому составу может занять проект.
Конструирование. Здесь уже речь идёт о конкретных инструментах для реализации идей: согласовываются требования к дизайну, языки программирования, уровни данных, сервисы и т. д. Описанный в предыдущем разделе скелет логики обрастает «мясом», впервые формируется внешний облик готового продукта.
Воплощение. Исполнительский этап, на который, как правило, приходится большая часть разработки. Если классическая модель допускает свободное взаимодействие с предыдущими этапами, то на практике допускается лишь внесение незначительных правок в «Конструирование».
Тестирование. На этом этапе QA, бета- и все другие тестеры обнаруживают и сообщают о проблемах в приложении. Данный этап чаще всего вызывает необходимый повтор предыдущей фазы кодирования, чтобы устранить критические неполадки. Если результатом тестирования становятся частые доработки кода, это вызывает возврат к этапу конструирования.
Развертывание. Когда приложение создано, его можно предъявлять заказчику и выпускать на волю. Так как данный этап включает ещё и поддержку, поэтому взаимодействие с предыдущими фазами неизбежно.
Преимущества каскадной модели
В последние годы модель водопада уступает свои лидирующие позиции более гибким методологиям. Это связано с общей динамикой в IT, когда за разработку ПО отвечают команды из 5-9 человек, а дедлайн может быть легко сдвинут из-за наращивания функциональности.
Тем не менее, каскадная модель всё ещё актуальна для крупных проектов и организаций. И вот почему:
Недостатки каскадной модели
В 1970-х годах идеи Ройса были актуальны. Но спустя почти 50 лет метод каскадной разработки всё меньше подходит для IT. Вот почему:
Получается, что каскадная методология – прекрасное решение точки зрения сроков и отчётности, но очень слабое в плане качества. Поэтому сегодня её рекомендуется использовать только в трёх случаях:
Несмотря на то, что эти 3 пункта всё реже встречаются в реальной практике, каскадная модель ещё долго будет популярна и востребована из-за чёткой организации. А значит любой профессиональный разработчик должен понимать её основные принципы и быть готовым существовать в рамках этой схемы.
Agile или Waterfall? Сравнение методологий веб-разработки
При создании нового проекта, заказчик должен определиться не только с выбором подрядчика, но и подходящей методологией разработки проекта. На современном этапе развития технологий, нет универсального подхода в создании проекта, поэтому возникает логичный вопрос: какой подход выбрать и какие «подводные камни» существуют?
Waterfall – это четко запланированный и детализированный подход, где исполнитель придерживается плану. Agile – прямая противоположность, которая предполагает гибкость разработки с возможностью внесения изменений на каждом этапе проекта.
В этой статье постараемся определить, в чем особенности этих двух методологий, назовем положительные и отрицательные стороны, а также разберемся, какой способ реализации подойдет для выбранного вами проекта.
Гибкие методологии строятся на принципе итераций. Создание нового продукта делится на несколько циклов от одной недели до месяца. В зависимости от особенностей проекта, временные рамки оговариваются отдельно. Каждый цикл представляет собой завершенный мини-проект, в котором есть этапы анализа, планирования, тестирования и реализации. В итоге клиент получает продукт, который, при необходимости, корректируется.
Главные принципы Agile:
Наиболее популярные методики Agile:
Scrum – система гибкой разработки проектов, основанная на принципе спринта. От 1 недели до месяца должна быть готова рабочая версия продукта.
Экстремальное программирование (XP) – методика, при которой важно взаимодействие с клиентом на каждом этапе. Благодаря такому подходу, выявляются недостатки предыдущих этапов, определяется необходимый функционал продукта и другие параметры.
Lean – базируется на системе управления производством. Главное отличие – принцип постоянного совершенствования продукта на всех уровнях организации процесса.
Про гибкую модель управления можно сказать, что она универсальна, так как подойдет к любому проекту. Сложность выбора заключается только в ограничениях заказчика по времени и боязнью «дыр» в бюджете. Качество обратной связи при данном подходе поможет прийти к согласованному решению. Выбирая эту модель, заказчик может быть уверен, что его проект будет уникальным, интересным и проверенным до мелочей.
Waterfall (с англ. – «водопад») – предполагает последовательный переход к каждому этапу разработки и невозможностью вернуться на шаг назад. Внести какие-либо изменения будет возможно только после релиза проекта.
Выбирая данную модель для своего проекта, необходимо понимать, что конечный продукт будет иметь недочеты. Предусмотреть все на этапе анализа и планирования просто невозможно, в процессе разработки могут появится новые требования. Однако, в Waterfall сделать правки в течении проекта невозможно также, как и вернуться на шаг назад. Классический подход представляет из себя каскадную модель, которая базируется на последовательном создании проекта, разбитого на циклы.
Выделяют следующие стадии разработки в Waterfall:
Востребованные методики Waterfal:
Сашими – одна из самых популярных моделей Waterfal. Представляет собой наслаивающиеся друг на друга этапы, которые перекрываются по времени.
Waterfall с субпроектами – методика работы с тремя крупными стадиями: разработка концепции, проектирование и структурирование продукта. Каждый из этих блоков имеет свои этапы разработки. По окончании работ в каждой стадии проводится их интеграция.
Модель снижения риска – проект разделяется на более мелкие проекты, которые направлены на выявление недочетов до релиза программного продукта.
Ключевая особенность Waterfall – невозможность сделать шаг назад или перепрыгнуть через итерацию, переход на следующую стадию возможен только после прекращения всех работ на предыдущей. Изменение функционала или исправление ошибок происходит только после релиза проекта. Работа по каскадной модели четко структурирована, определи точные сроки и конкретная стоимость разработки.
Waterfall подойдет, если:
Что из этого следует?
Каждая из моделей, рассмотренных нами выше, имеет определенный набор характеристик и подходит для реализации проектов разной направленности.
Как Agile, так и Waterfall помогут в создании практически любого продукта. Однако, в первую очередь выбирается та методология, которая может максимально эффективно и качественно реализовать проект. Быть может продукт универсален. Тогда необходимо отталкиваться от параметров, как время, бюджет, квалификация исполнителей и другие важные для вас критерии.
Гибкая модель требует высокого профессионализма от исполнителя и идеально подходит для стартапов и продвинутых нишах. Водопадная модель чаще всего используется в области строительства, инвестиций и т.д.
При выборе той или иной методологии заказчик должен внимательно изучить сильные и слабые стороны подходов, учесть советы специалистов, определить набор требований к проекту. И тогда выбор будет сделать гораздо легче. Некоторые разработчики считают, что в рамках одного проекта можно оптимально совместить Agile и Waterfall.
Помните, что, принимая решение в пользу того или иного метода, главной задачей является создание не только качественного продукта, но и возможность им решать поставленные задачи.
Ну вот какбэ да.
Выбирайте исполнителя, а с методологией уж пусть он сам пределяется. Если вы принципиально не хотите работать по предложенной методологии, а исполнитель не хочет ее менять, возможно, это не ваш исполнитель.
Ну и вопрос о месте работы автора.
Это ж каких размеров должна быть производственная махина, чтобы изменить продукт в процессе вотерфлоу было вот прям невозможно. Не дорого, не долго, не сложно, а вот прям невозможно?
Согласен, пожалуй «невозможно» слишком эмоциональное слово, по сути нет ничего не возможного, по этому да, правильней было бы сказать, что слишком дорого и не рационально.
** Преимущества Waterfall ** полный бред. Вы работали с реальными проектами?
Стоимость и сроки выполнения понятны ещё до начала работ. Поэтому заказчик точно будет знать, когда проект завершится и какой бюджет требуется потратить.
Стоимость и сроки не понятны, они взяты из носа и размазаны по бумаге. По факту сроки и бюджеты всегда нарушаются.
Интуитивно понятная структура работы, как для опытных специалистов, так и для новичков.
Структура работ не понятно, а расписана из ПРЕДПОЛОЖЕНИЙ руководителя проекта или другого руководящего лица. Это мешает контактировать, мешает помогать, все заняты своим делом и не заботятся о благополучии команды.
Детально структурированный план работ и продуманная документация.
Документация, которую никто не читает. План работ, основанный на предположениях.
Благодаря удобной отчетности легко отследить потраченное время, возможные риски и используемые ресурсы в процессе работы над проектом.
Постфактум в любом случае можно всё это отследить, если фиксировать во время работы.
Задачи, которые ставятся перед командой ясны и не меняются на протяжении всего проекта.
Для команды ясны, но в ходе проекта задачи меняются у заказчика и на выходе получается не жизнеспособный продукт, который не нужен заказчику.
Качество проекта занимает первоочередное место, а потраченное время и бюджет отходят на второй план.
А в Scrum и вообще в Agile продукт на последнем месте да?
С ** недостатками Agile ** тоже не согласен.
Рассчитать конечные затраты практически невозможно – требования могут постоянно меняться в зависимости от особенностей проекта. Сложность заключается в том, что они могут противоречить уже существующей структуре.
Требования могут меняться, но они не должны быть диаметрально противоположными. Требования могут дополняться, да. А чтобы вместо изначально запрошенного сарая, заказчик на выходе не требовал дворец, нужен грамотный Product Owner.
Agile требует большой вовлеченности в процесс и полному погружению в него, что бывает сложно, особенно для молодых подрядчиков.
Любая задача требует полного погружения и воволеченности, иначе это будет халтура, а не работа.
Возможность частого внесения правок может обернуться риском в бесконечном совершенствовании проекта. Здесь также возможна и обратная сторона – снижение качества продукта.
Опять таки, есть конечные требования, поставленные изначально, а чтобы губу клиент не раскатывал есть договор и Product Owner.
Вообще по Agile в статье много ошибок. Либо автор не до конца разобрался в вопросе, либо просто не смог правильно преподнести информацию.
А вообще советую прочитать книгу Scrum (Джефф Сазерленд). Там всё по полочкам.
Waterfall или Agile: как выбрать методологию управления проектом?
Привет! Я — Алиса Корнева — менеджер проектов в компании Azoft. Занимаюсь управлением проектов больше 8 лет. По моему опыту, выбор методологии управления проектом часто лидирует в списке холиварных вопросов клиента и команды. В этой статье поделюсь с вами своими мыслями на эту тему, без купюр и фаворитизма.
Когда вы решаете разработать свой продукт, то рано или поздно возникает вопрос, как организовать процесс разработки. Стоит ли жестко распланировать все этапы и делать все шаг за шагом? Или лучше работать короткими итерациями, чтобы чаще отслеживать результат и быстрее вносить правки? Все это определяют методологии разработки продукта. Каждая из них имеет свои преимущества и недостатки. В этой статье рассмотрим наиболее популярные из них. Также я расскажу на что обратить внимание при выборе подходящей методологии и как комбинировать разные подходы.
Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут последовательно. Следующая фаза начинается только после завершения предыдущей. Наглядно это выглядит так:
Получается, план такой:
В Waterfall можно управлять изменениями требований и рисками, но это скорее исключительные ситуации, которые требуют дополнительных затрат времени и бюджета.
Agile (гибкие) – это семейство методологий, объединенных ценностями и принципами Agile-манифеста.
Agile стал основой для целого ряда гибких методик, среди которых наиболее известны Scrum, Lean и экстремальное программирование.
В основном это фреймворки, предполагающие итерационную работу над проектом, то есть когда основные фазы разработки циклично повторяются друг за другом. Самый распространенный фреймворк – это Scrum, схематично рабочий процесс по которому можно изобразить так:
Жизненный цикл проекта в этом случае – это набор итераций, каждая из которых включает в себя мини-версию разработки проекта командами по методу Waterfall.
Получается, что итерационные методологии отличаются тем, что результатом каждой итерации является законченный продукт, и каждая последующая итерация наращивает его функциональность.
Ещё одна особенность в том, что на этапе аналитики требуется прояснить и зафиксировать не все требования по проекту, а только часть – то, что планируется завершить в текущей итерации. Аналогично с разработкой дизайна – идет отрисовка не итоговых прототипов, а только требуемых для реализации текущего спринта.
Waterfall, Scrum и другие гибкие методологии управления проектами имеют преимущества и недостатки. Каждая из методологий хорошо подходит для решения определенных задач и сложнее адаптируется к другим.
Характеристики проектов, подходящих под разные методологии можно обозначить так:
Скоуп и требования-
Waterfall — похожая задача уже решалась заказчиком/исполнителем, продукт не инновационный;
Гибкие методологии — для заказчика/исполнителя это качественно новая задача, либо продукт инновационный;
В чем подвох — в новой для себя области гораздо проще упустить что-то важное. Для Waterfall будет сложнее вносить изменения в исходные требования.
Waterfall — требования к проекту в процессе работы не будут значительно меняться;
Гибкие методологии — планируется применять Customer development (тестирование идеи или прототипа будущего продукта на потенциальных потребителях), тестировать гипотезы на рынке, в процессе проекта управлять приоритетами, опираясь на фокус-группы;
В чем подвох — по аналогии с первыми пунктами – здесь все упирается в потребность гибко управлять требованиями. Если нет такой потребности – Waterfall ваш вариант.
Waterfall — жестко ограничен;
Гибкие методологии — можно варьировать в заданных рамках;
Waterfall — жестко ограничен и определен до этапа аналитики;
Гибкие методологии — может варьироваться;
В чем подвох — отличительная особенность гибких методологий – результат каждой итерации в виде работающего продукта. После завершения этапа аналитики можно достаточно точно оценить срок завершения Waterfall-проекта.
Если проект характеризуется признаками только из одной колонки – можно смело выбирать соответствующую методологию проекта и не греть голову. Но что, если все сложнее (как и бывает в большинстве случаев)? Тогда на помощь приходят гибридные методологии управления проектами! Мы уже писали про свой опыт работы с ними на примере разработки портала «Спасибо от Сбербанка. Путешествия». Советуем ознакомиться, чтобы узнать подробнее когда и зачем их применять.
Большинство проектов Azoft управляются с помощью гибридной, индивидуально подобранной под проект методологии.
Для нас важно, чтобы инструменты управления использовались не «для галочки», и не потому, что это декларировано в PMBook, а для того, чтобы решить задачи проекта.
Объясняем, когда и как внедрить практики из разных методологий, чтобы в результате собрать актуальный для вашего проекта «гибрид»:
Как сделать подходящий к проекту гибрид:
Каждый проект – это уникальный коктейль из требований, команды, заказчика и внешних условий. Подходящий к проекту фреймворк управления позволяет использовать ресурсы эффективно, сильно снижая риски ошибиться в процессе. Надеюсь, статья поможет вам настраивать на своих проектах такие системы управления, которые помогут достигать классных результатов! Если вы знаете другие способы добиться идеальной управляемости проекта – пишите в комментариях, будем рады новым инсайтам.
Кратко о методологиях разработки ПО: Waterfall, Lean и Feature Driven Development
В нашем прошлом материале мы писали о методологиях разработки программного обеспечения, которые помогают оптимизировать рабочие процессы. Тогда речь шла о Scrum, канбан и экстремальном программировании. Сегодня мы расскажем о Waterfall, FDD и Lean — оценим плюсы и минусы подходов и взглянем на опыт организаций, которые их используют, чтобы помочь вашим компаниям оптимизировать процессы.
Waterfall
Waterfall, или каскадная модель, — традиционная методология, которая существует с 1970 года. В ней разработку проекта разбивают на этапы: от анализа системных требований до выпуска продукта.
Каждый шаг — отдельная фаза разработки ПО, и команда должна завершить одну фазу, прежде чем переходить к следующей. В «чистой» реализации Waterfall возвращаться на предыдущий этап запрещено — можно «плыть только по течению», чтобы пройти полный цикл разработки. Пользователи Quora сравнивают эту модель с поездом, который движется от станции к станции и не может повернуть назад.
Изначально автор Waterfall Винстон Ройс (Winston Royce) привел каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведет к ошибкам и выпуску некачественных продуктов. Однако потом в своей статье он довел методологию «до ума», отметив обратные связи и переходы от тестирования к написанию кода и др.
По данным исследования PMI, 12% компаний используют методологию Waterfall на постоянной основе, а 40% респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25% организаций.
Количество этапов в Waterfall варьируется от компании к компании, но общий подход выглядит следующим образом:
Кроме того, модель подразумевает документирование каждого этапа. Это помогает создавать базу для последующих проектов. Также большое количество отчетности позволяет в любой момент показать заказчику или руководству, на какой стадии находится продукт.
Однако есть и недостатки. Клиенты часто не знают, чего они действительно хотят, пока не взглянут на прототип. А по Waterfall нужно определять все требования заранее, поэтому есть риск что-то упустить. Исследование процесса разработки сайта компании Ericsson AB показало, что каскадная модель привела к путанице, и 26% изначальных требований оказались бесполезными.
Однако главный недостаток Waterfall — внесение изменений. Продукт тестируют в конце жизненного цикла, и может быть слишком поздно, чтобы что-то править. Именно стоимость внесения изменений побудила компанию Toyota задуматься о переходе на другую методологию разработки.
По словам Сатоси Исии (Satoshi Ishii), главного руководителя проектов компании, исправление дефектов, обнаруженных после производства, обходится в 1000–10000 раз дороже. Поэтому в Toyota решили отказаться от Waterfall и перейти к Lean, который мы рассмотрим далее.
Термин означает «бережливая разработка». Его корни уходят глубоко в историю компании Toyota и её подходов к решению задач. В компании вносят только те изменения, которые приносят пользу, требуют минимум затрат и отнимают не более 30% запланированного времени. Это помогло японской компании научиться переключать конвейеры на производство другой модели за считаные часы, в то время как другим автопроизводителям требовались недели.
Применили методологию Lean для разработки Мэри (Mary Poppendieck) и Том Поппендик (Tom Poppendieck). Они написали книгу «Lean Software Development». Дополнительную информацию также можно найти на их сайте, посвящённом Lean.
По данным исследования PMI, 8% компаний постоянно используют принципы Lean, а 26% часто к ним обращаются. Принципы Lean:
При этом, когда команда следует принципам бережливой разработки, она не просто выполняет задачи, а стремится сделать продукт с наименьшим количеством ошибок. В своём исследовании компания ВВС обнаружила, Lean повышает скорость разработки ПО на 37% и снижает количество багов на 24%.
Также, согласно исследованию Lean Business Report, в числе десяти преимуществ подхода указано снижение стоимости проектов — 27% IT-компаний уменьшили затраты за счет внедрения принципов Lean.
Однако они подходят не всем. Команда GlobalLuxSoft отмечает, что бережливую разработку стоит применять, только если к проекту подключены опытные разработчики, так как обучение на ходу оказывается невозможным и ставит создание продукта под угрозу.
Все принимаемые решения должны подкрепляться аналитическими данными и результатами мониторинга процессов, иначе команда рискует погрузиться в слишком большое количество изменений и забыть о главной цели проекта. Здесь можно обратиться к опыту Toyota: жесткий контроль со стороны не позволяет разработчикам отклоняться от приоритетных задач.
/ Flickr / Sebastian Sikora / CC
Feature Driven Development
Feature driven development (FDD) — методология, которая объединяет лучшие практики и сосредотачивает внимание разработчиков на функциональных элементах (features), полезных с точки зрения клиента. По этой ссылке можно найти примерную схему алгоритма разработки по FDD. Согласно исследованиям, 11% компаний постоянно используют Feature Driven Development, а 31% прибегает к использованию этой методологии время от времени.
Создатель FDD — Джефф де Лука (Jeff De Luca), впервые предложил методологию в 1997 году, когда искал оптимальное решение по разработке программного обеспечения для банка в Сингапуре. Тогда он предоставил комбинацию из 5 процессов:
Однако есть и плюсы. Постоянное составление отчетов о проделанной работе на всех уровнях помогает отслеживать прогресс и результаты. Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять клиенту информацию в любое время. А один из резидентов Stack Overflow утверждает, что главный плюс FDD — возможность в любой момент оценить отстаёт ли проект от графика или продвигается быстрее.
Как уже было отмечено, FDD используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает риск нежелательных «сюрпризов».