Рис.3-1. Связи между менеджером проекта и ведущими специалистами функциональных подразделений.

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

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

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

• Подбор кадров и управление ими

Менеджер проекта отвечает за создание команды и управление её составом. Он также курирует кадровое обеспечение, планирование карьеры, кадровую политику, анализ и проверку работы сотрудников и поддержание «боевого духа» группы. В его обязанность также входит найм новых сотрудников, повышение мастерства и развитие навыков специалистов, а также поддержание мотивации и целенаправленной деятельности людей во время работы над проектом.

• Формулирование и исполнение плана проекта

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

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

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

Менеджер проекта создаёт главный график работ на основе сведений, поданных всеми участниками проекта. Как правило, в соответствии с этим графиком работа над проектом подразделяется на ряд промежуточных этапов и базовых уровней. Менеджер проекта должен непрерывно следить за исполнением графика, вносить нужные изменения и сообщать о них группам разработчиков и другим группам, в сотрудничестве с которыми ведётся работа (группы менеджмента, технической поддержки и администраторов бета-тестирования), а также верхнего эшелона управления. Подробнее мы поговорим о планировании в главе 11.

• Руководство командой

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

• Обеспечение связи между подразделениями

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

Менеджер проекта также является главным каналом связи между группами разработчиков, технической поддержки и администраторов бета-тестирования. Он должен решать любые критические проблемы, возникающие как во время тестирования продукта клиентами (бета-тестирования), так и после выпуска;

• Обеспечение готовности продукта

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

Можно выделить три основных категории технических специалистов: ведущий разработчик (программист), ведущий программист, отвечающий за реализацию определённой функции и рядовой программист (рис. 3-2).

Рис. 3-2. Связи между ведущим разработчиком, ведущими программистами, ответственными за реализацию определённых функций ПО, и рядовыми программистами.

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

• наблюдение за соблюдением архитектурных и технических спецификаций продукта;

• подбор ключевых технологических инструментов и стандартов;

• диагностика и разрешение всех технических проблем;

• выполнение роли технического инструктора и консультанта для участников проекта;

• наблюдение и контроль за работой групп разработчиков документации, тестировщиков и технологов;

• мониторинг состояния (ведение списка обнаруженных ошибок);

• подбор инструментов разработки, метрик и стандартов и наблюдение за их использованием;

• ну и, конечно, программирование, программирование и ещё раз программирование.

Отвечают за реализацию отдельных функций продукта, часто на основе конкретной технологии. Обычно определение функций формулируют довольно широко, например, «интеграция с IDE» или «разработка API доступа к БД». Обязанностями ведущих программистов, отвечающих за создание отдельных функций ПО, являются:

• согласование архитектурных вопросов с коллегами, ответственными за разработку других функций;

• формулирование требований к функциям и их критический анализ;

• проектирование функций;

• снабжение тестировщиков и разработчиков документации техническими материалами;

• ну и, конечно, программирование, программирование и ещё раз программирование.

Работают над реализацией определённой функции ПО обычно под руководством ведущего программиста, ответственного за эту функцию. Они отвечают за реализацию конкретных аспектов этой функции, например, за «интеграцию в IDE окон X, Y и Z» или «написание для API баз данных методов create, update и delete». В круг их обязанностей входит:

• реализация функции;

• её тестирование;

• исправление ошибок в реализованной функции;

• помощь техническим писателям в документировании реализованной функции;

• помощь тестировщикам в испытаниях этой функции.

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

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

В NuMega удалось избежать обеих проблем, передав право окончательного решения вопросов о качестве ПО в руки менеджера проекта. Он должен предоставить качественный продукт, и именно с него спросят за любые проблемы с продуктом. Принимая решение о готовности продукта, ему приходится полагаться на результаты испытаний, проведённых группой тестировщиков. Такая структура организации (рис. 3-3) позволяет группе тестировщиков оставаться независимой, так как она является самостоятельным подразделением под руководством своего ведущего специалиста. Однако, будучи подотчётными тому же менеджеру, что и разработчики, они ощущают, что их воспринимают так же, как любых других участников группы, и обращаются с ними соответственно. Подробнее о тестировании будет сказано в главе 6.

Рис. 3-3. Связи между группами разработчиков и тестировщиков.

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

• Составление плана тестирования продукта

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

• Исполнение плана тестирования

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

• Автоматизация испытаний

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

• Проведение регрессивного тестирования

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

• Выбор инструментов, метрик и стандартов для тестирования

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

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

• планирование испытаний;

• автоматизация испытаний;

• оценка и выбор инструментальных средств.

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

• тестирование программы установки, всех функций и пользовательского интерфейса согласно плану тестирования;

• проведение автоматизированных испытаний;

• регистрация результатов автоматизированных испытаний и анализ обнаруженных неполадок;

• окончательное подтверждение устранения ошибки;

• подготовка среды для испытаний.

Обеспечивает пользователя справочными материалами: печатной документацией, электронной справочной системой, обучающими программами и карточками быстрой справки.

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

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

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

• Поскольку разработчик пользовательской документации создаёт руководство, описывающее использование продукта, часто именно он первым обнаруживает несогласованности, проблемы с функционированием продукта и недостатки в реализации функций. Нет ничего необычного, когда технический писатель заявляет: «Да, на собрании, посвящённому анализу спецификаций, у меня никаких вопросов не возникло. Но теперь, когда я начал писать руководство пользователя, мне ясно, что пользователю придётся выполнить целых десять действий, чтобы решить эту задачу, — чепуха какая-то!» Таким образом, он на ранних стадиях цикла разработки выполняет весьма ценную параллельную проверку удобства использования программы и даёт отзывы, позволяющие скорректировать недочёты.

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

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

Мы в NuMega всегда были убеждены, что именно первые 20 минут общения с нашим продуктом определяют, примет ли его пользователь и будет ли продолжать с ним работать. Это явление получило название «первоначальное впечатление от работы с продуктом». Если продукт не оставил у пользователя положительного впечатления и не помог ему легко и быстро решить свои проблемы, маловероятно, что этот продукт будет регулярно использоваться или будет по-настоящему ценным для потребителя.

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

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

Специалист по инженерной психологии должен:

• транслировать формулировки требований в ключевые задачи;

• разрабатывать дизайн пользовательского интерфейса (макеты диалоговых окон и т.д.) для решения этих задач;

• тестировать разработанный дизайн и согласовывать его с командой;

• определять, как сформировать положительное первоначальное впечатление от продукта;

• проводить подгонку и доводку пользовательского интерфейса;

• работать с заказчиком после выпуска ПО.

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

В общем случае у технолога по созданию ПО три основные обязанности:

• Создание и сопровождение подходящей среды для сборки продукта

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

• Создание и сопровождение процедуры установки

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

• Сопровождение и администрирование систем управления исходным текстом

Важно, чтобы за сопровождение системы управления исходным текстом постоянно отвечал один и то же специалист. Об инструментах для управления исходным текстом см. главу 4.

С точки зрения технических подразделений, эта группа играет две роли; первая — сбор информации, а вторая — её выдача.

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

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

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

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

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

• формулирование требований к функциям программы с целью облегчения её технической поддержки в дальнейшем;

• привлечение внимания разработчиков к важным проблемам с качеством и реализацией функций во время бета-тестирования продукта и после его выхода;

• предоставление статистики поступающих обращений за технической поддержкой (упорядоченной по типу и степени серьёзности проблемы, а также по числу обращений) и демонстрация необходимости исправлений или изменений программы;

• помощь в решении проблем с пользовательским интерфейсом путём проверки ранних версий (альфа-версий) продукта, при заминках с тестированием и при исправлении ошибок — здесь группа технической поддержки выступает в роли независимого эксперта.

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

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

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

Отвечает за планирование, управление и исполнение программы бета-тестировaния. Хорошо проведённая программа бета-тестирования способствует успеху продукта, обеспечивая поступление отзывов о нём из реального мира. Важность бета-тестирования столь велика, что я посвятил этому вопросу целую главу. Но пока просто рассмотрим основные обязанности администратора программы бета-тестирования:

