Kanban команды PVS-Studio. Часть 1: agile

Эта статья могла появиться на свет гораздо раньше, примерно на год. Ведь около года назад мы в компании PVS-Studio решили, что пришло время поэкспериментировать с agile. Но хотелось накопить пользовательский опыт, собрать статистику и уже потом поведать об этом миру. К тому же, одновременно с agile мы запланировали переход на другой трекер задач (вместо Bitbucket), а также много других изменений в наших внутренних процессах разработки. В общем, до написания статьи руки никак не доходили.

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

Несмотря на то, что здесь будет про управление проектами, я не планирую глубоко погружаться в теорию. Статья рассчитана на подготовленного читателя, знакомого с понятием kanban. Если же вы только слышали про эту методологию и сейчас хотите узнать о ней подробнее, то вы легко найдёте в сети множество публикаций по этой тематике.

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

Немного истории

Компания PVS-Studio имеет более чем десятилетнюю историю развития. Все это время работы ведутся над одноименным статическим анализатором кода. Подробнее про это можно почитать в статье «Как 10 лет назад начинался проект PVS-Studio«. Таким образом, PVS-Studio – фактически компания одного проекта. И это проект для разработчиков. Но мы внутри компании в качестве проектов привыкли также выделять и другие направления работы, которые фиксируются в трекере задач наравне с разработкой: маркетинг, продажи, внутренние интернет-проекты, административная и IT-поддержка офиса. Все это создает достаточно большой поток разнородных задач, с которым нужно как-то справляться.

До перехода на новый трекер мы использовали Bitbucket. Первая задача там датирована 30 июня 2014, а последняя – 5 февраля 2021 (примерно с этого момента мы начали использовать новый инструмент, про это будет вторая часть статьи). Всего за это время было создано 5527 задач. До Bitbucket в компании использовали еще какой-то инструмент, но не будем забираться так далеко в прошлое. Примерный подсчет дает около 3.3 новых задач на один рабочий день (при условии 250 рабочих дней в году и 24 рабочих дней в месяце). Давайте округлим это число до целого, не забыв, что не все задачи были доведены до состояния «Решено». Итого мы получим три новых задачи в день на примерно 30 сотрудников компании (с 2014 по 2021 год размер компании увеличился вдвое: с 20 до 40 человек). Вероятно, можно считать, что также и закрывали примерно три задачи в день. Предлагаю не анализировать это число, так как оно ничего не говорит о числе задач, находящихся у сотрудника единовременно в работе. Вот такой показатель был бы нам полезен. Но, к сожалению, получить его можно только экспериментально и при работе с определенной методологией, о чём будет рассказано далее.

Чуть выше я упомянул о росте команды. Очевидно, что рост команды приводит к увеличению потока задач и одновременному усложнению механизмов управления проектами. Конечно, есть масса других оказывающих влияние факторов, например структура и разнородность проектов (тоже наш случай), техническая сложность, квалификация менеджеров и исполнителей и т.п. Но, при прочих равных условиях, размер команды тут все же имеет решающее значение. Да, у нас не было ситуаций, когда в штат сразу брали много новых сотрудников, с нуля открывали какие-то большие направления и под них набирали команду. Поэтому всегда было время подготовиться и продумать план дальнейших действий. Тем не менее, именно рост команды привел нас к необходимости задуматься над изменениями в структуре компании, выборе более эффективной методики управления проектами.

Несмотря на то, что в нашем случае развитие компании шло достаточно планомерно, мы, как и многие другие, столкнулись с типичным паттерном проблемы: «Еще год назад это работало (хватало), а теперь не работает (не хватает)». Здесь и площадь офиса, и число баночек газировки в холодильнике, и максимум доступных процессорных потоков на сборочном сервере, и пр. Такая же ситуация с организацией работы и управлением. Кажется, еще совсем недавно мы обходились без регулярных one-to-one. Повышение разработчика происходило по принципу «вроде норм кодит». А фраза «верни задачу в бэклог на kanban» могла быть расценена в лучшем случае как неумелый троллинг. Конечно, все это обычная ситуация роста, и говорить о большой проблеме тут – излишне сгущать краски. Тем не менее, на мой взгляд, от готовности команды и руководства компании к переменам в таких ситуациях зависит успех бизнеса.

