Правила разработки программного обеспечения (+ CD)

Содержание

Введение к изданию 2006 года

Требования к системе .
Техническая поддержка.
Предисловие к изданию 1995 года .
Вводная часть к изданию 1995 года
Благодарности .
ЧАСТЬ I. 1995 год
Введение .

Подумайте об этом
Стадии игры .
Если вы не делаете коробочное программное обеспечение
Начальные шаги
Организация .
Контроль качества не важен?
Кто должен создавать проект?
Похоронный марш интеллектуалу
Дух группы .
Конкуренция
Немного антропологии .
Борьба программного обеспечения .
Клиент
Простая модель покупки
Проект .
Разработка.
Середина игры
Вы должны уметь отмечать прогресс .
Режим выпуска .
Режим выпуска: начало .
Режим выпуска: переходный период
Режим выпуска: окончание игры
СОДЕРЖАНИЕ VII
Запуск

Последнее слово .
Приложение. Как нанимать и удерживать хороших людей
Нанимайте умных .
Дайте людям перспективу .
Эклектичный список источников для лидера
в разработке программного обеспечения .
ЧАСТЬ II. 2006 год
Новые эмпирические правила
Элементы Системы ядра версии 3.0 .

Четыре шага к общему видению .
Протоколы ядра версии 3.0.
Обязательства ядра
Протоколы ядра .
Протокол пропуска (участия) .
Протокол регистрации
Протокол отключения .
Протокол запроса помощи
Протокол проверки протокола .
Протокол проверки намерений
Протокол принятия решения
Протокол разрешения
Протокол улучшения
Протокол персонального регулирования
Протокол исследования.
Об авторах.
Предметный указатель

Введение

Предмет этой книги — разработка качественного программного обеспечения (ПО) в срок — является, по крайней мере, на концептуальном уровне, простой задачей. Сначала вы изучаете пользователей и позиционируете себя на рынке. После этого вы определяете спецификацию продукта, который соответствует запросам рынка. Далее вы разрабатываете программный продукт, выпускаете его и занимаете достойное место в ряду основных производителей ПО. Вы постоянно фигурируете в журналах Fortune и на Интернет_сайтах. Конечно, поставка качественного ПО в срок — дело трудное. Наверно, поэтому до сих пор нет учебного пособия по этому вопросу. И, конечно, когда вы выведете волшебную формулу, люди будут думать, что вы всегда строго следовали ей. Позже я буду много говорить, как формулировать задачи для вашей организации и добиваться их выполнения. Однако, сейчас, с самого начала, еще раз утверждаю: самая трудная в мире задача — это выпуск качественного ПО в срок. Выпуск обычного ПО в срок — задача чертовски трудная. Выпуск качественного ПО в любые сроки — задача необычайно трудная. Выпуск качественного ПО в срок — редчайшее явление: вы должны определить насущные потребности клиента; найти подходящую команду разработчиков, ориентированную на нужды клиентов; так специфицировать продукт, чтобы он попал в зону наилучшего восприятия рынка; безукоризненно провести разработку и затем представить продукт на рынок под восторженные отзывы прессы. Ненасытные толпы трясущих кошельками клиентов построят палаточные лагеря у вашего магазина.

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

4 ЧАСТЬ I: 1995 год

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

Это не означает, что я презираю организационные и координационные усилия при создании ПО. Но совсем неглубоко под гладкой организованной поверхностью скрывается глубокая богатая психологическая феерия.

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

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

Подумайте об этом

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

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

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

Обычным результатом такого неправильного понимания является срыв сроков. Запаздывание — это обычное явление при разработке ПО. Как правило, запаздывание катастрофически велико, и не укладывается ни в какие рамки. Оно является объектом многих забавных шуток. И это было бы действительно смешно, если бы не разбитые надежды, промотанные деньги, впустую растраченный человеческий потенциал и потерянные доходы.

Истинная задача управления разработкой ПО заключается в том, чтобы привлечь как можно больше интеллекта и вкладывать этот интеллект во все сферы деятельности, связанные с созданием программного продукта. ИнСовсем неглубоко под гладкой, организованной поверхностью скрывается глубокая, богатая психологическая феерия. Чтобы поставлять качественное ПО в срок, надо учитывать каж- дую человеческую голову.

Интеллектуальная собственность

Интеллект может принимать различные формы абстрактных человеческих качеств, таких как творчество, ум, рассудительность, эффективность и четкость.

Интеллект может проявляться в таких нематериальных формах, как своевременность и соответствие требованиям клиента. Суть в следующем: для того, чтобы создать интеллектуальную собственность необходимо действительное участие создателей, а добиться этого участия — самая трудная вещь в процессе разработки ПО. Успевать вовремя — этого достаточно просто для людей, которые, каждый по отдельности и все вместе, думают об этом. И даже создание качественного ПО находится в пределах достижимости для интеллектуальной и сплоченной команды. Если осуществляется соответствующая финансовая поддержка проекта, то единственный реальный элемент, которого надо добиться, — это действительная полная вовлеченность команды. Все концепции и эмпирические правила, изложенные в этой книге, очевидны для людей думающих. Они, в самом деле, являются образцами здравого смысла. В основном, они касаются трех аспектов деятельности: как заставить человека думать, о чем люди должны думать, и как сделать человеческие мысли эффективными. Если вы когда_либо работали в интеллектуально вовлеченной команде разработчиков ПО, то, возможно, вы сами уже открыли для себя эти принципы.

Так в чем проблема? Поставка качественного ПО в срок — просто дело применения здравого смысла. Тогда, почему это так редко случается? Рассмотрим распространенную модель человеческой деятельности.