• поиск, проверка квалификации и привлечение кандидатов в бета-тестеры;

• распространение инструкций и ПО среди бета-тестеров;

• рассылка кандидатам в бета-тестеры анкет и других необходимых материалов;

• опубликование результатов бета-тестирования внутри группы;

• постепенное усовершенствование процесса бета-тестирования.

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

• Слишком расплывчатый или, наоборот, чересчур жёстко определённый круг обязанностей

Даже самым талантливым людям нужно объяснять их роли и обязанности. Они должны представлять, что от них требуется, чтобы знать, чему посвятить своё время. Формулировки обязанностей должны быть подробными и ориентированными на решение тех или иных задач. Но не переусердствуйте с этим, иначе эти формулировки станут слишком формальными и жёсткими. Вряд ли нужно, чтобы участники группы лишь цитировали описание их задания, когда пора уже выпускать продукт. Главное — избежать основных просчётов при исполнении проекта, а не пытаться управлять всем и всеми, даже в мелочах (см. описание обязанностей специалистов, приведённое в этой главе);

• Дисбаланс подразделений

Одно лишь наличие модели, которая поощряет равновесие навыков и опыта специалистов различных подразделений не означает, что обеспечение проекта кадрами осуществлялось как надо. Постоянно следите за балансом ресурсов функциональных подразделений проекта. Например, хватает ли в группе тестировщиков для реализации проекта? Бессмысленно держать 4-5 тестировщиков на 100 разработчиков, даже если первые обладают необходимыми навыками. Отношение числа разработчиков к числу тестировщиков критично для проекта и должно быть сбалансировано. Значение этого отношения зависит от потребностей проекта, но большинство организаций стремится поддерживать его между 2:1 и 4:1. Даже если не соблюдать такое отношение, тестирование всё равно придётся проводить, только в этом случае оно займёт больше времени.

• Недостаток масштабируемости

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

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

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

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

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

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

Само по себе понятие рейтинга не ново. Одни из примеров — спортивные команды, возводящие самых результативных спортсменов в ранг «привилегированных». Их значение для команды настолько велико, что с ними заключаются контракты на особых условиях. В некоторых организациях, занятых в создании ПО, рейтинг воплощён в системе должностных титулов. Например, используют такие приставки к названию должности, как «специалист первого (или второго) ранга», «старший» или «главный» специалист. Во всех примерах ранг служит для решения важных кадровых вопросов.

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

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

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

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

Здесь также можно встретить людей, которые работают неплохо, но обычно не демонстрируют исключительных качеств. Они стабильны, надёжны и последовательны, но их никак нельзя назвать выдающимися. Создание текущей версии продукта во многом зависит от их способностей, однако их нельзя считать «ключевыми игроками».

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

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

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

• Поощрение заслуженных сотрудников

Ранжирование позволяет отметить заслуженных сотрудников. Если специалист-«суперзвезда» пять лет трудился на благо группы, то факт принадлежности этого человека к внутреннему кругу и особого отношения к нему важен не только для него, но и для других членов группы. Он свидетельствует о том, что организация видит личный вклад сотрудника, благодарна за него и вклад других людей со временем также заслужит признание.

• Распределение привилегий и ограниченных ресурсов

Когда в компании появляются новые привилегии и ресурсы, которые нельзя разделить поровну, возникает вопрос: кому отдать предпочтение? Хорошая мысль — определить достойных по их рангу. Неважно, что это будет: захватывающие исследования новой технологии, посещение выставки, собственный кабинет или встреча с клиентом на Гавайях, — ранжирование даёт упорядоченный список авторов наибольшего вклада в успехи компании, которые будут первыми кандидатами на получение привилегий.

Значит ли это, что все блага будут доставаться лишь людям внутреннего круга? Вовсе нет. Если все работники внутреннего круга уже обеспечены, а некоторая привилегия имеет особое значение для другого работника, наверное, разумно было бы отдать ему эту привилегию. Важно, чтобы все привилегии не доставались лишь одному кругу — вместе с членами внутреннего круга что-то должны получать и люди среднего и внешнего кругов. И всё же основной принцип остаётся в силе: достойны заботы лишь те, кто заботится об успехе продукта.

• Планирование денежных компенсаций

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

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

• Планирование кадровой политики

Один мудрец как-то сказал мне, что текучесть кадров подобна ветру: не беда, если он сорвёт большую часть листьев (т.е. если уйдёт много людей внешнего круга): пройдёт немного времени, и они вырастут снова. Намного хуже, если ветер повредит ветви (средний круг) или ствол (внутренний круг) — их трудно восстановить и они долго растут. Мораль проста: если компанию покидают люди среднего и внутреннего кругов — это признак серьёзной проблемы, которую нужно решить. Ранжирование помогает разобраться, где появилась текучка и какой ущерб она наносит группе.

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

Большие привилегии означают и более высокую ответственность. В случае ранжирования как никогда верна старая поговорка: «положение обязывает». Не допускайте, чтобы привилегии, которыми наделены сотрудники в соответствии с их рангом, были больше возложенной на них ответственности. Если что-то одно начинает перевешивать, жди проблем, малых и не очень.

Из собственного опыта

В NuMega мы в шутку называли наших инженеров «богами», «полубогами» и «учениками богов». Хотя все работники компании были по крайней мере хорошими, а большинство — отличными специалистами, не все вносили одинаковый вклад в дело компании.

Чем больше вклад сотрудника, тем больше у него было возможностей и свободы. Но взамен от них ожидали новых идей и способности возглавить остальных, при необходимости направить их усилия и помочь советом. Поскольку большинство наших «cуперзвезд» были не только талантливы, но и скромны, признание их вклада редко вызывало у других отрицательные эмоции.

Когда люди меняются

Что происходит, когда член внутреннего круга начинает вести себя, как член внешнего? Или наоборот, когда новичок поражает всех качеством своей работы?

В первом случае лучше всего обсудить возникшие проблемы с этим человеком, представив ему конкретные факты в подтверждение снижения эффективности его труда. Часто такое обсуждение позволяет выявить источник проблемы: может, это упадок сил или какие-то личные проблемы? Вооружившись этим знанием, можно попробовать сразу же решить эту проблему с большими шансами на успех.

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

К чему стремиться

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

Корпоративная культура

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

Почему культура так важна?

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

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

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

Как воспитать корпоративную культуру?

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

Из собственного опыта

Воспитывая корпоративную культуру NuMega, мы специально предпринимаем ряд конкретных действий.

• Чётко определяем, кто мы и какие цели преследуем

Нам совершенно ясно, кто мы и что должны делать. Звучит довольно просто, да? Но на деле это не так просто, как кажется.

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

• Культивируем элитарность

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

• Отмечаем успехи и помним свою историю

Со временем в компании сформировалась история выпуска замечательных продуктов, успешных как в техническом, так и в экономическом отношении. «Отцы-основатели» постоянно приводят эти успехи в качестве примеров на собраниях и неформальных встречах. Все следят за тем, чтобы каждый новичок знал историю и путь развития компании. Это стимулирует формирование культуры стремления к успеху, создания замечательных продуктов и заставляет быть экспертом в выбранной нами области.

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

• Поддерживаем дух соперничества

Ставя цель перед коллективом, мы чётко определяем правила соревнования и относимся к поставленным целям, как к врагам, после чего, «сомкнув ряды», атакуем их. Цель соревнования очень чётко обозначена и пронизывает предметы наших многочисленных обсуждений и размышлений. Порой обсуждения проходят так оживлённо, что мысли переливаются через край, принимая причудливые формы; чего стоят те трюки, которые творят разработчики. Наглядевшись на это, я понял: эта команда сделает всё возможное и невозможное, чтобы добиться успеха, и нам удалось сформировать замечательную культуру соперничества.

• У нас свои способы отдохнуть и весело провести время

