Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

Последней подсказкой в этой книге является прямое следствие всех остальных. В разделе «Гордость и предубеждение» мы поощряем вас подписывать свою работу и гордиться тем, что вы делаете.

Пока в книге мы рассматривали прагматические методики, которые помогают отдельной личности стать лучшим программистом. Могут ли эти методы работать в приложении к командам?

Отвечаем на это громким «да!» В личностном прагматизме есть свои преимущества, но эти преимущества преумножаются, если личность работает в команде прагматиков,

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

Рассмотрим некоторые из предыдущих разделов с точки зрения команд.

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

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

В некоторых методологиях коллективной работы предусмотрен менеджер по качеству – сотрудник, которому команда делегирует ответственность за качество продукта, отправляемого заказчику. Это просто смешно: качества можно достигнуть только в результате индивидуальной лепты, вносимой каждым членом команды.

Помните несчастную лягушку, сидевшую в кастрюле с водой, из разделе «Суп из камней и сварившиеся лягушки»? Она не заметила постепенного изменения в окружающей среде и в конце концов сварилась. То же самое может произойти с отдельными личностями, которые теряют бдительность. Трудно уследить за общим состоянием среды в разгаре работы над проектом.

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

Боритесь с этим. Убедитесь, что каждый активно отслеживает изменения в состоянии среды. Может быть, стоит нанять «ответственного за состояние воды». Этот сотрудник должен постоянно следить за увеличением сферы покрытия, уменьшением масштабов времени, дополнительными средствами, новыми средами – всем тем, чего не было в первоначальном соглашении. Сохраняйте метрики по новым требованиям (см. раздел «Еще одна мелочь…»). Команде не нужно наотрез отказываться от изменений – просто надо знать, что они происходят. В противном случае лягушкой в горячей воде окажетесь именно вы.

Очевидно, что разработчики в группе должны разговаривать друг с другом. В разделе «Общайтесь!» даны некоторые советы для облегчения подобного общения. Однако не забывайте, что сама по себе команда находится в рамках определенной организации. Команде как субъекту приходится четко взаимодействовать с остальным миром.

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

Лучшие проектные команды обладают ярко выраженной индивидуальностью. Люди ожидают встреч с ними, поскольку знают, что увидят хорошо подготовленную презентацию, от которой всем станет лучше. Производимая ими документация отличается четкостью, точностью и последовательностью. В такой команде нет разноголосицы [44] В команде нет разногласий – но это только внешне. Внутри же команды поощряются оживленные серьезные дискуссии. Хорошие разработчики склонны быть страстными, когда речь идет об их работе. . У нее даже может быть чувство юмора.