5.6 Принцип «ежедневной сборки проекта»

5.6 Принцип «ежедневной сборки проекта»

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

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

Разумеется, реалии таковы, что приступить к ежедневной сборке проекта с самого первого дня невозможно. Правда, уже на второй день проекта можно написать подпрограмму типа «Hello, World», и трудно сегодня удивить кого-то совершенно новыми технологиями (в частности, многие из проектов, использующих Java, во время написания этой книги уже находились в процессе разработки). Однако, существуют определённые требования, которым должна удовлетворять версия прототипа системы при первой «официальной» демонстрации: помимо того, что она включает необходимую совокупность компонентов, процедур или модулей и, по крайней мере, несколько сотен, а может быть и тысяч строк кода, она должна выполнять реальный ввод данных, производить реальную обработку или вычисления и формировать реальный выход. Именно с этого момента следует начинать ежедневную сборку проекта и формировать каждый день новую (желательно улучшенную) версию системы.

Почему это так важно? Как любит говорить Jim McCarthy, менеджер продукта Microsoft Visual C++ и автор книги DynamicsofSoftwareDevelopment [4]:

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

Некоторые менеджеры проекта будут кивать головами и подтверждать, что они всегда именно так и поступают, однако большинство согласится, что они довольствуются еженедельным, ежемесячным или полугодовым контролем реализации системы. В то время как вряд ли кто-нибудь вправе претендовать на «изобретение» данного подхода, многие знают, что он впервые стал популярным во время разработки операционной системы Windows NT (интересную дискуссию на эту тему можно обнаружить в описании данного проекта, приведённом в [5]). Любопытно также отметить, что при разработке Windows 95 также использовался принцип ежедневной сборки проекта; заключительная бета-версия перед выпуском конечного продукта была реализована в августе 1995 года и называлась «Проект 951».

Важно осознавать, что подобный подход становится неотъемлемой составляющей процесса разработки системы, которому следует проектная команда. Представьте себе, каково быть участником команды, которая должна демонстрировать работающую версию программного обеспечения 951 день подряд! (Правда, если быть честным, я не уверен, что команда Microsoft действительно свято соблюдала такой порядок каждый день. Возможно также, что формирование более чем одной версии укладывалось в 24-часовой промежуток, и возможно, команда могла день или два отдохнуть в этом марафоне.) Кроме того, чтобы быть эффективным, процесс ежедневного завершения проекта должен быть автоматизированным и должен выполняться ночью без чьего-либо участия, когда все программисты отправились домой спать (или влезли на свои рабочие столы и забрались в спальные мешки!). Такой подход подразумевает наличие автоматизированного управления конфигурацией ПО и механизмов контроля исходных кодов, а также разнообразных «скриптов» для выполнения компиляции и сборки приложений. Но что ещё более важно, он подразумевает наличие системы автоматизированного тестирования, которая может работать всю ночь, выполняя гору тестов для проверки работоспособности системы. Таким образом, чтобы реализовать на практике принцип ежедневной сборки проекта, необходимо иметь в своём распоряжении адекватный набор средств и технологий; мы ещё вернёмся к этому вопросу в главе 6.

Действие данного принципа может также дополнительно усилить ряд следующих мер:

50) Менеджеру проекта следует переместить свой офис непосредственно к месту разработки и тестирования системы, как только начнётся процесс ежедневной сборки проекта. Так поступил Dave Cutler в Microsoft. Рассказывают страшные истории, как он метал громы и молнии, когда появлялся в офисе и обнаруживал, что сборка очередной версии в полночь накрылась. Будет менеджер проявлять свой гнев или нет, важно, чтобы он был почти всегда на виду и непосредственно участвовал в ежедневном процессе, а не уподоблялся генералу, который получает ежедневные сводки с поля боя, находясь за много миль от него в тылу.

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

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Сборки

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

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


Определение проекта

Из книги Информационные технологии и управление предприятием автора Баронов Владимир Владимирович

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


Техзадание для проекта СТО

Из книги Малый автосервис: Практическое пособие автора Волгин Владислав Васильевич

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


2. Команда проекта

Из книги Бизнес-планирование инвестиционных проектов автора Лумпов Алексей Андреевич

2. Команда проекта Как мы уже говорили, для успешной реализации любого инвестиционного проекта необходимо сформировать команду проекта. В неё должны войти все совладельцы совокупности объектов интеллектуальной собственности (ОИС), которые за реальное выполнение своих


Запуск проекта

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

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


Принцип от обратного, или Принцип пряника

Из книги Настольная книга по внутреннему аудиту. Риски и бизнес-процессы автора Крышкин Олег

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


Выбор проекта

Из книги Бизнес-план на 100%. Стратегия и тактика эффективного бизнеса автора Абрамс Ронда

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


От ежедневной работы к увеличению доходов

Из книги Запуск! Быстрый старт для вашего бизнеса автора Уокер Джефф

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


Шаг 1.3. Заказчик проекта

Из книги Управление проектами от А до Я автора Ньютон Ричард

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


13 Экспертиза окончательной редакции проекта стандарта. Подготовка проекта стандарта к утверждению

Из книги Управление качеством. Практикум автора Ржевская Светлана

13 Экспертиза окончательной редакции проекта стандарта. Подготовка проекта стандарта к утверждению 13.1 Общие требования к подготовке проекта стандарта к утверждению При получении окончательной редакции проекта стандарта национальный орган Российской Федерации по


График поставки и схема последовательности сборки

Из книги Канбан и «точно вовремя» на Toyota. Менеджмент начинается на рабочем месте автора Коллектив авторов

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


Точка сборки

Из книги Опять совещание?! Как превратить пустые обсуждения в эффективные автора Перл Дэвид

Точка сборки От рутины есть польза, но рутина сама по себе высасывает силы. Рутинные собрания – рутинное мышление. В тот момент, когда вы говорите себе, что собрания по-другому и не проходят, вы близки к предвзятому суждению: собрания, даже регулярные, не обязаны


Второй проект: линия сборки Cobus

Из книги Гемба кайдзен. Путь к снижению затрат и повышению качества автора Имаи Масааки

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


Спонсор проекта

Из книги Управление бизнес-процессами. Практическое руководство по успешной реализации проектов автора Джестон Джон

Спонсор проекта Роль спонсора проекта – обычная для бизнес-проекта. Часто в роли спонсора выступает ведущий бизнес-менеджер. Спонсор проекта должен быть его активным сторонником и защитником, выполняя следующие обязанности и неся ответственность за:• определение и


Директор проекта

Из книги В поисках совершенства. Книга о том, чего хотят сотрудники от своих работодателей автора Линдеберг Тери Энн

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


Глава 23 Что вы можете сказать о том, как вами руководят? На ежедневной основе? Каждый месяц?

Из книги автора

Глава 23 Что вы можете сказать о том, как вами руководят? На ежедневной основе? Каждый месяц? Для меня это был важный вопрос, поскольку всегда трудно оценивать эффективность руководителей и насколько они популярны или не популярны у сотрудников. Сотрудники же, как правило,