Зачем нужна канбан доска 🎞 , как ее создать и получить пользу для проекта + примеры физических и цифровых канбан досок

Канбан–доска — это инструмент, который визуализирует задачи, показывает, кто и чем занимается, как движется работа над проектом.

Наглядно показать все задачи, которые надо сделать, и те, что уже в работе, и те, что готовы. Уменьшить число незавершенных задач и увеличить скорость работы.

Доску делят на столбцы. Ход выполнения работ по проекту иллюстрируют карточками. На них пишут название задачи. Каждый столбец — это определенный этап работы.

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

В доске вся суть способа управления проектами Kanban. Оно и понятно, ведь его главная задача — улучшить то, что есть. А для этого — визуализировать каждый этап работы. Сила Канбан в том, что он помогает:

• оптимизировать процессы

• сделать рабочий процесс всем понятным и прозрачным

• расставить приоритеты

• оценивать риски

• контролировать работу каждого участника команды

• вовремя предотвращать ошибки, даже когда они еще не случились

• делать только то, что реально будет двигать проект вперед.

При этом Kanban делает команду гибкой, готовой к изменениям на любом этапе работы.

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

• Уменьшить число незавершенных задач.

• Увеличить скорость работы. В идеале — определить максимальную эффективность и стремится к ней.

• Упорядочивает ежедневную работу Agile–команд.

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

• Например, самый простой вариант наименования столбцов: сделать — в работе — готово.

• Или доска может отражать весь процесс создания проекта. Тогда на доске будут столбцы: в очереди — в работу — анализ — проектирование — дизайн — разработка — тестирование — готово.

• Или на доске в столбцах будем отражать весь путь от идеи до выхода в свет: надо сделать — аналитика — разработка — тестирование — развертка — готово.

Карточки–задачи перемещают по доске слева направо по степени готовности. Так, и команда, и менеджер проекта, и все заинтересованные видят всю механику рабочего процесса. Понятно, когда появляются новые задачи, все ли гладко идет.

Карточки — это по сути визуализация задачи. В них описывают работу, которую надо сделать:

• Пишем название и описание задачи.

• Даты работы.

• Участника команды, который выполняет задачу–карточку.

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

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

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

Но мало просто налепить на доску стикеры. Надо, чтобы команда следовала правилам Kanban. Разберемся, что это за правила.

• Ограничивать незавершенные задачи. То есть не валить на участников команды все новые и новые задачи, если они еще не справились с текущими. Расставлять приоритеты и устанавливать лимиты.

• Все процессы визуализировать. Каждая задача описана и отражена на доске. Статус задач постоянно обновляется.

• Фокусироваться на незаконченных задачах на канбан–доске. Смотреть, почему они зависли в том или ином столбце. Может, нужно добавить людей для выполнения? Или перераспределить ресурсы.

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

• Уважать людей и их мнение.

А теперь более подробно разберем из каких элементом состоят Канбан доски. Всего выделяют 5 главных составляющих.

• Карточки, стикеры, листки и любые другие видимые сигналы. Это то, что сразу бросается в глаза на канбан–доске. Выше мы описали процесс заполнения карточки–задачи. Одна карточка — одна задача. Или один небольшой проект. У Agile–команд одна карточка — одна user story (пользовательская история). Видимые сигналы сразу дают понять, над чем трудится команда.

• Столбцы, которые отражают рабочий процесс. По этим столбцам на канбан–доске перемещают карточки–задачки по мере их выполнения.

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

• Точка принятия обязательств. Многие команды сразу отражают на доске столбец со списком задачи из бэклога. Для его составления клиенты и участники команды вносят свои идеи и предложения. Когда команда будет готова, она к ним обращается. Точка принятия обязательство — этот момент, когда команда берет идею непосредственно в работу.

• Точка поставки. Команды сами определяют, что знаменует этот этап: продукт готов и передан клиенту, или завершена какая–то часть, запущен какой–то функционал. Здесь же фиксируется время выполнения задачи: с момента, когда она попала в точку принятия обязательства, до точки поставки. Помните, про одно из правил Канбана про постоянное совершенствование? Вот здесь оно тоже работает. Это самое время выполнения нужно стремиться свести к минимуму.

Канбан доски делятся на реальные и цифровые.

Реальные доски выглядят так:

