Урок 2. Жизненный цикл разработки программного обеспечения

Жизненный цикл

— этапы развития системы или продукта начиная от

создания и заканчивая выводом из эксплуатации.

Он состоит из следующих стадий:

Замысел и планирование
Анализ требований и постановка задач
Проектирование
Создание
Развёртывание и внедрение
Использование
Поддержка
Модернизация
Вывод из работы

Аналитик обычно активно участвует на первых четырёх, а дальше консультирует команду.

Методологии разработки

Agile - гибкая методология.

Фреймворки:

● Scrum

● Kanban

● Lean

и другие

Waterfall - каскадная модель

Waterfall. Этапы

Waterfall. Принципы

- Документы и инструкции — это важно, всё должно быть зафиксировано.

- Нет итераций, есть один общий процесс создания продукта.

- Следующий этап работы не начинается, пока не закончится предыдущий.

- Пропускать этапы нельзя.

- Если требования к продукту изменились после согласования — переписываем ТЗ.

- Нельзя возвращаться на предыдущий этап, чтобы что-то изменить.

- Выявлять и исправлять ошибки — только на этапе тестирования.

- Клиент не участвует в создании продукта после постановки до момента приемки

Waterfall. Плюсы

+ понятная структура процесса разработки: легче распределять задачи

по отделам и сотрудникам

+ стабильность за счет того, что задачи не терпят изменений. Ложка дегтя для этого +: пишется большое количество документации (это входит в задачи СА), которая не используется потом

+ понятная система отчетности

+ легче планировать, просчитывать бюджет и требуемые ресурсы, сроки

Waterfall. Минусы

- отсутствие гибкости и как следствие:

- невозможность оперативно реагировать на изменения: как внешние, так и внутренние для команды и компании

- проект может уйти в минус, если не все риски были учтены (а это невозможно)

- формально сроки должны быть зафиксированы, но по факту они редко “угадываются”

- заказчик не участвует в проекте с момента согласований требований до момента приемки, он мало вовлечен. Минусы довольно существенные для настоящего времени. И если что-то было не продумано вначале, то высок риск иметь проблемы при тестировании и приемке

Waterfall. As is (какой он?)

Каскадную модель применяют и в наше время. Чаще всего - в госсекторе, а также на проектах, где изначальный список требований хорошо известен и вероятность их изменений мала. Если требования все таки не известны полностью на 100%, но разработка идет по Waterfall, то:

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

Waterfall. Итоги

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

Agile. Гибкая методология разработки

Agile - гибкая методология.

Scrum - лишь наиболее популярный фреймворк.

Kanban - еще один популярный фреймворк.

Основная цель гибкой методологий: уметь эффективно реагировать на изменения требований.

Основные идеи:

- люди и взаимодействие важнее процессов и инструментов;

- работающий продукт важнее исчерпывающей документации;

- сотрудничество с заказчиком важнее согласования условий

контракта;

- готовность к изменениям важнее следования первоначальному

плану.

Принципы изложены в манифесте - Agile-манифест разработки программного обеспечения

Scrum. Кто участвует в работе над продуктом

- Владелец продукта

- Скрам-мастер. Может быть отдельным человеком или ролью

- Команды. А в команде: разработчики, дизайнеры, специалисты по тестированию, системные аналитики и т.д. Суть в том, что состав команды должен позволять выполнять задачи полностью

- Архитектор

- Сотрудники СБ

- DevOps

- Эксперты из других отделов (бизнес-юнит, маркетинг и т.д.)

Scrum. Спринт

Стандартно спринт длится 1-2 недели.

От спринта к спринту его длина не меняется и не зависит от трудоемкости задач

Scrum. Cпринт

Цели команды на спринт:

- выполнить DoD по текущей задаче:

- выполнить требования, описанные в задаче

- провести тестирование:

- модульное (юнит-тесты)
- регрессионное
- интеграционное
- нагрузочное
- юзабилити-тестирование (для задач интерфейса)

- доставить код. Команда доставляет код на тестовой среде, до прода - уже сопровождение

+ бонус для аналитика: довести задачи следующего спринта до состояния DoR

Kanban

● Основная цель - сократить количество незавершенной работы (WiP)

● Спринтов нет

● Отдельной роли kanban-мастера нет

● Изменениям в любой момент - welcome (канонически Scrum не принимает изменения к задачам в работе во время спринта)

● Поставка кода - непрерывно (CI/CD - continuous integration/continuous deployment)

Kanban-доска. Пример

● Столбцы для перемещения задач могут быть и иными. Какими - решает команда

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

● Условия перехода задачи из одного столбца в другой оговариваются заранее при оформлении доски.

Пример: Дизайн можно считать завершенным, если макеты одобрил стеклхолдер

● Хозяева доски - команда

Мероприятия в Kanban

● Канбан-митинг (ежедневная). Здесь обсуждаем статус заблокированных задач

● Встреча по наполнению очереди (обычно раз в две недели). Берем на себя обязательства, что будет делать, как сервис

● Встреча по планированию поставки (обычно раз в две недели). Возвращаем выполненные обязательства обратно

● Встреча по обзору сервиса (обычно раз в две недели). С метриками обсуждаем качество сервиса и как его улучшить, если нужно

● Операционная встреча (обычно раз в месяц). С метриками обсуждаем качество взаимодействия связанных сервисов

● Встреча по обзору рисков (обычно раз в месяц). С метрикам обсуждаем влияние заблокированных задач на работу сервиса

● Встреча по обзору стратегии (обычно раз в квартал). С метриками обсуждаем изменения в стратегии

Доставка кода. CI/CD/CDP

CI/CD/CDP (непрерывная интерграция и непрервыная поставка) - это по сути практика автоматизации развертывания кода (включая тестирование).

Упрощает доставку изменений, позволяет не дожидаться “крупных” сборок для выкладки.

Для каждого этапа доставки определено, “к кому обращаться” в случае проблем.

Видео по CICD (практику можно не повторять, но если очень хочется то можно =) ) - https://blog.aqa-pro.tech/10-cicd

Agile. Плюсы

+ полезность продукта пользователю - на 1ом месте

+ лояльность к изменениям (обеспечивается в том числе и короткими итерациями)

+ быстрая доставка продукта пользователю

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

+ взаимозаменяемость участников команды

+ горизонтальная структура: позволяет участникам иметь полное представление о процессах разработки продукта

+ минимализация рисков

Agile. Минусы

- слишком частые изменения могут задерживать продукт в развитии

- больше времени на коммуникации внутри рабочей группы чем в каскадной модели

- плавающая стоимость проекта

Agile. Итоги

- У гибкой методологии есть масса плюсов, позволяющая быстро реагировать на изменения рынка и фидбэк пользователей

- При этом методологии имеют и явные недостатки, которых лишен Waterfall

Реалии. Waterfall+Agile

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

Поэтому зачастую применяется комбинация методологий

Что взяли от Waterfall:

- Для каждого проекта определено заранее, что именно будет являться его результатом

- Интеграция происходит по оговоренному изначально сценарию

- У каждого проекта есть четкие сроки завершения этапов

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

Что взяли от Agile:

- Agile-подход в работе по задачам внутри проекта перенимает все плюсы гибкой методологии

Реалии. Важный итог

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

Методология - лишь инструмент, и должна помогать вести разработку.

Нет хорошей или плохой методологии. Каждая применяется исходя из нужд и потребностей проекта в момент времени. При изменении потребностей проекта может меняться и выбор методологии.