Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами
Урок 1. Впоследствии выяснилось, что для телефонных интервью консультантам предоставили длиннющие шпаргалки с ответами на все мыслимые и немыслимые вопросы. Стоило мне спросить: «Какое средство моделирования данных вы предпочитаете?» – как абонент, выдержав паузу, переспрашивал: «Повторите, пожалуйста, вопрос – я не совсем понял, о чем речь». В это время он листал шпаргалки в поисках правильного ответа. Отыскав его, он отвечал: «Больше всего мне нравится ERStudio, но у него есть такие-то недостатки. ERWin – тоже ничего, он выгодно отличается тем-то и тем-то». Понимаете, дословно повторяя содержимое шпаргалок, они говорили все то, что я хотел услышать. Мне уже стало казаться, что группа будет состоять исключительно из гениев. Вскоре после начала работы над проектом я понял, как сильно ошибался.
Собственно, по мере продвижения проектов я получил еще несколько печальных уроков. Все мои неудачи происходили от того, что я совершенно не учитывал культурные факторы – я даже не предполагал, что в деле управления группами, состоящими из зарубежных специалистов, культурные факторы имеют какое-то значение.
Урок 2. Когда индиец кивает головой, он имеет в виду «нет», а не «да». Вы можете себе представить, как это сбивает с толку?! Ведь мы принимаем за аксиому, что кивок выражает согласие!
Урок 3. В большинстве случаев специалисты из Индии не препираются, не пытаются вас поправить и не подвергают сомнению авторитет начальства – по крайней мере публично. Таким образом, они согласятся со всем, что вы скажете, – пусть даже вы будете нести полную чушь. Некоторые из них после совещаний продолжают решать задачу по-своему, вне зависимости от того, что им сказали. Работая с индийцами, я возомнил себя великолепным лидером – ведь американские программисты ни за что не позволят достичь консенсуса так быстро и легко!
Урок 4. Как правило, если консультанты не понимали, что я им говорил, они даже не пытались дать об этом знать. Они несколько раз повторяли, что все мои предложения в высшей степени разумны, после чего продолжали кодировать так, как считали нужным.
Урок 5. Последняя индийская перепись населения зафиксировала в стране более 200 языков и диалектов. Поскольку все мои сотрудники приехали из разных регионов Индии (кстати сказать, друг друга они недолюбливали), между собой они общались исключительно на ломаном английском. Многочисленные улыбки и жесты отнюдь не способствовали преодолению взаимного непонимания.
Урок 6. Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.
Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.
Оценка методологий разработки программных средств
Раньше программирование считалось уделом инженеров и ученых, весьма далеких от суеты бизнес-центров. Нынче компьютерами пользуются все подряд, а употребление технологических достижений в коммерческих целях обязывает создавать качественные программные продукты вовремя и в рамках установленного бюджета. К последнему утверждению можно, конечно, относиться с иронией, но факт остается фактом: эпоха программ, разрабатывавшихся энтузиастами по собственным правилам, ушла в историю. Бизнес требует тщательности в разработке и внимания к практическому результату деятельности персонала. Здесь-то и начинается самое интересное. Практически все представители нашей индустрии, получившие какое-никакое признание, считают себя экспертами и норовят продать «уникальные» методологии разработки.
Со мной другая ситуация – я пытаюсь продать принцип эклектичности в методиках разработки. Задействуйте и совершенствуйте те методы, которые доказали свою практичность для вас лично, для группы и для компании. Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения. В следующих разделах я привожу обзор заметных школ разработки программных средств, причем основной акцент делаю на их концептуальной основе. Школы проектирования я обсуждать не собираюсь. Структурное программирование, объектно-ориентированное проектирование, эталоны проектирования – все эти течения в основном сфокусированы на деталях конструкции и значительно меньше внимания уделяют общей методологии разработки. Архитектурные проблемы (рассматриваемые в главе 6) также не получают в них достаточно глубокого развития. Итак, отступив от деталей, я собираюсь представить на ваш суд наиболее общий анализ ситуации.
Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения.
Программная инженерия
В конце 1960-х годов, когда тогдашним инженерным гениям удалось высадить человека на Луну, располагая при этом меньшими вычислительными мощностями, чем любой современный калькулятор[110], в обиход вошел термин «программная инженерия». Эта концепция зиждется на представлении, согласно которому программное обеспечение можно разрабатывать средствами традиционных инженерных дисциплин. Применительно к сверхкрупным программным проектам, которые, как правило, заказывались правительством или крупными подрядчиками министерства обороны, эта методика несколько раз показала достойные результаты, но в остальных случаях потерпела фиаско[111]. Метод программной инженерии зачастую применялся в условиях одновременной разработки программного и аппаратного обеспечения. Кроме того, с его помощью удалось создать несколько коммерческих продуктов. IEEE определяет этот метод следующим образом:
«Программная инженерия – это систематический, структурированный, количественный подход к разработке, функционированию и сопровождению программных средств; иначе говоря, способ применения инженерных методов в разработке программных продуктов»[112].
Полагаю, вы, как и я, в замешательстве. Основное внимание в этом методе уделяется сокращению количества дефектов в коде – о соблюдении бюджетных рамок ни слова.
Это не в меру сжатое определение, по-моему, можно расширить.
• Систематически – все аспекты разработки можно контролировать в едином процессе.
• Структурно – последовательное употребление должных методов с целью производства качественного программного продукта.
• Количественно – все требования известны и допускают отображение на методы реализации.
Прежде чем чесать затылок, глядя на мою интерпретацию трех основных концепций программной инженерии, согласитесь: всем нам хотелось бы достичь определенности, точности и завершенности, которые декларируются. Посмотрим, как относится к мифу о суперпрограммистах один из наиболее последовательных поборников программной инженерии:
«Существует распространенное мнение, согласно которому несколько высококлассных специалистов, собранных вместе, способны сделать больше, чем стандартная группа разработчиков. Имеется в виду, что их знания о способах достижения высоких результатов интуитивны, а значит, потребность в систематизации процесса отпадает. Будь это действительно так, можно было бы предположить, что компании, у которых в штате числятся наиболее квалифицированные специалисты, не должны испытывать типичных проблем с качеством разрабатываемых программных средств и продуктивностью. Опыт же подсказывает нам, что это совершенно не так»[113].
Видите, какой получается конфликт. «Человек» противопоставляется «машине» – в контексте программной инженерии «машиной» можно назвать дисциплинированную группу разработчиков, работающую на основе общей методологии. «Человеком» же обозначается программист-светило, который как по волшебству мастерит продукты, руководствуясь исключительно своими познаниями. В дискуссию по этому поводу (по-моему, она немного искусственна) вступать не стоит. Хорошие специалисты и надежный процесс в равной степени необходимы – не будь одного из этих компонентов, создавать качественные программные продукты было бы крайне сложно. Вопрос лишь в том, является ли надежным процессом программная инженерия.
