Салливан Эд. Время - деньги. Создание команды разработчиков программного обеспечения

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

Сборочные машины и лаборатории

   Сборочная среда — это набор приложений, инструментов, библиотек и компиляторов, нужных для компиляции и компоновки ПО. Часто лучше всего установить эту среду на нескольких выделенных сборочных машинах, которыми распоряжаются и управляют исключительно технологи по разработке ПО, изменения на этих машинах недопустимы. Важно обеспечить и регулярное резервное копирование дисков этих машин, чтобы восстановление было простым и быстрым. А чтобы избавиться от неожиданных трудностей, не забудьте установить антивирусное ПО.
   С ростом числа ваших сборочных машин потребуется целая сборочная лаборатория. Лаборатория полезна, когда нужно параллельно собирать действительно большие программы или большое количество программ (возможно, по ночам). Сборочная лаборатория поможет обезопасить наши машины и предотвратить посторонние вмешательства, способные привести к сбою.

Оповещение и сбои

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

Проверка

   Созданная сборка должна быть помещена на сетевой диск с совместным доступом, где она будет проверена при помощи автоматических тестов, созданных командой тестирования. Проверка — очень важный этап, так как наличие готовой сборки ещё не означает, что продукт в рабочем состоянии. Вы знаете только то, что можете компилировать, и компоновать все нужные файлы.
   Один из лучших способов проверить сборку — установить продукт и запустить базисные тесты (см. о них главу 6). Для эффективного управления этим процессом для сборок следует завести два каталога.
   • Самая последняя сборка (MRB)
   В этом каталоге хранится самая последняя сборка программы. Однако она может и не устанавливаться или не работать правильно.
   • Последняя хорошая сборка (LKGB)
   Здесь хранится последняя хорошая сборка. Убедившись в том, что текущая сборка находится в хорошем состоянии (она установилась и прошла базисные тесты), скопируйте содержимое каталога MRB в каталог LKGB.
   Для своей повседневной работы команда должна производить установку из каталога LKGB. Обычно команда, отвечающая за контроль качества, перемещает последнюю сборку в LKGB сразу после её проверки. Если в последней сборке обнаружены проблемы, команда все равно может работать, так как сборка в каталоге LKGB является рабочей.

Штрафы и измерения

   Как я говорил в главе 5, в NuMega решили обойтись без большого числа технологических приёмов (процессов). Но к процессам, которые у нас имелись, мы относились очень серьёзно и следовали им. Сборка являлась одним из них. Мы решили, что если кто-то ломает сборку, то на следующее утро он покупает пончики на всю команду. Такая простая, но эффективная стратегия подчеркнула необходимость работы над сборкой должным образом и установила наказание за её порчу. В тех командах, где не было технологов, сломавший сборку брал на себя обязанности по технологической поддержке до следующего сбоя.
   Другим способом подчеркнуть важность процесса сборки является его измерение. Следите за тем, сколько раз за период времени в сборке происходит сбой, и, возможно, за тем, из-за кого сбои происходят чаще всего. Знание того, что за процессом сборки наблюдают, подстёгивает людей к самодисциплине при сдаче исходных файлов. Также вы можете наблюдать за тем, сколько времени команда работает, не ломая сборку, и предложить стимулы для достижений в этой области. В больших организациях можно подумать об организации соревнования с другими командами.

Частота сдачи и проверки сборки

   Чтобы не сломать сборку, ответьте на следующие вопросы.
   • Когда я должен сдать мой код?
   Сдавайте свою часть кода, когда у нас есть что добавить к проекту. Это может быть сосём простое добавление, скажем, набор заглушек API, или очень сложное, например, крупный компонент. Но вы должны сдавать свой код часто. Смысл в том, чтобы как можно раньше заставить работать код, созданный разными людьми.
   • Как я могу быть уверен в том, что не испорчу сборку?
   Если возможно, для проверки кода осуществите локальную сборку программы. Вы как обычно берете код из системы управления исходным кодом, интегрируете ваш код и возвращаете его в систему. В большинстве проектов эта процедура выполняется просто, и это отличный способ гарантировать то, что вы не испортите сборку. Дополнительно, чтобы убедиться в отсутствии новых ошибок, можно запустить входные тесты (см. главу 6).

Процедура установки

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

