Методология

Важно установить ясную и всеми воспринятую методологию разра% ботки, иначе работа будет носить хаотичный и произвольный ха% рактер. Один разработчик будет отдавать свой код для окончатель% ной версии, в то время как другой будет отказываться сделать это до проведения тщательного тестирования и отладки. Один разра% ботчик застопорит весь процесс, пока не получит сложной деталь% ной спецификации, а другой будет сразу писать прототип. И не та% кие проблемы являлись поводом для религиозных войн.

Методология определяет детали процесса разработки, устанавлива% ет ответственность за разного рода работу и порядок ее передачи. В результате каждый разработчик знает, что он должен делать и как ему участвовать в работе команды. Выбор методологии должен ос% новываться на численности команды, типе создаваемого кода и спо% собностях, опыте и динамике людей. Это обсуждается в главе 22.

План проекта

Чтобы выполнить какую%либо работу предсказуемым и своевремен% ным образом, необходима определенная организация. Ее обеспечи% вает план проекта, конкретизирующий работу каждого участника на протяжении разработки. План приносит пользу только тогда, когда основан на здравых оценках и своевременно корректируется.

Программисты славятся неумением оценивать сроки, а менеджеры – неумением планировать. Нельзя поддаваться давлению работать в соответствии с нереалистичным планом проекта. Это действи% тельно сложная проблема, которую мы разберем в главе 21.

Болезни, которым подвержены команды

Оправиться после неудачи иногда бывает легче, чем развить успех.

Майкл Эйзнер

Даже при наличии хороших программистов и замечательной органи% зации команда может оказаться неработоспособной. Есть много при% чин, по которым команды оказываются неспособными решать свои за% дачи, и мы можем выделить категории обреченных на провал команд так же, как выделили стереотипы программистов, и попытаться сде% лать из этого выводы.

Ниже приводятся некоторые классические типы неудачных команд. Для каждого из них мы опишем:

•Специфический путь к провалу

•Симптомы (по которым вы сможете узнать, что вас ожидает)

•Как вытащить команду, попавшую в эту колею

•Как остаться успешным программистом в условиях неудачной ко% манды (иногда вопреки команде)1

Будем надеяться, что вы не найдете свою команду в приводимом списке.

Вавилонская башня

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

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

Строители Вавилонской башни раскололись из%за множества языков, на которых они говорили.2 Однако интернациональные проекты редко страдают от вавилонского синдрома – когда требуется преодолевать языковые барьеры, люди проявляют стремление к налаживанию хоро% шего общения.

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

Эта проблема может возникнуть как в самой команде, так и между со% трудничающими командами. Внешний вавилонский синдром возни%

1Я не утверждаю, что эти стратегии решат общую проблему команды; это просто первые пришедшие в голову способы сделать нынешнюю работу с минимальным риском проблем.

2Книга бытия 11:1–9.

кает, когда разработчики отказываются общаться с тестерами или ко% манда менеджеров не контактирует с разработчиками.

Признаки опасности

Свидетельством того, что ваша команда движется в сторону Вави% лона, является нежелание одного разработчика обращаться к друго% му по какому%либо вопросу, поскольку он чувствует, что это беспо% лезно. Признаком нездоровья служит отсутствие подробных специ% фикаций и нечеткие контракты в коде. Почта посылается в слиш% ком малом или слишком большом объеме. Когда почты слишком много, значит, все кричат и никто не слушает: ни у кого нет време% ни, чтобы разобраться с потоком информации.

Для дороги в Вавилон характерно, что совещания команды не созы% ваются и никто толком не знает, в каком состоянии проект. Возь% мите любого разработчика, и он не ответит вам, в правильном ли направлении движется разработка.

Выход из ситуации

Начните говорить с людьми. Не нужно сдерживать себя! Вскоре все начнут делать то же самое.

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

Затем выработайте какую%либо стратегию, чтобы заставить людей общаться друг с другом. Создайте небольшие фокус%группы для рас% смотрения новых функций. Назначьте двух человек ответственны% ми за участок проектирования. Введите программирование парами.

Стратегия успеха

Чтобы написать хороший код при наличии таких проблем, необхо% димо соблюдать строгую дисциплину. Прежде чем приступить к па% кету работ, строго определите его. Если необходимо, сами напиши% те спецификацию и разошлите по почте всем, кого она касается, чтобы получить их одобрение (установите крайний срок подачи комментариев и сообщите, что отсутствие отзывов будет расцени% ваться как согласие). После этого успешность будет определяться выполнением согласованной спецификации.

Полностью заморозьте все внешние интерфейсы кода, чтобы не было никаких сомнений относительно ваших расчетов или того, что другие могут ждать от вашего кода.

Это настоящее представление с одним действующим лицом – команда, руководимая сильной личностью, нередко являющейся и высококвалифицированным программистом. Остальные программисты должны только поддакивать (даже если не хотят этого делать) и выполнять указания Диктатора, не обсуждая их.

Некоторые команды прекрасно работают в таком стиле – удачно подобранный благожелательный дик% татор и команда, относящаяся к нему с уважением. Проблемы возникают, когда личность Диктатора не отвечает занимаемому им положению или его техни% ческая подготовка недостаточна (см. раздел «Псевдо% гуру» на стр. 389). Если его самомнение встает попе% рек пути, команда в опасности: возникнет противо% стояние, которое заведет в тупик.

Когда такая команда формируется умышленно, она представляет собой иерархию с определенными линиями подчинения. Фредерик Брукс на% шел сходство такой структуры с хирургической бригадой (Brooks 95). В хирургической бригаде наиболее высококвалифицированный тех% нический специалист, главный хирург,1 занимает самое верхнее поло% жение: он выступает в роли кодера, а не администратора. Он выполня% ет основной массив работы и несет полную ответственность за возмож% ные неприятности (если пациент умрет). Ему помогает специально по% добранная бригада. В ее состав входит хирург%интерн, который решает более мелкие, менее рискованные задачи, помогает главному хирургу и учится у него. В команду также включают соответствующие эквива% ленты анестезиологов, сестер и, возможно, других младших хирургов (например, чтобы наложить швы).

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

Признаки опасности

Структура такого типа развивается медленно и незаметно, по мере того как будущий диктатор медленно меняет направленность своей

1Обычно это специалист%технолог по классификации групповых ролей Бел%

бина.