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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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