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

• Вы разработчик ПО, руководитель группы разработки, менеджер проекта или его эквивалент.
• Над проектом работает больше одного программиста, желательно — больше трех.
• Вы пробовали все эти скрамы и эджайлы, почувствовали их прелесть, но есть определенные нарекания к догматическому следованию методологии. Возможно, у вас никто не занимается постановкой процессов совсем и задачи просто «накидываются».
• Команда устала (от проекта, от стресса, …) и в скором времени всех ждут кнуты и пряники.

Хорошо, есть методология, которая выдумана командой программистов «для себя», но которую, по нашему мнению, будет интересно попробовать и другим. Внутри команды воссоздаётся небольшая экономическая модель рыночных отношений, а приоритеты регулируются при помощи курса внутрикомандной валюты. .

Преамбула

IT мир изобрёл немало подходов к построению процесса разработки ПО, заимствуя лучшие идеи у своих допостиндустриальных коллег. На определенном этапе своего профессионального развития мы столкнулись с проблемами мотивации, управления качеством и визуализации работ для команды и заказчика. Взяв все лучшее из всего лучшего, что взяли до нас, мы организовали работу над проектами среднего размера в виде старбана (starban).

Историческая справка

Долгое путешествие по вселенной коммерческой разработки программного обеспечения столкнуло нас с множеством подходов к ведению проекта. Мы видели и водопады, работали по RUP, пробовали применять базовые концепции MSF, но самые теплые воспоминания оставили гибкие методологии. В рамках одного проекта, который продолжался 2 года, мы перешли с scrum на kanban, делили и объединяли команды, сгибали под свои нужды Голдратта и тойоту.
Из скрама мы взяли способы коммуникации команды и оценку задач в безразмерных (условных) единицах. Итеративность процесса так же важна, но может регулироваться. Так же, в скраме отлично детализирована визуализация текущей работы (тактическое планирование). Канбан хорош применением теории ограничений, гибкостью их настройки под изменения внутри команды и визуализацией текущей работы на стратегической карте. Сложно полностью разделить две этих методологии, поскольку в каноническом воплощении они встречаются редко. У многих программистов, например, есть сложности с оценкой задач в story point, поэтому зачастую создаются таблицы перевода человекочасов в стори поинты или же оценка сразу проставляется в часах. Вместо этого мы решили оценивать задачи по их текущей ценности для проекта и назвали эту величину звездами. Так появилось название starban.

Когда нужен STARban

1. Есть проект с не всегда готовым или понятным ТЗ, которое нужно представить в осязаемом и оцениваемом виде.
2. Размер проекта достаточен для того, чтобы команда не успевала следить за изменениями в проекте, вносимыми другими участниками и текущим статусом проекта.
3. Проблемы коллективной ответственности (Почему это должен делать я? Закомичу так, может тестировщик не найдет? Опять кто-то билд свалил, пойду пока пообедаю. Не баг это.)
4. Снижение мотивации с течением времени из-за перехода проекта в статус поддержки или из-за overqualified. (слишком хорош чтобы работать, слишком уродлив чтобы заниматься проституцией).

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

Прежде всего нужно отметить, что starban это не законченная методология разработки ПО, а набор расширений, позволяющий повысить продуктивность и не дать проекту погрузиться в кризис. Уставший разработчик может уйти с проекта и унести с собой уникальные незадокументированные знания. Менеджер может слиться на оффер получше, и тогда понять текущий статус проекта может быть довольно проблематично. Отдел тестирования закроет задачу и построит приемочное тестирование таким образом, будто все пользователи продукта полностью прочитали инструкцию и поклялись могилой своего кота никогда ее не нарушать. Отдел разработки ругается с отделом с отделом тестирования, перекладывая ответственность на аналитиков и собирая масштабные митинги, на которых можно 2 часа слушать, 1 час составлять meeting minutes и по итогам назначить следующее собрание уже со стейкхолдером чтобы пересказать ему всё еще раз.

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

Принцы разработки STARban

Деление на команды