Их могут использовать и для очень масштабных дорогих проектов. Например, известна история, когда для строительного заказа стоимостью свыше $50 миллионов использовали физическую канбан–доску, которая висела прямо в трейлере на стройплощадке.

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

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

Именно физическая доска помогла компании Optimizely осознать полный объем работы по продукту. Это американская компания, которая производит прогрессивное программное обеспечение для A/B тестирования.

Над продуктом компании работали несколько команд, у каждой была своя виртуальная Канбан доска. Но команды работали по отдельности, между собой не общались. Тогда руководитель компании создал реальную Канбан доску. Она получилась такой большой, что ее назвали «стеной работы». На ней поместили все проекты технической команды, показатели, имена исполнителей, статусы задач. Этим руководитель Optimizely привлек внимание участников разных команд к одному общему делу. Они начали обсуждать работу друг друга, физическая Канбан доска помогала сотрудникам осмыслить весь проект целиком.

В итоге они предлагали свои идеи, улучшения, а «стена работы» разрасталась и развивалась.

• Ее не выключишь, как виртуальную. Она всегда будет перед глазами.

• Доску легко показать другим участникам рабочего процесса.

• Легко можно подготовить ее.

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

• Не подходит для удаленной работы, удаленных команд.

• Не подходит людям с очень плохим, неразборчивым почерком.

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

Самые популярные онлайн–решения в сфере Канбан–досок предлагают Trello.

• Trello больше подойдет небольшим проектам со средними и маленькими командами. Идеально для индивидуального использования. Но не очень удобен для Agile–команд.

• Jira — отлично для Agile–разработчиков, айти–компаний с большими командами. Не очень подойдет не техническим командам и тем, кто не работает по гибкой методологии.

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

• Paymo — Канбан доски для тех, кому крайне важно отслеживать время на выполнение задач и расставлять приоритеты.

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

• Leankit — если все прочие онлайн–доски вам не подошли, то здесь можно создать свою собственную, максимально кастомизированную, с детальной проработкой задач.

Хольгер начал работать в берлинской компании mobile.de в 2007 году в качестве фрилансера, затем перешел в штат. Интернет платформа насчитывает миллион предложений на автомобили как частных владельцев, так и дилеров.

Сервис используется преимущественно в Германии, а также во многих других странах Центральной и Восточной Европы. Нагрузка достигает до 2000 запросов в секунду. Сервис основан в 1996 году и куплен eBay.

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

Из–за предстоящего сложного реинжиниринга, немецкая консалтинговая компания IT-Agile посоветовала использовать гибкие подходы, такие как Скрам.

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

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

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

В 2010 году iPhone от Apple и их мобильный App Store были самыми продвинутыми на рынке, поэтому выбор iOS как базы для приложения был очевиден.

«При наличии сомнений относительно дизайна и удобства продукта, реализованного агентством, мы все равно решили выложить его в Apple App Store. Хотелось посмотреть, будет ли спрос. Мы не понимали, насколько слабо наше приложение», — вспоминает Ральф.

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

«Семь миллионов человек используют mobile.de. Пришлось столкнуться с тем фактом, что многие из них теперь хотели искать свою следующую машину на мобильных устройствах. Чтобы клиенты продолжали использовать mobile.de, мы должны были создавать беспроблемный опыт использования нашего приложения», — вспоминает Ральф.

Мобильное приложение должно было сохранить дух и философию mobile.de, сделавшими его таким популярным. Штатные разработчики лучше знали, как сделать это. Изучение и адаптация к мобильному окружению было лёгкой частью задачи.

«Мы поняли, что единственный шанс для появления хорошего мобильного приложения — это если команда будет создана и воспитана в внутри, с одним этим приоритетом в головах», — объясняет Ральф.

В то время Хольгер работал программистом в другой команде. На протяжении многих лет он проявлял интерес к Канбан Методу. Работая в Скрам–команде, он замечал другие команды, которые визуализировали работу на досках, называемых Канбан досками.

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

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

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

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

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

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

Мы могли бы потратить первые месяцы на обдумывание идей и проработку решений, но такая подготовка выглядела как пустая трата времени», — вспоминает Хольгер Проект имел стратегическое значение не только с экономической точки зрения, но и с точки зрения подтверждения способности mobile.de быть инновационной и быстро развивающейся компанией. Команда должна была стартовать разработку незамедлительно.

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

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

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

