Однако будьте осторожны и не перегрузите лучших участников команды. Хотя они могут сделать больше других, у них тоже есть свой предел. Эти люди ещё пригодятся, чтобы помочь другим, когда возникнут неприятности.
Возможные накладки
Наивно полагать, что все своё рабочее время люди будут трудиться над своими основными задачами. В каждой организации возникают накладки, к которым относится время, потраченное на собрания, наладку технологии, отпуска, стажировки, командировки, больничные и выходные. Даже при 80 рабочих часах в неделю, нетрудно заметить, что 10 из них тратятся на отвлечённые действия. Это тоже следует учесть в плане. Кроме предсказуемых событий (отпусков, командировок и т.п.), план должен учитывать и неожиданные: болезни сотрудников, зимнюю непогоду и пр.
Задачи: критичные и некритичные
Одни задачи критичны для продолжения работы над проектом, другие — нет. Опоздание в выполнении некритичных задач не влияет на ход реализации плана в целом, а задержки с критичными задачами непременно отражаются на реализации плана. Планируя, нужно определить, к какому виду относятся те или иные задачи. Нужно постоянно следить за исполнением критичных задач, так как любая задержка повлечёт за собой срыв конечных сроков плана или рост сверхурочной работы команды. Лучше поручать решение критичных задач опытным людям, чтобы свести к минимуму риски проекта.
Ловушки, подстерегающие любую команду
Ниже описан ряд наиболее распространённых проблем с планированием, с которыми приходится сталкиваться командам разработчиков.
Сроки: конечный и согласованный
Конечный срок — это предположительная дата сдачи проекта. Обычно он основывается на внешней рыночной конъюнктуре и состоянии дел в отрасли. Эта дата очень важна, поэтому нельзя соглашаться с конечным сроком, не составив прежде план. Подставьте этот срок в «уравнение» планирования, как одну из переменных и попробуйте уравновесить требуемую функциональность ПО и ресурсы для её разработки. Если уравнение не решается, придётся исключить часть функций, добавить ресурсы или сделать то и другое в некоторой пропорции. Конечная цель в том, чтобы составить уравновешенный, реалистичный и правдоподобный план, против которого не стал бы возражать ни один член команды.
Как только появится хороший план, необходимо удостовериться, что в команде нет возражений.
Согласованный срок — это дата сдачи ПО, с которой согласны все участники команды. Они считают эту дату разумной и вполне достижимой. Таким образом, команда разработчиков принимает на себя обязательство закончить ПО к этому сроку. Ситуация в небольших начинающих фирмах и крупных компаниях сходна тем, что от своевременного окончания работы над ПО зависит результат работы множества людей и значительных затрат, как денежных, так и временных. Для компании чрезвычайно важно выдержать утверждённый согласованный срок, чтобы, выполнив принятые обязательства, завоевать доверие к своей компании.
Ответственность за реализацию плана
Чаще всего команду ставят перед фактом, жёстко определяя необходимый объём функциональности ПО, выделенные для этого ресурсы и срок, к которому всё должно быть готово. И получается, что ответственность за выполнение плана лежит не на разработчиках, а на организации или персоне, которая эти требования «спустила сверху». Такова общая формулировка этой серьёзной проблемы. Боевой дух участников команды будет невысок: ведь они будут чувствовать, что их поставили в заведомо проигрышное положение. Без чувства ответственности, не принимая на себя обязательств, команда не сможет вложить в реализацию проекта сердце и душу, и никакого энтузиазма.
Вместо этого группа разработки должна создать свой собственный план, точнее, сама поддерживать баланс в рамках плана. С принятием обязательств в команде появляется чувство ответственности. Выдвинув свой план разработки ПО, за который она отвечает, команда должна приложить все усилия, чтобы выдержать установленные в нём сроки. Доверие — это следствие выполненных обязательств.
Из собственного опыта
Разработка ПО в NuMega обычно проходила под огромным давлением необходимости уложиться в срок. Конечные сроки сдачи наших продуктов обычно приурочены к выходу Microsoft Visual Studio или появлению новых платформ и технологий, например Microsoft Windows 95, Microsoft Windows NT или Microsoft COM. Чтобы воспользоваться преимуществом этих событий, наши группы маркетинга разработали всесторонние планы продвижения продукта, включающие рекламу, пресс-конференции, аналитические исследования, презентации и обучение продавцов. Ассигнования на эти мероприятия, зависящие от даты выхода ПО, достигают сотен тысяч долларов. Кроме того, наши специалисты по продажам и старшие менеджеры рассчитывали на существенный прирост прибылей с выходом каждой последующей программы. Любая задержка была чревата не только потерей больших денег и времени, но и упущенными возможностями по продаже и потерей выгодной для нашего товара рыночной конъюнктуры.
Чтобы обеспечить своевременный выпуск ПО, вся «домашняя работа» (поиск компромиссов между реализацией функций, доступным временем и ресурсами) выполнялась заранее, затем на основе конечного срока выхода ПО составлялись реальные планы. Таким образом, автором планов были технические специалисты, а не экономисты или старшие менеджеры. Приходилось брать на себя ответственность за реализацию этих планов независимо от их содержания. Любая ошибка планирования была нашей проблемой, и мы отвечали за то, чтобы найти решение, не допуская задержки выпуска ПО.
Вопрос доверия к техническим специалистам
Одна из наибольших проблем, с которыми сталкиваются технические специалисты, — нехватка доверия. Постоянно нарушая сроки, техническая группа теряет доверие остальных подразделений организации. Это угрожает потерей доверия к плану и достоверности суждений о возможных компромиссах проекта, а также открывает лазейку в планировании для разного рода игр («липовым» срокам сдачи, заведомо завышенным просьбам в расчёте получить хотя бы часть от запрошенного). Однако хорошая репутация, завоёванная своевременным исполнением работы, — источник доверия, которое при необходимости позволяет бороться с серьёзными трудностями, привлекать дополнительную поддержку и извлекать выгоду из чужих сомнений.
Как составить хороший план
Теперь можно сосредоточиться на особенностях составления хорошего плана разработки ПО. В этом процессе три основных этапа: определение задач, объединение задач в группы, называемые базовыми уровнями, и группировка последних в этапы проекта.
Ниже я приведу пример типичного плана с описанием основных структур проекта, необходимых для разработки плана. Легко заметить, что целью планирования не является «микроуправление» каждой деталью проекта. Просчитать, чем будет заниматься каждый член команды в течение шести месяцев, начиная с сегодняшнего дня, скорее всего невозможно. Вместо этого нужно составить план со списком чётко определённых задач, плавно сменяющих друг друга по ходу цикла разработки. Такой план позволяет контролировать работу команды над каждой задачей, а также отслеживать ход реализации проекта со значительной определённостью.
Задачи
На первом этапе следует определить все задачи, решение которых позволяет реализовать некоторую функцию. Суммарное время выполнения этих задач составляет общее время реализации функции. Сначала надо спланировать реализацию необходимых функций и лишь затем переходить к планированию желательных и возможных функций. Такой метод позволит как можно скорее получить жизнеспособную программу.
Затем следует распланировать задачи групп тестирования, обучения пользователей, разработчиков пользовательского интерфейса и технологов. У каждой группы должен быть свой набор задач, определяемый на основе частей проекта, за разработку которых отвечает группа. Эти задачи должны быть организованы так, чтобы их можно было интегрировать и их реализация не слишком отставала от реализации функций разработчиками.
Базовые уровни
Базовые уровни определяют срок реализации группы связанных функций. Каждые 2-3 недели должен быть готов очередной базовый уровень. Помните: соответствующий фрагмент ПО должен устанавливаться с помощью программы установки, а его функциональность должна быть доступна для разработчиков. Реализация базовых уровней — важные краткосрочные цели, на достижении которых необходимо сосредоточить внимание и усилия команды. Вообще ничто не может быть важнее своевременного завершения очередного базового уровня. Если он запаздывает, можно официально говорить об отставании проекта от плана, что требует немедленных корректирующих действий. Ниже приводится ряд базовых уровней (из продукта BoundsChecker, разработанного NuMegaдля обнаружения ошибок в программах).
• Создана библиотека исходных текстов, выполнена первая ежедневная сборка программы, закончена установочная процедура для «скелета» программы.
• Программа позволяет активизировать основные функции для работы с памятью и вести регистрацию их работы.
• Программа выводит первое сообщение об ошибке при работе с памятью с помощью прототипа пользовательского интерфейса.
• Программа успешно обнаруживает утечки памяти типа 1 и 2.
• Программа успешно обнаруживает утечки памяти типа 3 и 4.
• Программа успешно обнаруживает утечки памяти типа 5 и 6.
• Появляется реальный пользовательский интерфейс программы, но без поддержки печати, сортировки и фильтрации.
• Закончена поддержка печати, сортировки и фильтрации.
• Программа интегрируется с другими программами пакета.
Промежуточные этапы
Промежуточный этап — это группа базовых уровней, представляющих законченную часть программы. Необходимо равномерно распределить их завершение по ходу работы над проектом. Например, если для проекта определено 4 промежуточных этапа, то каждому из них должны соответствовать 25% реализации проекта. Очевидно, что чем сложнее проект, тем больше у него промежуточных этапов.
У каждого промежуточного этапа должен быть период стабилизации и интеграции (см. главу 6). Напоминаю, что в это время (обычно 1-2 недели) вся команда концентрируется на решении проблем, обнаруженных в реализованных функциях. Периоды стабилизации жизненно важны для проекта, поскольку в это время проводится тестирование, исправление ошибок, устранение неполадок в структуре и интеграции, проводится оценка производительности, т.е. все мероприятия, способствующие стабилизации программы. Не приступайте к реализации новой функции, пока не убедитесь, что только что законченные функции работают хорошо. Помимо всего прочего, периоды стабилизации очень удобны для разного рода доработок. В это время отставшие участники или подразделения команды могут наверстать упущенное и догнать остальных, чтобы вновь работать синхронно.
Внешние промежуточные этапы
В завершении внешних промежуточных этапов участвуют люди или группы, не работающие над проектом постоянно. Внешние промежуточные этапы знаменуют собой критические точки проекта. Вот самые распространённые внешние промежуточные этапы:
• альфа-версия — выпуск, в котором реализован лишь ряд критических функций программы; альфа-версии не предназначены для широкого использования, однако могут быть полезны для демонстрации прогресса проекта или сбора внешних отзывов о работе критических функций;
• бета-версия — выпуск, в котором реализованы если не все, то большинство функций; бета-версии передаются клиентам для испытаний и оценки;
• кандидат на выпуск — в случае успешного окончания тестирования этот выпуск будет передан в производство для тиражирования; появление кандидата на выпуск — знак того, что проект почти закончен и выпуск ПО состоится;
• передача в производство — к этому времени рабочий выпуск будет передан в производство для тиражирования (или опубликован в Web, в зависимости от назначения ПО).
Любой из внешних промежуточных этапов требует распространения ПО за пределами команды или даже компании. Так как это очень важное событие, перед каждым промежуточным этапом нужен период стабилизации. Он позволяет команде сосредоточиться на его качестве, интеграции; выполнить «подгонку» частей и устранить оставшиеся неполадки перед выпуском продукта. (Подробнее о бета-версии и кандидате на выпуск см. главы 13 и 14)
Пример
Чтобы закрепить основы, давайте шаг за шагом рассмотрим подробный пример (табл. 11-1). В таблице показано упрощённое описание проекта, откуда удалена часть информации, обычно имеющейся в нём. Тем не менее, этот пример достаточно детализирован, чтобы продемонстрировать стыковку всех частей проекта. Ниже приводится ряд допущений, сделанных при планировании этого примера.
• Принципы планирования.
* С каждой функцией связан список технических задач. В этом примере они не показаны, однако их легко перечислить в реальном плане. На выполнение одной задачи отводится не более 2 недель, а на большинство — неделя или даже меньше. В зависимости от приоритетных требований к ПО, в первую очередь реализуются необходимые функции, а затем — менее важные.
* Тестирование функций осуществляется по мере завершения их разработчиками. Тестирование некоторых функций будет автоматизировано, другие же придётся тестировать вручную. Подробное описание испытаний приводится в плане тестирования.
* Специалисты по обучению пользователей составляют описания функций по мере их завершения. Работа по составлению документации должна как можно меньше отставать от реализации функции. Подробно эти действия описаны в плане обучения пользователей.
* Специалисты по инженерной психологии оценивают качество реализации всех функций пользовательского интерфейса, консультируют по поводу внесения изменений и контролируют впечатление от продукта по мере реализации проекта. Детали работы специалистов по инженерной психологии описаны в специальном плане.
* Во время работы над выпуском ПО сразу же создаётся простая сборка программы и установочная процедура. Затем сборка и установочная процедура будут регулярно пополняться новыми функциями, таким образом, они будут включать все большую долю функциональности готовой программы. Они также поддерживают подключение новых функций по мере их готовности. Конкретные усовершенствования функций и возможностей программы будут описаны в плане работы над выпуском.
• Участники работы над проектом:
— Мэтт — ведущий разработчик, занятый полное рабочее время;
— Джон — программист;
— Джим — ведущий тестировщик, также отвечает за автоматизацию;
— Фрэнк — тестировщик, исполняет автоматизированное и ручное тестирование функций;
— Сара — ведущий специалист по обучению пользователей;
— Кенни — ведущий специалист по инженерной психологии;
— Боб — ведущий технолог.
• Промежуточные этапы, внешние и внутренние.
— План проекта состоит из 4 базовых уровней, на реализацию которых отводится по 2 месяца, и 2-х главных промежуточных этапов. Будут выпущены 2 бета-версии, 1 версия — кандидат на выпуск и 1 версия для тиражирования.
— Каждый промежуточный этап образован 2 базовыми уровнями. Первому промежуточному этапу будет соответствовать наполовину законченный проект, а второму этапу — полностью законченный проект.
— Работа над бета-версией 1 займёт 1 месяц. Функции 14 и 15 будут добавлены во время работы над бета-версией 1, а оставшееся время будет потрачено на тестирование, настройку и исправление ошибок. У каждого участника группы есть некоторый список действий на время работы над бета-версией 1.
— В бета-версии 2 не будет новых функций по сравнению с бета-версией 1. Внесение значительных изменений в главные функции не допускается, разрешено лишь тестирование, настройка и исправление ошибок. У каждого члена группы есть список задач на это время.
• Кандидат на выпуск.
Версия — кандидат на выпуск будет готова к концу работы над бета-версией №2, если её тестирование пройдёт успешно и не будет обнаружено серьёзных ошибок.
• Контрольные собрания.
— Проведение собраний для контроля за состоянием проекта запланировано на каждый понедельник. Если достигнуть базового уровня вовремя не удалось (или все говорит об этом), придётся вносить изменения, чтобы наверстать упущенное.
Табл. 11. Примерный план.
Цифрами обозначены функции, состояние функций обозначено следующими буквами:
Ф — функция запрограммирована, выполнено блочное тестирование и завершены все связанные с ней технические задачи;
А — тестирование функции автоматизировано:
Р — функция протестирована вручную;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Возможные накладки
Наивно полагать, что все своё рабочее время люди будут трудиться над своими основными задачами. В каждой организации возникают накладки, к которым относится время, потраченное на собрания, наладку технологии, отпуска, стажировки, командировки, больничные и выходные. Даже при 80 рабочих часах в неделю, нетрудно заметить, что 10 из них тратятся на отвлечённые действия. Это тоже следует учесть в плане. Кроме предсказуемых событий (отпусков, командировок и т.п.), план должен учитывать и неожиданные: болезни сотрудников, зимнюю непогоду и пр.
Задачи: критичные и некритичные
Одни задачи критичны для продолжения работы над проектом, другие — нет. Опоздание в выполнении некритичных задач не влияет на ход реализации плана в целом, а задержки с критичными задачами непременно отражаются на реализации плана. Планируя, нужно определить, к какому виду относятся те или иные задачи. Нужно постоянно следить за исполнением критичных задач, так как любая задержка повлечёт за собой срыв конечных сроков плана или рост сверхурочной работы команды. Лучше поручать решение критичных задач опытным людям, чтобы свести к минимуму риски проекта.
Ловушки, подстерегающие любую команду
Ниже описан ряд наиболее распространённых проблем с планированием, с которыми приходится сталкиваться командам разработчиков.
Сроки: конечный и согласованный
Конечный срок — это предположительная дата сдачи проекта. Обычно он основывается на внешней рыночной конъюнктуре и состоянии дел в отрасли. Эта дата очень важна, поэтому нельзя соглашаться с конечным сроком, не составив прежде план. Подставьте этот срок в «уравнение» планирования, как одну из переменных и попробуйте уравновесить требуемую функциональность ПО и ресурсы для её разработки. Если уравнение не решается, придётся исключить часть функций, добавить ресурсы или сделать то и другое в некоторой пропорции. Конечная цель в том, чтобы составить уравновешенный, реалистичный и правдоподобный план, против которого не стал бы возражать ни один член команды.
Как только появится хороший план, необходимо удостовериться, что в команде нет возражений.
Согласованный срок — это дата сдачи ПО, с которой согласны все участники команды. Они считают эту дату разумной и вполне достижимой. Таким образом, команда разработчиков принимает на себя обязательство закончить ПО к этому сроку. Ситуация в небольших начинающих фирмах и крупных компаниях сходна тем, что от своевременного окончания работы над ПО зависит результат работы множества людей и значительных затрат, как денежных, так и временных. Для компании чрезвычайно важно выдержать утверждённый согласованный срок, чтобы, выполнив принятые обязательства, завоевать доверие к своей компании.
Ответственность за реализацию плана
Чаще всего команду ставят перед фактом, жёстко определяя необходимый объём функциональности ПО, выделенные для этого ресурсы и срок, к которому всё должно быть готово. И получается, что ответственность за выполнение плана лежит не на разработчиках, а на организации или персоне, которая эти требования «спустила сверху». Такова общая формулировка этой серьёзной проблемы. Боевой дух участников команды будет невысок: ведь они будут чувствовать, что их поставили в заведомо проигрышное положение. Без чувства ответственности, не принимая на себя обязательств, команда не сможет вложить в реализацию проекта сердце и душу, и никакого энтузиазма.
Вместо этого группа разработки должна создать свой собственный план, точнее, сама поддерживать баланс в рамках плана. С принятием обязательств в команде появляется чувство ответственности. Выдвинув свой план разработки ПО, за который она отвечает, команда должна приложить все усилия, чтобы выдержать установленные в нём сроки. Доверие — это следствие выполненных обязательств.
Из собственного опыта
Разработка ПО в NuMega обычно проходила под огромным давлением необходимости уложиться в срок. Конечные сроки сдачи наших продуктов обычно приурочены к выходу Microsoft Visual Studio или появлению новых платформ и технологий, например Microsoft Windows 95, Microsoft Windows NT или Microsoft COM. Чтобы воспользоваться преимуществом этих событий, наши группы маркетинга разработали всесторонние планы продвижения продукта, включающие рекламу, пресс-конференции, аналитические исследования, презентации и обучение продавцов. Ассигнования на эти мероприятия, зависящие от даты выхода ПО, достигают сотен тысяч долларов. Кроме того, наши специалисты по продажам и старшие менеджеры рассчитывали на существенный прирост прибылей с выходом каждой последующей программы. Любая задержка была чревата не только потерей больших денег и времени, но и упущенными возможностями по продаже и потерей выгодной для нашего товара рыночной конъюнктуры.
Чтобы обеспечить своевременный выпуск ПО, вся «домашняя работа» (поиск компромиссов между реализацией функций, доступным временем и ресурсами) выполнялась заранее, затем на основе конечного срока выхода ПО составлялись реальные планы. Таким образом, автором планов были технические специалисты, а не экономисты или старшие менеджеры. Приходилось брать на себя ответственность за реализацию этих планов независимо от их содержания. Любая ошибка планирования была нашей проблемой, и мы отвечали за то, чтобы найти решение, не допуская задержки выпуска ПО.
Вопрос доверия к техническим специалистам
Одна из наибольших проблем, с которыми сталкиваются технические специалисты, — нехватка доверия. Постоянно нарушая сроки, техническая группа теряет доверие остальных подразделений организации. Это угрожает потерей доверия к плану и достоверности суждений о возможных компромиссах проекта, а также открывает лазейку в планировании для разного рода игр («липовым» срокам сдачи, заведомо завышенным просьбам в расчёте получить хотя бы часть от запрошенного). Однако хорошая репутация, завоёванная своевременным исполнением работы, — источник доверия, которое при необходимости позволяет бороться с серьёзными трудностями, привлекать дополнительную поддержку и извлекать выгоду из чужих сомнений.
Как составить хороший план
Теперь можно сосредоточиться на особенностях составления хорошего плана разработки ПО. В этом процессе три основных этапа: определение задач, объединение задач в группы, называемые базовыми уровнями, и группировка последних в этапы проекта.
Ниже я приведу пример типичного плана с описанием основных структур проекта, необходимых для разработки плана. Легко заметить, что целью планирования не является «микроуправление» каждой деталью проекта. Просчитать, чем будет заниматься каждый член команды в течение шести месяцев, начиная с сегодняшнего дня, скорее всего невозможно. Вместо этого нужно составить план со списком чётко определённых задач, плавно сменяющих друг друга по ходу цикла разработки. Такой план позволяет контролировать работу команды над каждой задачей, а также отслеживать ход реализации проекта со значительной определённостью.
Задачи
На первом этапе следует определить все задачи, решение которых позволяет реализовать некоторую функцию. Суммарное время выполнения этих задач составляет общее время реализации функции. Сначала надо спланировать реализацию необходимых функций и лишь затем переходить к планированию желательных и возможных функций. Такой метод позволит как можно скорее получить жизнеспособную программу.
Затем следует распланировать задачи групп тестирования, обучения пользователей, разработчиков пользовательского интерфейса и технологов. У каждой группы должен быть свой набор задач, определяемый на основе частей проекта, за разработку которых отвечает группа. Эти задачи должны быть организованы так, чтобы их можно было интегрировать и их реализация не слишком отставала от реализации функций разработчиками.
Базовые уровни
Базовые уровни определяют срок реализации группы связанных функций. Каждые 2-3 недели должен быть готов очередной базовый уровень. Помните: соответствующий фрагмент ПО должен устанавливаться с помощью программы установки, а его функциональность должна быть доступна для разработчиков. Реализация базовых уровней — важные краткосрочные цели, на достижении которых необходимо сосредоточить внимание и усилия команды. Вообще ничто не может быть важнее своевременного завершения очередного базового уровня. Если он запаздывает, можно официально говорить об отставании проекта от плана, что требует немедленных корректирующих действий. Ниже приводится ряд базовых уровней (из продукта BoundsChecker, разработанного NuMegaдля обнаружения ошибок в программах).
• Создана библиотека исходных текстов, выполнена первая ежедневная сборка программы, закончена установочная процедура для «скелета» программы.
• Программа позволяет активизировать основные функции для работы с памятью и вести регистрацию их работы.
• Программа выводит первое сообщение об ошибке при работе с памятью с помощью прототипа пользовательского интерфейса.
• Программа успешно обнаруживает утечки памяти типа 1 и 2.
• Программа успешно обнаруживает утечки памяти типа 3 и 4.
• Программа успешно обнаруживает утечки памяти типа 5 и 6.
• Появляется реальный пользовательский интерфейс программы, но без поддержки печати, сортировки и фильтрации.
• Закончена поддержка печати, сортировки и фильтрации.
• Программа интегрируется с другими программами пакета.
Промежуточные этапы
Промежуточный этап — это группа базовых уровней, представляющих законченную часть программы. Необходимо равномерно распределить их завершение по ходу работы над проектом. Например, если для проекта определено 4 промежуточных этапа, то каждому из них должны соответствовать 25% реализации проекта. Очевидно, что чем сложнее проект, тем больше у него промежуточных этапов.
У каждого промежуточного этапа должен быть период стабилизации и интеграции (см. главу 6). Напоминаю, что в это время (обычно 1-2 недели) вся команда концентрируется на решении проблем, обнаруженных в реализованных функциях. Периоды стабилизации жизненно важны для проекта, поскольку в это время проводится тестирование, исправление ошибок, устранение неполадок в структуре и интеграции, проводится оценка производительности, т.е. все мероприятия, способствующие стабилизации программы. Не приступайте к реализации новой функции, пока не убедитесь, что только что законченные функции работают хорошо. Помимо всего прочего, периоды стабилизации очень удобны для разного рода доработок. В это время отставшие участники или подразделения команды могут наверстать упущенное и догнать остальных, чтобы вновь работать синхронно.
Внешние промежуточные этапы
В завершении внешних промежуточных этапов участвуют люди или группы, не работающие над проектом постоянно. Внешние промежуточные этапы знаменуют собой критические точки проекта. Вот самые распространённые внешние промежуточные этапы:
• альфа-версия — выпуск, в котором реализован лишь ряд критических функций программы; альфа-версии не предназначены для широкого использования, однако могут быть полезны для демонстрации прогресса проекта или сбора внешних отзывов о работе критических функций;
• бета-версия — выпуск, в котором реализованы если не все, то большинство функций; бета-версии передаются клиентам для испытаний и оценки;
• кандидат на выпуск — в случае успешного окончания тестирования этот выпуск будет передан в производство для тиражирования; появление кандидата на выпуск — знак того, что проект почти закончен и выпуск ПО состоится;
• передача в производство — к этому времени рабочий выпуск будет передан в производство для тиражирования (или опубликован в Web, в зависимости от назначения ПО).
Любой из внешних промежуточных этапов требует распространения ПО за пределами команды или даже компании. Так как это очень важное событие, перед каждым промежуточным этапом нужен период стабилизации. Он позволяет команде сосредоточиться на его качестве, интеграции; выполнить «подгонку» частей и устранить оставшиеся неполадки перед выпуском продукта. (Подробнее о бета-версии и кандидате на выпуск см. главы 13 и 14)
Пример
Чтобы закрепить основы, давайте шаг за шагом рассмотрим подробный пример (табл. 11-1). В таблице показано упрощённое описание проекта, откуда удалена часть информации, обычно имеющейся в нём. Тем не менее, этот пример достаточно детализирован, чтобы продемонстрировать стыковку всех частей проекта. Ниже приводится ряд допущений, сделанных при планировании этого примера.
• Принципы планирования.
* С каждой функцией связан список технических задач. В этом примере они не показаны, однако их легко перечислить в реальном плане. На выполнение одной задачи отводится не более 2 недель, а на большинство — неделя или даже меньше. В зависимости от приоритетных требований к ПО, в первую очередь реализуются необходимые функции, а затем — менее важные.
* Тестирование функций осуществляется по мере завершения их разработчиками. Тестирование некоторых функций будет автоматизировано, другие же придётся тестировать вручную. Подробное описание испытаний приводится в плане тестирования.
* Специалисты по обучению пользователей составляют описания функций по мере их завершения. Работа по составлению документации должна как можно меньше отставать от реализации функции. Подробно эти действия описаны в плане обучения пользователей.
* Специалисты по инженерной психологии оценивают качество реализации всех функций пользовательского интерфейса, консультируют по поводу внесения изменений и контролируют впечатление от продукта по мере реализации проекта. Детали работы специалистов по инженерной психологии описаны в специальном плане.
* Во время работы над выпуском ПО сразу же создаётся простая сборка программы и установочная процедура. Затем сборка и установочная процедура будут регулярно пополняться новыми функциями, таким образом, они будут включать все большую долю функциональности готовой программы. Они также поддерживают подключение новых функций по мере их готовности. Конкретные усовершенствования функций и возможностей программы будут описаны в плане работы над выпуском.
• Участники работы над проектом:
— Мэтт — ведущий разработчик, занятый полное рабочее время;
— Джон — программист;
— Джим — ведущий тестировщик, также отвечает за автоматизацию;
— Фрэнк — тестировщик, исполняет автоматизированное и ручное тестирование функций;
— Сара — ведущий специалист по обучению пользователей;
— Кенни — ведущий специалист по инженерной психологии;
— Боб — ведущий технолог.
• Промежуточные этапы, внешние и внутренние.
— План проекта состоит из 4 базовых уровней, на реализацию которых отводится по 2 месяца, и 2-х главных промежуточных этапов. Будут выпущены 2 бета-версии, 1 версия — кандидат на выпуск и 1 версия для тиражирования.
— Каждый промежуточный этап образован 2 базовыми уровнями. Первому промежуточному этапу будет соответствовать наполовину законченный проект, а второму этапу — полностью законченный проект.
— Работа над бета-версией 1 займёт 1 месяц. Функции 14 и 15 будут добавлены во время работы над бета-версией 1, а оставшееся время будет потрачено на тестирование, настройку и исправление ошибок. У каждого участника группы есть некоторый список действий на время работы над бета-версией 1.
— В бета-версии 2 не будет новых функций по сравнению с бета-версией 1. Внесение значительных изменений в главные функции не допускается, разрешено лишь тестирование, настройка и исправление ошибок. У каждого члена группы есть список задач на это время.
• Кандидат на выпуск.
Версия — кандидат на выпуск будет готова к концу работы над бета-версией №2, если её тестирование пройдёт успешно и не будет обнаружено серьёзных ошибок.
• Контрольные собрания.
— Проведение собраний для контроля за состоянием проекта запланировано на каждый понедельник. Если достигнуть базового уровня вовремя не удалось (или все говорит об этом), придётся вносить изменения, чтобы наверстать упущенное.
Табл. 11. Примерный план.
Цифрами обозначены функции, состояние функций обозначено следующими буквами:
Ф — функция запрограммирована, выполнено блочное тестирование и завершены все связанные с ней технические задачи;
А — тестирование функции автоматизировано:
Р — функция протестирована вручную;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30