Даже если в команде всего 4-5 разработчиков, есть резон разделить их на 2 команды, поскольку больше 3 человек вряд ли смогут параллельно заниматься разработкой одной фичи (пользовательской истории). Чаще всего фичей заняты 1-2 человека, третий может в это время заниматься подготовкой к разработке следующего функционала.
Если усреднять, то наш опыт, почему-то, всегда показывал, что идеальные команды всегда состояли из трех человек. Возможно, это субъективное значение, но наши коллеги тоже часто приходили к такому же выводу. Быть универсальной автономной единицей сложно и плохо вследствие отсутствия внешнего контроля принимаемых решений, а коллектив большего состава может блокировать сам себя. К тому же, каждый член команды должен знать, чем заняты другие.

Использование доски для визуализации прогресса проекта и команд

Доска должна выполнять следующие функции:

1. Показывать наиболее полный RoadMap проекта. Команда будет видеть, к чему движется продукт и использовать это при разработке для применения наиболее оптимальных со стратегической точки зрения решений. Владелец продукта может на этой же схеме корректировать приоритеты и при этом понимать, что дополнительные срочные задачи повлияют на deadline других.
2. Иллюстрировать стек ближайших задач к разработке. Это дает стимул к завершению текущих задач. Задачи к разработке должны быть оценены в SP.
3. Отображать статус текущего исполнения задач командами. Это позволит членам команд скоординировать свои действия, информировать других членов команды о проблеме, увидеть моментальный статус. Менеджер на основе динамики этих данных может увидеть проблему и вмешаться в ее решение.
4. Готовые задачи могут разделяться на версии при выпуске очередного релиза, что позволит ориентироваться в функциональности того или иного выпуска продукта.

Доска является важной частью в оптимизации процесса и должна быть максимально информативной.
Самой левой колонкой является Roadmap проекта, отсортированный по приоритету задач. Здесь же должны содержаться глобальные технические задачи обслуживания и модернизации инфраструктуры разработки. Здесь же может содержаться срочный запрос на исправление функционала, но он должен соблюдать те же правила, что и остальные карточки. Для себя мы приняли два правила – карточки в этой колонке разделяются по цветам и для каждой карточки представлен ее числовой приоритет, который поможет при сортировке в системе ведения проекта. Эта колонка должна быть по возможности максимально заполнена чтобы все участники могли видеть ожидаемый результат разработки и учитывать будущие потребности при выполнении текущих задач. Менять приоритет выполнения задачи может единолично стейкхолдер (заказчик, его представитель, владелец разрабатываемого ПО). При изменении приоритета он сразу может оценить потери – выпуск каких фич сдвинется вследствие его изменений.

Следующая колонка – product backlog – содержит формализованные в виде пользовательских историй задачи по изменению функционала, баги и технические задачи. Детализация здесь может быть разной, как и типы задач. Например, слияние веток в системе контроля версий может относиться к конкретной user story, но может быть и отдельной оцениваемой карточкой в зависимости от контекста. Приоритет в этой колонке перестает играть роль, а порядок извлечения задач должен настраиваться менеджером при помощи «звездной оценки». О звездах поговорим позже, пока только стоит знать, что командам выгоднее брать к себе в разработку более звездные карточки. На эту колонку можно ввести ограничение по количеству одновременно находящихся в ней карточек чтобы избежать спекуляций. Мы пробовали правило кошачьего лотка, когда число карточек должно на 1 превышать число мини-команд, занимающихся разработкой (количество лотков, если вы содержите дома несколько кошек, должно так же превышать их количество на единицу).

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

Следующие четыре колонки разделены по горизонтали. Каждая команда владеет своим кусочком доски и ведет учёт на нём. Когда у команды возникает потребность взять в разработку очередную карточку из product backlog, она проводит планирование — декомпозирует задачу на таски, выясняет подробности реализации, оценивает сроки реализации. Задача берется «в работу» — и сюда же помещаются все карточки. Декомпозиция должна быть достаточно подробной для того, чтобы соблюдалось правило: один человек на одну задачу. Еще хорошо идёт иерархическая нумерация <номер фичи>.<номер таски> или цветовое деление по фичам.

