Архитекторы любят искать «единственный истинный путь» — методологию или философию, способную привнести столь желанную предсказуемость и открыть наконец те ясные ответы, которые, как им кажется, находятся где-то совсем рядом. Проблема в том, что ориентиры, которыми вы руководствуетесь сейчас, вряд ли останутся теми же через пару лет, не говоря уже о десятилетиях. Оглядываясь назад, вы всегда видите результаты, не соответствующие вашему нынешнему уровню притязаний. Научитесь принимать свои прежние достижения и боритесь с искушением попытаться вернуться и «исправить» их. Соответствовало ли решение поставленной задаче? Удовлетворяло ли оно требованиям? Используйте эти вопросы как критерии оценки — и у вас будет радостнее на душе.

Биография, автора приведена на стр. 79.

В последнее время в области разработки ПО наметилась одна прискорбная тенденция: стремление присвоить архитектуре ПО профессиональный статус наравне с классической школой архитектуры. Похоже, она обусловлена желанием архитекторов утвердить свои успехи и достижения в глазах более широкой общественности, нежели круг коллег и непосредственных работодателей. Но ведь архитектура обрела профессиональный статус лишь в конце XIX века — спустя тысячелетия после своего зарождения. Некоторые архитекторы программного обеспечения определенно слишком торопятся в своем стремлении к признанию.

Создание архитектуры программного обеспечения — искусство, и для достижения успеха в этой области, бесспорно, необходимы практика и дисциплина. И все же разработка программного обеспечения находится на относительно ранней стадии развития. Мы пока не располагаем достаточной информацией об этой отрасли, чтобы обоснованно придать ей профессиональный статус. Несмотря на молодость индустрии разработки ПО, ее продукция ценится достаточно высоко, и услуги квалифицированных специалистов в этой области (а также тех, кто стремится выглядеть таковыми) оплачиваются на том же уровне, что и в ведущих профессиональных областях, включая медицину, бухгалтерский учет и юриспруденцию.

Специалисты-практики в области разработки ПО получают хорошую оплату за свою творческую, сопряженную с исследованиями работу. Плоды наших трудов использовались для достижения многих значимых результатов, и некоторые из них принесли пользу всему человечеству. Преградами на пути к признанию являются наши действительные достоинства и возможности; в областях, достигших профессиональной зрелости, действуют программы обучения и стажировки, заметно превосходящие аналоги из нашей отрасли. Поразмыслите над этим и поймите, сколько у нас причин довольствоваться текущим положением дел и какой дерзостью будет настаивать на том, что архитектор программного обеспечения должен стоять на одной ступени с Адвокатом, Доктором и Зодчим.

Должность «архитектор программного обеспечения» пишется со строчной буквы «а»; осознайте этот факт и примите его.

Барри Хокинс (Barry Hawkins) за свою 13-летнюю карьеру в области создания ПО испробовал различные амплуа — от разработчика-одиночки до руководителя команды и инструктора по методологиям гибкой разработки. В настоящее время. Барри занимается преподаванием методологий гибкой разработки и проектирования на основе предметной области.

Границы проекта характеризуют его масштаб. Сколько времени, усилий и ресурсов необходимо для его реализации? Какую функциональность и с каким уровнем качества требуется получить? Насколько сложно сдать продукт к заданному сроку? Какова степень риска? Какие имеются ограничения? Ответы на эти вопросы определяют границы проекта. Архитекторам программного обеспечения больше нравится тот вызов, который им бросают большие, сложные проекты. Потенциальные выгоды даже искушают людей искусственно раздувать размеры проекта для повышения его кажущейся важности. Однако расширение границ — враг успеха, потому что вероятность неудачи растет быстрее, чем можно ожидать. Увеличение масштаба проекта вдвое часто приводит к тому, что вероятность провала возрастает на порядок.

Почему так происходит? Рассмотрим несколько примеров.

• Интуиция подсказывает нам выделить вдвое больше времени или ресурсов, чтобы удвоить объем работы. Однако история показывает,[17] что связь между ними не такая линейная, как утверждает интуиция. Например, в команде из четырех человек затраты времени на взаимодействия возрастают более чем вдвое по сравнению с командой из двух человек.

• Наши оценки — отнюдь не точная наука. Кто из нас не попадал в ситуацию, когда реализация какой-то функции оказывалась намного сложнее, чем предполагалось вначале.

Конечно, некоторые задачи изначально подразумевают выполнение проекта определенного масштаба и сложности. Написать текстовый редактор без возможности ввода текста несложно, но его вряд ли можно будет назвать текстовым редактором. Какие же стратегии помогают управлять границами в реальных проектах?

Узнайте реальные потребности. Реализация проекта должна обеспечивать выполнение набора требований. Требования определяют функциональность или некоторые ее качества. Подвергайте сомнению любые требования, не описанные так, чтобы их ценность для заказчика можно было измерить. Если требование не имеет никакой практической значимости, зачем оно нужно?

«Разделяй и властвуй». Ищите возможности разделить работу на меньшие независимые фрагменты. Управлять несколькими небольшими независимыми проектами проще, чем одним большим проектом с взаимосвязанными частями.

Назначайте приоритеты. Мир бизнеса изменчив. В крупных проектах требования многократно меняются по ходу дела. Действительно важные требования обычно таковыми и остаются, как бы ни менялись экономические условия, тогда как прочие требования видоизменяются и даже исчезают. Система приоритетов позволяет реализовать самые важные требования в первую очередь.

Демонстрируйте результаты как можно скорее. Люди редко понимают, что им нужно, пока не получат какой-нибудь результат. В известном комиксе[18] представлена эволюция проекта детских качелей: что сказал заказчик и как его требования поняли участники проекта, выполняющие те или иные роли. В итоге получается хитроумное сооружение, лишь отдаленно напоминающее качели. А на последнем рисунке под названием «Чего хотел заказчик» изображены простейшие качели из автомобильной покрышки на веревке. Когда у заказчика есть что-то, что он может самолично испытать, решение порой оказывается проще, чем предполагалось. При первоочередной реализации самых важных функций вы в качестве обратной связи получаете самую важную информацию на ранней стадии, когда она нужна больше всего.

Сторонники гибких методологий увещевают нас строить «самое простое, что будет работать».[19] Неудачи проектов со сложной архитектурой происходят намного чаще, чем с простой. Сокращение границ проекта часто приводит к упрощению архитектуры — и это одна из самых эффективных стратегий, позволяющих архитектору повысить шансы успешного завершения проекта.

Биография автора приведена ранее.

Когда архитектор приступает к проекту, у него появляется понятное желание «показать себя». Назначение на должность архитектора программного обеспечения обычно свидетельствует о доверии к технической компетентности специалиста со стороны компании; естественно, архитектор желает как можно скорее показать, что он заслуживает этого доверия. К сожалению, некоторые из нас ошибочно полагают, что для этого следует «представить себя во всей красе» — удивить, если не оглушить группу своей технической гениальностью.