Страница 1 из 2
Smart Reading
Ключевые идеи книги: Мифический человеко-месяц, или Как создаются программные системы. Фредерик Брукс
Мифический человеко-месяц, или Как создаются программные системы
Автор:
Frederick P. Brooks
Оригинальное название:
The Mythical Man-Month: Essays on Software Engineering
www.smartreading.ru
Из чего состоит сложность
«Мифический человеко-месяц» был написан тогда, когда человечество и не мечтало о персональном компьютере в каждом доме. Книга приблизила эту возможность. Из 1960–1970-х неразличимы айфоны и беспроводная связь, однако принципы управления сложными проектами, которые сформулировал в те годы молодой ученый Фредерик Брукс, работавший тогда в передовой сфере кибернетики – создании OS/360 в IBM, – могут быть полезны и по сей день. Мы подготовили саммари этой замечательной книги с комментариями руководителя разработки Smart Reading Вячеслава Никулина.
В 1960–1970-е годы не существовало разнообразного готового инструментария удаленной коммуникации, совместной работы над макетами и документацией, систем ведения и контроля поставленных задач и использованных ресурсов. Хотя сейчас все эти технологии активно используются, процесс разработки и проектирования ПО только усложняется. ПО разрабатывается для многих прикладных сфер жизни, разные программы автоматизировано взаимодействуют друг с другом, ошибки в оценке трудозатрат на разработки таких систем имеют те же корни, что и 40 лет назад.
Программа и программный продукт – не одно и то же. Программный продукт отличается от программы:
▶ максимально обобщенным диапазоном и видом входных данных;
▶ тщательным тестированием, которое представляет собой отдельную сложную задачу;
▶ подробной документацией.
Создание программного продукта требует в три раза больше времени, чем программа. При этом программное обеспечение (ПО) – одно из самых сложных творений человека, и с этой сложностью нелегко совладать. Мощным стимулом для повышения продуктивности ПО было широкое использование языков высокого уровня[1] (исследователи приписывают этому фактору пятикратный рост продуктивности ПО).
Свою роль сыграли и унифицированные среды программирования. И все-таки ПО можно упрощать лишь до определенного предела, который ставят четыре условия:
1) сложность (огромное количество программных конфигураций затрудняет их описание и тестирование);
2) подчиненность форме (интерфейсы создаваемого ПО должны подчиняться многообразию человеческих институтов и систем, для которых и создаются);
3) изменчивость (ПО функционально, а функциональность – то, что в наибольшей степени подвержено изменениям в связи с быстро меняющейся реальностью);
4) невидимость (реальность ПО не встроена в пространство, ее трудно представить в том смысле, в каком, допустим, Земля отражена на географических картах, визуализировать ПО без принципиального упрощения трудно).
Объективные трудности, однако, можно минимизировать, если организовать создание ПО грамотно. Дело не в том, как работают компьютеры, а в людях.
Как организовать коллектив
Главная причина, по которой провалилось большинство программных проектов, – нехватка времени.
▶ Программистов губит оптимизм: поскольку их продукт создается не из глины или красок, но из чистых мысленных абстракций, они зачастую уверены, что в реализации проекта не будет больших трудностей. Между тем сами идеи бывают ошибочными, а это влечет ошибки в программах.
▶ Мы путаем приложенные усилия и движение вперед. Ход выполнения работы не зависит от человеко-часов, люди и время не взаимозаменяемы.
Люди и месяцы взаимозаменяемы только тогда, когда не нужно выстраивать коммуникацию между сотрудниками. Сбор хлопка на полях? Идея человеко-часов работает. Создание ПО? Идея человеко-часов проваливается, потому что разные этапы этой работы взаимозависимы и программисты должны тратить время на взаимодействие друг с другом. Времени на наладку коммуникации всегда уходит больше, чем на усилия по сокращению времени выполнения отдельных этапов работы. Поэтому привнесение в проект новых сил на поздних стадиях разработки только отодвигает срок сдачи проекта (закон Брукса).
Брукс вывел правило для определения графика работ по сборке ПО.
Здесь увеличена доля планирования и значительно увеличено время на отладку кода – по той причине, что именно в этой области программисты не ждут больших трудностей, а они случаются повсеместно.
Спустя 20 лет, в редакции 1995 года, Брукс указал на уязвимое место в этой схеме: если она реализуется линейно, накопление ошибок неизбежно и с увеличенным на отладку кода временем. В издании 1975 года Брукс настаивал на практике пилотной системы, которую программисты должны создать перед тем, как разработают окончательную модель. Пилот выявит ошибки в проектировании, а потом будет полностью отредактирован. За 20 лет подход к созданию программ изменился, и в 1995-м Брукс признает: принцип «Планируй выбросить!» не работает. Он указывает на преимущества инкрементной модели – поэтапной стратегии, когда разные части системы разрабатываются в разное время и разными темпами, а если одна часть готова, ее сразу интегрируют в систему. Но его базовый принцип остался неизменным: добавить рабочую силу в отстающий по графику проект – окончательно затормозить процесс.
Концептуальная целостность – ключевое условие проекта. Вспомним средневековые соборы Европы, которые строились десятилетиями, но сохранили стилистическое единство. К этому же должны стремиться разработчики ПО. Отличный пример концептуальной целостности – интерфейс WIMP (windows, icons, menus, pointers – окна, значки, меню, указатели), ныне известный каждому пользователю.
Концептуальная целостность требует, чтобы проект исходил от одного разработчика (или нескольких человек, действующих в унисон). Этот разработчик называется главным архитектором проекта. Действуя исключительно в интересах пользователя, он решает, что должно входить в программный продукт, а что нет (это видение воплощено в справочном руководстве проекта, о котором ниже).
Традиционно структуру организации представляют древовидной, отражающей общий принцип иерархического подчинения. На деле она скорее похожа на сеть, имеющую множество организационных групп, комитетов.
Каждый подпроект такой сети содержит две лидерские роли: роль продюсера[2] (он собирает команду, распределяет работу, определяет график, ищет ресурсы) и роль технического директора[3], или архитектора (он продумывает дизайн и отвечает за концепцию). Иногда, особенно в малых командах, продюсер и директор могут быть одним и тем же человеком. Однако в крупном проекте каждая из ролей требует полного рабочего дня, и в этом случае роли лучше разделить: продюсер может быть главой группы, а директор – его правой рукой, и наоборот.
1
Роль продюсера сейчас называется teamlead.
2
Роль технического директора на мелком проекте выполняет techlead.
3
Подход отчасти устарел. Наиболее современный подход – группа так называемых Т-специалистов, максимально взаимозаменяемых сотрудников, в которой каждый знает какую-то часть функционала очень хорошо, но может делать и все остальное.