|
Если посмотреть на экстремальное программирование с практической точки зрения сквозь призму отечественной высшей школы, то можно смело его охарактеризовать не как методологию, а как систематизированный подход к разработке программного обеспечения. Тем не менее, как бы этот феномен не назывался, важен конечный результат. В данной статье будет рассмотрена практическая применимость экстремального программирования, и чем оно полезно для разработчиков.
Разработчиков и, конечно же, менеджеров всегда интересовали вопросы повышения эффективности работы и минимизации затратной части. Многие находили решения посредством собственного опыта, методом проб и ошибок. Но справедливости ради сказать, решения о которых можно услышать или прочитать в новостных группах, во многом схожи. Так, например, многие опытные менеджеры стараются спрашивать разработчиков, сколько времени займёт та или иная задача, вместо назначения его принудительно. Своё обещание более приятно выполнять, чем чьи-либо указки. В экстремальном программировании это более развито. По словам Кента Бека, основателя экстремального программирования, основная суть подхода заключается в разделении полномочий исполнителя и заказчика. Не смотря на лаконичность, в этих словах заложен высокий смысл. Ведь принятие ответственного решения должно быть возложено на понимающего человека: бизнес решение правильнее может принять заказчик, а, соответственно, техническое разработчик. Такое распределение ролей не обязательно понимать в буквальном смысле, и может быть отнесено к различным уровням отношений. Например, в классическом коллективе разработчиков, заказчиком может быть менеджер, в то время как для компании, внутри которой есть свой отдел разработки программного обеспечения, роль заказчика предельно ясна. Вот мы и подошли к вопросам применимости и применения экстремального программирования на практике. Что же является идеальной моделью работы экстремального программирования? Идеальную модель можно охарактеризовать двумя составляющими: условиями работы и отношениями между членами коллектива. Идеальные условия работы могут быть выражены подразделением разработчиков в рамках фирмы, занимающейся каким-либо бизнесом. Компании для более успешного продвижения бизнеса требуется программный продукт, при этом, некоторая функциональность его должна быть готова к использованию уже в следующем месяце. Менеджерам компании не понятно в деталях как и что будущая программа будет делать, тем не менее, определённое направление ясно и с приоритетами более-менее всё понятно. В этой схеме менеджеры компании являются заказчиками. Разработчики же хорошо знают своё дело, уверены в себе и готовы помочь заказчику. Что же касается идеальных отношений между членами коллектива, то они должны быть максимально открытыми и честными. Каждый вопрос, будь то со стороны разработчика или заказчика, не должен остаться без квалифицированного ответа. При этом, между всеми задействованными лицами должно царить максимальное доверие и понимание. Заказчик обязан доступно излагать свои желания по поводу каждой функциональности программы, и что для него более важно. Разработчик обязан внимательно слушать и оценивать ориентировочную трудоёмкость каждой функциональности, с тем, чтобы заказчик смог выбрать, что должно быть реализовано в первую очередь, а что ему вовсе не нужно за такие деньги. Разработчики не должны подстраивать существующий бизнес под программу, а, наоборот, руководствоваться его потребностями. Так, если возникает какая-либо неоднозначность в понимании задачи, разработчик с тетрадкой и ручкой в руках спешит к заказчику, чтобы услышать его мнение. Заказчик, в свою очередь, при изменении бизнеса или при лучшем понимании своих интересов относительно программы, просто обязан проинформировать об этом группу разработчиков, чтобы те своевременно смогли внести изменения в программу или подкорректировать план работ. Разработчики приветствуют изменения, так как только они способны максимально приблизить продукт к реальным потребностям заказчика на момент выпуска. Разработчики должны избавить заказчика от ошибок в программе, и предоставлять ему всегда проверенную и работоспособную систему. К сожалению, эта идеальная модель, как и любая другая, является упрощением реальной ситуации, и очень редко в чистом виде встречается на практике. По-этому в экстремальное программирование включены дополнительные методики, компенсирующие расхождения модели и реальности. Начнём с доверия. Людям свойственно ошибаться, это касается как разработчиков (недопонимания, ошибки в программе), так и заказчиков (неясность потребностей). Если заказчик со своими неясными требованиями, как слишком распространённый вариант, заложен в саму модель, то решение предотвращения ошибок нельзя обеспечить лишь социальными средствами. В экстремальном программировании применяются два круга автоматизированного тестирования. На первом уровне стоит модульное тестирование, для проверки работоспособности самого кода, а на втором приёмочное, для проверки работоспособности законченной функциональности с точки зрения заказчика. Эти методики развиты в более прогрессивные путём перестановки классической последовательности: теперь сначала идёт тест, а потом код. Это позволяет лучше понять задачу и предоставить дополнительную мотивацию создания тестов. Тесты являются хорошо сформулированным вопросом к программисту о том, что должно быть сделано и каковы критерии работоспособности. А как всем известно, правильно сформулированный вопрос может быть расценен как большая часть ответа. Для улучшения понимания потребностей заказчиком, новые версии строятся часто, и у него есть возможность попробовать, что удобно, а что нет. Эта методика получила название быстрые релизы. Далеко не всё в проекте определяют профессиональные навыки разработчиков. Очень большое значение имеет постоянный обмен информацией между членами коллектива. Это и вопросы к заказчику, и просьба о помощи у человека, который ранее разбирался с интересующей проблемой, и, конечно же, постоянная передача опыта и знаний между разработчиками. Всё это можно достичь интенсивным документооборотом, а можно открытым и честным общением. Экстремальное программирование выбирает второй путь, как наиболее простой и эффективный. Как правило, следование канонам любой методологии и выполнение её предписаний в обычных условиях длиться очень недолго. Лень и игнорирование методик приводит к скатыванию проекта на низшую ступень развития. Это ни может не отразится на качестве, скорости и успешности разработки. В экстремальном программировании есть ключик к такой проблеме – парное программирование. Два человека, работая совместно, значительно трепетнее относятся к использованию методик и выполнению требований стандартов кодирования. Эта методика способна стимулировать общение и позволить сосредоточиться на конкретных задачах двум умам одновременно. Очень часто можно услышать о текучести кадров в фирмах, занимающихся разработкой программного обеспечения. Это обусловлено целым рядом причин, выходящих за рамки данной статьи. Но избежать плачевных последствий ухода людей можно, если вовремя подготовить замену. На сегодняшний день это единственная возможность поддержать проект. В этом направлении экстремальное программирование и рекомендует двигаться. Программирование не было бы экстремальным, если бы не элементы экстрима: замена должна готовиться постоянно. Методики есть, это парное программирование и коллективное владение кодом. Что такое парное программирование в общих чертах понятно, а вот коллективное владение кодом чем-то напоминает распространение программ с открытым кодом: желающие могут добраться до интересующего кода, даже чужого, и внести соответствующие изменения. Эта, на первый взгляд, пугающая методика, при правильной подготовке и использовании, способна дать свободу и независимость от других членов команды, а также позволяет практически вникнуть в код других разработчиков. Правильность использования заключается лишь в выполнении других методик: постоянного общения, наличия модульных тестов и следование стандартам кодирования. Здесь перечислена далеко не вся мощь экстремального программирования, а затронуты лишь наиболее наболевшие вопросы. Таким образом, хоть экстремальное программирование, по мнению многих критиков, и не методология, а набор методик, оно позволяет вести разработку программных продуктов быстро, вовремя вносить изменения и поддерживать должный уровень качества. Последнее не требует, в большинстве случаев, ненужных затрат на отделы тестирования и оценки качества. Тестирование включено в саму разработку, более того, разработка тестов предшествует разработке кода. |