Распределение мощности в соответствии с нагрузкой

Поняв нагрузку, вы можете определить, какую мощность системы выделить на ее удовлетворение. В примере на рис. 6.5 приведены три «плавательные дорожки», по одной для каждого типа работы, а именно для запросов изменений, внутренней эксплуатационной деятельности (например, рефакторинга кода) и производственных текстовых изменений. В итоге выделено 60 % на запросы изменений, 10 % на работу по рефакторингу кода и 30 % на производственные текстовые изменения. Учитывая анализ нагрузки, который показывает, что производственные текстовые изменения прибывают порциями, такое распределение мощности демонстрирует, что значительный резерв выделяется на срочную обработку производственных текстовых изменений сразу после их прибытия без ущерба для дедлайнов по другим работам. Распределение мощности должно учитывать профиль риска. Если, например, допустима просрочка выполнения заданий для производственных текстовых изменений, а время выполнения по запросам изменений может быть более длительным и менее предсказуемым, то распределение будет иным: например, 85 % на запросы изменений, 10 % на обслуживание и 5 % на производственные текстовые изменения. Еще один вариант – оставить «плавательную дорожку» для производственных текстовых изменений, но не выделять для них никакой мощности, а просто превысить ограничение числа незавершенных задач, если поступает пакет производственных текстовых изменений. Тем самым вы отказываетесь от ненужного резерва и выдаете оптимальный экономический результат при обычной работе. Однако когда пакет производственных текстовых изменений действительно прибывает, это может повлечь за собой серьезные последствия для всех других задач с точки зрения времени выполнения и предсказуемости.

Такой выбор сделан в реальном примере (глава 4), когда было решено не резервировать отдельные силы для работы с производственными текстовыми изменениями.

.

Рис. 6.5. Канбан‑доска с типичными «плавательными дорожками», включая распределение мощности

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

Анатомия карточки

Каждая карточка, представляющая конкретный элемент работы, создающей ценности для клиента, содержит информацию по ряду пунктов. Важен дизайн карточек. Информация на них должна способствовать работе вытягивающей системы и помогать людям принимать индивидуальные решения об очередности новых задач. Информация на карточке группируется по типу работы или по классу обслуживания (об этом речь пойдет в главе 11). В примере на рис. 6.6 число в левом верхнем углу – это индивидуальный электронный номер, четко идентифицирующий задачу и связывающий ее с электронной версией системы управления задачами. Название задачи написано в середине. Дата поступления карточки в систему – слева внизу. Это служит двум целям: позволяет установить порядок очереди для стандартных классов обслуживания и дает возможность членам команды видеть, сколько времени прошло с момента соглашения об уровне обслуживания (описано в главе 11). Для элементов класса обслуживания с фиксированной датой поставки в правом нижнем углу карточки указывается требуемая дата выполнения.

.

Рис. 6.6. Увеличение участка стены карточек, демонстрирующее анатомию карточки

В примере на рис. 6.6 помимо текста на карточках приводится и другая информация. Звездочка обозначает, что данная задача завершена позже времени выполнения, указанного в соглашении об уровне обслуживания. Недавно я видел, как это же обстоятельство отмечалось стикером, прикрепленным к верхнему правому углу карточки. Имя назначенного специалиста тоже пишется над карточкой. Поскольку при перемещении карточки по доске назначенные специалисты меняются, писать имя на карточке нежелательно. Однако в последних вариантах применяются небольшие ярлычки, прикрепляемые к карточке, а иногда используются магниты (если доска магнитная), на которых помещаются аватары членов команды. Популярный источник аватаров – мультсериал «Южный парк». Подойдет любой механизм, который позволит членам команды и их руководителям сразу понять, кто над чем работает.

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

Системы управления задачами

Системы управления задачами для канбан‑систем применяются в разработке ПО с момента их первого внедрения в 2004 году. Но использование таких систем не обязательно. Правда, для географически распределенных команд или для коллективов, члены которых могут один либо несколько дней в неделю работать дома, система управления задачами необходима. Фиксировать задачи в электронном виде можно при помощи самых простых систем учета – например, Jira, Microsoft Team Foundation Server, Fog Bugz и HP Quality Center. Однако более мощная система позволяет визуализировать поток задач, как будто бы он находится на доске с карточками.

В настоящий момент на рынке появляются веб‑сервисы и приложения для электронной визуализации. Они используют визуальные панели, которые симулируют стены карточек с их столбцами, ограничениями числа рабочих задач и другими сущностными характеристиками Канбана. Среди них есть (список, конечно, неполон) Lean Kit Kanban, Agile Zen, Target Process, Silver Catalyst, RadTrack, Kanbanery, VersionOne, Greenhopper for Jira, Flow.io и некоторые другие надстройки с открытым кодом, которые добавляют интерфейс Канбана к таким инструментам, как Team Foundation Server и FogBugz. Рис. 6.7 демонстрирует пример из AgileZen.

Рис. 6.7. Скриншот AgileZen, система управления задачами

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