«Triage is a process of determining the priority of patients treatments based on the severity of their condition» [http://en.wikipedia.org/wiki/Triage]
Какое отношение этот медицинский термин имеет к IT?
В действительно термин triage может применяться не только к «больным», но и ко многим другим объектам требующим «лечения» в условиях недостаточности ресурсов («врачей»). Что в программном обеспечении может являться «болезнью», что требует лечения, и кто являются «врачами»? Дефекты софта и разработчики соответственно.
И так, что делать, если пользователи сообщают о проблемах быстрее, чем вы успеваете их исправить, т.е. скорость исправления дефектов меньше чем скорость обнаружения новых дефектов за какой-то промежуток времени? Какие дефекты нужно исправлять в первую очередь? Что делать с «лавинообразным» потоком дефектов? Ответ один: нужен triage.
Тriage — это процесс, на входе которого сущности (события, объекты, задачи и т. п.) с различными атрибутами или признаками, а на выходе те же сущности, отсортированные по необходимому атрибуту (например, по приоритету или серьёзности).
Рассмотрим software дефекты. В момент, когда дефект обнаружен, у него есть следующие атрибуты:
- описание;
- название дефекта;
- версия софта/железа;
- сабмиттер (заказчик) и другие.
Предположим, имеется большое количество дефектов с такими атрибутами и необходимо выяснить в какой последовательности (или в соответствии с какими приоритетами) их исправлять, поскольку невозможно назначить на каждый дефект выделенного девелопера. (Прим. На практике такая ситуация происходит достаточно часто в крупных проектах.) Можно сказать, что определение приоритетов поступающих дефектов и есть triage. Результатом defect triage-а являются следующие моменты:
1) Какая серьёзность проблемы («степень ранения»)? Насколько сильно последствия дефекта влияют на пользователей? Например, крах всей системы очевидно имеет большую серьёзность по сравнению с ошибкой в одной букве промпта. Сколько пользователей уже обнаружили эту проблему? Как правило, серьёзные проблемы находит достаточно много пользователей. (Прим. В английском языке используется слово severity для обозначения степени серьёзности или жёсткости проблемы.)
2) В каком компоненте/месте программы предположительно находится дефект? Другими словами какой разработчик или эксперт должен смотреть дефект в первую очередь («какой врач должен осмотреть пациента»)?
3) Какая дата выполнения («если не сделать операцию через час, то вероятно больной умрёт»)? Эта дата устанавливается на основе планов и серьёзности.
4) Не является ли проблема дупликатом («не принесли ли больного по второму кругу»)?
5) Исходя из серьёзности, даты выполнения, заказчика и других причин, устанавливается приоритет дефекта («в какую очередь раненый будет вылечен»);
6) И другие, например, нужно ли вообще кому-нибудь исправление дефекта (возможно планы заказчика изменились).
Решение такого круга вопросов может потребовать много времени для большого количества дефектов. Если времени будет потрачено слишком много, то ценность triage заметно упадёт. Например, это время могло бы быть потрачено на «лечение больных». Поэтому продолжительность triage ограничивается — на каждого «раненного» тратится строго не больше отведённого времени.
Чтобы достичь наибольшей производительности к defect triage-у привлекаются следующие группы специалистов (не обязательно одновременно):
1) представитель тестовой команды или представитель заказчика, чтобы ответить на уточняющие вопросы от других участников triage-а, определить серьёзность и сроки по дефектам;
2) эксперт широкого профиля («врач общей практики») или эксперты и/или руководители разных компонент, знающие проблемы своих компонент, чтобы примерно определить компонент (кто должен будет работать над проблемой), дупликаты, серьёзность, и согласовать приоритеты с заказчиком.
Все участники triage-а должны быть беспристрастными и квалифицированно выполнять свои функции, иначе «больной» может получить не тот «диагноз» и потерять ценное время в очереди не у того «врача». Хуже всего, когда один и тот же дефект найденный тестерами анализируется как два разных дефекта двумя или более разработчиками разных команд. В таком случае, происходит дублирование работ, поскольку маловероятно, что дефект окажется комплексной проблемой требующей участия сразу нескольких команд или разработчиков.
Triage — эффективная практика, но она не является панацеей, как в прочем и любая другая практика (за исключением реюза ;)). Не редко требуется реприоритезация дефектов после triage-а уже непосредственно перед назначением дефектов в работу. Поэтому нужно понимать, что triage — это всё-таки высокоуровневая приоритезация дефектов.