Завершение тестирования или этапа в целом. Этап завешен. Качество и оптимизация достигли приемлемого уровня. Начинается работа по плану следующего этапа и (или) поставки программного продукта. Поскольку это последняя фаза этапа, ее иногда называют завершением этапа. Если данный этап бы единственным или последним, то завершается весь проект.
Если не принимать во внимание качество подготовки технических условий, качество оценки работ и способности самой команды, то для соблюдения намеченных сроков будет действовать следующее простое правило: чем точнее определены критерии выхода, тем больше шансов на своевременное завершение.[89] Предполагается, что команда продолжает работать до тех пор, пока критерии выхода не будут соблюдены. Набор критериев выхода должен быть у любой мало-мальски значимой контрольной даты рабочего графика.
Определение набора критериев выхода
Критерии выхода не должны быть слишком сложными (хотя и могут быть таковыми). Тем не менее в наборе критериев выхода должны содержаться следующие элементы:
• Перечень завершаемых работ.
• Показатели качества, с которым должны быть завершены эти работы (взятые, возможно, из параметров тестовых испытаний, планов тестирования[90] и технических условий).
• Перечень необязательных дел, о которых у некоторых сотрудников сложилось мнение, что их обязательно нужно сделать.
• Перечень всего, что не нужно делать, даже если у кого-то сложилось иное мнение (проверка на здравый смысл).
Определять набор критериев выхода, доводить их до всей команды и отслеживать соблюдение можно различными способами. Детали здесь не имеют особого значения (предложите набор критериев команде, соберите отзывы, затем завершите его разработку и доведите результаты до всей команды). Важно, чтобы этот набор был определен как можно раньше, легко воспринимался и использовался открыто для отслеживания хода процесса и реализации принятых решений. Критерии выхода должны соответствовать концептуальному документу и целям проекта, стать наиболее удобными инструментами применения концепции и целей в разрешении всех вопросов и сложностей, возникающих в середине и на завершающей стадии любого этапа.
Обычно критерии выхода означают, что сделано следующее:
Составлены списки технических условий, проектных решений, работ. Как правило, эти списки полезны только как критерии завершения проектирования. Этапы проектирования должны иметь соответствующие критерии выхода независимо от того, какие инструменты или процессы применялись для их выполнения. Возможно, условием выхода из этой стадии станет принятие 90 % общего объема технических условий или создание прототипа с определенной функциональностью.
Выполнены текущие работы. Имеется в виду перечень работ, определенный в начале этапа или фазы проекта. Как только работы будут выполнены в соответствии с требованиями технических условий, этап (фаза) завершится.
Подсчитаны все ошибки по уровням их значимости. Ранее уже шла речь о том, что для выявления и оценки значимости ошибок (дефектов) применяется множество различных способов. Обычно критерии выхода включают создание детального описания обнаруженных ошибок конкретного типа.
Пройден определенный набор тестов. Определение факта завершения этапа может быть обусловлено прохождением некоторых тестов. Если результаты тестирования используются в качестве критерия, на их основе принимаются решения о том, какие ошибки или дефекты подлежат устранению до завершения этапа. Возможно, будет вполне достаточно использовать критерии выхода на основе определенного порога прохождения тестовых испытаний, к примеру: «должны быть пройдены 80 % тестовых испытаний по сценариям, относящимся к приоритетам первой очереди».
Достигнуты определенные показатели производительности или надежности. Если команда производит замеры производительности определенных компонентов (скажем, базы данных или поисковой машины), то критерии выхода должны быть основаны на ее показателях. Если критерии выхода заключаются в увеличении скорости на 10 % по сравнению с показателями предыдущей версии, значит, этап не может считаться завершенным до тех пор, пока не будет достигнуто 10-процентное увеличение.
Потрачено определенное время или деньги. Время является самым простым в мире критерием выхода. Этап завершается по прошествии определенного времени. И все. Лучше всего измерять этап месяцами, тогда не будет никаких сомнений насчет времени его начала, времени окончания и продолжительности. (Ведь меряют же люди остаток своей жизни месяцами и неделями, так почему же не построить на той же основе график разработки проекта?) Все наполовину или частично реализованные характеристики отбрасываются, чтобы учитываться уже на следующем этапе (если он предусмотрен). Деньги также могут стать критерием выхода: когда бюджет исчерпан, энергия иссякает, и работа останавливается.
В отсутствие критериев выхода команда должна придерживаться субъективных мнений относительно того, что для проекта является «вполне достаточным», а что считать бесполезной тратой времени. У каждого на этот счет может быть собственное мнение. Даже если решение принимается единолично, оно все равно будет считаться спорным, пока не созданы некие письменные нормативы. Отсутствие критериев скажется впоследствии вынужденными нелегкими дебатами, в которые команды позже будут втянуты, как только возрастут риски и опасения за судьбу проекта. Не ставьте команду в такие условия, при которых она должна в конце этапа тратить свою энергию на споры вокруг критериев выхода, а лучше спланируйте все так, чтобы она в конце этапа тратила всю свою энергию на реальное достижение этих критериев.
Запомните, что цель заключается не только в том, чтобы уложиться в указанный срок, но и в том, чтобы подвести проект к определенной дате в определенном состоянии. Чем скорее команда поймет, в чем заключается это состояние, тем выше будут шансы на успех. Если критерии известны на ранней стадии, они отражаются на всех решениях, принимаемых в ходе выполнения этапа. Даже если в процессе работы критерии претерпят какие-то изменения, команда будет перестраивать свою работу в едином направлении, дружно подводя проект к легкому эндшпилю.
К примеру, перечень критериев выхода для какого-нибудь этапа реализации проекта по созданию небольшого веб-сайта может быть следующим:
• Выполнить в соответствии с заданными техническими условиями все работы с первой по десятую.
• Достичь 80-процентных показателей потребительских качеств, относящихся к приоритетам первой очереди.
• Пройти все тесты первой очереди в автоматическом и ручном режимах.
• Пройти 80 % тестов второй очереди в автоматическом режиме.
• Классифицировать все найденные ошибки.
• Исправить все ошибки, относящиеся к приоритетам первой и второй очереди.
• Получить разрешение на завершение этапа от команды по маркетингу и развитию бизнеса.
Почему соблюдение сроков напоминает посадку самолета
Цель промежуточных этапов не только в том, чтобы выдержать определенный срок, но и в том, чтобы настроить команду на следующий этап (или на выпуск следующего варианта). Соблюдение сроков – это не только вопрос хронологии: риск, которому подвергается надежность программного кода и выполнение следующего этапа (если таковой имеется), зависит от плавности движения к контрольной дате.
Представьте себе посадку самолета. Удачное приземление облегчает повторный взлет самолета: крылья на месте, шасси исправно, экипаж жив. Все, что нужно – это дозаправка, план полета и сэндвич для пилота. Завершение этапа должно рассматриваться в этом же ключе. Чем круче закладывается вираж для завершения этапа, тем вероятнее, что по его окончании проект окажется не в самом лучшем состоянии.
Угол сниженияТиповые графики разработки проектов могут быть сведены к простой диаграмме, наподобие показанной на рис. 15.3. Диаграмма составлена с предположением, что показатель прогресса проекта является постоянной величиной, а проект завершится точно по графику при соблюдении постоянного темпа работы. Разумеется, все это из области фантастики. Эта диаграмма никогда не станет отражением реальных событий, поскольку темпы работы команды и ее продуктивность никогда не будут постоянными величинами (по многим рассмотренным ранее причинам).
Рис. 15.3. Характерный пример графика выполнения этапа с неправдоподобными допущениями
Скорее всего, большинство проектов могут оказаться в ситуации, воспроизведенной на рис. 15.4. В какой-то точке пути по направлению к конечной дате команда поймет, что работа идет не так быстро, как ожидалось. Такое может случиться из-за того, что команде поставили дополнительную задачу (см. раздел «Контроль изменений» в главе 14) или не оправдались сделанные ею оценки. Неважно, по какой причине это произошло, но теперь команда оказалась перед выбором: как преодолеть расстояние, оставшееся до конечной даты? Есть только три варианта:
