О Windows из первых рук: Лабораторные мыши

Манипулирование разработчиками ПО может оказаться полезной стратегией устранения дефектов в процессе разработки софта.

Раймонд Чен

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

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

Один из постоянных источников отложенных дефектов — неорганизованность в работе, которую один из моих коллег удачно называет «пестованием жучков».  Разработчики находят дефекты, от которых по их мнению нужно избавиться, но в текущей работе не находят времени на их исправление. Со временем дефекты стареют и матереют. Разработчики сопротивляются попыткам объявить такие дефекты не требующими исправления или отложенными до следующего выпуска, потому что чувствуют, что эти дефекты действительно нужно устранить.

Это типичное «поведение Плюшкина» в применении к разработке ПО. Разработчики эмоционально привязываются к дефектам, невзирая на отсутствие каких-либо рациональных причин их сохранения. Это обычно не ключевые дефекты. Очень часто это функциональность, срытая под дефект, что-то типа: «Когда я делаю X, хорошо бы иметь возможность сделать Y».

Вызываем дезинсектора

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

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

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

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

Такие недели устранения дефектов часто нацелены против «накопителей дефектов». Такие разработчики должны принять решение. Это последний шанс устранить дефекты, которые планировалось устранить «когда-нибудь». Если разработчик не избавится от «жучка», это дефект будет причислен к тем, которые исправлять не нужно. Так или иначе, но в конце недели дефекта не станет.

Прячем сыр

Во время этой недели менеджмент должен относиться к разработчикам, как к лабораторным мышам. Разработчики могут быть очень прогнозируемыми. Считается, что разработчики — высший уровень развития человеческого интеллекта, но на деле ими легко манипулировать, как марионетками. Опытные менеджеры могут манипуляцией заставить накопителей дефектов решиться избавиться от любимых «жучков».

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

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

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

Raymond Chen's — Web site, The Old New Thing, and identically titled book (Addison-Wesley, 2007) deal with Windows history and Win32 programming. This article was written on equipment that has been in contact with tree nuts.