Хмурый Техлид

Перелистывая старые страницы Вчера умер Фредерик Брукс - инженер, известный многим специалистам по программированию по книге “Мифический человеко-месяц”. Книга эта не нова - написана она была в 1975 году по следам работы Брукса в IBM, где он, в частности, руководил разработкой мейнфреймов System/360 и операционной системы для них OS/360. Кстати, именно он ввел в обиход термин “архитектура компьютера”. Произведение вносилось в различные списки важных произведений в области разработки ПО, хотя сейчас, конечно, новаторскими идеи, изложенные там, уже не назовешь. Просто потому, что они уже глубоко проникли во многие методы управлением инженерии программ и не кажутся чем-то необычным. Тем не менее, неплохо вспомнить некоторые из них и тем самым помянуть Фредерика Брукса, по книгам которого мы учились управлять хаосом. Многие из этих идей мы все знаем и не подозреваем, что они были впервые упомянуты именно в “Мифическом человеко-месяце”. Если у вас есть некоторая программа, то нужно в три раза больше начальных усилий, чтобы превратить ее в программный продукт - написать документацию, обеспечить сопровождение и так далее. Точно так же, нужно в три раза больше усилий, чтобы сделать эту программу расширяемой и назвать ее программным комплексом - сделать понятные API, точки расширения и так далее. Если же нужно и то, и другое, то это системный программный продукт, и его создание стоит в 10 раз больше, чем написание просто программы. Если программный проект отстает от расписания, то добавление к нему людей только еще больше задержит его. Связано это с тем, что инженерное дело - работа творческая и сложная, и подключение новых людей требует их обучения, причем обучать будут те, кто уже работает над проектом. Т.е. и новые люди еще толком ничего не делают, и старые отвлекаются. Кроме того, многие задачи легко не параллелятся - цитируя книгу, “чтобы родить ребенка, надо 9 месяцев, сколько женщин к этому не подключи”. Производительность сильных и слабых инженеров с похожим опытом и зарплатой может отличаться в десять и больше раз. К этому сложно что-то добавить. Это применимо и к командам - сильные и слабые команды по выхлопу тоже могут отличаться на порядок легко. Повторю - с похожим опытом и зарплатой. Т.е. это не про сравнением сеньора и джуна. Это снова подчеркивает важность качественного найма и своевременных увольнений - без этого поддерживать высокий уровень команды сложно. “Эффект второй системы” - если вы занимаетесь разработкой новой версии системы, которую создавали раньше, то будьте осторожны и не начните впихивать в дизайн разного рода фантазии. Нередко такой “архитектор с опытом” решает, что теперь он досконально знает требования и сможет разработать отличный дизайн, который позволит эти и будущие требования удовлетворить. Часто это заканчивается тем, что этот техлид оказывается в плену своих старых взглядов и ограничений и не может адекватно оценить изменившиеся реалии, где новая версия системы должна быть другой, а не совершенной. Готовьтесь выбросить прототип / начальную реализацию системы. В этой главе Фредерик пишет, что часто команды пытаются превратить в полноценную программу самую первую ее версию, и это ошибка, потому что единственное назначение этой версии - это проверка гипотез и получение опыта. То есть, нельзя дом из говна и палок превратить в дом, который долго простоит. Его надо разрушить и построить заново. “Постоянны только изменения” - хорошая фраза из той главы. Отставание от графика всегда происходит постепенно. Никакой проект не отстает сразу на год - это происходит через “блин, сегодня не успел, но завтра точно будет” раз за разом.. Чтобы избежать этого, цели должны быть атомарными - либо сделано, либо нет. “Готово на 90%” не подходит и будет самообманом. Также этапы должны быть короткими - несколько недель, не больше. Серебряной пули нет. Никакие отдельно взятые методика или инструмент не позволят ускорить разработку ПО в десятки раз. Комплекс мер и знаний на протяжении многих лет - возможно. Спи спокойно, Фредерик. Ты нас многому научил.