С какими же конкретно проблемами мы столкнулись при увеличении размера компании и росте потока задач? Основная – сильная централизация управления процессом разработки. К концу 2019 года вся разработка в компании на всех уровнях контролировалась в основном техническим директором, а в командах не хватало тимлидов. Также не вполне понятен был жизненный цикл задачи, неполно отслеживалась эффективность работы и сложно прогнозировался ее результат. В штате PVS-Studio на тот момент состояло около 34 человек: команды маркетинга и продаж; команды разработки на языках C/С++, C#, Java; команда DevOps, административный персонал и руководство. Примерно половина команды занималась непосредственно разработкой.

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

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

Выбор методологии

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

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

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

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

• возможность сопровождения своими силами, несложная в освоении методология;

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

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

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

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

Наконец, переход на scrum потребовал бы внесения значительных изменений в привычный ход работы. Преимущества kanban в том, что вначале вы просто описываете с его помощью те процессы, которые у вас есть, ничего не меняя в них. И только затем постепенно начинаете их совершенствовать. Это делает внедрение более плавным и менее тревожит команду.

На самом деле, многое из того, что декларирует agile, мы применяли ранее. Мы проводили ежедневные митинги, хоть и не во всех командах. Команды, как я уже говорил, были достаточно самоорганизованы, а сотрудники отвечали за результат. Также сотрудники имели некоторую свободу при выборе задач, например могли заняться написанием статьи одновременно с процессом разработки, самостоятельно планируя своё рабочее время. Любой сотрудник мог поставить задачу другому, независимо от его уровня в компании (матричная структура). Наконец, у нас были подобия спринтов, привязанные к релизному циклу.

Не хватало только систематизации, ритмичности при работе с потоком задач, а также чётко прописанных правил и требований, которые бы были понятны, однозначно приняты и соблюдались каждым участником процесса. «Баланс и общение» – вот практически девиз нашей команды в настоящее время. И kanban здесь подходит как нельзя лучше.

Подпольный kanban

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

Доску решили какое-то время вести подпольно узким кругом менеджеров. Для этого она была установлена в закрытом кабинете с ограниченным доступом. В таком режиме планировалось работать до момента, пока не будет полностью согласован макет доски. Если вам кажется (как нам поначалу), что сделать kanban-доску достаточно просто, то вот как процесс шел у нас:

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

• по столбцам в первоначальном варианте получилось так: Backlog (общий пул задач), Assignee (ответственный, исполнитель), On hold (буфер задач исполнителя), Analyze (задача на стадии изучения), In progress (задача в работе), Check (оценка результатов, приёмка), Done (задача решена);

• макет карточки выглядел так:

• некоторое время потратили на выбор значения лимита незавершенной работы (WIP) для исполнителя. Логичным казалось, что у человека не может быть в работе одновременно более двух задач. Тем не менее, для начала решили остановиться на ограничении в три задачи, учитывая, что разработчики у нас могут заниматься и не связанными с разработкой активностями (написание статей, например), которые можно эффективно совмещать с разработкой. Для kanban такой подход является классическим: вначале выбирается примерное значение, которое затем уточняется в процессе работы. Вообще весь kanban – это один сплошной эксперимент в попытке уменьшить значение WIP. 🙂 Спойлер: значение WIP мы в итоге все же установили равное двум;

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

• за следующие пару недель использования макет доски ещё несколько раз уточнялся. Добавили отдельную строку для задач-эпиков без конкретного исполнителя. Уменьшили ширину столбца «Done» и за счет этого увеличили ширину столбца для бэклога. Добавили столбец «Waiting» (задача на ожидании, например, ответа от клиента, или статья на переводе) между столбцами «Check» и «Done». Решили использовать карточки разных цветов для разделения задач по типу работ: просто задача, правка бага, эпик, написание статьи и т.п.;

• любая правка доски обсуждалась, при этом обсуждения часто бывали достаточно эмоциональными;

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

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

Так прошло чуть больше месяца (с учетом новогодних каникул), и вот в январе 2020 года мы, наконец, решили, что пришло время обнародовать доску (на фотографии ниже видна одна сторона доски, не включающая направление C++).

Kanban в массы

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

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

