Введение
В последние годы наблюдается устойчивый рост популярности гибкой разработки, и многие компании размышляют над тем, как воспользоваться выгодами процессов и методов гибкой разработки. И хотя я не проповедую гибкость, методы гибкой разработки подтвердили свою выгоду при использовании в определенных типах организаций и проектов.
В обсуждениях процессов разработки и связанных с ними проблем гибкая разработка уже давно стала горячей темой, поскольку:
- предприятия хотят быстрее реагировать на изменения рынка;
- ИТ-подразделения хотят выпускать продукты без формального (или обычного) шестимесячного цикла;
- разработчикам нравится стабильная среда разработки, в которой они могут полностью сосредоточиться на функциях и качестве создаваемого программного обеспечения.
Гибкая разработка годится не для всех организаций или клиентов. Существуют определенные критерии, которые делают гибкую разработку более пригодной для одних организаций, чем для других. И, как всегда, только люди делают процесс реально осуществимым (а люди бывают разные).
В этой колонке я опишу критерии, которые помогут вам оценить, пригодна ли гибкая разработка для вашей организации. Вы узнаете о выгодах, которые сулит гибкая разработка, и о "человеческом" факторе процесса гибкой разработки.
Что такое гибкая разработка
Для начала давайте определим, что мы понимаем под словом "гибкая разработка". Существует множество различных гибких методов разработки. Все они фокусируются на личном общении и быстрых циклах выпуска и нацелены на выпуск работающего фрагмента программы в кратчайшие сроки. Методы гибкой разработки являют собой попытку сокращения бюрократизма процесса разработки и обеспечения выпуска работающей программы, реализующей наиболее важные требования клиента. Кто-то может сказать, что гибкая разработка - это голос разума в полностью бюрократизированной и документированной пустыне процесса разработки, но это не совсем так. Все зависит от обстоятельств.
Вопреки распространенному мнению, разработчики, придерживающиеся гибких методов, - это вовсе не бунтари, пишущие программы без всяких правил и ограничений. "Ковбойское программирование" свидетельствует об отсутствии дисциплины и плохом управлении и является признаком непрофессионализма. Если в вашей компании (или того хуже - в вашей группе) есть такие "ковбои", сделайте все возможное для изменения этой ситуации, хотя бы ради своих клиентов.
При описании гибкой разработки часто рассказывают типичную историю о двухлетнем проекте, разработкой которого занималась небольшая группа (скажем, из пяти человек). Если бы эта группа использовала традиционный каскадный метод, показанный на рисунке 1, у нее ушло бы от двух до трех месяцев на детальную проработку всех требований. Затем группа проанализировала бы эти требования. За анализом требований последовала бы разработка системы, в том числе и архитектуры. К этому времени заказчик внес бы первые измерения, что активизировало бы процесс управления изменениями. Процесс управления изменениями сам по себе требует некоторой переработки требований, дополнительного анализа и, возможно, дополнительного проектирования.
Через шесть или семь месяцев группа, наконец, будет готова к реализации. Как вы уже можете догадаться, клиент может внести еще какие-то изменения, которые снова пройдут через процесс управления изменениями. Не поймите меня превратно - существуют ситуации, когда иного пути просто нет - например, в критически важных системах или системах жизнеобеспечения.
Рисунок 1. Традиционная каскадная разработка
Если бы группа в этом примере использовала гибкий подход, показанный на рисунке 2, она бы грубо набросала требования, которые были бы представлены в виде, позволяющем владельцам проекта определить их приоритеты. Затем владельцы и разработчики проекта совместно выбрали бы из требований небольшую группу функций и реализовали их за несколько итераций, которые заняли бы от двух до трех недель каждая. За пару итераций они создали бы работающую версию приложения, после чего владельцы проекта смогли бы приступить к его опробованию или применению. Еще через пару итераций приложение уже обладало бы базовыми функциями и было бы готово к запуску.
Рисунок 2. Первая итерация процесса гибкой разработки
Показанный на рисунке 2 гибкий метод дает рабочую версию программы за меньшее время, чем было бы потрачено только на проработку приложения при использовании каскадного метода. Это рабочее приложение содержит лишь базовые функции, но уже работает. Иметь рабочую версию приложения (пусть даже содержащую лишь основные функции) очень полезно, поскольку вы можете начать его использование, тем самым ускоряя бизнес-процессы, или выпустить бета-версию коммерческой услуги и начать привлечение клиентов.
В следующем разделе мы обсудим выгоды гибких процессов разработки.
Принципы и выгоды
Если ваша организация не получит от гибких методов никаких выгод, то в их применении нет смысла. Для упрощения обсуждения выгод перечислим принципы гибкой разработки:
- Быстрая и непрерывная поставка
- Удовлетворение клиента за счет быстрой и непрерывной поставки полезных программ. Важно ли это для вашей организации? Ваша компания только образовалась и хочет привлечь клиентов бета-версиями приложений? Сократит ли ваше приложение внутренние расходы, исключив ручную работу?
Если это так, то вы можете получить выгоду от использования гибкой разработки. - Частая поставка
- Работающие версии программного обеспечения можно будет поставлять чаще - за недели, а не за месяцы. Если вы создаете Web-приложения, то, возможно, захотите чаще выпускать обновления, добавляя новые функции, или улучшать приложения по результатам отзывов клиентов. Вам не придется заботиться о строгом контроле версий или сопровождения файлов для отслеживания версии приложения, которой пользуется каждый из клиентов.
Если выпускаемая вами версия вызывает изменения или необходимость проведения дополнительных работ на стороне клиента, то вряд ли вам захочется часто выпускать обновления. И все же частые итерации могут оказаться полезными, поскольку дают уверенность, что вы можете реализовать и выпустить изменения за недели, а не месяцы. - Работающая программа
- Главной мерой продвижения является работающая программа. Написания документов и презентаций недостаточно для удовлетворения большинства коммерческих требований - для этого нужна работающая программа.
Если вы предоставляете услуги консультирования, то, вероятно, документов и слайдов будет достаточно, однако целью большинства организаций является именно разработка работающих программ. - Адаптация
- Гибкие методы разработки позволяют справиться даже с поздними изменениями требований. Долгое время профессиональные разработчики прилагали все усилия к тому, чтобы сделать поздние изменения невозможными или очень дорогими. Но поскольку корпоративная среда может меняться крайне быстро, требования к программному обеспечению должны за ней поспевать.
- Тесное и повседневное сотрудничество
- Бизнес-пользователи и разработчики программ должны ежедневно обмениваться мнениями и сотрудничать между собой. От коммерсантов могут исходить поздние изменения требований, которые должны реализовываться разработчиками. Если процесс разработки допускает изменение требований, то ежедневное взаимодействие необходимо.
Для приложений, реализующих интерфейс или спецификации, требования совпадают с требованиями, описанными в спецификации, опубликованной специально уполномоченным органом. Изменения таких документов связаны с серьезной работой и не могут возникнуть просто так. - Целеустремленные профессионалы
- Проекты создаются мотивированными профессионалами, которым можно доверять, - это должно составлять основу любой организации. Я легко могу написать еще одну серию статей о том, почему одни люди мотивированны, а другие нет.
У вас есть ресурсы для стимулирования и обучения работников, которые не мотивированны и не профессиональны, или вы хотите найти и нанять людей, которые уже мотивированны и высокопрофессиональны? - Самоорганизующиеся группы
- В большинстве проектов разработки программного обеспечения существование самоорганизующихся групп невозможно. Это требует наличия колоссального опыта, как со стороны разработчиков, так и со стороны руководства. Самоорганизующаяся группа сама решает, какую часть требований она может реализовать в определенной итерации, и кто чем будет заниматься. Роли членов группы распределяются на основе их интересов и знаний, а не диктуются руководством.
Плохо организованная группа примет лишь часть требований и многого не сделает. Чтобы группа работала нормально, ее члены должны понимать, что они делают, а руководство должно им доверять.
Самоорганизующиеся группы следует сравнивать с другими типами групп, а не с туманными оценками работы, которую нужно выполнить. Есть ли в вашей организации профессионалы? Нет ли у вас, как у члена группы или менеджера, опасений в отношении задач, которые необходимо выполнить?
Возможно, вы уже задумались, применимы ли принципы гибкой разработки или самоорганизующиеся группы к вашей организации. Это с неизбежностью порождает следующий важный вопрос.
Готова ли ваша организация к гибкой разработке?
Адаптация к методам гибкой разработки легче проходит в организациях, которые обладают определенными характеристиками. Как впервые отметил Дэвид Коэн (David Cohen) с соавторами, эти характеристики таковы:
- культура ведения переговоров
Открытое и честное обсуждение проблем важно в любой организации, так что если вы планируете использовать методы гибкой разработки, разные части вашей организации должны хорошо взаимодействовать и при необходимости уметь идти на компромисс; - взаимное доверие сотрудников организации.
Если руководство не доверяет разработчикам, или разработчики не доверяют сотрудникам торгового отдела, то у вас будут проблемы; - уменьшение числа сотрудников с увеличением уровня компетенции.
Работу может сделать небольшая группа высококвалифицированных разработчиков, которым не придется сталкиваться с избыточным бюрократизмом; - среда, упрощающая быстрое взаимодействие между членами группы.
Требования бизнес-пользователей должны удовлетворяться сейчас, а не на следующей неделе. Культура вашей организации должна опираться на быстроту реакции, что позволит избежать погружения в трясину; - небольшой размер проектной группы (20-30 человек и менее).
С ростом группы затрудняется личное общение.
Несколько лет назад я работал в компании, которая использовала упрощенную версию IBM Rational Unified Process (RUP). Применяемый процесс был близок по характеристикам к гибкой разработке, хотя мы и не называли его таковым. Я рассказывал об итерациях, о методах их использования и о том, почему они хороши. Но по какой-то причине реакция людей была прохладной. Позже менеджер проекта объяснил, что под "итерацией" люди понимали многократное выполнение одной и той же работы в связи с неясностью требований. Предшествующий опыт заставлял их оставаться глухими к моим речам. Тогда я понял, что как бы вы ни были подготовлены, процессы в конечном итоге реализуются людьми, знание послужного списка которых играет очень важную роль.