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

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

На заре 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пешной. Коллега ответил: «Ты что, считаешь, что мы должны создавать эту сборку каждый день?» Да, каждый день. Это часть нашей модели разработки, и это критично для способа, которым мы работаем.

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

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

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

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

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

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

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

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

Дисциплина

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