Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Laughing_Silencer, Вы писали:


L_S>>1. Определить функциональные области и их распределение по командам. Разделить проблемы по функциональным областям (вообще уже должно быть, но вдруг нет) и проанализировать их распределение. Если какая то функциональная область перегружена проблемами собрать совещание с соответствуещей командой и проанализировать причины (2-3 часа максимум).

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

G>Три группы имеют равномерное распределение проблем.

G>А вот одна — огромное количество появляющихся проблем, выше в несколько раз чем в остальных группах. Говорят, сложная область у них. Ядро системы делают. Центральный компонент системы.

G>Что делаем дальше?

Классифицируем дефекты по причинам возникновения. Навскидку пусть будут такие: баг внесенный исправлением, баг внесенный новой фичей, legacy, изменение требований (не баг, а допил по живому). Смотрим чего из них больше и по факту принимаем решение. Если баги вносятся в ходе исправления других багов, то ужесточаем процесс (инспекции и ревью плотнее или в другом составе, ревью у архитектора в обязательном порядке, юнит тестировние расширенное, тестирование специально выделенным на это человеком). Аналогично и при написании новых фич разве что нужно определить почему поломали — или не продумали на стадии дизайна или не правильно закодировали, ну или не дотестировали. С legacy и так все понятно и ничего поделать нельзя, но и много их быть не должно. В случае частых изменений требований их нужно согласовывать со мной. Буду выставлять приоритеты и сроки основываясь на загрузке команды и приоритетах других задач.


L_S>>Приоритеты задач выставляются мною на основе общения с маркетингом, заказчиками и т.п. Практически все корректирующие действия, как видно, производятся в рамках команды и кроме команды требований никого привлекать пока не нужно — по результатам видно будет с кем общаться.

G>1. Каким именно правилом вы будете руководствоваться для выставления приоритета?
G>2. В базе уже 2000 дефектов. Им выставлен приоритет по пятибальной шкале. Что с ними будем делать?
G>3. Процесс выстроен так, что дефекты заводит группа поддержки. В ней, скажем, пятеро человек. Сейчас — она выставляет приоритет. Что именно вы будете делать с этим, и каким образом?

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

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

G>Выяснили, что в команде, в которой рейт исправления низкий, есть два новичка, которые дефектов не правят, а делают фичи сбоку. Так произошло потому, что "старики" боятся их пускать в ядро системы, чтобы дров не наломали. И вообще, их тимлид слабо представляет себе, что ему с ними делать.

G>Однако, даже если новички подключатся к исправлению, рейт не будет на уровне остальных команд. Дефекты, говорят они вам, сложные, и ваще. Что именно вы будете делать для того, чтобы выровнять рейт исправления дефектов?

Выше написал — нужно понять причины возникновения. Дальше на основе приоритетов выстроить порядок исправления существующих дефектов и наименее приоритетные отдать новичкам. Пусть учатся. На ревью кода новичков в обязательном порядке приглашать "стариков" хотя бы 1-го. Через месяц по результатам переводить на фикс уже полноценный. Если новички технически подкованны, то за месяц основы новой системы усвоят и лишнего не поломают с учетом обязательного ревью изменений. Если по факту анализа выяснится, что дефектов все равно слишком много на такую команду, то добавить еще людей из других где меньше дефектов и по схеме выше.

L_S>>Основные направления выяснения причин — бардак при распределении задач, проблемы с постоянно меняющимися приоритетами, посторонние задачи, не эффективное переключение между задачами.

G>Давайте на этом остановимся. Пусть будет по порядку. Отвечать реально тяжело — приходится ситуацию в голове симулировать. Допустим, вы заметили, что приоритеты часто меняются. И что переключение между задачами не эффективно. Как вы трактуете эти симптомы, ваша версия, почему они произошли, и что вы будете с ними делать.

Обычно приоритеты меняются когда либо меняются требования, либо реалии рынка. Бороться с этим мало реально, но можно превентивными мерами сильно снизить воздействие и не допустить бардака. Например выделить уже продаваемые и стабильные версии на бранчи в системе контроля версий и туда вносить исключительно критичные исправления. Также можно на ревью требований обсуждать с заказчиком реальную их необходимость — может быть это не так и нужно и услышав, что требуются еще монеты за их внесение он откажется, но тут надо аккуратно, что бы не ушел. На каждое новое требование в уже работающую систему нужно обязательно делать фича тестирование, регрешен тестирование и санити до сабмита. Не допускать сабмита до достижения 95/100 на фича тестировании, а также при наличии не разрешенных проблем с санити и регрешена. Время на получение фичи в продукте увеличиться, но подавляющее количество багов будет найдено.