На большинстве предприятий вы вкладываете инвестиции в две принципиальные области: с одной стороны в интеллектуальную деятельность, с другой — в механические усилия. Эти две области можно называть: проектирование и производство, или разработка и создание. До сих пор большинство ресурсов предприятий (люди и финансы) уходили на механические усилия. Автомобиль, здание и автомагистраль, безусловно, имеют интеллектуальную составляющую. Но она, хотя и имеет решающее значение, относительно незначительна в общем объеме капиталовложений.

Давайте подумаем, как мы организуем промышленное предприятие. Основной его ценностью является эффективность, и вся организационные меры нацелены на ее достижение. Генри Форд занял свое место в истории, как "изобретатель" конвейера, основного производственного процесса 20_го века. Повторяющийся, количественно предсказуемый, неумолимо эффективный конвейер принимает сырье на одном конце и выдает осязаемую продукцию на другом. Появилось множество иерархических организаций для обеспечения и управления конвейерами. Каждый человек на конвейерном предприятии имеет маленькую, четко описанную роль.

В фирме, производящей ПО, ситуация обратная. Желаемым выходом является интеллектуальная собственность, а не осязаемый продукт. Доля механической составляющей крайне незначительна.

ВВЕДЕНИЕ 7

Управлять фирмой, производящей ПО на заказ, не сложнее, чем управлять фирмой, производящей потребительские товары умеренной сложности, например, фотоаппараты для широкого рынка. Реальные проблемы софтверной фирмы возникают в связи с неопределенностью, связанной с наличием "ювелиров", которые собственно и создают ПО. При наличии интеллектуальной собственности — готового программного продукта — проблем не возникает.

Неопределенности и сложности производства ПО связаны с интеллектуальной деятельностью. Традиционные организационные структуры и обычаи плохо приспособлены для перехода от механического производства к производству интеллектуальной собственности, с ее несговорчивой интеллектуальной деятельностью. Проблемы связаны с "сырьем" для интеллектуального продукта. Большинство коммерческих предприятий по своей природе не способно поощрять умственную деятельность. Вам следует несколько изменить форму своего предприятия. Вы должны понять все причины, по которым люди в вашей группе не работают творчески, и устранить их — причины, но не людей.

В этой книге мы постараемся нарисовать полную картину успешной фирмы по производству ПО. Эта картина не будет детализироваться до конкретных структурных подразделений. Для менеджера проекта важно понимать трудности, связанные с неопределенностью графика выпуска, в то время как для разработчика нужно полностью оценить критичность отдельных работ. До тех пор, пока отдельный исполнитель не имеет целостного представления о процессе, его вклад в работу будет ограничен выполнением сценария, написанного его руководителем или старшим программистом. А это есть потеря человеческого потенциала. Если вы хотите выпускать качественное ПО в срок, "каждая голова" должна быть на учете. Вовлечь каждого работника в процесс и держать его в этом процессе на протяжении всего проекта — это первостепенная обязанность руководителя и главная тема данной книги.

Стадии игры

Мы можем рассматривать программный проект как процесс, проходящий четыре основных стадии:

Начальные шаги включают создание разумной маркетинговой стратегии, проектирование продукта, создание плана разработки и первые шаги по разработке. Но первая сложная задача — она и в книге рассматривается первой — собрать работоспособную команду из хаоса, который царит в фирме. Эта стадия достигает своей кульминации в момент события, которое я называю "Трогательный день" — даты, начиная с которой можно говорить, что проект рассматривается всерьез.

Середина игры Это (обычно длительный) промежуток времени, начинающийся с момента первого нарушения графика разработки и оканчивающийся наступлением режима выпуска. По длительности и перенесенным страданиям середина игры напоминает 40 лет, проведенных народом в пустыне, до тех пор, пока бог не возглавил его, очистив от банды негодяев, состоящей из беглых рабов. Обычно середина игры длится менее сорока лет, но впечатление остается такое же. Горстка уцелевших участников проекта неведомым образом превращается в сплоченную группу, живущую с единственной целью: спихнуть это чертово ПО клиенту, и положить конец жутким мучениям.

Режим выпуска Туда вы попадаете, прежде чем выйти из этого ада. Выход существует только один. Как процесс рождения ребенка, это время боли и страха. И стадия эта неизбежна. Вы должны пройти стадию режима выпуска, чтобы родить. Единственное хорошее на этой стадии — нервная дрожь от неминуемых родов. Окончание игры — это последний, мучительный месяц (или около этого) кусания ногтей, который заканчивается выпуском продукта.

Запуск Незабываемый критический момент. Этот момент сохранится в сердцах и умах ваших клиентов навсегда — или до следующего запуска (зависит от того, что случится быстрее). После запуска продукт считается выпущенным.

Если вы не делаете коробочное программное обеспечение

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

Эта книга представляет собой наглядное и практическое пособие по разработке ответственного крупномасштабного программного обеспечения в срок. В ней рассматриваются 57 актуальных принципов (эмпирических правил), которых следует придерживаться в процессе разработки ПО. Вы узнаете, как создавать успешную команду разработчиков, соблюдать равновесие критических отношений между ее членами, достигать общего видения и более эффективно осуществлять поставку качественного программного обеспечения. Книга предназначена руководителям команд разработчиков программного обеспечения, а также всем участникам проекта: спонсорам, аналитикам, разработчикам, тестерам, техническим писателям и другим. На прилагаемом оригинальном компакт-диске находятся: популярная презентация Джима "23 1/2 эмпирических правила (для выпуска качественного программного обеспечения в срок)" и четыре эпизода из "Шоу Маккарти".