Практики адаптивной разработки программного обеспечения основаны на вере в непрерывную адаптацию, жизненный цикл которой позволяет принимать постоянные изменения в качестве нормы.
Жизненный цикл разработки адаптивного программного обеспечения посвящен —
- Непрерывное обучение
- Изменить ориентацию
- Переоценка
- Вглядываясь в неопределенное будущее
- Интенсивное сотрудничество между разработчиками, руководством и клиентами
Адаптивный SDLC
Адаптивная разработка программного обеспечения объединяет RAD с передовой практикой разработки программного обеспечения, например:
- Инициирование проекта.
- Адаптивное планирование цикла.
- Совместное проектирование компонентов.
- Обзор качества.
- Окончательный контроль качества и выпуск.
Практика разработки адаптивного программного обеспечения может быть проиллюстрирована следующим образом:
Как показано выше, практика разработки адаптивного программного обеспечения распространяется на три этапа следующим образом:
-
Спекулировать — Инициирование и планирование
-
Инициирование проекта
-
Установление времени для всего проекта
-
Определите количество итераций и назначьте временные рамки для каждой
-
Разработайте тему или цель для каждой итерации
-
Назначить функции для каждой итерации
-
-
Совместная работа — разработка параллельных функций
-
Сотрудничество для распределенных команд
-
Сотрудничество для небольших проектов
-
Сотрудничество для более крупных проектов
-
-
Learn — Обзор качества
-
Качество результата с точки зрения клиента
-
Качество результата с технической точки зрения
-
Функционирование команды доставки и членов команды практики используют
-
Статус проекта
-
Спекулировать — Инициирование и планирование
Инициирование проекта
Установление времени для всего проекта
Определите количество итераций и назначьте временные рамки для каждой
Разработайте тему или цель для каждой итерации
Назначить функции для каждой итерации
Совместная работа — разработка параллельных функций
Сотрудничество для распределенных команд
Сотрудничество для небольших проектов
Сотрудничество для более крупных проектов
Learn — Обзор качества
Качество результата с точки зрения клиента
Качество результата с технической точки зрения
Функционирование команды доставки и членов команды практики используют
Статус проекта
Спекулировать — Инициирование и Планирование
В разработке адаптивного программного обеспечения фаза спекуляций состоит из двух действий:
- инициирование
- планирование
В Speculate есть пять практик, которые можно выполнять многократно на этапе инициации и планирования. Они —
- Инициирование проекта
- Установление времени для всего проекта
- Определите количество итераций и назначьте временные рамки для каждой
- Разработайте тему или цель для каждой итерации
- Назначить функции для каждой итерации
Инициирование проекта
Инициирование проекта включает в себя —
- Установление миссии и целей проекта
- Понимание ограничений
- Создание проектной организации
- Выявление и определение требований
- Создание начального размера и оценки объема
- Определение ключевых рисков проекта
Данные о начале проекта должны быть собраны на предварительной сессии JAD, учитывая скорость как основной аспект. Инициирование может быть завершено в течение двух-пяти дней для небольших и средних проектов или двух-трех недель для больших проектов.
Во время сеансов JAD требования собираются достаточно подробно, чтобы идентифицировать функции и создать обзор объекта, данных или другой архитектурной модели.
Установление времени для всего проекта
Временной интервал для всего проекта должен быть установлен на основе объема, требований к набору функций, оценок и доступности ресурсов, которые являются результатом работы по инициации проекта.
Как вы знаете, спекуляция не отменяет оценки, а просто означает, что оценки могут пойти не так.
Итерации и время
Определите количество итераций и длительности отдельных итераций на основе общего объема проекта и степени неопределенности.
Для малых и средних приложений —
- Итерации обычно варьируются от четырех до восьми недель.
- Некоторые проекты лучше всего работают с двухнедельными итерациями.
- Некоторые проекты могут потребовать более восьми недель.
Выберите время, исходя из того, что работает для вас. Как только вы определитесь с количеством итераций и продолжительностью каждой из итераций, назначьте расписание для каждой из итераций.
Разработать тему или цель
Члены команды должны разработать тему или цель для каждой итерации. Это что-то похожее на Спринт в Scrum. Каждая итерация должна предоставлять набор функций, которые могут демонстрировать функциональность продукта, делая продукт видимым для клиента, чтобы обеспечить возможность просмотра и обратной связи.
В рамках итераций сборки должны предоставлять рабочие функции предпочтительно ежедневно, обеспечивая процесс интеграции и делая продукт видимым для команды разработчиков. Тестирование должно быть непрерывной, неотъемлемой частью разработки функции. Это не должно быть отложено до конца проекта.
Назначить функции
Разработчики и клиенты должны совместно назначать функции для каждой итерации. Наиболее важным критерием для этого назначения функции является то, что каждая итерация должна предоставлять видимый набор функций со значительной функциональностью для клиента.
Во время назначения функций для итераций —
-
Команда разработчиков должна придумать оценки возможностей, риски и зависимости и предоставить их заказчику.
-
Клиенты должны определить приоритетность функций, используя информацию, предоставленную командой разработчиков.
Команда разработчиков должна придумать оценки возможностей, риски и зависимости и предоставить их заказчику.
Клиенты должны определить приоритетность функций, используя информацию, предоставленную командой разработчиков.
Таким образом, планирование итераций основано на функциях и выполняется в команде с разработчиками и заказчиками. Опыт показывает, что этот тип планирования обеспечивает лучшее понимание проекта, чем планирование, основанное на задачах, руководителем проекта. Кроме того, функционально-ориентированное планирование отражает уникальность каждого проекта.
Сотрудничество ─ Параллельная разработка функций
На этапе совместной работы основное внимание уделяется разработке. Этап сотрудничества состоит из двух мероприятий —
-
Команда разработчиков сотрудничает и поставляет работающее программное обеспечение.
-
Менеджеры проектов облегчают сотрудничество и параллельную деятельность по развитию.
Команда разработчиков сотрудничает и поставляет работающее программное обеспечение.
Менеджеры проектов облегчают сотрудничество и параллельную деятельность по развитию.
Совместная работа — это процесс совместного создания, охватывающий команду разработчиков, заказчиков и менеджеров. Совместное творчество поощряется доверием и уважением.
Команды должны сотрудничать по —
- Технические проблемы
- Бизнес-требования
- Быстрое принятие решений
Ниже приведены методы, относящиеся к фазе совместной работы в разработке адаптивного программного обеспечения.
- Сотрудничество для распределенных команд
- Сотрудничество для небольших проектов
- Сотрудничество для более крупных проектов
Сотрудничество для распределенных команд
В проектах с участием распределенных групп следует учитывать следующее:
- Различные партнеры по альянсу
- Широкие знания
- Как люди взаимодействуют
- Как они управляют взаимозависимостями
Сотрудничество для небольших проектов
В небольших проектах, когда члены команды работают в непосредственной близости, следует поощрять сотрудничество с неформальными чатами в коридоре и писаниной доски, поскольку это считается эффективным.
Сотрудничество для крупных проектов
Крупные проекты требуют дополнительных практик, инструментов для совместной работы и взаимодействия менеджера проектов и должны быть организованы на контекстной основе.
Learn — Обзор качества
Адаптивная разработка программного обеспечения поощряет концепцию «Экспериментируй и учись».
Чтобы учиться на ошибках и экспериментировать, необходимо, чтобы члены команды заблаговременно обменивались частично завершенным кодом и артефактами, чтобы —
- Найти ошибки
- Учитесь у них
- Сократите переделки, обнаружив небольшие проблемы, прежде чем они станут большими
В конце каждой итерации разработки нужно изучить четыре основные категории:
- Качество результата с точки зрения клиента
- Качество результата с технической точки зрения
- Функционирование команды доставки и команды практики
- Статус проекта
Качество результата с точки зрения клиента
В проектах по разработке адаптивного программного обеспечения первоочередной задачей является получение отзывов от клиентов. Рекомендуемая практика для этого — фокус-группа для клиентов. Эти сеансы предназначены для изучения рабочей модели приложения и записи запросов клиентов на изменение.
Сессии в фокус-группах для клиентов — это облегченные сеансы, аналогичные сеансам jad, но вместо того, чтобы генерировать требования или определять планы проекта, они предназначены для анализа самого приложения. Клиенты предоставляют отзывы о рабочем программном обеспечении в результате итерации.
Качество результата с технической точки зрения
В проектах адаптивной разработки программного обеспечения следует уделять особое внимание периодическому анализу технических артефактов. Проверка кода должна проводиться на постоянной основе. Обзоры других технических артефактов, таких как техническая архитектура, могут проводиться еженедельно или в конце итерации.
В проектах по разработке адаптивного программного обеспечения команда должна периодически отслеживать собственную производительность. Ретроспективы побуждают команды узнавать о себе и своей работе вместе как о команде.
Ретроспективы конца итерации способствуют периодическому самопроверке работы команды, такой как —
- Определите, что не работает.
- Что команда должна сделать больше.
- Что команда должна делать меньше.
Статус проекта
Обзор состояния проекта помогает в планировании дальнейшей работы. В проектах разработки адаптивного программного обеспечения определение статуса проекта основано на функциональном подходе, и конец каждой итерации отмечен завершенными функциями, приводящими к работающему программному обеспечению.
Обзор статуса проекта должен включать —
- Где находится проект?
- Где проект против планов?
- Где должен быть проект?
Поскольку планы в проектах по разработке адаптивного программного обеспечения носят умозрительный характер, больше, чем вопрос 2 выше, вопрос 3 является важным. То есть команда проекта и клиенты должны постоянно задавать себе вопрос: «Чему мы научились до сих пор, и меняет ли это наш взгляд на то, куда нам нужно идти?»