У работников технических компаний есть два удовольствия: возможность от души повеселиться и разные способы отдохнуть от повседневных забот. У нас куча всяких вещиц: футболок, рекламных материалов с выставок, бесплатных обедов, кроме того, «NuMega specials» (пицца с поджаренным луком, чесноком и жгучим «чили»), самодельные площадки для гольфа и велосипедные дорожки прямо в помещениях компании. Всё это формирует атмосферу исключительности и веселья. Мы знаем, что это очень нетипично, но это нам и нравится!

• Не прячем своих разработчиков от клиентов

В NuMega искренне убеждены, что разработчиков не следует прятать от клиентов. Проще всего попросить их присутствовать на стенде компании на какой-нибудь выставке. Там они смогут не только отдохнуть от работы, но и попадут на передний край общения с клиентами, смогут ответить на их вопросы, получить новые идеи и услышать о созданных ими продуктах как хорошее, так и плохое.

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

***

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

• ценит выполненную вовремя работу?

• ценит техническое превосходство?

• ценит высокое качество?

• ценит даже минимальный вклад?

• поощряет риск?

• поощряет исключительную производительность труда?

• проявляет благородство?

• небезразлична к социальным проблемам?

• считает, что каждый должен принимать участие в тестировании продукта?

• оперативно реагирует на внешние угрозы?

• считает, что тестирование практичности программы имеет решающее значение?

• считает сверхурочную работу обычным делом при отставании от графика?

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

Корпоративная культура и технологические приёмы

Другой аспект культуры состоит в использовании и освоении внутренних технологических приёмов. Характерной чертой некоторых культур является наличие множества технологических приёмов разработки, в то время как у других их почти нет. Молодые компании часто неохотно осваивают новые технологические приёмы, тогда как в более крупных организациях без них не обходится ни одно задание. По мере роста группы следует подумать о том, как вы собираетесь осваивать новые технологические приёмы. Какие типы приёмов необходимы, а без каких можно обойтись? Как не впасть в крайность, пустив всю работу на самотёк или изнурив себя разными правилами и положениями?

Вот некоторые правила, которых полезно придерживаться при росте организации:

• Взвешивайте затраты на внедрение технологических приёмов и пользу от них

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

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

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

• Прежде, чем внедрять новые приёмы, нужно извлечь максимум из имеющихся

Один из самых обескураживающих аспектов разработки ПО — внедрение новых приёмов, в то время как команда не полностью использует все возможности имеющихся. В вашей команде так быть не должно. За правильное использование имеющихся приёмов отвечают менеджеры и ведущие специалисты. Можно потерять доверие участников команды, санкционируя добавление новых технологических приёмов и игнорируя те, что уже есть. Если обнаружится, что ни один из имеющихся документированных приёмов не используется полностью, созовите собрание группы и решите, представляют ли они ценность. Да — оставьте их и используйте «на все сто». Нет — избавьтесь от лишних технологических приёмов. Что толку держать приёмы, развесив их по стенам, как картины? Они только портят интерьер.

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

• Взвешивайте потребности отдельного специалиста и всей команды

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

Из собственного опыта

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

Представляет ли новый приём ценность для компании? Иногда — да, когда дополнительная точная информация позволит легче устранять ошибки, но число таких ошибок не превышает 5-10 в месяц. Однако затраты на ввод этой информации, который должны были выполнять 15 человек на протяжении всего внутреннего цикла разработки (особенно когда приходилось регистрировать до 10 ошибок в день), не стоили потенциальной пользы. Кроме того, большинство ошибок воспроизводилось на любой машине, в противном случае было нетрудно связаться с офисом, откуда поступило сообщение об ошибке, и выяснить необходимую информацию о конфигурации.

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

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

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

Проблемы с ранжированием

• Не держите ранжирование в секрете

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

• Не затрудняйте переход из одного круга в другой

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

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

• Не заводите фаворитов

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

• Играйте честно

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

Проблемы с культурой

• Культуру можно изменить

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

• Если организация растёт

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

— кто мы?

— чем мы занимаемся?

— почему мы делаем своё дело лучше, чем кто-либо другой?

— чем мы отличаемся от других?

— что мы ценим?

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

Глава 5

Инструментальные программы

В компании NuMega мы использовали лишь те инструментальные программные средства, которые были жизненно необходимы для нашей работы и вписывались в наш стиль работы. Из всех доступных инструментов мы больше всего применяли и полагались на систему управления исходным кодом и систему устранения проблем и неисправностей (поиска «жучков»). Возможность приспосабливать эти продукты к нашим нуждам позволила ускорить работу — вся команда использовала их почти каждый день.

Средства управления исходным кодом

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

О чём пойдёт речь

Продукты по управлению исходным кодом хранят файлы с кодом, отслеживают их версии, управляют файлами, составляющими проект, и предоставляют следующие функции.

• Хранение файла и его прошлых, настоящих и будущих версий

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

• Отслеживание истории изменений для каждого файла

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

• Группирование файлов

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

• Маркировка файлов, связанных с конкретным выпуском программного продукта

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

• Блокировка и разблокировка файлов

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

Что туда входит

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

• исходные файлы;

• файлы заголовков;

• файлы библиотек;

• сценарии компоновки;

• результаты компиляции;

• результаты компоновки;

• инструменты и файлы для установки программ;

• инструменты и файлы для тестирования;

• спецификации проекта;

• планы проекта (ПО, документации и тестирования);

• пользовательская документация;

• тестовые задания и сценарии;

• тестовые модули разработчиков.

Из собственного опыта

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

Заметим, что в систему управления исходным кодом мы поместили всё, что можно было представить, а не только исходный код. Если что-то использовалось в проекте или относилось к проекту, мы помещали это в систему.

Зачем это нужно

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

Например, в NuMega была возможность отслеживать изменения в планах, тестовых сценариях и документации для всего проекта. К тому же мы могли помечать целые наборы тестовых сценариев и пользовательской документации для каждого внутреннего этапа и для каждого основного или неосновного выпуска. Мы могли с точностью до символа воссоздать все файлы (не только файлы исходного кода) любого выпуска в истории проекта.

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

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

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

Каковы их технологические возможности

Помимо функциональных возможностей, описанных ранее, команда в NuMega нуждалась в поддержке пяти жизненно необходимых технологических возможностей. Хотя они специфичны для наших продуктов и компании, многие из них стандартны для большинства проектов в отрасли. Это:

• управление разработкой нескольких редакций продукта;

• управление разработкой нескольких версий одной редакции;

• применение общих компонентов, как в рамках одного, так и нескольких проектов компании;

• компоновка продукта на основе самого свежего набора файлов с исходным кодом (или на основе другого набора исходных файлов);

• поддержка локальных сборок для отдельных разработчиков.

Как ими управлять

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

Мы использовали систему управления исходным кодом Visual Source Safe (VSS) компании Microsoft. Она предоставляет нужные нам основные функции, и у неё отличная цена — как раз для начинающего бизнеса. Хотя обсуждение VSS выходит за рамки этой книги, я расскажу о том, как мы приспособили этот продукт под наши нужды.

Основы структуры

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

Структура и использование хранилища исходного кода

Все файлы, используемые при разработке наших продуктов, были рассортированы по трём папкам:

• Product Name — для файлов, относящихся к продукту;

• Environment — для файлов среды разработки;

• Imports — для сторонних файлов.

Папка Product Name содержала создаваемые нами файлы, необходимые для сборки, тестирования и написания документации к продукту (табл. 5-1). В ней были подкаталоги Branch для каждого варианта, над которым мы работали. В подкаталоге Parts хранились стандартные и совместно используемые компоненты, включаемые в продукт. И, наконец, для каждой редакции продукта имелся подкаталог Product. В каждой папке Product содержались необходимые для продукта части. Чтобы эта структура работала, нужно строго соблюдать соглашения об именах и не нарушать структуру. Координация изменений в частях и продуктах также была критичной.

Табл. 5-1. Примерная структура папки «Product Name».

$/Product_Name/ — Файлы, относящиеся к продукту

$/Product_Name/Branch/ — Различные направления в разработке

$/Product_Name/Parts/ — Совместно используемые файлы, входящие в продукт

