Адаптивная разработка программного обеспечения - практики

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

Жизненный цикл адаптивной разработки программного обеспечения посвящен -

• Непрерывное обучение
• Изменить ориентацию
• Re-evaluation
• Вглядываясь в неопределенное будущее
• Интенсивное сотрудничество между разработчиками, руководством и клиентами

Адаптивный SDLC

Адаптивная разработка программного обеспечения сочетает в себе RAD с передовыми методами разработки программного обеспечения, такими как:

• Запуск проекта.
• Адаптивное планирование цикла.
• Параллельная разработка компонентов.
• Проверка качества.
• Окончательный контроль качества и выпуск.

Практики адаптивной разработки программного обеспечения можно проиллюстрировать следующим образом:

Как показано выше, методы адаптивной разработки программного обеспечения разбиты на три этапа следующим образом:

• Спекулировать - Инициирование и планирование

  • Инициирование проекта

  • Установление временных рамок для всего проекта

  • Определитесь с количеством итераций и назначьте для каждой временной интервал.

  • Разработайте тему или цель для каждой итерации

  • Назначьте функции каждой итерации

• Collaborate - Параллельная разработка функций

  • Сотрудничество для распределенных команд

  • Сотрудничество для небольших проектов

  • Сотрудничество для больших проектов

• Learn - Обзор качества

  • Качество результата с точки зрения клиента

  • Качество результата с технической точки зрения

  • Функционирование группы доставки и ее участники используют

  • Статус проекта

Спекулировать - Инициирование и планирование

В адаптивной разработке программного обеспечения фаза размышлений включает два действия:

• Initiation
• Planning

В Speculate есть пять практик, которые можно многократно выполнять на этапах инициации и планирования. Они -

• Инициирование проекта
• Установление временных рамок для всего проекта
• Определитесь с количеством итераций и назначьте для каждой временной интервал.
• Разработайте тему или цель для каждой итерации
• Назначьте функции каждой итерации

Инициирование проекта

Инициирование проекта включает -

• Определение миссии и целей проекта
• Понимание ограничений
• Создание проектной организации
• Выявление и описание требований
• Выполнение первоначальных оценок размера и объема
• Выявление ключевых рисков проекта

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

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

Установление временных рамок для всего проекта

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

Как вы знаете, «Спекуляция» не отказывается от оценок, это просто означает признание того, что оценки могут ошибаться.

Итерации и тайм-бокс

Определитесь с количеством итераций и продолжительностью отдельных итераций в зависимости от общего объема проекта и степени неопределенности.

Для приложений малого и среднего размера -

• Продолжительность итераций обычно составляет от четырех до восьми недель.
• Некоторые проекты лучше всего работают с двухнедельными итерациями.
• Для некоторых проектов может потребоваться более восьми недель.

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

Разработайте тему или цель

Члены команды должны разработать тему или цель для каждой итерации. Это что-то похожее на цель спринта в Scrum. Каждая итерация должна предоставлять набор функций, которые могут продемонстрировать функциональность продукта, делая продукт видимым для покупателя, чтобы обеспечить возможность обзора и обратной связи.

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

Назначить функции

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

Во время присвоения функций итерациям -

• Команда разработчиков должна предложить оценки функций, рисков и зависимостей и предоставить их заказчику.

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

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

Совместная работа ─ Параллельная разработка функций

На этапе совместной работы основное внимание уделяется разработке. Этап совместной работы включает два действия:

• Команда разработчиков сотрудничает и поставляет работающее программное обеспечение.

• Руководители проектов способствуют сотрудничеству и параллельной разработке.

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

Команды должны сотрудничать:

• Технические проблемы
• Бизнес-требования
• Быстрое принятие решения

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

• Сотрудничество для распределенных команд
• Сотрудничество для небольших проектов
• Сотрудничество для больших проектов

Сотрудничество для распределенных команд

В проектах с участием распределенных команд следует учитывать следующее:

• Различные партнеры по альянсу
• Широкие знания
• Как люди взаимодействуют
• Как они управляют взаимозависимостями

Сотрудничество для небольших проектов

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

Сотрудничество для более крупных проектов

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

Учитесь - проверка качества

Адаптивная разработка программного обеспечения поощряет концепцию «экспериментируй и учись».

Чтобы учиться на ошибках и экспериментировать, необходимо, чтобы члены команды заранее обменивались частично завершенным кодом и артефактами, чтобы:

• Найдите ошибки
• Учитесь у них
• Сократите переделки, найдя мелкие проблемы до того, как они станут большими

В конце каждой итерации разработки есть четыре общие категории вещей, которые нужно изучить:

• Качество результата с точки зрения клиента
• Качество результата с технической точки зрения
• Функционирование группы доставки и группы практик
• Статус проекта

Качество результата с точки зрения клиента

В проектах адаптивной разработки программного обеспечения получение обратной связи от клиентов является первым приоритетом. Рекомендуемая практика для этого - фокус-группа на потребителе. Эти сеансы предназначены для изучения рабочей модели приложения и записи запросов клиентов на изменение.

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

Качество результата с технической точки зрения

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

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

Ретроспективы итераций облегчают периодическую самооценку работы команды, например:

• Определите, что не работает.
• Что команде нужно делать больше.
• Что Команде нужно делать меньше.

Статус проекта

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

Обзор статуса проекта должен включать:

• Где проект?
• Где проект по сравнению с планами?
• Где должен быть проект?

Поскольку планы в проектах адаптивной разработки программного обеспечения являются спекулятивными, важнее, чем вопрос 2 выше, вопрос 3. То есть, проектная группа и заказчики должны постоянно спрашивать себя: «Что мы узнали на данный момент, и меняет ли это наше видение того, куда нам нужно двигаться?»