За последние 2-3 месяца к нам несколько раз приходили клиенты с просьбой добавить на Kanban доску возможность быстрого изменения ограничения на максимальное количество задач в столбце (WIP limit).

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

На первый взгляд - да, с точки зрения основ юзабилити, идти в настройки проекта за 5-10 кликов для того, чтобы изменить ограничение - это неправильно. Но.

С точки зрения основ самого подхода к разработке, Kanban, это выглядит гораздо более правильным, объясню почему.

Для чего вообще используется ограничение на количество незавершенной работы, WIP?

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

Такое ожидание - одна из основных потерь, с которыми борятся Lean и Kanban. Как можно уменьшить ожидание? Сделать короче очередь задач. Как сделать короче очередь? Ввести ограничение на размер этой очереди и научиться соблюдать это ограничение, например, фокусируясь на доведении каждой задачи до конца перед тем, как взять следующую.

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

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

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

Согласны?

Мы добавили новый раздел на сайте под названием "Решения", в котором будем описывать решения конкретных задач, построенных при помощи системы управления проектами DEVPROM.

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

Группы проектов (или портфели проектов) предназначены для объединения нескольких проектов по некоторому признаку. Например, для организации портфелей проектов относительно заказчика или продуктовой линейки. Основное назначение группировки - упростить просмотр различных отчетов по проектам, например, с целью балансировки ресурсов, самого портфеля или анализа текущего состояния портфеля.

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

Рассмотрим пример использования Devprom.ALM для выполнения некоторого грандиозного проекта "Система хранения данных", в который вовлечено несколько групп сотрудников или внешних исполнителей. Обычно такой проект называется программой проектов, декларирующей общие цели, объединяющей в себе данные и ресурсы нескольких проектов.

Структура программы

В качестве примера рассмотрим программу, состояющую из трех проектов:

1. Корневой проект "Программа: система хранения данных", назначением которого является агрегация пожеланий по программе, хранение общей информации по программе, контроль за ходом выполнения программы проектов.
2. Дочерний проект (или подпроект) "СХД: поддержка продукта", созданный на основе шаблона "Поддержка" и используемый для поддержки пользователей основного продукта, при помощи плагина или автоматической обработки входящих email.
3. Проект "СХД: разработка продукта", в котором ведется основная разработка продукта.

Объединение знаний по всей программе

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

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

Управление ожиданиями по программе

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

Таким образом, руководитель программы может оперативно реагировать на ожидания пользователей, управлять руководителями проектов и корректировать их активности. Для этого в связанных проектах необходимо настроить импорт пожеланий из проектов в программу.

Просмотр результатов работы по программе

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

Контроль за ресурсами программы проектов

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

Любой проект подразумевает выполнение некоторых типовых активностей и создание артефактов ради достижения поставленной цели, что подразумевает наличие какого-то процесса. Процессы могут быть формализованными, общеизвестными или ad-hoc, то есть вашими собственными. Даже если вы считаете, что в вашем проекте нет никакого процесса, то это лишь от того, что вы пока не задавались целью его описать.

Любой процесс, связанный с разработкой ПО, делится на этапы, в каждом из которых обозначаются цели этапа, полезные результаты (deliverables), задачи по получению этих результатов, распределение зон ответственности между типовыми ролями участников процесса. Рассмотрим для примера стадии двух известных процессов, отличающихся по структуре:

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