При проведении последних тестов служба поддержки, тестировщики, администратор бета- тестирования, инженеры да и любой участник группы могут обнаружить серьёзную проблему. Её следует рассмотреть на собрании «штурмовой группы», которая может предпринять следующие действия:
•
Прежде всего надо убедиться в реальности проблемы, затем исследовать её природу и определить её значение для проекта: выяснить, воспроизводится ли она, а также какие и сколько платформ она затрагивает.
•
Сначала нужно определить, можно ли устранить неполадку в принципе, а затем оценить масштаб и величину изменений, которые для этого придётся внести в программу.
•
Следует взвесить затраты на решение проблемы и сравнить их с ущербом, которая она нанесёт, если оставить её без решения. Достаточно ли серьёзна проблема, чтобы оправдать затраченное на её решение время, особенно если при этом задержится выпуск продукта?
Если решено создать новую сборку, следует назвать её с учётом схемы именования RC
•
Если неполадка локальна, достаточно повторного тестирования лишь той части программы, что была изменена при её устранении. Однако повторное тестирование программы установки следует провести в любом случае.
Эти решения очень важны, и следует проследить, чтобы их принимали компетентные представители каждого из функциональных подразделений. Поскольку эти проблемы решаются на собраниях «штурмовой группы» с участием всех ключевых специалистов, можно быть уверенным в наличии достоверных данных, солидном опыте принимающих решение и в распространении сведений о принятых решениях от первого лица.
Если тестирование кандидата на выпуск успешно прошло в полном объёме, его можно утвердить. Последнее утверждение продукта — во многом формальность, так как именно успешное окончание испытаний кандидата определяет момент, когда проект можно считать завершённым. Однако эта процедура гарантирует, что каждый внёсший свой вклад в создание проекта, будет готов поддержать проект и, если понадобится, отстаивать его. Проект должны утвердить следующие специалисты.
•
Все подразделения: разработчики, тестировщики, специалисты по обучению пользователей, инженерные психологи и технологи — должны единогласно утвердить проект. Это означает, что каждое подразделение внесло свой вклад в создание реального продукта и готово дать ему «зелёный свет». В рамках модели, принятой в NuMega, за готовность проекта в конечном счёте отвечает менеджер проекта, а сама готовность определяется по согласованию с командой. Технические специалисты первыми ставят свою подпись под проектом, без их визы проект дальше не пойдёт.
•
Если группа менеджеров утвердила проект, это означает, что качество реализации функций ПО позволяет выйти с ним на рынок. Планы лицензирования, формирования цены, обучения продавцов, производства дистрибутивов и сбыта также уже составлены, и можно приступать к их реализации.
•
Виза группы технической поддержки означает, что ни одна критическая проблема не осталась нерешённой и группа готова осуществлять поддержку продукта после выхода его на рынок.
•
Виза заказчиков означает, что продукт готов к использованию в их производственном или коммерческом окружении.
После того, как все дали «зелёный свет» можно передавать проект заказчику и принимать поздравления с окончанием работы! Но прежде, чем считать проект завершённым, обязательно прочитайте следующую главу, «Закрытие проекта» (вот тогда проект действительно будет закрыт).
Общие проблемы и решения
Далее обсуждается ряд типичных проблем и вопросов, возникающих при использовании описываемых здесь методик, а также их решения.
Одна из наиболее распространённых проблем, мешающих плавно завершить проект, — нехватка руководства и дисциплины на завершающих стадиях. В этот период менеджер проекта отрабатывает свой оклад, поскольку должен быть кто-то один, ответственный за выпуск ПО. Обеспечить эффективную работу на завершающих этапах проекта нелегко. Возможно, придётся задержать группу в выходные, чтобы провести повторные тесты или отвергнуть последний набор действительно классных изменений из-за слишком высокого риска. Не ограничивайте себя в средствах. чтобы выполнить эту работу в лучшем виде.
Когда на группу обрушиваются все заботы, связанные с выходом ПО, обмен информацией между участниками группы часто нарушается, что провоцирует возникновение слухов и сомнительных разговоров. Обязательно нужно организовать управление работой над проектом вплоть до его закрытия, обмен информацией о его состоянии и решение любых проблем по мере их возникновения.
Поскольку в производстве ПО участвует много людей и постоянно приходится принимать решения, важно назначить ответственных в каждом подразделении, работающем над кандидатом на выпуск. Очень плохо, когда ответственность постоянно переходит от одних людей к другим. Нужны люди, которые могут отвечать за вверенные им команды и за принятые решения.
Необходим конкретный план тестирования кандидата на выпуск. Нельзя тестировать все подряд, на это просто не хватит времени. Нужно сосредоточиться на важнейших фрагментах. Однако у многих групп отсутствует чёткое представление о том, что и как нужно делать. Заключительное тестирование должно быть продумано, прежде чем проект вступит в фазу работы с кандидатом на выпуск.
Если тестирование автоматизировано недостаточно, дело плохо. Возможность автоматизированного тестирования ключевых функций на окончательной сборке программы (и на новых сборках программы, если они будут созданы) имеет решающее значение для своевременной и полной проверки продукта. Нельзя тратить время на тестирование каждого кандидата на выпуск вручную.
Глава 15
Закрытие проекта
Наконец, проект завершён, программа отправлена заказчикам! Это все, не так ли? Ещё нет. Завершить работу над проектом — это больше, чем просто вынести его за дверь и уйти домой. В проект