Как удержать команду от захвата лишних задач, на которые нет свободных рук? Нужно ли это делать? Вводить ли ограничение на число карточек? Скорее это нужно регулировать звездно-рыночным методом, о котором еще будет рассказано, но при возникновении проблем можно без проблем вводить Голдраттовские ограничения. Для заданий из колонки «в работе» можно использовать значки — это дополнительные приметные издалека пометки для карточек. Стикеры с жирными символами — подходят. Примеры: "!" — задача находится в работе дольше, чем по изначальной оценке; "?" — по задаче есть вопрос, который требует проведения собрания с другими командами. Следует актуализировать эту часть доски как можно чаще и следить за бейджами на задачах.

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

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

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

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

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

Экспоненциальная временная шкала доски

Это так же можно переформулировать как «одна доска для всего». Бывает так, что доску с Roadmap продукта разделяют со скрам-доской, а уж распределение фич по релизам и вовсе не визуализируют. Это имеет свои преимущества, например, дорожную карту можно проиллюстрировать в виде настоящей карты, показав зависимость элементов вместо не всегда очевидных числовых приоритетов или плоского списка. ОК, никто не ограничивает вас в пространстве (если быть более точным — никто не ограничивает вас в пространстве-времени)!

Магнитно-маркерной доски с площадью 2-3 квадратных метра вполне хватит чтобы сделать двухмерную модель крупного проекта со всеми необходимыми колонками и еще останется место для художественного оформления. Если использовать электронную версию с масштабированием, то ничего не мешает детализировать задачи до любого необходимого предела. Доска с точки зрения временной шкалы будет выглядеть как «месяцы -> недели -> дни -> месяцы».

Оценка задач в звездах

В чем оценивать задачи — в часах или в story point? Много существует попыток определения стори поинта и методики оценки в безразмерных величинах (слонах, попугаях). Большинство приводят к понятию сложности и в итоге к внутреннему (а иногда и официально утвержденному записанному) построению таблицы соответствия SP -> часы. Погуляв между проектами, можно встретить вначале оценку из расчета 1 SP == 8 часов команды, а потом, в соседнем кабинете, увидеть 20 SP == 8 часов работы 1 человека. Иногда зависимость нелинейная. И никогда нет понимания с первого раза, что же такое этот story point. Все, как говорят книги, в сравнении. Было бы с чем сравнивать.

«Star point» или просто «звезда» — безразмерная величина оценки задач в проекте на основе их текущей значимости для проекта. Можно провести аналогию с деньгами. Есть команда разработчиков, которые непрерывно работают по договорной ставке в звездах. Менеджер предлагает новую задачу — необходимо добавить в продукт версионирование и сделать присвоение версий полуавтоматическим при сборке на билд-сервере. Предлагает цену в 10 звезд. Программисты оценивают задачу и понимают, что проще поправить 10 багов, которые сейчас оцениваются в 1 звезду за каждый. Поскольку указание версии срочно требует служба поддержки для нужд фиксации ошибок, этот функционал является более приоритетным, чем стабилизация продукта, поэтому менеджер назначает цену в 20 звезд и первый же освободившийся разработчик торопливо забирает эту задачу для себя или своей команды, чтобы заработать сразу 20 звезд.

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

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

Рынок

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

