Используемые в таких случаях методологии получили название экстремальных. Они представляют собой наборы рекомендаций, которые по отдельности нередко выглядят противоречащими здравому смыслу и классическим схемам (отсюда и название — экстремальные методологии, ЭМ). Самое интересное, что, будучи собраны в правильной комбинации, такие рекомендации превращаются в эффективно работающий инструмент.
ЭМ нацелены на скорейшее получение конкретного результата, удовлетворение главных требований пользователя и более медленную доработку системы в соответствии с дополнительными пожеланиями. При этом требования, как уже говорилось, могут меняться весьма значительно (поэтому длительность каждой итерации коротка, чаще всего неделя). Направление развития системы рассматривается прежде всего с точки зрения потенциальных рисков (сложные или сомнительные, если говорить о прикладной полезности, фунциональные возможности откладываются; учитывается близость конечного срока и объемы оставшихся бюджетных средств).
ЭМ будут работать только при наличии высокопроизводительной команды, в которой отлажен механизм взаимодействия, а каждый сотрудник способен переключаться на разные виды работ. Разработка ПО — это прежде всего организация сотрудничества между людьми и только потом — применение Java или Си++, считает Пауль Аллен, эксперт консорциума Cutter, возглавляемого Эдом Йордоном.
Экстремальное программирование
Познакомимся с одной из наиболее популярных ЭМ — экстремальным программированием (ЭП, Extreme Programming; http://www.xprogramming.com/). Эта легкая методология была придумана Кентом Бэком (Kent Beck), одним из активных участников проекта по развитию языка SmallTalk, и изложена им в книге “Extreme Programming Explained”. Бэк использовал для создания ЭП достаточно простой подход — брал различные методологические элементы и, если они выглядели (по его мнению) простыми и полезными, обобщал на весь проект или применял в рамках очень коротких циклов.
Например, в классических методиках считается, что тестирование — это хорошо, и Бэк решил тестировать все что можно, и при этом непрерывно. Если полезно проектирование системы, значит, анализ и синтез структуры продукта будут выполняться ежедневно. Если важна простота при построении системы, то целью разработки ставится скорейшее создание реально работающей системы, реализующей минимум самой главной функциональности. Если эффективны комплексные сборки (что позволяет выявить проблемы с нестыковкой нескольких модулей) и интеграционное тестирование, значит, они будут выполняться несколько раз в день. Наконец, если хорошо работают короткие итерационные циклы “анализ — проектирование — разработка — тестирование”, значит, их продолжительность будет составлять не недели и месяцы, а часы или минуты. Полезно документирование? Вся документация включается в код и представляет собой списки связанных с требованиями заказчика правил, принципов, пожеланий и уточнений.
Версия для печати
предыдущая
