Как организовать коллектив
Главная причина, по которой провалилось большинство программных проектов, – нехватка времени.
▶ Программистов губит оптимизм: поскольку их продукт создается не из глины или красок, но из чистых мысленных абстракций, они зачастую уверены, что в реализации проекта не будет больших трудностей. Между тем сами идеи бывают ошибочными, а это влечет ошибки в программах.
▶ Мы путаем приложенные усилия и движение вперед. Ход выполнения работы не зависит от человеко-часов, люди и время не взаимозаменяемы.
Люди и месяцы взаимозаменяемы только тогда, когда не нужно выстраивать коммуникацию между сотрудниками. Сбор хлопка на полях? Идея человеко-часов работает. Создание ПО? Идея человеко-часов проваливается, потому что разные этапы этой работы взаимозависимы и программисты должны тратить время на взаимодействие друг с другом. Времени на наладку коммуникации всегда уходит больше, чем на усилия по сокращению времени выполнения отдельных этапов работы. Поэтому привнесение в проект новых сил на поздних стадиях разработки только отодвигает срок сдачи проекта (закон Брукса).
Брукс вывел правило для определения графика работ по сборке ПО.
Здесь увеличена доля планирования и значительно увеличено время на отладку кода – по той причине, что именно в этой области программисты не ждут больших трудностей, а они случаются повсеместно.
Спустя 20 лет, в редакции 1995 года, Брукс указал на уязвимое место в этой схеме: если она реализуется линейно, накопление ошибок неизбежно и с увеличенным на отладку кода временем. В издании 1975 года Брукс настаивал на практике пилотной системы, которую программисты должны создать перед тем, как разработают окончательную модель. Пилот выявит ошибки в проектировании, а потом будет полностью отредактирован. За 20 лет подход к созданию программ изменился, и в 1995-м Брукс признает: принцип «Планируй выбросить!» не работает. Он указывает на преимущества инкрементной модели – поэтапной стратегии, когда разные части системы разрабатываются в разное время и разными темпами, а если одна часть готова, ее сразу интегрируют в систему. Но его базовый принцип остался неизменным: добавить рабочую силу в отстающий по графику проект – окончательно затормозить процесс.
Концептуальная целостность – ключевое условие проекта. Вспомним средневековые соборы Европы, которые строились десятилетиями, но сохранили стилистическое единство. К этому же должны стремиться разработчики ПО. Отличный пример концептуальной целостности – интерфейс WIMP (windows, icons, menus, pointers – окна, значки, меню, указатели), ныне известный каждому пользователю.
Концептуальная целостность требует, чтобы проект исходил от одного разработчика (или нескольких человек, действующих в унисон). Этот разработчик называется главным архитектором проекта. Действуя исключительно в интересах пользователя, он решает, что должно входить в программный продукт, а что нет (это видение воплощено в справочном руководстве проекта, о котором ниже).
Традиционно структуру организации представляют древовидной, отражающей общий принцип иерархического подчинения. На деле она скорее похожа на сеть, имеющую множество организационных групп, комитетов.
Каждый подпроект такой сети содержит две лидерские роли: роль продюсера[2] (он собирает команду, распределяет работу, определяет график, ищет ресурсы) и роль технического директора[3], или архитектора (он продумывает дизайн и отвечает за концепцию). Иногда, особенно в малых командах, продюсер и директор могут быть одним и тем же человеком. Однако в крупном проекте каждая из ролей требует полного рабочего дня, и в этом случае роли лучше разделить: продюсер может быть главой группы, а директор – его правой рукой, и наоборот.
Для обеспечения концептуальной целостности системы важно отделить архитектуру от реализации. Архитектура проекта определяет, что сделано, реализация – как сделано.
Простой пример – часы. Их архитектура состоит из циферблата и стрелок. Те, кто усвоил эту архитектуру, никогда не разучатся определять время. Реализация же отвечает за работу механизмов в корпусе. От реализаторов зависит соотношение стоимости к производительности продукта.
Архитекторы – аристократия проектов, но это не значит, что они ограничивают творческие возможности разработчиков. Те могут начать работу, как только у них появляются более-менее четкое понимание справочного руководства и критерии по стоимости и производительности. Разработчики могут заняться дизайном потоков данных, концепций упаковки и пр. Часто процессы создания архитектуры, программная и аппаратная реализация проходят параллельно, как и дизайн аппаратного и программного обеспечения.
В связи с этим одно из самых многообещающих технологических решений – разработка подходов и инструментов для быстрого прототипирования систем как части процесса разработки спецификаций. Прототипы симулируют задуманный программный продукт, позволяя обозреть заданную концептуальную структуру, проверить ее на удобство и непротиворечивость.