Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие
жүктеу/скачать 2,75 Mb. Pdf көрінісі
|
разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте содержит несколько стадий (рис. 3.5): 1. Определение объемов работ. 2. Каждый день проводятся 15-минутные встречи, для того, чтобы каждый член команды мог скорректировать свою работу и подвести итоги на данный промежуток времени. 3. Демонстрация полученных результатов. Обсуждение спринтов нужно для поиска удачных и неудачных решений и действий. 50 Чаще всего Scrum используется в работе со сложным программным обеспечением и для разработки продукта с использованием инкрементных и итеративных методов. С помощью этого серьезно повышается производительность команды и сокращаются временные затраты на достижение цели. Scrum улучшает результаты, помогает адаптировать проект к изменениям, обеспечивает более точную оценку при меньших трудозатратах на анализ и позволяет эффективнее контролировать этапы работы и сценарий проекта. Рис. 3.5 – Разработка с использованием метода Scrum 51 3.7 Методология XP Рис. 3.6 – Методология XP Экстремальное программирование (XP) — одна из гибких методологий разработки программного обеспечения. Суть методологии - возможность вести разработку в условиях постоянно меняющихся требований (рис. 3.6). Основные признаки XP: 1. Игра в планирование Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта. Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части. |