Disclaimer: Данная статья — только мнение отдельно взятого разработчика о бизнес-процессах в отдельно взятой компании. Никаких неопровержимых доказательств здесь не приводят.

Я работаю в команде разработки раздела сайта в банке. Сайт внешний, содержит FAQ о продуктах банка. Посещаемость клиентами в стране около 587к в месяц. Хотя относительно остальных разделов сайта это небольшая цифра. Например, в разделе “Мой банк” — мобильное интернет-отделение — посещаемость гораздо выше, но точных цифр мне никто не дал. Да я и не просил. Веб-приложение работает с кучей внутренних сервисов, дизайн раздела должен строго соответствовать установленному на всем сайте. В общем, наша команда не автономна, всегда есть зависимости от других подразделений.

Работаем по скраму, по крайней мере пытаемся. Что-то не получается, довольно часто факапим спринты. На очередном дэйли у кого-то из команды возникла:

А почему бы нам не переехать на канбан? Там нет спринтов, каждый берет задачи по мере освобождения, делает их так быстро, как может он. Не нужно планировать спринты, каждый подтягивает задачи себе и делает потихоньку. Крупные юзер-стори анализирует, делит на небольшие задачи, остальные могут подхватить их. После анализа озвучивает сроки продакту. Одни плюсы!

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

Какова ситуация в банке

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

Сразу скажу, что далее по тексту для обозначения бизнес-заказчика я буду использовать разные варианты: PO, Product Owner, продакт оунер, продакт, заказчик. Под этими названиями я имею в виду только одну определенную роль — product owner в Agile.

Однако процесс этот нелегок. Нашему PO нужно принудить другие отделы, которые рассматривают эти обращения, изменить свои бизнес-процессы. А такова природа человека, что если боли особой нет, то и менять нечего. Например, один отдел вел свою базу данных в простом EXCEL-файле, который шарил на сетевом диске. “Доступ к базе одновременно? Зачем, мы ж можем попросить других не трогать файл, пока работаю я”. Предложили внедрить свое подобие CRM-системы — нехотя согласились, а спустя полгода разработки уже требуют новые фичи, чтобы были написаны еще вчера. В общем, процесс ввода форм на сайте затянулся. Продакт в течение спринта накидывал новые требования по блокам, полям ввода и прочим штукам, на которые юристы компании указывали.

Фактически, все разработчики работали над задачами, условия которых менялись по несколько раз в спринт. Получается, что и спринт как таковой потерял важность и стал лишь формальным триггером к тому, чтобы проводить периодические встречи скрама. Планирование мы проводили тоже формально, потому что не было смысла задавать какие-то вопросы заказчику — все равно они могут измениться в течение спринта. Скрам-покер тоже перестали проводить — зачем нам оценивать задачу сейчас, если все равно придут правки. А не брать задачу в спринт нельзя, потому что на это есть два фактора: • Заказчик хочет наконец-то внедрить эти формы в обращение, ему психологически легче, если он видит, что задача формально “в работе”;• Часть задачи все же понятна — можем потихоньку клепать верстку фронта и делать другие низкоуровневые вещи интеграции с другими внутренними сервисами.

Как мы должны были поступить по скраму.

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

если нашему Product owner’у нужно согласование от третьего лица, значит это третье лицо и есть истинный Product owner.

Читатель может мой вывод перевернуть с ног на голову и сказать, что все несут ответственность перед СЕО компании и никакие стратегические вопросы не должны принимать без его ведома и/или согласия. Значит СЕО — продакт для всех команд. Это отчасти верно, но у СЕО может пупок развязаться от такой нагрузки. Для того СЕО и назначает ответственных за продукты и направления, делегируя им право принятия решений, если они не противоречат общей философии компании.

На планирование заказчик приходит с уже определенным и согласованным бизнес-видением юзер-стори (User story). Разработчики должны задавать спонтанно возникающие вопросы на планировании, а продакт — на них отвечать. Разработчики наполняют каждую юзер-стори минимальным набором требований, с которыми можно начинать работу по ним. Иначе в планировании пропадает смысл.

