Искусство управления IT-проектами - Скотт Беркун Страница 131
Искусство управления IT-проектами - Скотт Беркун читать онлайн бесплатно
Но когда ошибка достаточно серьезна, чтобы заставить желе трястись, все опять начинают работать в полную силу. Военный совет берет на себя бремя руководства командой (или, если быть точнее, программистом), пытаясь разобраться с проблемой до такой степени, чтобы можно было применить хирургическую операцию. Затем набор тестов при разных условиях выполняется заново, чтобы гарантировать, что все пришло в прежнее состояние, за исключением той самой маленькой вещицы, которую нужно было изменить. Это очень напряженный процесс. В отличие от масштабных изменений, проводимых в период миттельшпиля, или выявлению ошибок в начале эндшпиля, в завершающие дни уже нет возможности отложить что-либо масштабное на потом. Здесь все очень маленькое, и выплеснуться напряжению некуда.
В этом процессе иные измерения и приоритеты, но они не приводят к существенным изменениям характера работы. Это просто промежуточные этапы на пути к выпуску продукта. Но, по крайней мере, они позволяют скрасить напряженную монотонность поздней стадии эндшпиля.
Баланс нуля ошибок. Когда количество активных и санкционированных (военным советом) к исправлению ошибок становится нулевым, говорят, что команда дошла до баланса нуля ошибок (Zero Bug Bounce, ZBB). Балансом это состояние называется потому, что как только обнаружится очередная ошибка, у команды уже не будет «нуля ошибок». Есть несколько симпатичных теорий относительно дистанции, разделяющей ZBB и текущий выпуск продукта, но ни одна из них не проработана в достаточной степени, чтобы попасть на страницы этой книги.
Нулевое количество решенных ошибок. Решенные ошибки могут представлять собой скрытые проблемы, о которых команда ничего не знает. Пока такая ошибка не будет закрыта (с подтверждением), полной уверенности в том, что ошибка действительно исправлена именно так, как это и предполагалось, быть не может. Достижение нулевого количества решенных ошибок означает, что проект действительно пришел в состояние возможного завершения.
Обнаруживаемыми и активными ошибками в данном случае мы пренебрегаем, поскольку они находятся ниже рассматриваемых критериев. Даже если команда занимается исследованием таких ошибок, пока они не вынесены на рассмотрение военного совета, они в действительности не влияют на продвижение проекта.
Первая сборка проекта, которая отвечает всем критериям выхода, называется кандидатом на выпуск (Release Candidate, RC). Как только появится такая сборка, должен быть добавлен новый критерий выхода: какие из найденных в этой RC-сборке проблем могут стать основанием для создания второго кандидата на выпуск? Если такого критерия не существует, следует предположить, что RC-сборка прошла все проверочные тесты и тесты на качество и может быть выложена в Интернете или помещена на компакт-диск и доставлена заказчикам.
Если такой критерий существует, эндшпиль повторяется. Военный совет решает, какие исследования, проектные решения или разработки должны быть проведены, изменения утверждаются и вносятся, и процесс уходит на второй круг.
В мире программных продуктов, особенно продуктов в коробочном исполнении, RC-сборки стоят дорого. Часто применяются дополнительные тесты и процедуры, через которые должна пройти сборка для подтверждения ее прав относительно установки на компьютер, локализации, соответствия торговой марке и т. п. Что касается Интернета, то тут все зависит от того, как проект интегрируется в другие проекты. Этот механизм может напоминать сложное дерево зависимостей, которыми нужно управлять.
Когда завершается работа над финальной RC-сборкой, праздник в команде наступает далеко не для всех. В зависимости от природы проекта финальная RC-сборка может дать толчок для целой серии новых работ. Возможно, для команды тестировщиков и аналитиков качественного состояния продукта работа будет в самом разгаре, им потребуется оценить загруженность сервера или иные разновидности проблем совместимости, которые могут быть протестированы только при наличии финальной RC-сборки. Конечно, решение этих вопросов можно запланировать, но испытания нельзя начать до тех пор, пока все биты не окажутся на своих местах.
Большинство веб-сайтов или веб-продуктов при публикации проходят через последовательность тестовых серверов, в которых задаются различные условия и сопутствующие нагрузки для окончательного тестового охвата. Чем больше платформ или языков должен охватить проект, тем сложнее процесс обкатки. Разумеется, время, требующееся для надлежащей обкатки, может быть примерно определено на этапе первоначального планирования. В зависимости от организации процесса нагрузка по проведению обкатки может лечь на одну подгруппу или разделена на всю команду разработчиков проекта.
Поскольку приближается завершение этапа или всего проекта, кто-то должен настроить команду на извлечение уроков из всего только что сделанного. Эту работу часто называют описанием ретроспективы проекта, или постпрограммой. На эти действия наталкивает желание зафиксировать информацию, пока она еще свежа в памяти людей, а когда люди соберутся отпраздновать успех и отложить все дела, им вряд ли захочется возвращаться назад и вспоминать обо всех проблемах, с которыми они недавно имели дело. Многие хотят двигаться вперед, оставляя позади свое прошлое.
И тут снова на первый план выступает руководитель. Руководитель команды должен внести свой вклад в процесс выполнения постпрограммы. Поскольку дел становится все меньше, руководитель должен попросить людей подумать над тем, что удалось, а что нет, и оформить это хотя бы в виде списков на отдельных листках бумаги. Руководитель проекта должен составить план по сбору этих записей и созданию постпрограммного отчета. В отчете должны быть отражены две вещи: анализ и резюме всех извлеченных уроков и обязательство учесть в следующем проекте самую незначительную часть этих уроков (если подборка окажется слишком большой, чтобы попасть в следующий проект, расставьте приоритеты и выберите самое главное).
Возможно, для выполнения постпрограммы имеет смысл нанять профессионала [100](или взять кого-нибудь не из команды, а из организации). Исполнители, потратив неделю на расспросы всех специалистов команды, на основе изученного материала составят отчет, который должен пройти экспертизу консультанта. Преимущества такого подхода заключаются в объективности взгляда, поскольку сторонний наблюдатель подметит и озвучит то, что ускользает от взгляда других людей. [101]Возможно, более важным станет то, что они принесут в организацию стороннюю оценку, обращенную к нуждам конкретного проекта и команды.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.
Comments