Что может являться рабочим продуктом в процессе разработки по
Процесс разработки программного обеспечения
Процесс
Центральным объектом изучения программной инженерии является процесс создания ПО – множество различных видов деятельности, методов, методик и шагов, используемых для разработки и эволюции ПО и связанных с ним продуктов (проектных планов, документации, программного кода, тестов, пользовательской документации и пр.).
В рамках компании возможна и полезна стандартизация всех текущих процессов, которую будем называть стандартным процессом. Последний, таким образом, оказывается некоторой базой данных, содержащей следующее:
Необходимо отметить, что наличие стандартного процесса свидетельствует о наличии «единой воли» в организации, существующей именно на уровне процесса. На уровне продаж, бухгалтерии и др. привычных для всех компаний процессов и активов единство осуществить не трудно. А вот на уровне процессов разработки очень часто каждый проект оказывается сам по себе (особенно в оффшорных проектах) – «текучка» захватывает и изолирует проекты друг от друга очень прочно.
Совершенствование процесса
Определение. Совершенствование процесса ( software process improvement ) – это деятельность по изменению существующего процесса (как текущего, в рамках одного проекта, так и стандартного, для всей компании) с целью улучшения качества создаваемых продуктов и/или снижения цены и времени их разработки. Причины актуальности этой деятельности для компаний-производителей ПО заключается в следующем.
Что и каким образом можно улучшать.
Пример использования стратегии organization pull – внедрение новых средств тестирования в ситуации, когда высоки требования по качеству в проекте, либо когда качество программной системы не удовлетворяет заказчика.
Классические модели процесса
Фазы и виды деятельности. Говоря о моделях процессов, необходимо различать фазы и виды деятельности.
Фаза ( phase ) – это определенный этап процесса, имеющий начало, конец и выходной результат. Например, фаза проверки осуществимости проекта, сдачи проекта и т.д. Фазы следуют друг за другом в линейном порядке, характеризуются предоставлением отчетности заказчику и, часто, выплатой денег за выполненную часть работы.
Наконец, в рамках этой модели было введено прототипирование, то есть предлагалось разрабатывать систему дважды, чтобы уменьшить риски разработки. Первая версия – прототип – позволяет увидеть основные риски и обосновано принять главные архитектурные решения. На создание прототипа отводилось до одной трети времени всей разработки.
Спиральная модель была предложена Бэри Боемом в 1988 году для преодоления недостатков водопадной модели, прежде всего, для лучшего управления рисками. Согласно этой модели разработка продукта осуществляется по спирали, каждый виток которой является определенной фазой разработки. В отличие от водопадной модели в спиральной нет предопределенного и обязательного набора витков, каждый виток может стать последним при разработке системы, при его завершении составляются планы следующего витка. Наконец, виток является именно фазой, а не видом деятельности, как в водопадной модели, в его рамках может осуществляться много различных видов деятельности, то есть модель является двумерной.
Каждый виток имеет следующую структуру (секторы):
Отдельная спираль может соответствовать разработке некоторой программной компоненты или внесению очередных изменений в продукт. Таким образом, у модели может появиться третье измерение.
Спиральную модель нецелесообразно применять в проектах с небольшой степенью риска, с ограниченным бюджетом, для небольших проектов. Кроме того, отсутствие хороших средств прототипирования может также сделать неудобным использование спиральной модели.
Рабочий продукт, дисциплина обязательств, проект
Рабочий продукт
Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что первый необязательно материален и осязаем ( not to be engineered ), хотя может быть таковым. Нематериальный рабочий продукт – это, как правило, некоторый налаженный процесс – промышленный процесс производства какой-либо продукции, учебный процесс в университете (на факультете, на кафедре) и т.д.
Важно отметить, что рабочий продукт совсем не обязательно является составной частью итоговой поставки. Например, налаженный процесс тестирования системы не поставляется заказчику вместе с самой системой. Умение управлять проектами (не только в области программирования) во многом связано с искусством определять нужные рабочие продукты, настаивать на их создании и в их терминах вести приемку промежуточных этапов работы, организовывать синхронизацию различных рабочих групп и отдельных специалистов.
Итак, подытожим, что промежуточный рабочий продукт должен обязательно иметь ясную цель и конкретных пользователей, чтобы минимизировать накладные расходы на его создание.
Дисциплина обязательств
В основе разделения обязанностей в бизнесе и промышленном производстве, корпоративных правил и норм лежит определенная деловая этика, форма отношений – дисциплина обязательств. Она широко используется на практике и является одной из возможных форм социального взаимоотношения между людьми. Привнесение в бизнес и промышленность иных моделей человеческих отношений – семейных, сексуальных, дружеских и т.д. часто наносит делам серьезный урон, порождает конфликтность, понижает эффективность.
Основой этой формы отношений являются обязательства, которые:
Отметим, что дисциплина обязательств не является каким-то сводом правил, законов, она отличается также от корпоративной культуры. Это – определенный групповой психический феномен, существующий в обществе современных людей. Приведенные выше пункты не являются исчерпывающим описанием этого феномена, но лишь проявляют и обозначают его, так сказать, вызывают нужные воспоминания.
С другой стороны, люди, освоившие эту дисциплину, часто стремятся применять ее в других областях жизни и человеческих отношений, что оказывается не всегда оправданным. Подчеркнем, что данная дисциплина является далеко не единственной моделью отношений между людьми. В качестве примера можно рассмотреть отношения в семье или дружбу, что, с очевидностью, не могут быть выражены дисциплиной обязательств. Так, вместо точности и пунктуальности в этих отношениях важно эмоционально-чувственное сопереживание, без которого они невозможны.
Проект
Однако высокий уровень сложности ряда задач в промышленности и бизнесе не позволяет (к счастью!) так работать везде. Существует много творческих, новых задач, где, быть может, в будущем и удастся создать конвейеры, но в данный момент для их решения требуется существенная концентрация сил и энергии людей, неожиданные решения, а также удача и легкая рука. Это и есть область проектов.
Отметим несколько важных аспектов управления проектами.
При разработке программных проектов, следуя MSF 3.1, важны следующие области управления.
Рабочий продукт, дисциплина обязательств, проект
Рабочий продукт
Ключевая разница между рабочим продуктом и компонентой ПО заключается в том, что первый необязательно материален и осязаем ( not to be engineered ), хотя может быть таковым. Нематериальный рабочий продукт – это, как правило, некоторый налаженный процесс – промышленный процесс производства какой-либо продукции, учебный процесс в университете (на факультете, на кафедре) и т.д.
Важно отметить, что рабочий продукт совсем не обязательно является составной частью итоговой поставки. Например, налаженный процесс тестирования системы не поставляется заказчику вместе с самой системой. Умение управлять проектами (не только в области программирования) во многом связано с искусством определять нужные рабочие продукты, настаивать на их создании и в их терминах вести приемку промежуточных этапов работы, организовывать синхронизацию различных рабочих групп и отдельных специалистов.
Итак, подытожим, что промежуточный рабочий продукт должен обязательно иметь ясную цель и конкретных пользователей, чтобы минимизировать накладные расходы на его создание.
Дисциплина обязательств
В основе разделения обязанностей в бизнесе и промышленном производстве, корпоративных правил и норм лежит определенная деловая этика, форма отношений – дисциплина обязательств. Она широко используется на практике и является одной из возможных форм социального взаимоотношения между людьми. Привнесение в бизнес и промышленность иных моделей человеческих отношений – семейных, сексуальных, дружеских и т.д. часто наносит делам серьезный урон, порождает конфликтность, понижает эффективность.
Основой этой формы отношений являются обязательства, которые:
Отметим, что дисциплина обязательств не является каким-то сводом правил, законов, она отличается также от корпоративной культуры. Это – определенный групповой психический феномен, существующий в обществе современных людей. Приведенные выше пункты не являются исчерпывающим описанием этого феномена, но лишь проявляют и обозначают его, так сказать, вызывают нужные воспоминания.
С другой стороны, люди, освоившие эту дисциплину, часто стремятся применять ее в других областях жизни и человеческих отношений, что оказывается не всегда оправданным. Подчеркнем, что данная дисциплина является далеко не единственной моделью отношений между людьми. В качестве примера можно рассмотреть отношения в семье или дружбу, что, с очевидностью, не могут быть выражены дисциплиной обязательств. Так, вместо точности и пунктуальности в этих отношениях важно эмоционально-чувственное сопереживание, без которого они невозможны.
Проект
Однако высокий уровень сложности ряда задач в промышленности и бизнесе не позволяет (к счастью!) так работать везде. Существует много творческих, новых задач, где, быть может, в будущем и удастся создать конвейеры, но в данный момент для их решения требуется существенная концентрация сил и энергии людей, неожиданные решения, а также удача и легкая рука. Это и есть область проектов.
Отметим несколько важных аспектов управления проектами.
При разработке программных проектов, следуя MSF 3.1, важны следующие области управления.
Методология гибкой разработки SCRUM
Получить представление о процессах и основных артефактах методологии гибкого создания программных продуктов Scrum.
Введение
Рабочие элементы
Цикл выпуска продукта в Scrum состоит из ряда итераций, которые называются спринтами. Спринт имеет фиксированную длительность, как правило, 1-4 недели. Элементы работы, включенные в очередной спринт, не подлежат изменению до его окончания. Хотя спринт завершается подготовкой работоспособного программного продукта, его текущей функциональности может быть недостаточно для оформления выпуска, имеющего ценность для заказчика. Поэтому выпуск работоспособного программного продукта, который заказчик может использовать, включает, как правило, несколько спринтов.
Организация команды
Организация команды в методологии Scrum определяет три роли [46]:
Руководитель отвечает за состояние и координацию проекта, продуктивность команды и устранение препятствий, мешающих проекту. В обязанности руководителя входит:
Члены команды отвечают за разработку программного продукта высокого качества. Они должны обладать навыками в проектировании и архитектуре программного продукта, бизнес-анализе, программировании, тестировании, настройке баз данных и проектировании пользовательского интерфейса. Члены команды участвуют в планировании спринтов. Команда может включать опытных разработчиков и новичков, которые в процессе работы должны совершенствоваться при обмене знаниями с другими членами команды. Члены команды отвечают за следующие задачи в проекте:
Жизненный цикл проекта ПО
Инструментальная и методическая поддержка гибкого подхода к созданию программных продуктов Scrum, реализованная в VisualStudio 2012, позволяет управлять жизненным циклом проекта ПО ( рис. 16.1) [47].
Управление невыполненной работой
Владелец продукта на основе требований и пожеланий клиентов формирует список функций продукта в виде элементов задела работы продукта, которые помещает в список Невыполненная работа по продукту. При создании нового элемента невыполненной работы для него устанавливается состояние «Новый» ( рис. 16.3).
После установки элементу работы приоритета его состояние изменяют на «Утверждено». На собрании по планированию спринта команда просматривает наиболее приоритетные элементы работы и выбирает те, которые будут выполняться в текущем спринте. Для элементов невыполненной работы, которые попали в текущий спринт, устанавливается состояние «Зафиксировано». Это означает тот факт, что рабочие элементы спринта не подлежат изменению до конца спринта. При завершении работы по элементу его состояние устанавливается «Выполнено». Если для элемента работы, находящегося в состоянии «Выполнено» выявляется дополнительная работа, то этот элемент может быть переведен в состояние «Зафиксировано». Для элемента работы, находящегося в состоянии «Зафиксировано», при возникновении проблем, препятствующих его завершению в спринте, может быть работа приостановлена и установлено состояние «Утверждено». Элемент невыполненной работы может быть удален из списка Невыполненная работа по продукту по решению Владельца продукта. Это может произойти как из состояния «Новый», так и состояния «Утверждено», что соответствует установке для элемента работы состояния «Удалено». В результате пересмотра элемента работы, имеющего состояние «Удалено», для него вновь возможен перевод в состояние «Новый».
Список Невыполненная работа по продукту является главным документом для Scrum-команды. На основе данного списка команда создает другие рабочие элементы, составляющие спринты и выпуски. Для Элементов невыполненной работы команда создает задачи и тестовые случаи. Задачи детализируют элемент работы и определяют конкретную реализацию требований пользователя. Тестовые случай необходимы для проверки соответствия функциональности кода требованиям пользователя. Если тестовый случай не проходит, то создается рабочий элемент «Ошибка». При блокировании задачи из-за невозможности её выполнения в текущем спринте создают рабочий элемент «Препятствие». Scrum- команда может создавать вспомогательные рабочие элементы (ошибки и препятствия) в отношении элементов, на которые они влияют (задачи и тестовые случаи) и связывать эти элементы ( рис. 16.4).
Методология Scrum имеет следующие положительные стороны:
Ключевые термины
| Методология Scrum | гибкая методология разработки программного обеспечения, которая представляет собой итеративный процесс. |
| Рабочий элемент | запись, которая создается в Visual Studio Team Foundation Server для задания определения, назначения, приоритета и состояния элемента работы. |
| Элементы задела работы продукта | список пользовательских требований, которые определяют функциональность продукта, в методологии Scrum. |
| Элемен тработы | краткое описание функций продукта, в методологии Scrum. |
| Спринт | набор задач, запланированных на выполнение определенный период времени, в методологии Scrum. |
| Владелец продукта | член Scrum-команды, который отвечает за всё, что связано с потребительскими качествами программного продукта. |
| Руководитель | член Scrum-команды, который отвечает за состояние и координацию проекта, продуктивность команды и устранение препятствий, мешающих проекту. |
| Член команд | член Scrum-команды, который наравне с другими членами команды отвечает за разработку программного продукта высокого качества. |
| Невыполненная работа по продукту | список элементов работы (пользовательских описаний функциональности), которые необходимо выполнить при создании программного продукта. |
| Незаконченная работа | список элементов работы планируемого спринта. |
Краткие итоги
В лекции показано, что методология Scrum представляет собой итеративный процесс разработки программного обеспечения. Рабочие элементы используются для отслеживания, наблюдения за состоянием хода разработки ПО и создания отчетов.Организация команды в методологии Scrum определяет роли владельца продукта, руководителя и членов команды. Жизненный цикл проекта ПО включает формирование и управление невыполненной работой, планирование и выполнение спринта, развертывание ПО у заинтересованных лиц, получение отзывов для улучшения программного продукта. При управлении рабочим процессом элементов невыполненной работы по продукту постоянно отслеживаются связи и изменяется состояние этих элементов.
Модели и методологии разработки ПО
За прекрасную картинку спасибо Toggl.com.
Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.
Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.
Этапы жизненного цикла ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки ПО
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.
Waterfall (каскадная модель, или «водопад»)
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.
Преимущества «водопада»
Недостатки каскадной модели
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.
V-образная модель (разработка через тестирование)
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.
Incremental Model (инкрементная модель)
Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.
Преимущества инкрементной модели
Недостатки инкрементной модели
Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.
Iterative Model (итеративная модель)
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.
Рассмотрим на примере создания мессенджера, как эта модель работает.
Преимущества итеративной модели
Недостатки итеративной модели
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.
Spiral Model (спиральная модель)
Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.
Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».
Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.
Преимущества спиральной модели
Большое внимание уделяется проработке рисков.
Недостатки спиральной модели
На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.
Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!
За прекрасную картинку спасибо Toggl.com.
Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.
Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.
Этапы жизненного цикла ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки ПО
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.
Waterfall (каскадная модель, или «водопад»)
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.
Преимущества «водопада»
Недостатки каскадной модели
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.
V-образная модель (разработка через тестирование)
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.
Incremental Model (инкрементная модель)
Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.
Преимущества инкрементной модели
Недостатки инкрементной модели
Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.
Iterative Model (итеративная модель)
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.
Рассмотрим на примере создания мессенджера, как эта модель работает.
Преимущества итеративной модели
Недостатки итеративной модели
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.
Spiral Model (спиральная модель)
Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.
Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».
Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.
Преимущества спиральной модели
Большое внимание уделяется проработке рисков.
Недостатки спиральной модели
На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.
Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!