«Это был наш шанс поэкспериментировать с Канбаном, и мы им воспользовались», — говорит Хольгер.

Такой подход имел свои риски. Хольгер и команда были готовы взять на себя ответственность за них. Вопрос был в том, согласятся ли вышестоящие менеджеры? Проекты в mobile.de обычно выполнялись с четкими вехами и отчетностью по расходованию ресурсов.

Предыдущие внедрения Канбан–Метода улучшали поставку, но они шли поверх существующих релизных циклов и процессов. Мобильная команда была первой, кто начал с нуля с Канбан. Они настаивали, чтобы не было ни итераций, ни оценок, ни сроков: просто постоянный поток работ, коммуникаций, обучения и поставки.

«Для этого потребовался прыжок веры, что эта команда без нужного опыта, добьется успеха с самого начала, без метрик, чтобы привлечь к ответственности, используя только Канбан–доску», — говорит Ральф.

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

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

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

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

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

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

В течение нескольких месяцев был разработан слой бизнес логики.

Как бы ни пыталась команда c помощью разработчиков из IT-Agile спасти iOS приложение, стало понятно, что его нужно переписывать с нуля, чтобы сделать удобным, стабильным и обслуживаемым в долгосрочной перспективе.

Часть команды взялась за переписывание iOS приложения, и спустя немногим более года после старта, у многих владельцев айфонов в Германии появился удобный способ найти себе следующий автомобиль. Но усилия были далеко не окончены: были и другие ОС для мобильных устройств.

«Вы действительно думаете, что этой функциональности достаточно, чтобы выпустить Android приложение?»

Унизительный вопрос представителей бизнеса застал Хольгера врасплох. К 2012 году ОС Android уже набрала внушительную динамику на рынке. Все больше производителей смартфонов использовали ее, база пользователей была значительной.

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

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

«Но вы все время могли наблюдать за тем, что мы разрабатывали, и не говорили, что этого недостаточно, — возмущался Хольгер.

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

В команде полагали, что пользовательская история в тикете с полями «кто», «что» и «почему» описывает требования в простой и сжатой̆ форме, что это должно быть понятно всем. Не было необходимости в дополнительном слое управления.

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

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

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

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

В поисках ответа Хольгер отправился на Канбан доску. Он смотрел на столбцы, на массу цветных стикеров в них, и размышляя о решении. Вспомнил, как с любопытством изучал Канбан–доски других команд.

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

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

Вскоре было введено понятие «Эпик», и для него было обозначено место на доске (рис. 1). Эпик представлял собой набор функций, связанных одной идеей, и назывался таким образом, чтобы каждый понимал, что это такое. При формулировании эпиков команда старалась сделать так, чтобы разработка занимала не более двух–трех недель.

Пользовательские истории в нем по–прежнему были написаны на языке разработчиков, например «Поле ввода для первой даты регистрации», но Эпик будет называться, например, «Создать форму для вставки автомобиля частными клиентами» — это язык, который понятен каждому в компании.

«Изначально придумали это, чтобы помочь руководству понять, что делаем, но со временем эпики помогли придумать, как управлять и ожиданиями», — говорит Хольгер.

В конце концов, эпики доказали возможность команды контролировать объем незавершённой работы и многозадачность — правило состояло в том, что разработчик Работает над пользовательскими историями только в контексте одного эпика. Кроме того, эпик стал метрикой успеха и способом оценки возврата инвестиций, поскольку представлял собой осязаемое улучшение продукта

«Вы должны чувствовать боль от проблемы и работать над ее решением».

Это направление ознаменовало первые месяцы пребывания Торстена на mobile.de. Будучи Фронтенд разработчиком, он был первым специалистом в разработке для мобильных устройств, начавшим работать в команде.

«Я пришел из рекламных агентств и стартапов, и привык к идее продуктивности. Если что–то блокировало мою текущую задачу, я откладывал ее и переходил к следующей в списке», — говорит Торстен.

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

«В первые месяцы мне было очень сложно сосредоточиться только на одной пользовательской истории, особенно, когда она заблокирована. Трудно было побороть желание нарушить это правило», — говорит Торстен.

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

«В mobile.de мы с товарищами по команде работали над одной функциональностью, добиваясь, чтобы она работала, прежде чем перейти к следующей», — вспоминает Торстен.

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

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

Хольгер снова пошел за ответами к Канбан доске. Проблему решили во время встречи команды.

