Экстремальное программирование (eXtreme Programming или XP)
Методология XP является наиболее известной из гибких методологий. Основными принципами методологии являются: простота решений, интенсивная разработка малыми группами (до 10 человек), активное общение в группе и между группами, заказчик включен в процесс разработки, достаточная степень смелости и желание идти на риск. Разработка ПО при использовании данной методологии производится небольшими итерациями (от недели до месяца) при использовании парного программирования (два программиста вместе создают код на одном общем рабочем месте). Важной особенностью методологии является принятие первого наипростейшего рабочего решения. Это связано с высокой степенью риска, обусловленного поверхностностью анализа и жестким временным графиком, при этом реализуются минимальный набор функций системы, а дальнейшая функциональность расширяется с каждой итерацией.
При использовании XP тщательное предварительное проектирование ПО заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой стороны, регулярными переработками кода. Основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода.
|
|
|
Семейство методологий Crystal.
Crystal - это не просто методология, это целое семейство методологий, разработанное Алистером Коберном.
Коберн рассматривает процесс создания ПО как конечную целенаправленную игру и утверждает, что у этой игры есть всего две цели: главная и вспомогательная. Главная цель заключается в том, чтобы успешно закончить проект, то есть создать работающий продукт. Второстепенная цель - подготовиться к следующей игре. Для достижения этой цели может понадобиться документация, качественное написание кода, то есть все, что облегчает дальнейшее развитие и поддержку продукта.
Если в процессе разработки достигнуты обе цели, то проект считается успешным. Помимо конечного продукта, всегда создаются вспомогательные промежуточные продукты: модели, схемы, описания и т.п. Их должно быть ровно столько, сколько необходимо для достижения конечной цели. Проблема состоит в том, что очень сложно заранее предсказать, какие промежуточные продукты нужны, а какие - нет.
Коберн классифицирует проекты по двум параметрам: критичность и величина команды. Под критичностью понимается величина ущерба, нанесенного в результате использования продукта. Например, ошибка в ПО для космического корабля или для аппарата искусственного дыхания несравнима с ошибкой в ПО для форума на сайте. Жизненно важные проекты имеют категорию L, а те, ошибка в которых обозначает потерю удобств, категорию С.
|
|
|
Степень важности нарастает по вертикальной оси. Величина команды нарастает по горизонтальной оси. В результате получается семейство методологий. Чем ниже критичность и чем меньше команда, тем более "легкую" методологию нужно использовать. Самой легкой из всего семейства является методология Crystal Clear. Главные принципы данной методологии:
Вся команда разработчиков (до 6 человек) находится в одном помещении. Это позволяет сократить временные затраты на коммуникацию.
Частые поставки продукта позволяют выработать "ритм" проекта. Ничто так не вдохновляет команду, как поставленный вовремя продукт.
Обмен информацией с реальными пользователями позволяет быстро получать обратную связь и ликвидировать недостатки на ранних стадиях.
Средства контроля версий кода обеспечивают коллективное владение кодом.
|
|
|
Семейство методологий Crystal построено на итеративной разработке. Продолжительность итерации может изменяться в предела от 1 до 4 месяцев. Чем меньше итерация, тем лучше.
Важной особенностью Crystal является непрерывная настройка методологии. Это позволяет постепенно адаптировать ее для конкретной команды и конкретного проекта. Пожалуй, ни в одной другой методологии настройке не уделяется такого внимания.
После каждой итерации команда собирается вместе и обсуждает необходимость промежуточных продуктов, имеющиеся недостатки и т.п. В результате принимается решение о том, что может помочь исправить недостатки, а затем, с согласия разработчиков, начинается корректировка.
Дата добавления: 2018-02-15; просмотров: 998; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!