передачи кода тестировщикам (иллюстрации последуют не-

медленно) включают:

1. Наличие требований к содержанию спеков и следова-

ние правилам их изменения;

2. Возможность прямой, быстрой и эффективной комму-

никации между программистами и программистами и

продюсерами;

3. Инспекции кода;

4. Стандарты программирования;

5. Реальные сроки;

6. Доступность документации;

7. Требования к проведению юнит-тестирования (о кото-

ром мы поговорим уже через 30 секунд);

8. Реальные финансовые рычаги стимуляции написания

эффективного и "чистого" кода;

9. Наличие понятий "качество" и "счастье пользователя"

как основных составляющих корпоративной философии.

Подробности.

1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ

И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ

О спеках мы уже говорили.

2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ

КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ

И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ

Здесь есть следующие аспекты:

а. Психологические аспекты

Очень важно привить в культуру компании следующее правило:

"Если к тебе обратились — помоги".

90

Тестирование Дот Ком. Часть 1

Пример

Программист приходит к продюсеру с просьбой объяснить некую часть

спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра,

добро?"

Очень часто после пары "давай завтра" программист что делает? Пра-

вильно! Он пишет код так, как его понимает, — без всякой гарантии, что

сей код отразит требуемое.

Следующий аспект:

программист (как и все остальные участники цикла) никогда не

должен стесняться спрашивать (хоть двести раз!) и подтверждать

свое понимание е-мейлами типа: "Просто хотел уточнить, что я

правильно понял, что пункт 12.2 такого-то спека говорит..." Если

же программисту не отвечают, когда он подходит, прекрасно —

нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я

хотел уточнить". Если снова не отвечают, программист должен

идти к своему менеджеру и просить его принять меры. И это не

стукачество, а деловая практика — business is business.

Следующий аспект:

Менеджмент должен регулярно устраивать так называемые Team

Building Activities (мероприятия по сплочению коллектива) с той

простой целью, чтобы между членами команды кроме профес-

сиональных налаживались и человеческие контакты. Причем, как

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

месяц гораздо эффективнее для сплочения коллектива, чем со-

вместная проспиртовка мозгов во время пятничных застолий.

б. Технический аспект

Каждый из участников цикла разработки ПО должен быть досту-

пен для контакта: желательно, чтобы все они работали в одном

здании; в локальной сети должны быть доступны служебные, мо-

бильные и домашние телефоны; необходимо согласовать часы

(хотя бы 4 часа в день), когда все (и тот, кто ушел в 6 часов вече-

ра и в 3 утра) находятся в офисе.

3. ИНСПЕКЦИИ КОДА

У некоторых программистов есть такая концепция: "Если я пишу

код, который могу понять только я, то меня не уволят".

Ну, во-первых, при желании можно уволить даже президента

"ЮКОСа", во-вторых, такой подход к работе априори неправи-

Цикл разработки ПО

91

лен: в интернет-компаниях никто никого силком не держит, и

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