$/Product_Name/Parts/Src/ — Исходный код для Parts (при необходимости совместно используется с/Products/Src)

$/Product_Name/Parts/Doc/ — Исходные файлы документации

$/Product_Name/Parts/Help/ — Исходные файлы справочной системы

$/Product_Name/Parts/Install/ — Исходный код программы установки

$/Product_Name/Parts/Patch/ — Исходный код вставок

$/Product_Name/Parts/Setup/ — Исходный код установщика

$/Product_Name/Parts/Samples/ — Исходный код с примерами

$/Product_Name/Parts/Tests/ — Исходный код тестов, тестовые задания и т.д.

$/Product_Name/Product/ — Редакции продукта Product Name (по одной папке на каждую редакцию)

$/Product_Name/Product/Output/ — Область для программ, созданных в других проектах

$/Product_Name/Product/Src/ — Исходный код продукта (при необходимости совместно используется с /Parts/Src)

$/Product_Name/Product/Doc/ — Файлы документации к продукту (совместно используется с /Parts/Doc)

$/Product_Name/Product/Help/ — Файлы справочной системы продукта (совместно используется с /Parts/Help)

$/Product_Name/Product/Imports/ — Импорт (совместно используется с /Imports)

$/Product_Name/Product/Install/ — Файлы для установки продукта (используется с /Parts/Install)

$/Product_Name/Product/Samples/ — Примеры для продукта (совместно используется с /Parts/Samples)

$/Product_Name/Product/Tests/ — Тестовые задания, тестовые сценарии (совместно используется с /Parts/Tests)

Из собственного опыта

Когда я пришёл в NuMega, для одного из продуктов было создано три каталога по именам разработчиков: Frank, Bill и Matt. Так как каждый работал над своим собственным кодом, они могли вносить изменения, не повреждая чужих файлов. Однако там было мало общего кода (одна большая структура данных для основных подсистем). Но это работало! Дальше нам нужно было увеличить команду разработчиков, и мы уже не могли обойтись без системы управления исходным кодом. Такая система позволила усложнить проект, удерживая его под контролем. Без неё я просто не могу представить ПО для разработчиков.

В папке Environment ($/Env) хранятся файлы, используемые командой разработчиков, но не являющиеся частью конечного продукта. Это все, начиная с инструментов и утилит и заканчивая стандартами создания кода и шаблонами для проекта. Папка Environment содержит файлы среды, описывающие среду с точки зрения разработчика, а также с точки зрения тестирования и документации. В NuMega мы хотели создать общую среду для команд разработчиков, и потому для этой цели мы создали специальный раздел в хранилище исходного кода. Вот примерный список подкаталогов, которые могут быть в этом разделе хранилища исходного кода (табл. 5-2):

Табл. 5-2. Примерная структура папки Environment.

$/Env/Dev/ ПО среды разработки и инструментальных средств

$/Env/Dev/Bin Исполняемые модули (подкаталог для каждого инструмента)

$/Env/Dev/Src Исходный код для этих инструментов (подкаталог для каждого)

$/Env/Dev/Doc Документация для этих инструментов (подкаталог для каждого)

$/Env/Dev/Etc Прочие файлы

$/Env/Test/ Инструментальные средства и файлы для тестирования

$/Env/Test/Bin Исполняемые модули

$/Env/Test/Src Исходный код и документация для этих инструментов

$/Env/Test/Doc Документация по среде тестирования

$/Env/Test/Etc Прочие файлы

$/Env/Documentation/ Документация по среде проекта

$/Env/Documentation/Templates Шаблоны проекта, шаблоны документации и справочники по стилям

$/Env/Documentation/Plans Планы и спецификации проекта, тестовых заданий и документации

$/Env/Documentation/Process Технологические документы проекта

$/Env/Etc Прочие файлы, не вошедшие в предыдущие категории

В папке Imports ($/Imports) хранились файлы или наборы инструментов из сторонних продуктов (табл. 5-3). Сами сторонние продукты в этой папке не содержались, там были только библиотеки и заголовки. В результате в разделе Imports проводилось совсем немного изменений. Однако так как эта область использовалась для хранения различных версий сторонних продуктов, было очень важно не вносить никаких изменений без чёткого осмысления, полного тестирования и учёта связей с элементами, на которые эти изменения могли бы подействовать.

Табл. 5-3. Примерная структура папки Imports.

$/Imports/RogueWave Библиотеки и заголовки RogueWave

$/Imports/ObjectSpace Библиотеки и заголовки ObjectSpace

$/Imports/Visual С Результаты компиляции, библиотеки и заголовки Visual С

$/Imports/Install Shield Библиотеки и заголовки Install Shield

$/Imports/Прочие Папки для каждого инструмента или библиотеки сторонних производителей

Компоновочная система

В NuMega мы писали сценарий сборки продукта на выделенной «компоновочной машине». Сценарий должен был выбирать нужные для сборки продукта файлы из системы управления исходным кодом. Эта информация включала как сами средства компоновки, так и исходные файлы, библиотеки, заголовки и другие необходимые компоненты. Для ведения процесса компиляции мы выбрали Nmake — популярное средство управления компоновкой. Nmake сначала собирает все части продукта, а затей компонует окончательные исполняемые файлы продукта.

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

Надёжная автоматическая система компоновки — необходимое условие успешной разработки. Затраты времени и сил на то, чтобы заставить эту систему работать, своего стоят. Этот и другие вопросы применения технологического ПО обсуждаются в главе 7.

Устранение проблем и неисправностей

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

О чём пойдёт речь

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

Что туда входит

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

Примечание

Я бы не советовал писать собственные программы по устранению проблем и неисправностей, так как хватает различных коммерческих программных продуктов по разумным ценам. Например, Compuware/NuMega TrackRecord, PVCS Tracker, Rational ClearQuest и др. Хотя вам потребуется самим определить, какая из них отвечает вашим потребностям, я настоятельно рекомендую принять решение в пользу покупки. Ведь вы не обязаны тратить время на создание собственных инструментов, ваше дело — поставлять ПО.

Рассмотрим пример. Разработчик замечает, что производительность в одной из частей приложения здорово снизилась, и сообщает об этом по электронной почте в конференцию разработчиков. А дальше? Кто заметит сообщение, а кто и нет. Даже если кто-то находит неполадку, её нужно запротоколировать и устранить, иначе о проблеме просто забудут. Послать сообщение по электронной почте — не плохо, но не зафиксировать наличие неисправности — беда. То же касается предложений по выпуску. Есть вероятность, что на предложение никто не откликнется, и если сообщение электронной почты было послано без протоколирования, то не будет и никакой истории работы над предложением.

Как это работает

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

• текущее состояние проблемы: открытая или закрытая;

• дата возникновения, изменения и решения;

• текстовое описание проблемы;

• номер выпуска/сборки программы, в которой обнаружена проблема;

• имя человека, описавшего проблему:

• имя человека, работающего над проблемой в настоящее время;

• состояние проблемы: расследуется, требуется больше информации, ожидается внешнее событие, решена и т.д.;

• приоритет проблемы: низкий, средний, высокий;

• выпуск, в котором присутствует проблема;

• статут процедуры контроля качества;

• количество попыток неуспешного решения проблемы;

• список изменений к отчёту о проблеме или неисправности.

Посмотрим, как мы использовали ПО для устранения проблем и неисправностей в NuMega.

Из собственного опыта

Когда я начинал работать в NuMega, «жучки» и другие различные неисправности фиксировались на доске (если вообще фиксировались). Они оставались там до тех пор, пока не были исправлены, а затем их просто стирали. Когда доска заполнялась полностью, новые записи втискивали в уголок или, чтобы освободить место, стирали другие ошибки. Эта система работала для одного-двух человек, но истории работы над ошибками не было.

С ростом организации становилось очевидно, что нам требуется автоматизированное решение. Если бы мы в то время не перешли к нему, то не смогли бы успешно вырастить свою команду. Хотя поиск инструмента, способного решить наши проблемы, и не был сложен, способ его использования часто становился предметом спора. В конце концов мы выяснили, что для группы нашего размера куда важнее выполнять на «отлично» всего несколько функций, чем пытаться делать всё, что мы можем только представить.