Почему это важно

   Процедура установки служит для выполнения двух важных функций. Во-первых, она заставляет команду думать об установочной среде, которая требуется для продукта. Процедура установки требует от вас знания состава приложения: образов, библиотек, компонентов, файлов справки, библиотек типов и т.д. Также она заставляет вас определить исполняющую среду, в том числе поддержку драйверов баз данных, стандартных компонентов и операционных систем. Если вы сохраните компоненты продукта целыми и актуальными, вы сможете избежать проблем в дальнейшем.
   Во-вторых, при наличии процедуры установки у членов команды имеется простой доступ к самым последним сборкам программы. Им не нужно запоминать все ненужные подробности по поводу установки программы, такие как местоположение файлов, процедур регистрации компонентов, команд запуска, параметров реестра и т.д. Они могут просто установить продукт и использовать его для своих целей. Примеры использования перечислены далее.
   • Разработчики смогут увидеть свои компоненты со стороны официальной сборки и оценить проблемы, используя ту же процедуру установки, что и вся команда.
   • Тестировщики будут устанавливать программу обычным образом и тестировать её на наличие проблем. Работать с последней сборкой будут как автоматические регрессивные тесты, так и вся команда, которая будет тестировать последнюю хорошую сборку. Это обеспечивает тестирование самой последней и наиболее стабильной версии программы. Единая официальная сборка упрощает и определение работоспособности компонентов. То, что разработчику удаётся заставить компонент работать на своей машине, не имеет значения, если компонент не работает в официальной сборке. Если в официальной сборке компонент, установленный при помощи текущей процедуры установки, не заработал, значит, он не работает вообще.
   • Для корректного составления документации техническим писателям нужно видеть, использовать и оценивать программу. Доступ к сборке, которую можно установить, заметно ускоряет их работу, так как новые возможности, добавленные разработчиками в сборку, видны и могут быть документированы на следующий день.
   • По мере развития сборки специалисты по инженерной психологии смотрят за тем, как пользовательский интерфейс продукта претворяется в жизнь, оценивают его и дают рекомендации. Без официальной сборки у психологов нет простого доступа к компонентам, с которыми они должны работать. В итоге проколы и несогласованности проекта обнаруживаются в процессе разработки слишком поздно.
   • Значительно расширяются возможности менеджера проекта. Наличие официальной сборки обеспечивает отличное видение текущего состояния проекта. Состояние компонентов, параметров производительности, качества онлайновой справочной системы и т.д. перестаёт быть секретом.
   • И, наконец, имея процедуру установки на раннем этапе, расширяется обратная связь с другими группами, такими как менеджеры продукта, специалисты по технической поддержке и отдел продаж. Каждая из этих групп даст ценные отзывы о продвижении продукта, а также сможет отловить несколько ошибок.

Как её создавать

   Хотя конкретные детали по применению значительно отличаются для разных продуктов и приложений, подход к процедуре установки всегда одинаков. Вы начинаете создание процедуры установки в самом начале проекта и со временем наращиваете её.

Скелет

   Первый шаг в создании процедуры установки — конструирование скелета. Задача проста: сделать так, чтобы первый набор файлов был скопирован в каталог установки, Если даже программа не может сделать ничего, кроме как вывести на экран надпись «Hello World», для неё нужно создать процедуру установки. Она не должна быть сложной, но вам по крайней мере следует создать инфраструктуру, на основе которой начнётся строительство.

Мышцы

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

Комплект

   Это набор файлов, поставляемый пользователю. В процессе создания комплекта процедура установки связывается с устанавливаемыми файлами. Результатом часто является набор сжатых файлов, не представляющих того, что реально будет помещено на систему пользователя. Хорошо бы знать, что применяется в процессе создания комплекта и что получается на выходе. Неплохо разработать и тест, проверяющий наличие нужного числа файлов с приблизительно правильной датой и размером. Для этого могут быть очень полезны приложения, автоматически проверяющие содержимое комплекта.

Сбор всего вместе

   Когда у вас есть сборки и процедура установки, следует собрать все вместе в автоматизированный конвейерный процесс. Процесс должен быть создан в самом начале проекта, возможно, это должно быть первой задачей.
   Главные шаги цикла сборки таковы:
   • сборка образов;
   • создание комплекта;
   • тестирование комплекта;
   • отправка сообщения о прохождении теста или сбое;
   • запуск базисных тестов для проверки сборки;
   • если тест пройден удачно, копирование в каталог LKGB;
   • отправка сообщения о прохождении базисного теста или о сбое.

