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

Главное, чтобы выбранный способ удовлетворял потребностям проекта. Гибкость приветствуется даже в выборе методологии этой самой гибкости. Доступно проиллюстрирует идею XP способ «парного программирования».

Методология рационального управления (Lean)

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

Соответственно, V-образная модель также подходит для небольших и средних по объемам проектов, где вся документация четко прописана и требуется определенный уровень качества (высокий). Это могут быть приложения безопасности, наблюдения за тяжелобольными пациентами, ПО для атомных электростанций и так далее. С одной стороны, проектом легко управлять, есть четкая последовательность действий, сроки выполнения и бюджет известен заранее.

Нужна ли новая методология разработки?

Узнайте, как масштабировать работу в стиле agile с помощью методологий Scrum of Scrums или SAFe® (Scaled Agile Framework). Обе методологии прекрасно подходят для того, чтобы начать применять agile-подход на разных уровнях вашей организации. Чередование этих
этапов, взаимодействие между ними может меняться, исходя из выбранной вашим
руководителем или вами модели процесса разработки ПО. Так как методология рационального управления сосредоточена на сокращении потерь, она лучше всего подойдёт командам, испытывающим проблемы с эффективностью.

• Однако в последние годы, в связи с распространением продуктового подхода в бизнесе, я буду рассматривать методологии именно в разрезе разработки продукта.
• Agile (читается «эджайл») — набор принципов и ценностей, описанных в манифесте.
• Постоянная обратная связь может оттягивать завершение проекта.
• Интересно, что основным аргументом отказа от каскадной модели были изменения в требованиях по мере написания кода (отсутствие гибкости).

По статистике, лишь 20 % функциональности в типичной программе используется постоянно. Получается, что до 66 % программного кода создается бесцельно. Можно представить, каких колоссальных затрат времени и труда можно избежать, если просто не создавать эту ненужную функциональность. Неиспользуемый код не только делает программу сложнее и медлительнее — он требует тестирования, документирования, технической поддержки, доработки. В предыдущем посте мы рассказали о гибких методологиях разработки — Scrum и экстремальном программировании (если вы еще не читали о них — сделайте это!) Но на этом список Agile-методологий не заканчивается. Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом.

Agile

Это нарушило бы одну из функций, явно согласованных в бизнес-требованиях, имеющих подпись клиента. Первая user story выбирается из расчета того, что она будет делаться 4 часа. Далее задачи оцениваются в story points, в зависимости от того насколько они более трудоемкие по прогнозам команды.

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

Методологии[править править код]

Есть множество инструментов для того, чтобы выстроить работу команды по Kanban. О некоторых из них можно почитать в статье “Инструменты для командной работы над стартапом”. Здесь тоже нужно планирование и четко определенные методологии разработки требования к продукту, кроме того, у вас в команде должны быть тестировщики — без них модель окажется нерабочей. Что это будет, классический Скрам из учебников или смесь Канбан и XP,  зависит целиком и полностью от вас.

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

Приложение 1. Шаблон требований

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Руководитель, уважающий своих коллег и подчиненных, собирает вокруг себя думающих и увлеченных работников, способных сообща создавать успешные проекты. И напротив, коллективы, где мнение «заслуженных», «приближенных» или «избранных» ценится выше остальных, — погрязают во внутренних проблемах, а лучшие специалисты при первой возможности покидают такие команды. Избежать этого сможет только коллектив мотивированных профессионалов, способных оперативно решать проблемы, не дожидаясь указаний сверху.

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