Для всех ошибок — одно хранилище

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

Как далеко это заходит? Значит ли это, что если у одного разработчика возникла проблема с API, который реализовал другой разработчик, то её сразу же нужно запротоколировать? Вовсе нет. Разработчики могут решить проблему друг с другом самостоятельно, и тогда её не нужно протоколировать. Однако если решение проблемы займёт некоторое время и требует наблюдения (что особенно важно), то необходимо занести её в систему и описать, чтобы не забыть о её существовании. Эти правила распространяются на всех членов команды и на все отделы.

Другое преимущество от протоколирования неполадок — возможность отчитываться о них. Как здорово пойти на текущее совещание с полным списком всех крупных неполадок и людей, над ними работающих! Это эффективный способ фокусировать внимание в процессе разработки на важных вопросах. Заявивший об ошибке будет польщён тем, что её признали и она обсуждается. А тот, кто назначен для её разрешения, поймёт, что теперь не отвертеться.

Управление изменениями

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

Приоритеты на основе времени

Хотя классификация «низкий, средний и высокий» часто полезна при назначении проблемам приоритетов, всё же в одной категории оказываются десятки и даже сотни неполадок. Чего не хватает в таких приоритетах, так это элемента времени. Очень часто есть ошибки с высоким приоритетом, которые нужно срочно исправить к бета-версии, а есть такие (с таким же приоритетом), что могут подождать до последнего выпуска, поскольку они очень сложны или требуют дополнительного исследования.

Рассмотрите включение поля «Исправить к дате» для установления приоритетов на основе критерия времени. Значения, помещаемые в это поле, могут браться на основе внутреннего графика выпуска проекта, например, здесь может быть указан определённый этап, бета-версия или кандидат на выпуск. Чтобы определиться с приоритетом, задайте себе вопросы: «эту проблему нужно решить к этапу 2 или бета-версии 1?», «Что, если мы выпустим продукт сейчас, а ошибку исправим в следующем выпуске?»

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

Проверяйте и исправляйте ошибки

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

Используйте замечания по выпуску

Когда мы сталкивались с неполадкой, которую следует описать в замечаниях по выпуску или файле Read Me, мы изменяли её статус на «Release Notes», но оставляли её открытой. В примечаниях по выпуску описываются известные проблемы, способы их обойти и информация, появившаяся в последний момент и не попавшая в официальную документацию. Когда наступал момент выпуска бета-версии или окончательной версии, было очень просто составить список проблем, о которых следует указать в замечаниях по выпуску. И только после того, как проблему разрешили, мы окончательно её закрывали.

Используйте стандартные запросы

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

Все открытые ошибки

Позволяет менеджеру проекта и руководству оценить проект в целом

Все открытые ошибки для конкретного этапа

Позволяет команде увидеть, какие ошибки остаются открытыми в проекте для заданного этапа.

Все открытые ошибки для конкретного человека

Позволяет каждому человеку просмотреть свой текущий список ошибок

Все открытые ошибки для конкретного этапа и человека

Позволяет каждому человеку просмотреть свой список ошибок для заданного этапа.

Все открытые ошибки тестировщиков с полем «Контролю качества: проверить» = «Истина»

Позволяет команде просмотреть свой план тестирования

Все открытые ошибки с полем «Предложения» = «Истина»

Позволяет менеджеру проекта и руководству пересмотреть текущие предложения по изменениям

Другие способы применения

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

Интенсивность возникновения и устранения ошибок

Интенсивность возникновения — это мера того, сколько новых ошибок или неисправностей было обнаружено за определённый период времени. Интенсивность возникновения взлетает вверх в начале проекта, но с течением времени снижается. Интенсивность устранения — это мера того, сколько ошибок или неисправностей закрыто за определённый период времени. Она снижается по мере устранения ошибок. Ниже показана интенсивность возникновения и устранения ошибок — для проекта эти данные могут быть весьма полезны (рис. 5-1 и 5-2).

Рис. 5-1. Интенсивность возникновения и устранения ошибок в начале проекта.

Рис. 5-2. Интенсивность возникновения и устранения ошибок в моменты, когда проект близится к завершению определённого этапа.

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

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

Интенсивность устранения поможет вам определить эффективность обнаружения причин возникновения неполадки, а также примерный срок устранения ошибок, которые могут появиться в будущем. Скажем, если интенсивность устранения в течение двух последних недель составляла 10 ошибок в день, это может быть большим успехом. Если у вас 100 открытых ошибок, то вполне закономерно ожидать, что все они будут устранены приблизительно в течение следующих 10 дней. Эта цифра конечно же не точна (для исправления какой-нибудь неполадки может потребоваться и неделя), но она позволяет понять, чего вам следует ожидать при наличии большого количества оставшихся ошибок.

Количество изменений

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

Счётчик неудачных исправлений

Ещё один хороший способ оценки нестабильности проекта — счётчик неудачных исправлений для всех ошибок, которые считались исправленными, но на самом деле исправлены не были. При устранении неполадки от команды тестировщиков требуется подтверждение того, что ошибка действительно исправлена. Если проблема всё ещё существует или исправление не принято, ей возвращается статус открытой, а значение поля «Исправлено неудачно» устанавливается в 1. Если тестировщики снова не могут подтвердить устранения неполадки, значение счётчика увеличивается до 2 или 3. Это сигнализирует о серьёзности проблемы и говорит о необходимости вмешательства ведущих специалистов или менеджера проекта.

Дополнительные средства

Хотя средства управления исходным кодом и устранения проблем были стержнем процесса разработки в NuMega, мы регулярно использовали и другие инструменты.

Отладчики

Одним из наиболее важных инструментов для наших разработчиков был разработанный NuMega Technologies невероятно мощный отладчик для Windows — SoftICE. Он загружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные возможности управления и наблюдения за внутренними процессами приложения и операционной системы. Команда разработчиков часто использовала SoftICE для разрешения наиболее сложных проблем при отладке.

Средства анализа производительности и полноты

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

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

Средства написания сценариев и автоматизации тестирования

Так как наши планы тестирования требовали максимально возможной автоматизации, мы всегда интересовались инструментами, способными нам в этом помочь. Наиболее важными были средства написания сценариев (Perl, командные файлы DOS и т.п.) и средства автоматизации тестирования. В то время Visual Test был доступен по разумной цене и предлагался взыскательным тестировщикам и разработчикам. С его помощью мы тестировали пользовательский интерфейс, но в подавляющем большинстве мероприятий по автоматизации полагались на средства написания сценариев.

Из собственного опыта

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

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

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

Проблемы с инструментами

• Отбор нужных инструментов

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

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

• Смена инструментов на средине пути

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

Проблемы управления исходным кодом

• Структура проекта

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

• Содержание

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

• Конфликты ключевых файлов

Типичный случай: разработчику X был выдан файл, и поэтому разработчик Y не может его взять для внесения важных изменений. Такие конфликты из-за файлов способны замедлить работу над проектом. Предусмотрите способ быстрого внесения критичных исправлений или изменений.

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

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

В большинстве систем управления исходным кодом поддерживается слияние файлов. Это позволяет совместить изменения в файлах. Хотя обычно эта функция работает правильно, не позволяйте операцию слияния проводить автоматически. Вы должны убедиться, что проверили все изменения, сделанные в файле. Если в нашей системе управления исходным кодом поддержка слияния реализована плохо, можете воспользоваться такими редакторами кода, как Visual Slick Edit и Code Write. Они помогут выявить различия визуально и проверить результат слияния перед его реальным осуществлением.

• Маркировка

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

Метки должны устанавливаться не только для файлов с исходным кодом. Помечайте файлы-сборки, установочные файлы, файлы документации, файлы контроля качества — словом, все файлы, включённые в выпуск. Метка должна быть информативной и следовать соглашениям об именах, принятым для проекта.

