Искусство управления IT-проектами - читать онлайн книгу. Автор: Скотт Беркун cтр.№ 129

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

Расстановка приоритетов. После первичной обработки и исследований ошибки могут быть расставлены по приоритетам и отправлены на конвейер в соответствии со степенью их важности.

Процесс классификации осложняется тем, что для выполнения любой из этих трех операций знаний какого-то одного человека может не хватить. Чем крупнее проект, тем меньше вероятность, что эффективная классификация окажется по силам одному человеку. Поэтому для большинства команд и большинства проектов классификация является коллективной работой. На ранней стадии классификация силами отдельных специалистов их собственных ошибок вполне допустима, но чуть позже эта работа должна поручаться небольшим группам и подгруппам. Это связано с тем, что ошибки должны быть классифицированы по принадлежности к различным областям проекта (см. ранее радел «Устранение ошибок и дефектов»). Небольшим группам, ответственным за определенную область, проще собираться вместе и классифицировать ошибки независимо от остальной команды.

Чуть позже, ближе к концу эндшпиля, когда каждые решения по ошибкам тщательно анализируются, классификация должна быть централизована в масштабе всего проекта и проводиться основной группой руководителей проекта (мы рассмотрим этот вопрос в разделе «Военный совет»). Теперь важно разобраться с двумя основными разновидностями классификации: ежедневной и целенаправленной.

Рис. 15.8. По мере развития эндшпиля классификация все более централизуется

Ежедневная или еженедельная классификация

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

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

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

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

Как только ошибки будут классифицированы, для них должно быть заполнено поле классификации. Тогда в проекте появятся дополнительные условия для представления данных об ошибках и можно будет отделить количество классифицированных ошибок (в достаточной мере распознанных) от общего количества активных ошибок (еще не прошедших оценку).

Целенаправленная классификация

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

Низкое соотношение числа классифицированных ошибок к числу активных. Если на 500 активных ошибок приходится лишь 200 классифицированных, то невозможно узнать серьезность оставшихся 300 ошибок. Кто знает, все они могут оказаться ошибками с приоритетом первой очереди, вызывающими полный крах системы, или двойниками уже существующих ошибок. Целенаправленная классификация может иметь особую задачу по ликвидации всех неклассифицированных ошибок к определенному сроку (к завтрашнему полудню). Ели эта проблема приобрела для команды хронический характер, задачей может стать не оставить ни одной активной неклассифицированной ошибки старше определенного количества часов (например, 24 часов).

Изменились критерии выхода. Если руководство команды решило, что критерии выхода должны претерпеть изменения, то классификация станет единственным способом вывести проект на путь этих изменений. Обычно новые критерии выхода используются для изменения угла снижения, исключая определенные классы ошибок из рассмотрения для повышения безопасности этого угла (но при этом жертвуя качеством процесса).

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

Ближе к завершению проекта распределенная до этого власть должна централизовываться. В отличие от проектировки функций и программирования, которые могут быть разумно распределены внутри команды, к концу проекта возможности для распределения ошибок уменьшаются. Решения становятся более критичными, представляя собой кропотливое занятие, а не создание какой-нибудь конструкции. В терминах Microsoft такое централизованное управление называется военным советом (что, по-моему, берет начало от термина военная комната, означавшего то место, где лидеры встречались для решения важных проблем). Доминирующей ветвью исполнительной власти становится небольшая группа руководителей команды. В небольших командах подобное смещение властных полномочий может быть и ни к чему, но для средних и больших команд оно просто необходимо. Оно поднимает планку всех принимаемых решений и реализует функцию принуждения в отношении команды, завершающей игру.