Проблемы нашего скрама.

Мне кажется, что все проблемы нашего скрама исходят из неверного начала спринта — планирования. Само мероприятие превращается в назначение задач людям, которые должны будут отслеживать телодвижения по задачам, если появится какая-то зависимость от третих лиц. Задачи часто переводятся автоматом в колонку “Ожидание”, а исполнитель ждет некоего триггера, чтобы начать хоть что-то делать. Параллельно, чтоб не пить кофе все 8 часов рабочего времени, в спринт берутся операционные задачи или задачи из техдолга.

Через две недели видим одну из двух ситуаций:• В спринт накиданы еще задачи с бэклога, потому что разработчик закончил свою текучку до окончания спринта, а триггер по бизнесовым задачам так и не появился.• В спринте осталась куча текущих задач в колонке “Сделать”, потому что триггер по бизнесовым наступил рано. Еще хуже, если некоторые задачи остались в колонке “в ожидании”. Разработчик большую часть спринта занимался бизнесовой задачей, не начиная текучку или бросив на полпути. Ведь бизнес-задача более приоритетна, не так ли?

Скрам не просто так призывает не назначать продакт-оунером прямого руководителя программистов. Продакт на планировании презентует юзер-стори, пытается вдохновить разработчиков, заинтересовать. Разработчики в свою очередь стремятся выяснить больше о задаче сразу на планировании, чтобы на начало спринта они понимали, с чего начать. Если бы продакт был в иерархии властвования над отделом разработки, то о какой презентации задач может идти речь? Продакт может просто сказать “надо взять, там выясните требования”, а программисты не могут не подчиниться. Идеальный “водопад”.

Немного о канбане и его сути

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

Канбан — это об ограничениях. Канбан позволяет определить бутылочные горлышки процесса разработки, так как вводит ограничения на количество задач в той или иной колонке: • В “работе” не должно быть больше задач, чем количество разработчиков в отделе. • В “ожидании/код-ревью/тестировании” не должно быть больше, чем N задач, где N — утвержденное число всеми участниками процесса.

Если мы видим, что на тестировании скапливается много задач, то это — повод пересмотреть правила и процессы тестирования. А разработчик не может перевести свою задачу на тестирование, пока там не появится место для нее. Что делать в данном случае? Я считаю, что пока не нанят еще один тестировщик, то сам разработчик берет другие задачи на тестирование, чтобы освободить место для своей.

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

Аналогично будет и с задачами в ожидании: разработчик не может перевести задачу “в ожидание”, если там нет места. А если место занято на 100%, то это повод разобраться с факторами, мешающим работе над этими задачами.

Другой отдел не может согласовать свои требования в нашей совместной интеграции? Предлагаем свои варианты и/или пишем урезанные “туповатые” возможности этой самой интеграции, создавая задачу типа “доделать урезанную функциональность фичи А”. Ждем дизайна от ответственного подразделения? Предлагаем нашему продакту написать интерфейс, не противоречащий общему гайдлайну, пока дизайн не утвердили. Продакт не соглашается? Значит зря взяли вообще в работу, если знаем, что дизайн в этой задаче очень важен и отдход от него может стоит репутации компании. Ну а конкретный разработчик работает над внутренними делами отдела: техдолг, рефакторинг, внедрение typescript в проект. А то уже стыдно в 2к18 году только лишь jquery на фронте пользоваться. Что, что? Продакт против работы над typescript? Ну а что вы хотели, не нужно давать в работу задачи, где есть зависимость от третьих подразделений и она еще не решена.

Почему канбан не решит наши проблемы

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

Канбан не отменяет планирование, заказчик все также должен презентовать юзер-стори и их значимость для проекта, а разработчики — задавать спонтанно возникающие вопросы. Все также разработчики должны давать оценки небольшим задачам в 2–5 дней, а большие задачи — брать на анализ, чтобы понять возможность поделить на небольшие. По моему мнению, задачу не должны брать в спринт, пока ее реализация занимает больше чем 10 рабочих дней одного программиста. Если продакту она нужна “вчера”, то разработчики должны делить ее. А вдруг не все требования юзер-стори нужны сейчас, некоторые могут и потерпеть до следующего спринта? А вдруг есть возможность параллельно делать задачу? А вдруг можно наговнокодить с обязательным выпилом говнокода в следующем спринте? Есть много вариантов.