Из собственного опыта

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

Проблемы поиска ошибок и неисправностей

• Целостность данных

Обеспечение целостности данных в системе должно быть приоритетной задачей. Если вы не будете доверять информации в системе, то не станете её использовать, и она потеряет свою значимость. Очень важно определить правила обеспечения целостности данных, в большинстве основанных на внутреннем процессе разработки. Так, вы никогда не должны сталкиваться с ошибками, которые реально «закрыты», но для них установлен статус «исследуется». Чтобы отображать работу над ошибками, нужно со временем изменять статус ошибок. Также убедитесь, что вы вводите правильные значения в поля (информацию об этапе, информацию о выпуске и т.д.). Какими бы ни были у вас внутренние методы проверки целостности, не допускайте хранения недостоверных или устаревших данных, иначе команда разработчиков будет присваивать данным любые значения, а вся система перестанет внушать доверие и станет бесполезной.

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

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

Глава 6

Основы системы контроля качества

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

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

Основные принципы

Начнём с принципов работы системы контроля качества. Лейтмотив — обеспечение качества непосредственно в процессе разработки. Продукту нельзя придать качество позже без значительных затрат денег, сил и времени. Создание качественного продукта основывается на четырёх простых принципах:

• тестирование продукта осуществляется параллельно с процессом его разработки;

• качество продукта улучшается регулярно при завершении каждого планового этапа разработки;

• тестирование необходимо максимально автоматизировать;

• качество является частью культуры и технологии.

Параллельное тестирование

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

Ниже представлен идеальный график параллельного тестирования набора функций программы (табл. 6-1). Заметьте, что разработка и тестирование идут максимально плотно друг за другом. Реализация функции завершается в конце недели, команда испытателей готова приступить к тестированию в начале следующей. Хотя разработчики ответственны и за создание кода, и за его базовое тестирование, команда тестировщиков в заданный период проверяет функцию по максимуму. Так как разработчики и тестировщики должны работать над функцией вместе, их называют «оперативной командой».

Табл. 6-1. График работы оперативной команды над функциями А, В и С.

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

Запомните: одновременно должно разрабатываться функций не более, чем вы можете обеспечить их сотрудниками. Иначе говоря, число оперативных команд должно основываться на числе функций, для которых допустима параллельная работа (разработка и тестирование). Если тестировщиков больше, чем разработчиков, или наоборот, то при использовании такой модели разработки команда считается несбалансированной, и вам следует набрать дополнительный персонал в те области, где испытывается дефицит.

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

Стабилизация и интеграция

Через каждые 4-6 недель команда должна отводить 1-2 недели (в зависимости от сложности проекта) на тестирование, стабилизацию и интеграцию функций, завершённых к данному моменту. Такие периоды стабилизации и интеграции идут на пользу команде, функциональности и качеству. Вы можете завершить незаконченное тестирование, начать интегральную проверку функциональности и определить проблемы, которые следует решить, прежде чем продолжить работу над проектом. Не обращайте особого внимания на мелкие неисправности и детали. Просто перед началом очередной стадии убедитесь, что структурно и функционально проект находится в хорошем состоянии. В течение этого периода все члены команды должны направлять свои усилия только на стабилизацию и интеграцию. Не работайте над новыми функциями, кодом или чем-то ещё до тех пор, пока вы не будете уверены в стабильности того, что уже построено.

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

Автоматизация

Максимально возможная автоматизация процесса тестирования — ключ к параллельному тестированию (и раннему обнаружению ошибок). Автоматизация предоставит вам следующие преимущества:

• Сокращение внутреннего цикла тестирования

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

• Сокращение потребностей в персонале

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

• Проверка изменений, внесённых в последний момент

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

• Обеспечение полноты тестирования для новых выпусков

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

Из собственного опыта

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

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

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

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

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

Из собственного опыта

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

Команды, процессы и культура

У вас есть опыт создания качественного ПО? Ваши технологические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитывается ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обеспечить качество? О качестве заботится каждый или есть такие, которые говорят: «это не мой участок»?

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

Из собственного опыта

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

Что, когда и как тестировать

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

• процедуре установки;

• функциональных возможностях;

• интеграции функций;

• производительности.

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

• Входные тесты

Проверяют ПО перед подтверждением внесённых изменений.

• Ежедневные базисные тесты

Выполняются для каждой сборки программы.

• Тесты по завершении функции

Проверяют функцию сразу же после завершения работы над ней.

• Тесты при стабилизации и интеграции

Проверяется интеграция функций через определённые интервалы времени.

• Бета-тестирование и кандидаты на выпуск

Производится внешнее тестирование продукта через определённые интервалы времени.

В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.

Входное тестирование

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

• совместимостью между всеми машинами;

• простотой установки, запуска и выполнения;

• проверять ключевые функции или подсистемы продукта.

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

Ежедневное базисное тестирование

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

Из собственного опыта

Продукт BoundsChecker компании NuMega хорошо известен за свою способность находить утечки памяти в приложениях C/C++. Ежедневные базисные тесты для этой программы включали в себя приложение BugBench, в котором было множество утечек памяти, а также других отвратительных «жучков». Мы использовали эту программу-пример для генерации ошибок, которые BoundsChecker должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по утрам «ещё дымящийся отчёт о тесте» с результатами проверки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работающим, поскольку наши базисные тесты сразу находили критические проблемы.

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

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

Тестирование реализованной функции

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

Ключевые функции

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

Тестировщики почти всегда будут находить проблемы. Для их устранения в графике разработки должно быть отведено некоторое время в период разработки компонента или в ближайшем периоде стабилизации. Я советую выделять немного времени в обоих периодах. Скажем, в пятидневном задании должен быть предусмотрен один день как раз для устранения неполадок, то есть 20% «лишнего времени».

Установка

К сожалению, процедура установки — самая «забытая» часть любого продукта. Люди редко думают о том, что установка — это важнейшая функция программы, и поэтому не уделяют ей должного внимания. Если вы не протестируете процедуру установки, можете пожалеть: этот компонент программы используют все. Единственный способ создать великолепное первое впечатление — это разработать отличную процедуру установки. Иначе пользователь с первых минут будет недоволен вашей программой.

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

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

• Операционные системы

Проверка на всех операционных системах, поддерживаемых вашей программой.

• Сервисные пакеты

Проверка со всеми сервисными пакетами ОС, поддерживаемых вашей программой.

• «Чистая» установка

Проверка установки продукта на ОС, где не установлены предыдущие версии программы.

• «Грязная» установка

Проверка установки продукта на ОС с установленными предыдущими версиями программы.

• Конфигурации продукта

Проверка поддержки процедурой установки различных конфигураций продукта.

• Функции программы установки

Проверка собственных возможностей процедуры установки (онлайновая регистрация, кнопка «Далее», кнопка «Назад», кнопка «Отмена» и т.д.).

• Тест удаления

Проверка процедуры удаления продукта.

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

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

Из собственного опыта

Не забудьте о процедуре удаления! В NuMega команды разработчиков и тестировщиков оценили значимость процедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление записей реестра и файлов из системного каталога.

Тестирование при стабилизации и интеграции

До этого момента в цикле разработки тестирование было направлено на проверку отдельных функций. Но в период стабилизации и интеграции внимание уделяется:

• завершению всех отложенных тестов отдельных функций;

• проверке интеграции функций;

• проверке текущей производительности и нагрузки;

• исправлению всех серьёзных ошибок, изъянов проекта или архитектурных проблем;

• тестированию бета-версий и кандидатов на выпуск.

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

Завершение тестирования отдельных функций

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

Проверка интеграции

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

Тестирование производительности и нагрузки

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

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

Из собственного опыта

