Каскадная модель жизненного цикла

Каскадная модель жизненного цикла

 

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

Хорошая иллюстрация рабочего процесса при отсутствии методологии разработки и контроля обеспечения качества:

Источник

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

Создателем модели считают Уильяма Ройса. В 1970 году он опубликовал статью, в которой описывал эту модель, несмотря на то, что сам отдавал предпочтение итеративному подходу (англ. iteration — «повторение»). Эта статья и легла в основу концепции.

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

У этой модели есть и другое название — водопад (waterfall). Возможно, это связано со схематичным изображением её стадий:

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

Если вы решили использовать «Водопад» при создании сложной, комплексной системы, то можете неожиданно налететь на подводные камни. Представьте, что только на этапе тестирования обнаруживается логическая ошибка в требованиях. Вернуться к этапу проектирования уже невозможно. Значит, придётся придумывать «костыли» на уровне кода, что, естественно, негативно скажется на качестве и функционале продукта.

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

 

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

 

Agile: принципы и подходы

 

IT-сфера стремительно развивается, всё больше и больше людей занято работой в этом секторе. В связи с чем подходы к моделям и процессам разработки проходят этапы переосмысления и приобретают новые формы. Именно так появилась методология Agile.

В переводе с английского "agile" означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования, именующих себя "AgileAlliance". Они разработали особенный документ — AgileManifesto.

Манифест гибкой разработки программного обеспечения (AgileManifesto) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения.

Текст манифеста доступен более чем на 50 языках (и на русском), включает в себя четыре ценности, двенадцать принципов. С манифестом можно ознакомиться по ссылке .

Сейчас можно смело сказать, что Agile (Agilesoftwaredevelopment) — обобщающий термин для целого ряда подходов и практик, основанных на ценностях «Манифеста гибкой разработки программного обеспечения» и принципах, лежащих в его основе.

В процессе работы и усовершенствования подходов методологии были сформированы и зафиксированы 12 принципов AGILE:

1. Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения.

2. Изменение требований приветствуется даже на поздних стадиях разработки.

3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

7. Работающий продукт — основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.

9. Постоянное внимание к техническому совершенству и к качеству проектирования повышает гибкость проекта.

10. Простота — искусство минимизации лишней работы — крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

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

 

Основные ценности Agile состоят из 12 принципов. Рассмотрим их подробнее.

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

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

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

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

Scrum-разработка

 

Что важно понять?

Scrum как подход подразумевает обязательное наличие трёх компонентов:

1. Scrum-команда с ролями;

2. Набор артефактов;

3. Процессы.

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

Рассмотрим подробнее:

Scrum подразумевает три основные роли в команде:

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

Scrum -мастер — является двигателем и коммуникатором процесса. Осуществляет коммуникацию извне со scrum-командой. Помогает участникам производства выполнять работу, не отвлекаясь на внешние факторы.

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

Большая часть коммуникации команды происходит на встречах. Их можно разделить на четыре вида: планирование, обзор и ретроспектива, ежедневный скрам.

Для наглядности описание каждого мероприятие отображено в таблице:

Название	Длительность	Состав участников	Цель встречи
Планирование спринта	1-2 часа	Вся команда	Назначить приоритеты задачам, Оценить сроки
Обзор спринта	1-2 часа	Вся команда	Демонстрация продукта в текущем состоянии
Ретроспектива	1-2 часа	Вся команда	Обсуждение плюсов и минусов процесса, выявление путей улучшения
Скрам-митинг	15 минут Ежедневный	Scrum-команда	Планирование задач на день, Обсуждение насущных проблем
Спринт	1-2 недели (возможны иные сроки)	Scrum-команда	Собственно разработка

Разработка идет в рамках одного спринта. Его длительность определяется командой, чаще всего это 1-2 недели. Из спринта в спринт мероприятия циклично повторяются.

Задачи в Sсrum-методологии выступают в виде артефактов. Это тот пул работы, который нужно выполнить, чтобы закрыть спринт. Информация о проекте в таком случае прозрачна для всех участников.

Есть три обязательных артефакта:

o ProductBacklog — это список всех элементов продукта, требований к ним и любой связанной с продуктом информации. Бэклог продукта формируется на всем протяжении проекта.