Ежедневные сборки, комплекты и тесты

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

Убеждение

   В организациях, где уже приняли эти правила, люди знают, что сборки, установки и базисные тесты могут выполняться ежедневно. Но в других организациях сотрудники могут отнестись к этому скептично. Обычно они слишком заняты, у них нет ресурсов, и они противятся выполнению лишней работы. У кого есть время на эту ерунду? Я бывал в таких фирмах и знаю, что это сложно. Но выгода огромна, и вы можете внедрить эти принципы. Я рекомендую сначала убедить команду в этих идеях, а затем реализовывать их шаг за шагом: сначала создавать рабочие сборки, затем процедуры установки и, наконец, базисные тесты.
 
   Из собственного опыта
   Вначале принцип ежедневной сборки был новым для нашей компании. Мы были небольшой командой, и запускать процесс ежедневной сборки было сложно. Не хватало поддержки, достать сборочную среду, машины и наладить процессы было тяжело.
   Однажды я спросил, была ли сегодняшняя сборка уcпешной. Коллега ответил: «Ты что, считаешь, что мы должны создавать эту сборку каждый день?» Да, каждый день. Это часть нашей модели разработки, и это критично для способа, которым мы работаем.
   Спустя годы смешно оглядываться на те дни. Сейчас ежедневные сборки — часть нашей культуры, чему никто не сопротивляется. Это само собой разумеется, и когда в сборке происходит сбой, мы видим справедливый гнев всей команды.
 

Типичные проблемы и их решение

   Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.

Отсутствие технологов по разработке ПО

   Не забудьте учесть в планах и графике вашего проекта мероприятия по технологическому обеспечению. Некоторые команды не учитывают значительный объём работ в этом направлении. В результате их часто ожидают сюрпризы и необходимость корректировки графиков.

Недостаточная автоматизация

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

Запоздалая процедура установки

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

Дисциплина

   Ежедневное создание сборок, комплектов и тестирование требует много сил. Если дисциплина в команде недостаточно высока или проблемы остаются неразрешёнными, вы не сможете воспользоваться преимуществами, о которых мы говорили ранее. У команды должна быть культура решения проблем. Каждый член команды должен быть дисциплинирован и бороться с проблемами с момента их появления.

Часть 2
Формулирование и планирование проекта.

Глава 8
Требования

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

Центральная идея проекта

   В начале работы над каждым выпуском нужно добиться простого и ясного видения проблемы, при котором задачи и приоритеты проекта стали бы очевидными для всех его участников; критически важно объединить их усилия и гарантировать, что группа будет работать сообща.
   Атрибутом хорошего видения проблемы является центральная идея (лейтмотив проекта), которая сплотит группу и даже всю компанию воедино. Она должна не только направлять усилия при разработке, но и способствовать позиционированию, сбыту и продвижению продукта на рынке. Вокруг неё должны объединиться все группы, обеспечивающие коммерческий успех продукта.
   Хотя у крупных проектов может быть несколько таких идей, распыляться всё же не стоит. Основная идея проекта должна быть сформулирована кратко и ясно, в ней должен быть призыв к превосходству в одной-двух областях. Выбрать её нелегко, обычно такая идея является результатом тщательного анализа рынка и состояния бизнеса в данной области. Убедитесь, что достижение цели, поставленной основной идеей, принесёт значительную прибыль.
   Мы в NuMega всегда пытались сделать выпуск каждого продукта волнующим событием, претендуя на самый короткий срок его создания, либо на первенство в использовании новых технологий, вплоть до того, что целью ряда наших проектов было получение премий в нашей отрасли. Вот ряд идей, которые в прошлом позволили эффективно объединить наши усилия по разработке:
   • закрыть путь на рынок новым конкурентам, предоставив программистам на языке C/C++ продукт с самым полным набором функций по обнаружению ошибок;
   • создать продукт для анализа производительности, самый простой в эксплуатации во всей отрасли, и добиться признания этого факта;
   • создать самый мощный и функционально насыщенный отладчик ядра Windows NT.
   Мы руководствовались этими идеями при выборе функций продукта и в процессе их реализации. Они также играли главную роль, когда приходилось идти на компромисс. Например, если приходилось выбирать одну из двух взаимоисключающих возможностей, достаточно было одного взгляда на центральную идею проекта, чтобы стало ясно, какую из них выбрать.