Итак, наша доска с актуальными задачами была представлена на всеобщее обозрение и размещена в конференц-зале. Ранее мы уже практиковали ежедневные рабочие собрания, но они не носили системный характер и проводились от случая к случаю. Теперь мы решили организовать работу по расписанию и проводить ежедневные митинги по отдельности для четырёх команд разработки (C/С++, C#, Java; DevOps). Продолжительность митинга установили не более 15 минут. В дополнение к этому в отделе маркетинга велась еще одна независимая доска, которая несколько отличалась, но также вписывалась в нашу общую концепцию работы по kanban.

Собственно, введение ежедневных митингов по расписанию, а не доска, стало причиной ожидаемого сопротивления команды. Основной вопрос был примерно такой: «Зачем нам эти митинги? Мы и так знаем, кто и что делает внутри команды, проводим свои ежедневные обсуждения. Просто трата времени какая-то. Да еще эта доска». Нам кажется, что теперь после более чем года работы по kanban мы можем дать ответы на эти и другие вопросы.

Довольно быстро мы осознали, что kanban-доска является отличным местом для проведения митингов. Идея наших митингов состоит в том, что разработчик рассказывает о своей активности в первую очередь себе (систематизируя работу, выявляя что-то упущенное или не так понятое им), а уже затем коллегам и руководителю. При этом доска помогает видеть весь поток задач (как своих, так и чужих) и понимать, что ты не перегружен, что будет чем заняться дальше (есть буфер и бэклог) и есть вот эта пухлая пачка твоих задач в последнем столбце «Done» – по-настоящему осязаемый результат твоей работы за последний релизный цикл. Это действительно работает, проверено.

Мы постоянно объясняли и объясняем разработчикам, что в первую очередь митинги и доска нужны именно им. Но, конечно, она помогает и руководителям всех вышестоящих уровней в принятии решений. Пример очевидной пользы доски, который приводят во всех книжках, – выявление «бутылочных горлышек», быстрое устранение проблемных мест, скопления большого числа задач на одном сотруднике. Пример менее очевидной пользы – выявление малой загруженности исполнителей или работы над «удобными» задачами. Речь о ситуациях, когда в работу берётся мало задач или же, берутся не самые нужные задачи, а те, над которыми просто интереснее работать сотруднику. Такие аномалии сложнее выявлять при анализе классического списка задач, так как их легко не заметить на общем фоне.

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

Таков путь

К сожалению, полноценно поработать с физической kanban-доской нам удалось только два релизных цикла (четыре месяца). После чего весной 2020 года весь офис, в связи с известными событиями (COVID), был переведен на удалённый режим работы. Конечно, ведение доски в таких условиях оказалось невозможным, и, что характерно, мы остро почувствовали нехватку этого инструмента при проведении ежедневных митингов. Я думаю, это основной показатель полезности любого инструмента: когда ты начинаешь ощущать дискомфорт при его отсутствии.

Примерно в это время мы начали задумываться об электронной kanban-доске. Какое-то время ситуация с COVID была непонятной, мы вели онлайн-митинги в Zoom. При этом каждый участник использовал список задач Bitbucket, чтобы отчитаться о работе. Это было очень неудобно и осложняло и так непростой режим работы online.

Осенью 2020 года стало понятно, что удаленная работа затягивается. Возникла идея не просто внедрить электронный аналог kanban-доски, а действовать более радикально и полностью сменить трекер задач на более удовлетворяющий нашим требованиям на тот момент. В первую очередь, конечно, мы обратили внимание на Jira. Тем более что переход на эту систему с Bitbucket позволил бы легко перенести все ранее созданные задачи. Также мы рассматривали еще одну систему – YouTrack, которая очень нравилась тимлиду нашей С++ команды (привет, Филипп). Более того, по этой системе еще летом Филипп даже делал презентацию для менеджеров.

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

Заключение

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

Что касается вообще методологий agile и kanban, их ценности для построения рабочих процессов, сложности внедрения, могу еще раз кратко озвучить наш опыт. Главное – не бойтесь экспериментировать. Ведь не зря же эти подходы называют гибкими. Я бы еще добавил, что они достаточно дружелюбны и прощают множество ошибок. Можно внедрить новые подходы максимально безболезненно и даже скрытно на первых порах, а в случае неудач потери будут невелики. И если вы, как в нашем случае, будете внедрять какую-то методологию с нуля, то полученный результат, польза, точно превысят затраты.

Спасибо за внимание и до встречи во второй части.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Khrenov. PVS-Studio Team’s Kanban Board. Part 1: Agile.