Роберт Мартин - Идеальный программист. Как стать профессионалом разработки ПО

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

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

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

Возможно, кто-то из нас пришел в программирование не для того, чтобы работать с людьми. Ему не повезло: все программирование неразрывно связано с работой с людьми. Мы должны общаться со стороной бизнеса, и мы должны общаться друг с другом.

Знаю, знаю: мы бы предпочли работать в закрытой комнате с шестью большими экранами, каналом T3, параллельным массивом сверхбыстрых процессоров, неограниченным объемом памяти и дискового пространства, а также бесконечным запасом диетической колы и острых кукурузных чипсов. Увы, так не будет. Если вы хотите заниматься программированием, придется научиться общаться.

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

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

Заметили закономерность? Проект настолько мал, что никто не может заниматься только им одним. Все участники уделяют проекту 50 % или даже 25 % времени.

А теперь правило: половины человека не бывает.

Бессмысленно приказывать программисту посвятить половину времени проекту A, а другую половину – проекту B, особенно если в двух проектах участвуют разные руководители, бизнес-аналитики, программисты и тестеры. Разве подобную мешанину можно назвать группой?

Группы формируются не сразу. Между участниками постепенно налаживаются отношения. Они учатся работать друг с другом, узнают странности, сильные и слабые стороны своих коллег. Со временем участники «притираются» друг к другу.

В «притертой» группе есть что-то волшебное: она способна творить чудеса. Участники понимают друг друга, поддерживают и требуют максимальной отдачи. Благодаря их взаимодействию достигаются результаты.

«Притертая» группа обычно содержит около дюжины участников. Их может быть и больше (до 20) или меньше (до 3), но оптимальный размер обычно где-то около 12. В группу должны входить программисты, тестеры и аналитики. И у нее должен быть руководитель проекта.

Соотношение численности программистов и тестеров/аналитиков изменяется в широких пределах, но пропорция 2:1 вполне разумна. Таким образом, хорошо «притертая» группа из 12 человек может состоять из семи программистов, двух тестеров, двух аналитиков и руководителя проекта.

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

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

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

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

Разбивать такие группы только из-за завершения проекта слишком расточительно. Лучше сохранить группу в прежнем составе и поручать ей новые проекты.

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

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

У каждой группы имеется определенная скорость работы, [50]а проще говоря, объем работы, выполняемый за фиксированный промежуток времени. Некоторые группы измеряют свою скорость в пунктах в неделю (пункты – единица сложности). Функциональность каждого проекта, над которым работает группа, разбивается на блоки, сложность которых оценивается в пунктах. В дальнейшем производительность группы оценивается по количеству пунктов, реализованных за неделю.