«Что нам нужно сделать, чтобы стать лучше?» — спросил он. «Было бы полезно видеть, куда мы идем, на уровне с эпиками и пользовательскими историями», — таков был ответ.

Вскоре после этого появилось "Видение" — колонка концептуальной фазы более высокого уровня. К тому времени у команды уже был третий пул задач, на котором она фокусировала внимание: мобильный веб–браузер.

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

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

Только тикеты размера эпиков помещались в столбец Vision Ongoing, и после тщательной оценки владельцем продукта перемещались в колонку Vision Done. Оттуда они будут перемещены в колонку Epic, когда откроется слот.

Колонка Vision помогла Торстену придерживаться пользовательских историй, но также и постоянно коммуницировать.

«Мне никогда не было одиноко в борьбе с блокерами. Мы разрешали их вместе, обсуждая на встречах. Я взял на себя ответственность показывать прогресс на следующее утро тем же людям, которые помогли мне с проблемой накануне», — говорит Торстен.

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

Из–за хрупкой природы мобильных приложений и вебсайтов Торстен часто расстраивался из–за сбоев в продуктах после изменений или рефакторинга кода.

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

«У нас всегда была проблема — разработчиков больше, чем специалистов по тестированию. Когда соотношение достигло двенадцати к одному, у нас начались проблемы» — вспоминает Хольгер.

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

Разработчики привыкли передавать свои пользовательские истории в QA для тестирования, но вскоре поток был прерван, и команда больше не добивалась желаемого непрерывного развертывания. Вопрос был поставлен так: нужно ли стремиться к большему количеству инженеров по тестированию, чтобы команда могла продолжать работать как раньше, или к каким–то другим изменениям?

«На ретроспективе мы поговорили о нашем понимании роли QA», — говорит Хольгер.

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

Насколько это было оправдано? Разработчики были авторами кода, как они могли помочь устранить это узкое горлышко? Когда команда размышляла над этими вопросами, согласились, что нужны радикальные изменения.

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

Он поделился с командой практиками для самостоятельного тестирования собственной работы.

«Тест–кейсы — это не то, что я мог бы написать как фронтенд разработчик. Не знаю соответствующего языка программирования. Но наш QA создал фреймворки, которые сильно упростили написание тестов. Используя их, я сразу понимаю, хорошо ли реализовал свою фичу», — заметил Торстен.

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

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

Это эволюционное изменение роли QA помогло вернуть поток в прежнее состояние. Оглядываясь назад, ретроспективы позволили решить многие проблемы, с которыми сталкивались мобильные команды.

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

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

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

«Следующим проектом должно стать iOS приложение mobile.de для автодилеров», — сказали однажды представители бизнеса.

Это был февраль 2013 года. Команда скептически отнеслась к тому, что такая потребность существует. В то время у команды мобильной разработки уже были приложения для iOS, iPhone и iPad, а также приложения для Android на немецком и английском языках.

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

К тому времени две трети автодилеров в Германии пользовались mobile.de. Процесс разработки в мобильной команде стабилизировался, и у Хольгера стало больше времени, чтобы сосредоточиться на других вопросах.

Например, почитать книгу Lean Startup, которую он и его коллеги получили от mobile.de. Он впечатлился идеей для ранней проверки гипотез о потребностях клиентов. Сделать это было просто — создать минимально возможное решение, способное функционировать как жизнеспособный продукт: минимальный жизнеспособный продукт (MVP).

Этот MVP должен быть выведен в поля для тестирования с представителями целевой аудитории, даже если версия приложения для iOS 7 уже на доске команды iOS, даже если много дефектов. Смысл теста в том, чтобы узнать, насколько приложение ценно и интересно целевым пользователям.

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

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

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

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

За эти четыре дня участники получили так много ценных отзывов о существующем приложении, что вернулись в Берлин с «полным багажником» пользовательских историй. Вдохновленные этим опытом, члены команды Ларс и Макс (владелец продукта и архитектор взаимодействия, соответственно) начали проводить регулярные эксперименты по валидации. Например, раз в неделю Макс берет свой ноутбук и работает в разных кафе Берлина. Там он разговаривает с незнакомцами и просит их поиграть с прототипом.

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

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

Исследование того, чего хотят люди, стало движущей силой на этапе генераций идей в процессе. Плоский дизайн iOS 7 — один из следующих вызовов.

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

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

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