Страница 1 из 19 За последние несколько лет сильно вырос интерес к так называемым гибким методологиям разработки программного обеспечения (известным также под названием "облегченных методологий"). В данной статье приводятся их основные характеристики, причем главное внимание уделяется не "весу", а адаптивной сущности этих методологий и их ориентации на человека. Кроме того, здесь же дан краткий обзор существующих на данный момент методологий подобного типа и указаны факторы, которые помогут вам решить, стоит или не стоит идти этим непроторенным путем.
От полного отсутствия - к монументальности, от монументальности - к гибкости Как правило, разработка программного обеспечения представляет собой довольно хаотическую деятельность, которую нередко можно охарактеризовать фразой "code and fix" ("пишем и правим"). Единого плана не существует, а общий проект представляет собой просто смесь краткосрочных решений. Такой подход может сгодиться для создания небольшой системы, однако если система начинает расти, добавлять в нее новые свойства становится все более затруднительно. Кроме того, в ней будет появляться все больше ошибок, которые будет все труднее исправлять. Типичные признаки такой системы - долгий тестовый период уже после того, как разработка всей функциональности системы закончена. При этом нарушаются все планы выпуска программы, так как при подобном тестировании и исправлении ошибок адекватное планирование просто невозможно. Именно так мы и работали довольно продолжительное время. Впрочем, у нас всегда была альтернатива - использовать методологию. Методология превращает создание программного продукта в упорядоченный процесс, с помощью которого можно сделать работу программиста более прогнозируемой и эффективной. Для этого создается детальное описание процесса создания системы, особое место в котором занимает планирование (аналогично другим инженерным дисциплинам). Такие методологии существуют уже давно. Нельзя сказать, что они очень уж эффективны. С еще меньшей степенью уверенности можно говорить об их популярности. Чаще всего их обвиняют в бюрократизме - чтобы следовать такой методологии, нужно выполнять так много различных предписаний, что замедляется весь темп работ. Именно поэтому их называют тяжеловесными методологиями, или, согласно термину Джима Хайсмита ( Jim Highsmith ), - монументальными. За последние годы в противовес этим методологиям появилась группа новых, которые раньше было принято называть облегченными (lightweight). Теперь для них используют другой термин - гибкие (agile) методологии. Привлекательность новых методологий для многих заключается в отсутствии бюрократизма, присущего монументальным методологиям. Новые методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу. По сравнению с монументальными методологиями, в гибких смещены все основные акценты. Самое очевидное различие - меньшая ориентация на документацию, что выражается в меньшем ее объеме для каждой конкретной задачи. Правильнее в данном случае будет говорить об ориентированности на код, то есть основная предпосылка состоит в том, что ключевая часть документации - это исходный код. Впрочем, я думаю, что не это является главным отличием гибких методологий от монументальных. Отсутствие документации - это следствие куда более существенных различий: - Гибкие методологии адаптивны, а не предсказуемы. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, и такой подход работает - однако до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих.
- Гибкие методологии ориентированы на человека, а не на процесс. В них ясно заявлено о необходимости учитывать в работе природные качества человеческой натуры, а не действовать им наперекор. Кроме этого в гибких методологиях особо подчеркивается, что работа по созданию программных продуктов должна приносить удовольствие.
В последующих разделах я рассмотрю эти различия более подробно, чтобы вы ясно понимали, что имеется в виду под понятиями "адаптивный" и "ориентированный на человека" процесс, в чем его преимущества и недостатки, и стоит ли вам использовать его в своей работе - и как разработчику программных продуктов, и как заказчику. |