Поиск и решение пользовательских проблем

   Сформулировав центральную идею проекта, надо сосредоточиться на потребностях пользователя. На этом этапе процесса формулирования требований следует рассматривать те проблемы, что необходимо решить пользователю, а не конкретные действия, которые он хотел бы выполнять. Возьмём в качестве примера одну из формулировок идеи проекта из предыдущего раздела. Если нужно предоставить программистам на C/C++ наиболее полный продукт для обнаружения ошибок, то надо выяснить, какие ошибки являются наиболее распространёнными и труднее всего поддаются обнаружению. Вот ещё один пример: если нужен самый простой в использовании продукт для анализа производительности, нужно понять, какие сведения о производительности критичны для пользователей и в каком виде они хотели бы их получить.
   Чтобы понимать пользовательские проблемы, важно поддерживать обратную связь с клиентами для проверки сделанных предположений. Лучший способ убедиться в разумности своих планов и преодолеть внутренние разногласия — иметь обратную связь, заслуживающую доверия.
 
   Из собственного опыта
   При работе над BoundsChecker 3.0 было много прений вокруг набора функций продукта. Несколько недель обсуждения этого предмета, порой доходившего до жарких споров, прошли без видимого прогресса. Было принято совместное соглашение оставить этот вопрос, чтобы избежать возобновления споров. Чтобы выйти из тупика и поднять боевой дух группы, мы решили пригласить группу заказчиков и потенциальных пользователей на вечеринку с угощением и раздачей призов. Там мы продемонстрировали разные идеи о возможных функциях программы и попросили приглашённых высказать своё мнение. На основе информации извне стало намного легче прийти к компромиссу и выработать решение, у которого были неплохие шансы на успех.
 

Формулирование требований

   Когда установлено общее видение проекта и достигнуто понимание пользовательских проблем, пора переходить к определению требований. Как сформулировать требования, насколько подробными должны быть формулировки и как ничего не упустить?
 

Общие и частные требования

   Один из лучших способов дать чёткое описание набора требований к проекту — представить его в виде схемы. Самый высокий уровень схемы занимают общие требования. Они объединяют совокупности частных требований, которые, таким образом, можно обсуждать, оценивать, сравнивать и утверждать как единое целое. Нужно иметь возможность анализа общих требований и обладать совершенным пониманием их основных целей. Общих требований не должно быть слишком много, так как каждое в свою очередь генерирует ряд второстепенных требований. Например, в случае компании, которой надо адаптировать имеющееся приложение обработки заказов для работы в Интернете, достаточно пяти общих требований:
   • разработать интерфейс на базе браузера;
   • повысить производительность до уровня, приемлемого для Web-пользователей;
   • организовать рассылку уведомлений о выполнении заказов по электронной почте;
   • добавить к программе новые возможности, которые повысят производительность пользователей;
   • предусмотреть применение в будущем в качестве клиентской платформы карманных компьютеров.
   Каждое общее требование должно подразделяться на несколько частных. С последними могут быть связаны и другие требования, конкретизирующие или поясняющие функциональность требований более высокого уровня. В результате документация может принять такой вид:
   • Общее требование 1
   •• Частное требование 1
   ••• Частное требование нижнего уровня 1.1
   ••• Частное требование нижнего уровня 1.2
   •• Частное требование 2
   ••• Частное требование нижнего уровня 2.1
   ••• Частное требование нижнего уровня 2.2
   Ниже приводится пример некоторых общих и частных требований, организованных в соответствии с вышеописанной структурой.
 
   • Разработать интерфейс на базе браузера для приложения по обработке заказов.
   • Функциональные требования.
   •• При размещении заказа:
   ••• Ввести для каждого заказа следующую информацию (по пунктам).
   ••• Проверить идентификатор покупателя.
   •• Удалить заказ.
   •• Проверить статус заказа.
   •• Сгенерировать подтверждение заказа.
   • Обеспечить поддержку следующих браузеров:
   •• Microsoft Internet Explorer версии X.
   •• Netscape версии Y.
   • Производительность должна быть приемлема для Web-пользователя.
   • Требования ко времени реакции системы:
   •• Размещение заказа должно занимать менее 3 секунд.
   •• Удаление заказа должно занимать менее 6 секунд.
   •• Проверка статуса заказа должна занимать менее 4 секунд.
   •• Подтверждение заказа должно занимать менее получаса.
   • Облегчить использование приложения с помощью новых возможностей:
   •• Разрешить заказ нескольких товаров в одном заказе.