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

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

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

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

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

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

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

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

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

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

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

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

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

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

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