Computerworld, США
Противоречит ли парадигма скорой разработки использованию услуг офшорных компаний?
В мире программного обеспечения набирает популярность новая тенденция. Апологеты методологии скорой (agile) разработки утверждают, что она может настолько повысить производительность кодирования в некоторых областях, что у программистов непременно наступит головокружение от успехов.
Методология скорой разработки призывает программистов начинать работу не с детализированного набора требований, а с написания небольших функциональных частей, которые можно завершить в течение двух-четырех недель (на языке данного подхода такие этапы называют «итерациями»). Тестированию отдельных модулей уделяется не меньшее внимание, как и реальному написанию кода. При завершении одной итерации разработчики принимаются за следующее требование, которое добавит новую функциональность к только что законченному модулю, и таким образом начинают новую итерацию.
Применение скорой разработки обещает дать возможность создавать высококачественные программы с богатой функциональностью при меньших затратах времени и ресурсов, чем в традиционных методах. Скорая разработка вряд ли заменит методы так называемой «нис?ходящей разработки», которые доказали свою железобетонную надежность при разработке всего чего угодно — от систем ракетного наведения до ERP для учета разных штуковин. Для многих проектов, особенно крупных, с относительно точно сформулированными требованиями, «золотым» стандартом были и остаются подходы Software Engineering Institute, который предложил модели зрелости (Capability Maturity Model).
В эру глобального и массового производства на заказ меняется сама разработка. У вас уже нет трех месяцев на этап разработки требований, отдельные детали которых неясны и могут меняться. В сути метода скорой разработки лежит превалирование метода проб и ошибок над планированием и документированием, или, говоря языком нового подхода, «быстрого достижения результата» над «формализмом».
Скорая разработка склоняется к более интуитивной и одновременно строгой форме создания программ. Создайте и протестируйте программный модуль для ERP-системы силами небольшой, но тесно связанной команды разработчиков. Затем измените требования к этому модулю в процессе тестирования — и вы получите требуемую программу еще до того, как будут разработаны требования к ней в условиях традиционных методов нисходящего программирования.
Скорая разработка уже показала себя. Некоторые разработчики будут рассматривать ее в первую очередь как часть смешанной методологии, когда одни части проекта управляются нисходящим методом, а остальные — скорыми методами. Подходящими кандидатами для передачи группам разработчиков, применяющих методы скорой разработки, являются те программные модули, в которых реализуется неопределенная и подлежащая изменению функциональность.
Вместо того чтобы ожидать, когда будут решены все неясные вопросы или клиент опишет свои требования, дайте простор скорым методам. Разработайте план тестирования, создайте и протестируйте «игрушечные» интерфейсы, которые могут быть легко изменены по ходу проекта. Методы скорой разработки прекрасно работают в таких условиях.
Потенциальная экономия, обеспечиваемая методом скорой разработки, заставляет обратить на него внимание рынок глобальной разработки программ. Вокруг его плюсов и минусов разгораются жаркие споры. Если скорое программирование выполнит свои обещания, то в отрасли программного обеспечения изменится все.
Но если изменится все, то в отрасли будут как победители, так и проигравшие. Среди первых будет много тех первопроходцев, которые смогли разглядеть и воспользоваться этими изменениями и которые не вкладывали существенных средств в предыдущие технологии. Среди проигравших большинство будут составлять команды разработчиков, которые исповедовали традиционные подходы и которые не смогли или не захотели принять эти изменения.
Взоры многих приверженцев скорой разработки обращены в сторону офшорного программирования. Анализу с точки зрения скорых методов подвергаются те миллиарды долларов, которые уходят на разработку программного обеспечения в офшорах. Что лучше: написать прекрасное техническое задание, вооружиться мощной системой управления проектами в расчете сэкономить на дешевой рабочей силе офшорных разработчиков или распланировать итерации скорого программирования параллельно с планом тестирования и начать кодирование, не уезжая далеко от дома, чтобы уже вскоре получить работоспособное решение?
Офшорная разработка ставит под сомнение некоторые культурные аспекты, фундаментальные для практики скорого программирования, в частности наличие небольшой тесно работающей группы, наличие постоянной связи и интегрированное в разработку тестирование. Скорая разработка разрушает устоявшиеся правила как в Бангалоре, так и в Пекине, Бостоне, Берлине.
Но было бы ошибочным считать, что на территории западных стран скорое программирование всегда дает преимущество перед офшорными разработками. Как только компании, работающие на рынке офшорных разработок, начнут применять методы скорой разработки — а этот процесс уже идет, — они найдут соответствующие инструменты и методы управления и будут получать те же самые стоимостные преимущества, что и сейчас, но уже в ускоренном темпе.
Марк Виллоуби — ветеран ИТ-отрасли с двадцатилетним стажем, журналист. С ним можно связаться по электронной почте, написав письмо на адрес markw@messaginggroup.com