Во время разработки BoundsChecker одной из главных проблем была производительность. Ничего не стоило полностью поменять характеристики производительности продукта, добавив несколько строчек кода в критичные функции. Чтобы обнаружить источник проблем с производительностью, мы использовали несколько тестовых приложений, которые нагружали BoundsChecker до предела. Одно из таких приложений называлось Torture. Оно создавало 256 параллельных потоков и запрашивало и освобождало десятки тысяч блоков памяти в куче. В течение всего периода разработки мы запускали Torture (и подобные программы), чтобы определить, не снизилась ли производительность продукта. Так как мы хотели видеть результат сразу, мы стали каждую ночь запускать Torture как часть наших автоматических регрессивных тестов и сравнивать показатели производительности. С таким уровнем контроля мы обычно могли определять снижение производительности в сборке предыдущего дня. Весьма неплохо!

Коррекция после тестирования

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

Оценка после тестирования

Когда период стабилизации и интеграции подходит к концу, не забудьте оценить результаты и произвести изменения. Усовершенствовать ли аппаратную часть? Нужно лучше тестировать подсистемы? Требуется ли лучшее определение API? Больше людей? Какие бы изменения ни требовалось провести, это нужно сделать сейчас.

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

Пример тестирования

Рассмотрим простой пример, чтобы показать, как все эти области работают вместе. Допустим, вы создаёте Web-приложение и проходите фазу стабилизации и интеграции. Вы уверены в работоспособности определённых функций. Скажем, вам нужно только создание, редактирование и удаление покупателей. Но чтобы заставить эти функции работать, нужно потрудиться. Их работа затрагивает пользовательский интерфейс, Web-сервер, промежуточные звенья и базу данных. Все эти компоненты взаимосвязаны. В этом случае проверка интеграции может состоять из таких заданий:

• попытаться добавить покупателя;

• некорректное добавление покупателя (проверка полей);

• повторное добавление одного и того же покупателя;

• редактирование сведений о покупателе (всех полей, ни одного поля);

• редактирование сведений о несуществующем покупателе;

• некорректное редактирование сведений о покупателе;

• удаление существующего покупателя;

• удаление несуществующего покупателя.

Завершив тестирование интеграции, вы будете обладать сведениями о производительности приложения. Как долго добавить покупателя? А удалить? Получить сообщение об ошибке? Хотя может быть несколько причин плохой производительности, если вы не можете быстро добавить покупателя в маленькой базе данных, возможно, имеется проблема, требующая дополнительного исследования. Есть ли проблемы с драйверами БД? Может быть, у вас плохая структура БД? Нет ли претензий к промежуточному уровню? Чтобы это проверить, через определённое время нужно проводить мониторинг, устанавливать планку производительности для основных транзакций и регулярно сравнивать результаты, чтобы знать, что вы на верном пути.

Задача тестирования интеграции — убедиться в том, что к завершению первого этапа функциональность продукта удовлетворительна. Если это так, вы готовы приступить к следующему крупному этапу. Если нет, скажем, вы не можете добавить, отредактировать или удалить покупателя, остановитесь и исправьте всё, что мешает двигаться вперёд.

Тестирование бета-версий и кандидатов на выпуск

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

Одна из главных задач при работе с бета-версиями и кандидатами на выпуск — определить, что следует протестировать в сборке, прежде чем предоставить её сторонним организациям. Конечно, вы не сможете заново протестировать весь продукт. Полное тестирование и доводка продукта займёт месяцы, если не годы. Вместо этого вам нужно составить очень конкретный и хорошо продуманный план, который будет выполнен в очень сжатые сроки. (Для большинства небольших и средних проектов норма составляет 7-10 дней.) В планы тестирования бета-версий и кандидатов на выпуск нужно включить:

• выполнение всего набора автоматических тестов;

• выполнение набора ручных тестов, включая:

* нормальную установку/проверку лицензии (полностью вручную);

* тестирование базовых функций продукта (полностью вручную);

* тестирование производительности и нагрузки (полностью вручную);

* выборочную проверку на всех поддерживаемых платформах;

* другие специфические разделы проекта.

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

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

Кто должен тестировать?

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

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

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

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

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

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

Из собственного опыта

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

Я готов был зааплодировать. Не потому, что мне нравилось состояние бета-версии. Кэрол дала понять разработчикам, что в их обязанности входит базовое тестирование программ и самостоятельная работа над проблемами кода. До команды разработчиков это дошло. Мы согласились и занимались тестированием и исправлениями в программе, пока не почувствовали, что готовы позвать Кэрол. Это заняло около двух дней.

В отношении тестирования разработчики имеют ряд обязанностей:

• анализ плана тестирования;

• тестирование на уровне модулей (работает ли функция в большинстве ситуаций);

• предварительное интегральное тестирование (работает ли функция в связке с другими);

• протоколирование или устранение всех неполадок, обнаруженных в программе, когда они сами её использовали.

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

Далее команда, отвечающая за контроль качества, проводит тестирование продукта на другом уровне. Она сосредоточивается на:

• планировании тестов;

• автоматизации создания тестов;

• автоматизации тестирования;

• тестировании функций в различных комбинациях;

• тестировании процедуры установки;

• тестировании интеграции и связи с системой;

• тестировании производительности и нагрузки;

• ручном тестировании (функций, для которых неприменимо автоматическое тестирование);

• диагностике проблем и их протоколировании;

• проверке исправлений и «закрытии» ошибок.

Хотя все эти обязанности привычны для тестировщиков, последняя может быть менее знакомой. «Закрытие» ошибки должен проводить только тестировщик — член оперативной команды. Задача разработчика — исправить ошибку в коде, занести исправление в систему управления исходным кодом и обновить статус ошибки на «Исправлено» в системе устранения неполадок. Но пересмотр всех исправленных ошибок и проверка того, что они действительно исправлены, входит в обязанности тестировщиков. Только после такой проверки ошибка считается официально «закрытой».

Другие критичные моменты для контроля качества

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

Матрица тестирования

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

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

Из собственного опыта

В NuMega мы решили проблему тестирования на нескольких конфигурациях путём распределения их между разработчиками и тестировщиками. Один получил Microsoft Windows 95, другой — Microsoft Windows 98, третий — Microsoft Windows NT 3.51 и ещё один — Microsoft Windows NT 4.0. От каждого требовалось выполнить тест на своей ОС в надежде как можно раньше — в процессе разработки — обнаружить проблемы. Таким простым способом мы почти сразу находили проблемы на всех платформах.

Ручное тестирование

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

• Для тестирования ключевых функций в случаях, когда автоматические тесты запаздывают или вовсе не существуют

Что, если у вас нет времени или ресурсов для написания всех автоматических тестов, а команда разработчиков уже выдаёт вам готовую функцию? В таком случае нужно приступить к ручному тестированию, чтобы оценка функции проходила согласно графику. Раннее обнаружение ошибок и их устранение остаётся главной задачей.

• Для редко изменяемых, некритичных функций

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

• Когда все трещит по швам

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

Но помните: нельзя быть зависимым от ручного тестирования. Его наращивание потребует больших затрат, а тестирование параллельно с разработкой продукта становится затруднительным.

Оборудование для тестирования

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

• 2-3 компьютера на каждого тестировщика

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

• 2 компьютера на одного разработчика

Помните: разработчики тоже занимаются тестированием. Один компьютер им нужен для разработки, другой — для тестирования. Разработчики могут переконфигурировать его при «охоте на жучков», и это не помешает их основной работе. Повторю: хорошо, если одна машина представляет компьютер конечного пользователя.

• Доступная библиотека программ

Все ПО, которое требуется для разработки или тестирования, должно быть постоянно доступно. Для быстрого и простого доступа сотрудников к инструментам, продуктам и ОС, необходимым для работы, удобен дисковод с автоматической сменой компакт-дисков. Конечно, придётся позаботиться о наличии лицензий, но избавление сотрудников от хождения по коридорам в поисках нужного диска того стоит.

• Тестовая лаборатория

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

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

Из собственного опыта