o SprintBacklog — набор элементов бэклога продукта, который команда принимает в разработку на ближайший спринт.

o Инкремент — сумма завершённых элементов бэклога продукта во время текущего и предыдущих спринтов. То есть это текущее состояние разрабатываемого продукта, включая доработки последнего спринта.

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

Подведём итоги

Мы с вами познакомились с мероприятиями, ролями, артефактами Scrum-разработки. Всё это является основой правил работы в процессе, направленном на усиление сотрудничества и выпуска качественного продукта в кратчайшие сроки.

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

 

Теперь рассмотрим прикладную часть вопроса: где и как вести журналы пожеланий проекта (англ. Projectbacklog) и спринта (англ. Sprintbacklog), чтобы все функции были разбиты по задачам, каждая из которых оценивается командой, позволяет поддерживать актуальный статус проекта. Какой сервис (инструмент) лучше использовать для индивидуальной или командной работы на основе Scrum-подхода?

Для примера возьмем процесс написания текста этого юнита.

Этап 3. Определить сущности

Уровень вложенности задачи и тот объем информации, который она несёт, может быть бесконечно большим. Для удобства задачи можно распределять по стадиям жизненного цикла (идея, анализ требований, разработка, проектирование, тестирование...) или по статусам. Вскоре в каждой категории у вас появятся подзадачи или сущности (в логике Trello они называются карточки).

Для нашего примера достаточно двух сущностей:

o Задача — там описано, что нужно сделать.

o Ошибка — содержит комментарии, замечания к частям текста, которые нужно исправить.

Наша доска выглядит следующим образом:

Что мы видим в итоге? Четыре колонки, каждая из которых отвечает за выбранный статус (см. название вверху колонки).

Сущности различаются по цвету: задача — зеленая, ошибка — красная. Наглядное представление помогает понять, какой объем работы еще остался, в каком направлении идёт прогресс, и не переживать о том, что что-либо будет забыто или не вовремя сделано.

В Trello также легко расставляются дедлайны и назначаются ответственные. А если вам не нравятся зеленые листья на фоне, всегда можно изменить картинку.

Составьте расписание занятий (можно вписать тренировки, курсы, дом.дела, дом задания и другое)

Как работать:

1. Зарегистрируйтесь в Trello или YouGile. Если у вас есть аккаунт, то создайте новую доску с названием, явно отражающим суть процесса.

2. Определите статусы. Создайте нужное количество колонок в соответствии со статусами и п. 4, 5.

3. Определите необходимые сущности (карточки). Проанализируйте процесс, с которым будете работать, какие сущности были бы удобны. Не переживайте, если сразу что-то не учли! Мы используем гибкую методологию, и всегда можно что-то добавить/ убрать/изменить.

4. Используйте вашу доску в течение недели, актуализируйте список задач и статусы. Посмотрите, насколько вам это упрощает/усложняет рутинный процесс. Тестируйте и записывайте промежуточные результаты каждый день и финальные результаты в отдельной колонке «Результаты».

5. Пригласите на свою доску сокурсников. Для этого в настройках вашей доски не забудьте разрешить доступ по ссылке и возможность комментирования, если вы работаете в YouGile. Или сделайте вашу доску общедоступной, если вы работаете в Trello. Попросите их оставить комментарии в специально созданной для этого колонке «Комментарии».

 

Каскадная модель жизненного цикла

 

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

Хорошая иллюстрация рабочего процесса при отсутствии методологии разработки и контроля обеспечения качества:

Источник

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

Создателем модели считают Уильяма Ройса. В 1970 году он опубликовал статью, в которой описывал эту модель, несмотря на то, что сам отдавал предпочтение итеративному подходу (англ. iteration — «повторение»). Эта статья и легла в основу концепции.

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

У этой модели есть и другое название — водопад (waterfall). Возможно, это связано со схематичным изображением её стадий:

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

Если вы решили использовать «Водопад» при создании сложной, комплексной системы, то можете неожиданно налететь на подводные камни. Представьте, что только на этапе тестирования обнаруживается логическая ошибка в требованиях. Вернуться к этапу проектирования уже невозможно. Значит, придётся придумывать «костыли» на уровне кода, что, естественно, негативно скажется на качестве и функционале продукта.

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

 

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