Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
Когда проект разрастается
Я имею в виду классическое понятие разрастания проекта. Если аналитик бизнес-требований утверждает, что занимается уточнением рамок, знайте: он их раздвигает. Не важно, как этот процесс называть. Факт тот, что специфицировать и сконструировать программу, избежав разрастания требований, не удавалось еще никому. Объясняется это натурой человека – невозможно с первой попытки сформулировать все функции, которые предполагаемой программе предстоит выполнять.
Рассмотрим типичный процесс производства программного
1. Замысел. У кого-то появляется блестящая идея.
2. Специфицирование. Куча людей пытаются описать эту идею.
3. Проектирование. Высокоинтеллектуальные товарищи решают, как сконструировать предполагаемый программный продукт.
4. Конструирование. Бессонными ночами и нескончаемыми днями программисты программируют.
5. Тестирование. Обнаруживается, что конечная реализация блестящей идеи не так хороша, как хотелось бы, или, еще хуже, что идея-то отнюдь не блестящая.
6. Все начинается заново со второго этапа, пока вы не почувствуете, что все нормально, всего хватает, или, наоборот, не придете к заключению, что идея, высказанная на первом этапе, ужасна и вам срочно требуется новый блестящий замысел (в последнем случае, опять же, все начинается со второго этапа).
А теперь подумайте: таким ли уж неожиданным станет разрастание рамок в контексте отраженного в этом списке реального сценария? Мне так не кажется, и вам тоже не должно так казаться. И тем не менее, если речь об этом зайдет, воя и зубовного скрежета программистов не избежать. Как заставить их поверить, что вы во всеоружии и ваша позиция правильна? Лучше всего поставить их перед фактом, что разрастание неизбежно, и научить их справляться с этой проблемой. Вы руководитель, и это – ваша обязанность. Не поддавайтесь соблазну разнести «крайних» в других отделах – этим вы не приблизите завершение работы и не исправите ситуацию.
В своей немного устаревшей, но, тем не менее, сохраняющей значимость книге под названием «Managing the Software Process» Уотс Хэмфри (Watts Humphrey) сформулировал принцип, актуальный по сей день:
«Когда программисты берутся за оценку объема кода реализации какой-либо функции, результаты неизменно оказываются заниженными. Этому есть множество возможных объяснений. В этом контексте следует понимать, что их оптимизм есть относительно прогнозируемая функция состояния проекта» [35] .
35
Watts S. Humphrey, Managing the Software Process (New York: Addison-Wesley, 1989), p. 93.
На самом деле, разрастание рамок объясняется очень просто – сказать, сколько времени и сил уйдет на создание очередной
• любой процесс продлится дольше, чем вы надеетесь;
• всегда появляется что-то, о чем вы не подумали.
Вооружившись этими аксиомами и введенным Хэмфри понятием «состояния проекта», старайтесь контролировать разрастание и обязательно убедите ваших подчиненных в том, что вы человек проницательный, поскольку предсказывали такую возможность и учли ее в процессе тщательного планирования. «Тщательное планирование»! Звучит замечательно, но что же это означает в контексте выпаса котов? А вот что. Вернитесь к главам 1 и 2, еще раз пробегитесь по изложенным в них принципам и попытайтесь сделать их неотъемлемыми элементами своего характера. Помните, что лидерство происходит от сердца, а не от ума [36] .
36
Вспомните, что говорил Йода: «Сила Джедая есть результат его собственных усилий». У нас то же самое.
Конечно, и для мозга найдется работа – в частности, ему предстоит разработать методы контроля над разрастанием рамок проекта. Давайте рассмотрим типичный план проекта. Предположим, что, исходя из заданного набора требований, вы должны разработать проектное решение с расчетом на его последующую реализацию программными средствами. Элементарный, но наивный план иллюстрирует табл. 3.3.
Задача……Время выполнения (произвольные интервалы)
Анализ требований……А
Создание проектного решения……В
Реализация проектного решения……С
Тестирование программного обеспечения……D
Исправление ошибок……Е
Развертывание программного обеспечения……F
Руководствуясь таким планом, вы рискуете нарваться на кучу неприятностей. Будучи глубоко убеждены, что конечная дата сдачи проекта будет равняться сумме временных интервалов A+B + C + D + E + F, вы немало удивитесь, обнаружив, что это совершенно не так.
Рассмотрим более реалистичный план, показанный в табл. 3.4.
Задача……Время выполнения (произвольные интервалы)
Анализ требований……А
Обсуждение результатов анализа с сотрудниками отдела……В
Создание проектного решения……С
Макетирование проектного решения……D
Оценка макетов……Е