Утверждать, что нельзя поделить задачи на небольшие, в 99% случаев неправильные — любую задачу в вебе можно поделить пополам: два человека могут работать параллельно над красотой на фронте и подкапотной логикой в бэкенде. Если разработчики не умеют делить задачи пополам, то должны учиться. Некоторые могут возразить, что деление задачи для ее параллельного выполнения накладывает дополнительные расходы: время, чтобы определить границы деления, время на мердж в мастер и все такое. Я считаю, что это небольшая плата за следующее:• Что разработчики в команде лучше будут понимать проект;• Научатся делить задачи на небольшие кусочки и сдавать их в срок;• Чаще будут общаться в отделе, что еще больше сплотит группу людей в команду.

Планировать и выдерживать периоды планирования нужно, потому что продакт хочет понимать, когда он получит ту или иную фичу в продакшене. Можно сообщить ему, что фича А будет готова через 20 дней, фича Б — 14 дней, а фичи В-К — мелкие, что можно раскидать их за две недели.Тогда продакт оунер должен держать в голове пачку юзер-стори и примерную дату их выполнения в голове и/или в блокноте. А может прямо на доске скрама — вот же и есть тот самый список задач, которые будут накачены на бой спустя две недели.

Проблемы сроков

При скраме, если кто-то не успевает свои задачи закончить, остальные должны стремиться ему помочь. Иначе зачем на каждом дэйли нам задают вопрос “есть ли что-то такое, что мешает закончить спринт вовремя?” В канбане перестроиться на выполнение тяжелее, ведь у каждого есть своя задача в работе, которую человек обязался сдать к определенному сроку. Я думаю, что ответ очевиден, что выберет человек: помочь другому закрыть его задачу или закрыть свою в срок.

В скраме все понятно: команда не сделала задачи за спринт — виновата команда. Нужно теперь понять на ретроспективе, почему зафакапили спринт, сделать выводы и работать над ними. В канбане за срыв сроков отдельно взятой задачи несет ответственность её исполнитель. И если он помогал другим с их задачами, то он зафакапил свою задачу по объективной причине. Но объяснить это заказчику становится тяжелее, значит каждому придется вести себе специальный дневник и записывать туда записи типа “потратил полтора часа, чтобы помочь человеку M. закончить его задачу” и “делал ревью человеку П. в течение двух часов”. Потом же нужно будет подсчитывать все эти записи, чтобы понять, равно ли общее время штрафному, на сколько зафакапил задачу. И да поможет тебе бог, если не будет тождества между ними.

Разработчики должны думать прежде всего о задаче, над которой они работают. Точной статистики нет, но я считаю, что программист думает 60–70% над задачей и только остальное время пишет код. Если он будет думать еще и над тем, не забыл ли он внести запись для оправданий в будущем, то о какой эффективности идет речь?

Что же теперь делать?

Уж точно не затевать переезды на канбан, если не сумели работать по скраму. Канбан, как и скрам, не отменяет ограничения сверху, и нельзя потихоньку работать над задачей, пока заваривается чаёк. Заказчик будет давить на разработчиков, чтобы быстрее делали задачи. В скраме вся команда ответственная за набор задач, и продакту нужно давить на пятерых людей.

Фича А из примера выше занимает 20 дней? Давайте делить! Нельзя делить на планировании потому что можем не успеть поделить в течение двух часов? Пусть один из разработчиков возьмет ее на анализ на пару дней, определит способы разделения. Можем с заказчиком договориться, что поделенные задачи возьмем тут же в спринте, если вся юзер-стори срочная, а можем отложить на следующий спринт. Можем делать урезанные фичи в спринте, чтоб потом доделать в последующих.

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

P.S. Если читателю показалось, что он видит совпадения с реальными людьми и компаниями, то это — только совпадения и они случайны.