Эта статья могла появиться гораздо раньше, где-то на год. Ведь около года назад мы в PVS-Studio решили, что пора экспериментировать с Agile. Но мне хотелось накопить пользовательский опыт, собрать статистику и только потом рассказать об этом миру.
Кроме того, одновременно с agile мы планировали переход на другой трекер проблем (вместо Bitbucket), а также множество других изменений в наших внутренних процессах разработки.
В общем, я так и не удосужился написать статью.
Кстати, о переходе на другой трекер будет вторая статья.
И в этом я кратко познакомлю вас с историей нашей компании, расскажу о предпосылках перехода на канбан, с административными и техническими трудностями, с которыми нам пришлось столкнуться, и почему, собственно, была выбрана именно эта методология.
В общем, хотелось бы поделиться практическим опытом, который может быть полезен другим компаниям.
Несмотря на то, что речь пойдет об управлении проектами, я не планирую глубоко погружаться в теорию.
Статья предназначена для подготовленного читателя, знакомого с понятием канбан.
Если вы только слышали об этой методике и теперь хотите узнать о ней больше, то вы легко найдете множество публикаций на эту тему в Интернете.
Читая сторонние статьи на тему управления проектами, я обычно испытываю чувство глубокого уважения.
Все эти статьи потрясающие.
Авторы умело используют терминологию, рассматривают практические случаи, а также успешно продают идеи другим.
Сразу хочется запустить и внедрить что-то подобное у себя, чтобы было эффективно, чтобы «лучшие практики».
Но существует общеизвестная разница между теорией и практикой.
Теория часто замалчивает неудобства, связанные с интеграцией передовых технологий в существующие рабочие процессы.
Отсутствие необходимых ресурсов, неквалифицированный менеджмент, незрелость и сопротивление команды.
Примерно таким был наш путь к agile: трудным, но увлекательным.
Немного истории
Компания PVS-Studio имеет более чем десятилетнюю историю развития.Все это время велась работа над одноименным статическим анализатором кода.
Подробнее об этом вы можете прочитать в статье « Как начинался проект PVS-Studio 10 лет назад ".
Таким образом, PVS-Studio фактически является компанией одного проект .
И это проект для разработчиков.
Но внутри компании мы привыкли выделять в качестве проектов и другие направления работы, которые фиксируются в таск-трекере вместе с разработкой: маркетинг, продажи, внутренние интернет-проекты, административная и ИТ-поддержка офиса.
Все это создает достаточно большой поток разнородных задач, с которыми нужно как-то справляться.
До перехода на новый трекер мы использовали Bitbucket. Первое задание там датировано 30 июня 2014 года, а последнее — 5 февраля 2021 года (примерно в этот момент мы начали использовать новый инструмент, это будет вторая часть статьи).
Всего за это время было создано 5527 задач.
До Bitbucket компания использовала другой инструмент, но не будем заходить так далеко в прошлое.
Грубый подсчет дает около 3,3 новых задач за рабочий день (при 250 рабочих днях в году и 24 рабочих днях в месяце).
Округлим это число до целого числа, не забывая, что не все задачи были доведены до состояния «Решено».
Итого мы получим три новых задач в день примерно 30 сотрудники компании (с 2014 по 2021 год численность компании увеличилась вдвое: с 20 до 40 человек).
Наверное, можно предположить, что мы тоже выполняли около трёх задач в день.
Я предлагаю не анализировать это число, поскольку оно ничего не говорит о количестве задач, над которыми одновременно работает сотрудник.
Нам бы пригодился такой индикатор.
Но, к сожалению, получить его можно только экспериментальным путем и при работе по определенной методике, о которой пойдет речь ниже.
Чуть выше я упомянул о росте команды.
Очевидно, что рост команды приводит к увеличению потока задач и одновременно к усложнению механизмов управления проектами.
Конечно, есть много других влияющих факторов, таких как структура и неоднородность проектов (тоже наш случай), техническая сложность, квалификация менеджеров и исполнителей и т. д. Но при прочих равных условиях размер команды все равно имеет решающее значение.
здесь.
Да, у нас не было ситуаций, когда мы сразу нанимали много новых сотрудников, открывали с нуля какие-то крупные направления и набирали под них команду.
Поэтому всегда было время подготовиться и продумать план дальнейших действий.
Однако именно рост команды привел нас к необходимости задуматься об изменении структуры компании и выборе более эффективной методологии управления проектами.
Несмотря на то, что в нашем случае развитие компании шло достаточно планомерно, мы, как и многие другие, столкнулись с типичной картиной проблемы: «Год назад работало (было достаточно), а сейчас не работает (недостаточно) ».
Вот площадь офиса, количество банок газировки в холодильнике, максимально доступные потоки процессора на сборочном сервере и т.д. Та же ситуация и с организацией работы и управления.
Кажется, совсем недавно мы обходились без регулярных встреч один на один.
Продвижение разработчика происходило по принципу «как нормы кодирования».
А фразу «вернуть задачу в канбан-бэклог» можно расценивать в лучшем случае как неумелый троллинг.
Конечно, все это нормальная ситуация роста, и говорить здесь о большой проблеме — значит излишне преувеличивать.
Однако, на мой взгляд, успех бизнеса зависит от готовности команды и руководства компании меняться в таких ситуациях.
С какими конкретно проблемами мы столкнулись по мере увеличения размера компании и увеличения потока задач? Главный из них – сильная централизация управления процессом разработки.
К концу 2019 года все разработки в компании на всех уровнях контролировался в основном техническим директором, и командам не хватало тимлидов.
Также не совсем был ясен жизненный цикл задачи, не полностью контролировалась эффективность работы, а ее результат было трудно предсказать.
На тот момент штат PVS-Studio насчитывал около 34 человек: команды маркетинга и продаж; команды разработчиков на C/C++, C#, Java; Команда DevOps, административный персонал и руководство.
Около половины команды принимало непосредственное участие в разработке.
Исторически (мой любимый термин) наши команды разработчиков были самоорганизованными.
И до определенного момента это работало, пока их размер не начал расти.
При этом из-за практически отсутствующего управления на командном уровне общая картина на более высоких уровнях становилась все более размытой.
Да, были неофициальные техлиды и потенциальные тимлиды, но что с ними делать, пока не было ясно.
Дополнительным негативным последствием описанной ситуации является отсутствие прозрачности и на уровне разработчиков: мало кто мог объяснить, чем занимается соседняя команда.
А иногда возникало непонимание даже внутри команд. Поэтому мы столкнулись с необходимостью выбора новой современной технологии управления разработкой.
Выбор методологии
Понятно, что простое внедрение какого-то нового подхода не решит всех наших проблем.Поэтому одновременно мы начали менять структуру команд: была введена система грейдинга, подкоманды внутри команд были четко распределены по направлениям работы с регулярной ротацией разработчиков между направлениями (от одного цикла релиза к другому).
.
Мы также сосредоточились на выявлении явных лидеров и подталкивании сомневающихся к лидерству.
Трекер задач не был забыт как одна из важных составляющих работы: используемая система (Bitbucket) уже не справлялась с растущими потребностями.
Переход на новый трекер планировался на втором этапе: после выбора и пробного внедрения новой методологии.
Внедрение планировалось на существующем рабочем процессе, поэтому нам нужна была максимально гибкая, удобная для пользователя технология, удовлетворяющая следующим критериям:
- легкость перехода.
Мы предвидели возможность естественного сопротивления со стороны команды, поэтому хотели максимально безболезненно внедрить новые практики для рядовых сотрудников;
- короткий период адаптации, быстрый положительный эффект. Мне не хотелось слишком затягивать процесс, чтобы он не начал казаться участникам просто утомительной и бесполезной бюрократией;
- возможность самоокупаемости, простая в освоении методика;
- гибкость.
Возможность использования для всех наших задач, даже не связанных с разработкой.
Большой задел на будущее;
- прозрачность, видимость контроля и управления потоком задач.
Годы работы с плоскими списками задач показали их неэффективность.
Мне хотелось иметь визуальный инструмент, отображающий распределение задач по направлениям работы и конкретным исполнителям, позволяющий быстро выявлять проблемные места;
- возможность получить полную актуальную картину в любой момент. Основная задача, решение которой позволит вывести процесс управления развитием в нашей компании на новый уровень.
Мы выбирали между канбаном и скрамом.
Но идея коротких спринтов совершенно не вписывается в наши техпроцессы: у нас в разработке один проект, и мы привыкли работать в рамках релизного цикла (два месяца) и только потом подводить итоги и оценивать результаты.
Есть и неотложные дела, которые в любом случае нужно выполнить.
Наконец, переход на Scrum потребует значительных изменений в том, как мы работаем.
Плюсы канбана в том, что поначалу вы просто используете его для описания тех процессов, которые у вас есть, ничего в них не меняя.
И только потом постепенно начинаешь их улучшать.
Это делает внедрение более плавным и менее напряженным для команды.
Фактически, мы уже использовали многое из того, что заявляет Agile, раньше.
Мы проводили ежедневные встречи, хотя и не во всех командах.
Команды, как я уже говорил, были достаточно самоорганизованными, и сотрудники несли ответственность за результат. Также у сотрудников была некоторая свобода в выборе задач, например, они могли начать писать статью одновременно с процессом разработки, самостоятельно планируя свое рабочее время.
Любой сотрудник мог поручить задачу другому, независимо от его уровня в компании (матричная структура).
Наконец, у нас появилось что-то вроде спринтов, привязанных к циклу выпуска.
Не хватало только систематизации, ритмичности при работе с потоком задач, а также четко определенных правил и требований, которые были бы понятны, четко приняты и соблюдались каждым участником процесса.
«Баланс и коммуникация» — это практически девиз нашей команды на данный момент. И канбан сюда идеально подходит.
Подземный канбан
Рассмотрев предысторию, плавно переходим к созданию нашей первой канбан-доски.Вернемся в декабрь 2019 года.
На тот момент у нас еще не было инструмента, который позволил бы сделать электронную плату.
Поэтому мы решили купить обычный белый магнитный маркер и много цветной бумаги.
Кстати, идея такой доски не так уж и плоха, поскольку она дает возможность непосредственно прикоснуться к процессу работы.
Правление решили какое-то время держать в подполье узким кругом менеджеров.
Для этого его установили в закрытом офисе с ограниченным доступом.
В таком режиме планировалось работать до полного согласования разводки платы.
Если вам кажется (как это было поначалу нам), что сделать канбан-доску довольно просто, то вот как этот процесс проходил у нас:
- неделя была потрачена на согласование первоначального макета доски и разработку дизайна карточек.
В результате мы остановились на классической форме доски, где этапы производственного процесса располагались в столбцах, а конкретные исполнители — в строках, при этом отдельный столбец был выделен для невыполненной работы и еще одно небольшое место для « корзина»;
- по графам в исходной версии получилось так: Бэклог (общий пул задач), Цессионер (ответственный, исполнитель), На удержании (буфер задач исполнителя), Анализ (задача на стадии проработки), В Progress (задача в работе), Check (оценка результатов, приемка), Done (задача решена);
- Схема карты выглядела так:
- Потратил некоторое время на выбор предельного значения незавершенного производства (НЗП) для подрядчика.
Казалось логичным, что человек не может иметь на работе более двух задач одновременно.
Однако для начала мы решили остановиться на лимите в три задачи, учитывая, что наши разработчики могут заниматься и неразработочной деятельностью (например, написанием статей), которую можно эффективно совмещать с разработкой.
Для канбана такой подход классический: сначала выбирается приблизительное значение, которое затем уточняется по ходу работы.
В общем, весь канбан — это один непрерывный эксперимент в попытке снизить стоимость незавершенного производства.
:) Спойлер: в итоге мы установили значение WIP равное двум;
- После того, как доска была разлинована и на нее разложены все карточки, оказалось, что использовать маркер для разметки доски — плохая идея: линии стирались при перемещении карточек.
Мне пришлось удалить все карты и переклеить доску тонкой зеленой клейкой лентой;
- За следующие пару недель использования разводка платы дорабатывалась еще несколько раз.
Добавлена отдельная строка для эпических задач без конкретного исполнителя.
Мы уменьшили ширину столбца «Готово» и тем самым увеличили ширину столбца невыполненной работы.
Между столбцами «Проверить» и «Готово» добавлен столбец «Ожидание» (задача, ожидающая, например, ответа от клиента или переводимая статья).
Мы решили использовать карточки разных цветов, чтобы разделить задачи по типу работы: просто задача, исправление ошибки, эпопея, написание статьи и т. д.;
- любые изменения в совете обсуждались, и дискуссии часто были весьма эмоциональными;
- Пока плата велась тайно, штат пополнился еще несколькими разработчиками и места на линиях уже не хватало.
Двустороннюю плату было решено купить впоследствии, но уже после ее презентации;
- Также хотелось бы отметить необходимость проведения ежедневной работы по поддержанию доски в актуальном состоянии: синхронизация с трекером задач.
По моим подсчетам, на это тратилось не менее получаса рабочего времени в день.
.
Канбан в массы
В литературе представлены различные сценарии использования канбан-досок.Для продвинутых команд предлагается автономное использование, когда разработчики самостоятельно берут (вытаскивают) задачи из бэклога.
Отставание пополняется по результатам встречи менеджеров, каждый из которых является заказчиком тех или иных изменений.
При этом за перемещение карт по доске отвечают сами разработчики.
Такой подход полностью соответствует философии канбан, где упор делается на самоорганизацию и баланс (канбан, в отличие от скрама, не предполагает привлечения скрам-мастера).
Командам, которые только внедряют канбан (как наша), все же рекомендуется нанять выделенного сотрудника, который будет поддерживать доску в актуальном состоянии, организовывать встречи и обсуждения вокруг доски, а также следить за соблюдением правил работы с методологией.
Такой подход также помогает снизить возможное негативное влияние на команду при переходе на канбан.
В дополнение к этому мы решили пополнить бэклог и проанализировать работу с платой с интервалом в один релизный цикл (два месяца).
Итак, наша доска с текущими задачами была представлена всем и размещена в конференц-зале.
Раньше мы уже практиковали ежедневные рабочие встречи, но они не носили систематического характера и проводились эпизодически.
Теперь мы решили организовать работу по графику и проводить ежедневные встречи отдельно для четырех команд разработки (C/C++, C#, Java; DevOps).
Продолжительность митинга была установлена не более 15 минут. В дополнение к этому отдел маркетинга содержал еще один независимый совет, который немного отличался, но также вписывался в нашу общую философию канбана.
Фактически введение ежедневных плановых собраний, а не правления, стало причиной ожидаемого сопротивления команды.
Главный вопрос был примерно такой: «Зачем нам эти встречи? Мы уже знаем, кто чем занимается в команде, проводим ежедневные обсуждения.
Это просто пустая трата времени.
И даже эта доска.
Мы думаем, что теперь, после более чем года работы с канбаном, мы можем дать ответы на эти и другие вопросы.
Довольно быстро мы поняли, что канбан-доска — отличное место для проведения встреч.
Идея наших встреч в том, что разработчик рассказывает о своей деятельности прежде всего самому себе (систематизируя работу, выявляя что-то упущенное или непонятое им), и только потом своим коллегам и руководителю.
При этом доска помогает видеть весь поток задач (как своих, так и чужих) и понимать, что вы не перегружены, что будет что делать дальше (есть буфер и бэклог) и есть эта пухлая стопка ваших задач в последней графе «Выполнено» — действительно осязаемый результат вашей работы за последний цикл релиза.
Действительно работает, проверено.
Мы постоянно объясняли и продолжаем объяснять разработчикам, что в первую очередь им нужны собрания и совет. Но, конечно, это также помогает менеджерам всех более высоких уровней принимать решения.
Пример очевидной пользы доски, который приводится во всех книгах, — выявление узких мест, быстрое устранение проблемных мест, накопление большого количества задач на одном сотруднике.
Пример менее очевидной выгоды — выявление низкой загруженности исполнителей или работа над «удобными» задачами.
Речь идет о ситуациях, когда задач берется мало, или когда берутся не самые необходимые задачи, а те, над которыми сотруднику просто интереснее работать.
Такие аномалии сложнее обнаружить при анализе классического списка задач, поскольку их легко не заметить на общем фоне.
Еще одно интересное наблюдение: за время использования доски наши техпроцессы как-то сами адаптировались к работе с доской, а значит, и в соответствии с методологией канбан.
И теперь мы уже не понимаем, как раньше обходились без этого.
Это способ
К сожалению, полноценно работать с физической канбан-доской нам удалось только в течение двух циклов выпуска (четыре месяца).После чего весной 2020 года весь офис в связи с известными событиями (COVID) был переведен на удаленную работу.
Конечно, поддерживать доску в таких условиях оказалось невозможно, и, что характерно, мы остро ощущали нехватку этого инструмента при проведении ежедневных совещаний.
Я думаю, это главный показатель полезности любого инструмента: когда начинаешь чувствовать дискомфорт при его отсутствии.
Примерно в это же время мы начали задумываться об электронной доске канбан.
Некоторое время ситуация с COVID была неясной, мы проводили онлайн-встречи в Zoom. Каждый участник использовал список задач Bitbucket, чтобы отчитаться о своей работе.
Это было очень неудобно и усложняло и без того непростой режим работы онлайн.
Осенью 2020 года стало понятно, что удаленная работа затягивается.
Возникла идея не просто внедрить электронный аналог канбан-доски, а действовать более радикально и полностью поменять таск-трекер на тот, который больше удовлетворяет нашим требованиям на тот момент. В первую очередь, конечно, мы обратили внимание на Jira. Более того, переход на эту систему с Bitbucket позволил бы легко перенести все ранее созданные задачи.
Мы также рассматривали еще одну систему — YouTrack, которая очень понравилась тимлиду нашей C++ команды (привет Филиппу).
Более того, Филипп еще летом даже провел презентацию для менеджеров, использующих эту систему.
В итоге только к декабрю 2020 года мы сделали свой выбор и решили перейти на YouTrack. Подробнее о том, как мы перешли на этот таск-трекер, я расскажу во второй части этой статьи.
Заключение
В заключение хотелось бы подвести итоги проделанной в прошлом году работы.На данный момент у нас есть ощущение контроля над потоком задач на всех уровнях, лучшее понимание жизненного цикла задач и удобные инструменты для отслеживания эффективности.
Мы значительно улучшили ритм работы, сделав производственный процесс более экономичным.
Думаю, что наши ожидания от внедрения канбана в целом оправдались, а цели, поставленные на начальном этапе внедрения, были достигнуты.
Но, конечно, мы еще только на середине пути.
Что касается методологий agile и kanban в целом, их ценности для построения рабочих процессов и сложности внедрения, могу еще раз кратко изложить наш опыт. Главное – не бойтесь экспериментировать.
Не зря эти подходы называют гибкими.
Еще добавлю, что они достаточно дружелюбны и прощают многие ошибки.
Новые подходы можно будет внедрять поначалу максимально безболезненно и даже тайно, а в случае неудачи потери будут небольшими.
А если, как в нашем случае, внедрить какую-то методологию с нуля, то полученный результат, польза, обязательно превысит затраты.
Спасибо за внимание и увидимся во второй части.
Если вы хотите поделиться этой статьей с англоязычной аудиторией, воспользуйтесь ссылкой для перевода: Сергей Хренов.
Канбан-доска команды PVS-Studio. Часть 1: Agile .
Теги: #agile #kanban #pvs-studio #management
-
Как Развлечь Себя С Помощью Api Вк
19 Oct, 24
