Пример использованияОписание работы системы на примере учета багов и модификаций программыПроиллюстрируем принцип работы системы "Трекер" на примере того, как мы используем его для учёта процесса сопровождения и развития наших систем. Напоминаем, что в абстрактном виде Трекер оперирует понятиями:
Если вдуматься, то, оперируя этими понятиями, даже в чистом виде можно вести учёт любых процессов предприятия. В простейшем случае Трекер мог бы состоять из одного класса – Предприятие. В абстрактной форме процесс решения любой проблемы может быть разбит на следующие этапы:
Трекер автоматически ведёт учёт времени, когда что-то изменилось в заявке, и автора изменений, что позволяет постфактум разобраться в произошедшем, анализируя лог. В простейшем случае любой сотрудник имеет право на все действия в системе. Сама же проблема в принципе может быть описана одним большим текстовым полем. Настроив систему таким образом, мы получаем возможность вести учёт произвольного процесса, и очень во многих случаях такой примитивный подход позволяет принести пользу и решить многие проблемы. К такому подходу мы иногда прибегаем, когда проблемы подразделения носят очень разнообразный характер, и декомпозиция всех бизнес-процессов представляется слишком трудоёмкой. Или как вариант – если мы не знаем, какие именно задачи возникнут перед подразделением. Например, классический случай такой ситуации – работа менеджера по управлению проектами. Тем не менее, несмотря на соблазнительность такого подхода (несомненный плюс – простота развертывания), на практике, будучи реализованным, он приводит к мешанине задач, непониманию исполнителем, что именно он должен делать, и невозможности провести анализ работы подразделения. Чтобы Трекер принес вашему предприятию пользу, необходимо реализовать следующий подход:
Практика показывает, что Трекер начинает приносить реальную пользу только тогда, когда исполнитель видит в сводной таблице не больше тридцати задач. Если в сводной таблице задач больше, то большинство исполнителей теряется, или не делает вообще ничего, или начинает заниматься не совсем тем, чем нужно. Фактически, если вы настроили Трекер так, что в сводной таблице у исполнителя оказывается больше тридцати задач, значит вы его настроили неправильно, и необходимо проводить декомпозицию, вычленять этапы, делить ответственных, делить бизнес-процесс на разные потоки и фиксировать изменения в Трекере. Не исключено, что на предприятии неправильно поставлен сам бизнес-процесс, Трекер – неплохой инструмент, помогающий осознать точки перегрузки или недогрузки :) Девелоперский коллектив у нас разбит на несколько рабочих групп. Каждая группа занимается своим проектом. Работа над Трекером ведётся группой из трёх человек: два программиста и один аналитик. При этом у программистов есть свои профили – типы задач, которыми они занимаются. Сам рабочий процесс построен следующим образом. Пользователь системы, у которого есть какое-либо пожелание по функционалу, либо он хочет зафиксировать баг создает новую заявку. Права на создание новых заявок есть у всех сотрудников Ринета (реально этой возможностью пользуются руководители и ответственные сотрудники подразделений, которые естественным образом аккумулируют пользовательские проблемы). При создании заявки заполняются поля: описание, класс задач, тип изменения, комментарий, важность.
Созданная заявка рассматривается аналитиком. При этом она уточняется и обычно переформулируется. Часть заявок на этом этапе отклоняется ввиду технической неисполнимости. Часть заявок закрывается ввиду того, что реализация либо запланирована, либо проходит в данный момент. Кроме этого аналитик согласовывает очерёдность и важность этой заявки у руководства компании. По результатам рассмотрения аналитик заполняет поля: ответственный (программист), очередь разработки, подтверждает согласованность заявки. По окончании работы аналитик переводит заявку в этап «Принять заявку на разработку».
Этап «Принять заявку на разработку» накопительный, так как скорость поступления заявок выше скорости разработки. Программист на основании очерёдности заявки знакомится с ней. Если у него возникают вопросы по формулировке, то он уточняет их у аналитика. На этом этапе определяется предположительная трудоёмкость разработки (в часах). Если в процессе реализации оказывается, что трудоёмкость превышает первоначальные оценки, то производится пересогласование у руководства компании. Кроме трудоёмкости, оцениваются другие параметры сложности (нужно ли менять движок, могут ли потеряться данные). Для того, чтобы учитывать эти особенности в форме на этом этапе заполняются соответствующие поля.
По мере того, как программист решает свои задачи, он переводить заявки из этапа «Принять заявку на разработку» в этап «Провести реализацию». Для того чтобы избежать мешанины и правильно оценивать загрузку программистов, этот этап у нас разбит на четыре этапа:
Как видно, задачи у каждого программиста разбита на два потока: длинные задачи и короткие задачи. Рабочее время программистов разделено на время, когда они занимаются длинными задачами, и на время, когда они занимаются короткими задачами. Это сделано для того, чтобы очереди не блокировались. На данном этапе программист заполняет поля: План работ, предполагаемый срок реализации. По окончании реализации программист подтверждает её окончание.
На следующем этапе программист заливает произведённые изменения на тестовую платформу для тестирования. Аналитик тестирует изменения, проверяет полноту реализованного функционала и пытается убедиться в том, что в систему не внесены новые баги. Если аналитик считает, что разработка по заявке произведена успешно, он заполняет поля «Проверено?» - «да», а также переводит в этап «Накатить задачу».
На данном этапе программист заливает произведённые изменения на основную платформу и переводит в этап «Проверить на основном серваке».
На этом этапе аналитик убеждается, что все нормально, и пытается показать результат пользователю, который создавал заявку.
Если все нормально, то заявка переводится в архивное состояние (этап «Заявка закрыта»). Если есть проблемы, то заявка возвращается на доработку.
С помощью механизма расширенного поиска руководство компании оценивает количество решённых заявок за период. Кроме того, дополнительным механизмом контроля является просмотр количества заявок по этапам. Если в каком-то этапе заявок слишком много или слишком мало, то можно предположить наличие организационного сбоя. |