На что можно тратить звезды? Все зависит от проекта и компании, нематериальная мотивация бывает разной. Можно не брать в рассмотрение отгулы, xbox one, спортзал и прогулки на яхте за каждые полтысячи звезд — ведь это ваша компания предоставляет своим сотрудникам без всяких условий. Внутри проекта есть много другой рутины, которая может являться товаром. Не все задачи интересные, а интересные могут быть не так актуальны и от этого в низком приоритете. Две команды могут присматриваться к одной задаче. Можно устроить торги за эту задачу и тот, кто даст больше звезд — имеет право взять ее на исполнение. У команды завал по фичевым багам, а хочется взять какую-то задачу, не влезающую в ограничения колонки? Пусть продаст баги по фиче другой команде! А уж о цене договорятся. Или пусть покупают дополнительный слот в колонке на неделю. Но если опоздают по срокам — оштрафовать в звездном эквиваленте так, чтобы ближайший месяц им доставались только самые неприятные задачи (другие команды откупятся от них). Кому-то не нравится мержить, а кому-то писать тесты. За отсутствие тестов на новый функционал положен штраф, но можно за половину стоимости штрафа найти кого-нибудь, кто эти тесты напишет. Пример с загруженностью команды тестирования и самопроверкой задач — тоже подходит.

Задача руководителя здесь удерживать баланс звезд, не обесценивая их и прозрачно указывая приоритеты, манипулируя рынком. Нужно задать определенные правила, такие, как курс обмена багов на звезды, но в то же время проявлять постоянную гибкость и поддерживать инициативы команды. Если кто-то решит продать свою очередь мыть кофемашину — почему бы и нет! Комиссия за операции со звездами? Можно. Но желательно сохранять желание к получению большего количества звезд, поскольку иначе ничего работать не будет.

Если этот пункт все-таки будет вызывать сложности, то настольная игра от Мосигры и Хабрахабра "Стартап" может дать хорошую почву для размышлений и лишний раз порадовать ваших коллег, уставших от xbox one и прогулок на яхтах.

Технические задачи важны

Да. Нужно просто это помнить. Обновление версий используемых библиотек, ревизии, настройка CI и CD, настройка VCS, поддержка team-wiki, модификация трекера задач. Эти задачи должны быть учтены в общем объёме работы, они должны иметь свой приоритет и стоимость в звездах. Команда приобретет навыки DevOps, а проект немного сэкономит.

Постамбула

А мы пробовали скрам, но нам не понравилось

А у нас и так все работает

А тимлид не хочет ничего менять

Менеджер сказал, чтоб заканчивали в игрушки играть и писали код

У нас слишком мало программистов, зачем это вообще нужно?

А тут не написано, что делать, если …

… программисты не захотят зарабатывать звезды

… у нас постоянно вклинивается срочный багфикс на продакшене

… мы неправильно оцениваем задачи, стоит ли на это вообще тратить время?

… все горит, а ограничения не дают ничего исправить

… у нас нет доски

… Мигалкин хомячит все звезды и не хочет их отдавать

Ох, да. Разработка ПО это такая область, где скепсис является необходимым качеством для выживания как специалиста, так и проекта. Что ж, starban предназначен скорее для тех, кто успел познать горечь разочарования в каноническом Agile, но и знает о существовании специального места в аду, где вы продолжаете работать программистом, один на проекте, с менеджером, у которого еще 4 таких же проекта. И у вас, возможно, еще один. Или на одном проекте у вас одна команда, а на другом совсем другая, частично укомплектованная заказчиком. Словом, лучше бы вам вести себя благопристойно в этой жизни.

Гибкие методологии разработки были созданы чтобы решить определенные задачи – защита разработчиков от заказчика, обеспечение конвейерной обработки задач, адаптивность к изменению требований. Есть полезные практики, которые выгодно использовать всегда независимо от конкретной методологии. Старбан попытался собрать их воедино чтобы сделать разработку проекта комфортной и интересной для всех участников процесса. При этом он остаётся адаптивным к разным условиям. Бывает так, что на проекте всего пара разработчиков, но и им можно организовать звездную конкуренцию, заменив командный зачет личным. Доска может подстраиваться под реалии постановки задач и возможности формализации в проекте. Никто не мешает даже не привязывать starban к конкретному проекту — если можно представить задачи в рамках единого беклога (что часто бывает в IT-отделе производственных компаний) и уместить на одну доску, то проект является только условным делителем.

А в итоге каждый получит тот процесс разработки ПО, которого заслуживает.

Автор: Vadimyan

Источник