На заре NuMega у нас не было постоянно доступной библиотеки программ, а охота за компакт-дисками здорово раздражала и отнимала драгоценное время. Часто наши планы требовали поддержки самой последней ОС или компилятора Microsoft. К счастью, мы участвовали в тестировании их бета-версий и регулярно получали обновления. Жаль, что только на одном компакт-диске. Когда кому-то требовалась последняя бета-версия Windows или Visual Studio, начиналась охота за диском. Если везло, мы находили человека с диском, который нам требовался, но чаще всего мы слышали: «Я отдал его тому-то», — и продолжали идти по следу. (Однажды я ходил так от одного к другому и только пятый человек в цепочке сказал мне, что этого диска в глаза не видел!) Если такой способ не работал, мы писали сообщение по электронной почте и с надеждой ждали ответа, а это время занимались чем-то другим.

После того, как в течение нескольких месяцев мы столкнулись с десятками таких сообщений, мы окончательно поняли, что проблему нужно решать, тем более что наша компания росла. Решением стала «вертушка» компакт-дисков. Это сработало, но только после того, как мы перевели все в режим онлайнового доступа. Наши попытки создать традиционную библиотеку не увенчались успехом, так как люди, бравшие компакт-диски, никогда не возвращали их на место, и мы вновь задавались вопросом: «У кого диск?»

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

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

Нехватка ресурсов

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

Если работы просто больше, чем ваши сотрудники могут выполнить, а вы хотите поставить качественный продукт, существует только два выхода:

• пересмотреть графики, чтобы они отвечали ограничениям, накладываемым разрабатываемыми функциями и возможностями персонала;

• пересмотреть функциональность программы, чтобы она отвечала ограничениям графика и возможностям персонала.

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

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

Недостаточная подготовка

Многие проекты «встают не с той ноги» и, честно говоря, обречены с самого начала, так как члены команды просто к ним не готовы. У вас должны быть основные планы, средства автоматизации и оборудование, о которых говорилось выше. Все это потребуется почти с самого начала разработки. Если вы будете писать планы или ждать поставки нужного оборудования в процессе разработки, вы уже опоздаете и не сможете делать то, что от вас требуется — тестировать.

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

Отсутствие автоматизации

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

Ненадлежащее исполнение обязанностей

Проблемы с качеством не всегда являются результатом игнорирования приёмов и концепции контроля качества. Это может быть следствием ненадлежащего исполнения обязанностей. Если вам приходилось беседовать с менеджерами или ведущими специалистами о контроле качества в таком проекте, они, вероятно, постарались наговорить много всего о том, что нужно сделать. Но когда вы видите их проекты, то замечаете, что ничего не делается. Создание качественного продукта требует усилий: сосредоточенности, активного участия, исполнительности. Это не теоретические выкладки — все члены команды должны действовать активно и увлечённо.

Неправильная расстановка акцентов

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

Глава 7

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

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

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

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

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

• определение, создание и сопровождение сборочной среды продукта;

• определение, создание и сопровождение процедуры установки продукта;

• определение, создание и обслуживание пакетов исправлений или сервисных пакетов;

• проведение модульного тестирования и основных мероприятий по контролю качества процедуры установки;

• разработка инструментов, сценариев и автоматизация разработки ПО;

• планирование сборочной среды (сборочной лаборатории).

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

Из собственного опыта

В NuMega не было выделенных технологов, функции реализации готового продукта выполняла команда. Сначала она состояла из инженера по поддержке и специалиста по инженерной психологии. Что бы вы ни думали, они по совместительству составляли великолепную команду и больше года отлично решали технологические проблемы. Талантливые люди могут брать на себя много задач! Но однажды они позвонили мне из сборочной лаборатории (на самом деле это небольшая комнатка), где боролись со сложной сборкой и сценарием установки. Сообщение было недвусмысленным: «Эд! С нас хватит! Найми технолога!»

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

Сборки

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

Почему они важны

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

Из собственного опыта

Когда я пришёл в NuMega, единственным человеком, способным собрать продукт целиком, был один из талантливейших инженеров — Мэт Питрек. Даже когда команда и продукты ещё были небольшими, среда разработки была чрезвычайно сложной. Только Мэт знал, что делать. Чтобы собрать программу, он уходил в свой кабинет и закрывал дверь. Он как помешанный колдовал над тремя разными компиляторами и дюжиной сценариев, вручную редактировал конфигурационные и другие файлы. Затем, после 3-4 часов интенсивной работы, он взмахивал волшебной палочкой, и обычно у нас появлялась готовая сборка. Мы предполагали, что он не нашёл никаких проблем.

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

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

Как их создавать

Далее приведён ряд рекомендаций о том, как сделать задачу создания сборки более простой и эффективной.

Утилита Make

Поддерживает набор правил сборки и отношений в программе для всего приложения или компонента. Описав эти правила, Make может решить, какие образы необходимо собрать и какие исходные файлы должны быть откомпилированы или скомпонованы.

Make существует уже несколько десятилетий, всё началось в UNIX, а затем она появилась практически на всех остальных платформах. В течение многих лет её улучшали, и последняя версия — Nmake — входит в состав Microsoft Visual Studio. Обязательно изучите утилиту Make в вашей среде разработки и используйте её для автоматизации задач сборки ПО.

Номера сборок

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

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

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

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

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

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

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

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

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

Проверка

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

Один из лучших способов проверить сборку — установить продукт и запустить базисные тесты (см. о них главу 6). Для эффективного управления этим процессом для сборок следует завести два каталога.

• Самая последняя сборка (MRB)

В этом каталоге хранится самая последняя сборка программы. Однако она может и не устанавливаться или не работать правильно.

• Последняя хорошая сборка (LKGB)

Здесь хранится последняя хорошая сборка. Убедившись в том, что текущая сборка находится в хорошем состоянии (она установилась и прошла базисные тесты), скопируйте содержимое каталога MRB в каталог LKGB.

Для своей повседневной работы команда должна производить установку из каталога LKGB. Обычно команда, отвечающая за контроль качества, перемещает последнюю сборку в LKGB сразу после её проверки. Если в последней сборке обнаружены проблемы, команда все равно может работать, так как сборка в каталоге LKGB является рабочей.

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

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

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

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

Чтобы не сломать сборку, ответьте на следующие вопросы.

• Когда я должен сдать мой код?

Сдавайте свою часть кода, когда у нас есть что добавить к проекту. Это может быть сосём простое добавление, скажем, набор заглушек API, или очень сложное, например, крупный компонент. Но вы должны сдавать свой код часто. Смысл в том, чтобы как можно раньше заставить работать код, созданный разными людьми.

• Как я могу быть уверен в том, что не испорчу сборку?

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

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

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

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

Процедура установки служит для выполнения двух важных функций. Во-первых, она заставляет команду думать об установочной среде, которая требуется для продукта. Процедура установки требует от вас знания состава приложения: образов, библиотек, компонентов, файлов справки, библиотек типов и т.д. Также она заставляет вас определить исполняющую среду, в том числе поддержку драйверов баз данных, стандартных компонентов и операционных систем. Если вы сохраните компоненты продукта целыми и актуальными, вы сможете избежать проблем в дальнейшем.

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

• Разработчики смогут увидеть свои компоненты со стороны официальной сборки и оценить проблемы, используя ту же процедуру установки, что и вся команда.

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

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

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

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

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

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

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

Скелет

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

Мышцы

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

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

Комплект

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

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

Когда у вас есть сборки и процедура установки, следует собрать все вместе в автоматизированный конвейерный процесс. Процесс должен быть создан в самом начале проекта, возможно, это должно быть первой задачей.

Главные шаги цикла сборки таковы:

• сборка образов;

• создание комплекта;

• тестирование комплекта;

• отправка сообщения о прохождении теста или сбое;

• запуск базисных тестов для проверки сборки;

• если тест пройден удачно, копирование в каталог LKGB;

• отправка сообщения о прохождении базисного теста или о сбое.

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

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

Убеждение

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

Из собственного опыта

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

Однажды я спросил, была ли сегодняшняя сборка уcпешной. Коллега ответил: «Ты что, считаешь, что мы должны создавать эту сборку каждый день?» Да, каждый день. Это часть нашей модели разработки, и это критично для способа, которым мы работаем.

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

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

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

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

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

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

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

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

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

Дисциплина

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

Оглавление