Кэтрин – первый разработчик
Тимати – второй разработчик
Дэн – их руководитель
Акт II. Игра в догонялки
Дэн раздражал Кэтрин и Тимати. Они понимали, что есть сроки и выполняемая работа важна. Они даже не возражали против давления, которое он оказывал. Но казалось, что каждый, даже самый маленький проект завершался «в режиме интенсивной терапии», как называл это Дэн, когда начинал заниматься микроменеджментом.
Текущий проект не отличался от остальных. Они работали над новой функцией приложения для камеры телефона, которая превращает лица друзей в старые плакаты «Разыскивается». Предполагалось, что это будет простой проект, который интегрирует их приложение с системой социальных сетей материнской компании.
Как обычно, во время тестирования обнаружилось множество ошибок, что заставило их пропустить дедлайн.
– Я уверен, что у нас не было бы проблем со сроками, если бы он не мешал нам работать, – сказал Тимати.
– Я знаю, что ты имеешь в виду, – добавила Кэтрин. – Это его вмешательство в каждую мелочь. Мы говорим о вмешательстве после семи вечера, когда на улице уже темнеет. Мы опаздываем на вечерний статус-митинг.
Это был «решающий момент», как называл это Дэн, имея в виду, что есть дедлайн, в который они не могут уложиться, но это означало, что аврал был всегда.
Кэтрин и Тимати вошли в кабинет Дэна и сели. Другие члены команды были уже там, и никто не выглядел счастливым. Дэн настроился на микроменеджмент.
– Итак, последние три проекта протекают в режиме «интенсивной терапии». Тим, Кэтрин, начнем с вас.
– Мы делаем успехи… – начала было Кэтрин.
Дэн прервал ее:
– У вас нет прогресса. Этот проект разваливается. Я дал вам достаточно времени для выбора собственного метода работы, а теперь мы должны действовать правильно.
Тимати возразил:
– Но там была ошибка, которую требовалось исправить.
– Вам всегда кажется, что есть ошибка. Просто вы, ребята, неспособны выполнить проект в срок. Мне придется погрузиться в процесс. Я подозреваю, что вы не понимаете всей его важности.
– Постойте! – воскликнула Кэтрин. – Ведь нет ничего удивительного в том, что в конце всегда возникают проблемы. В ходе работ накапливается много потерь.
– Что ты понимаешь под словом «потери»? – поинтересовался Дэн. – Это звучит негативно. Если мы хотим добиться успеха, то нужно оставаться позитивными. (Дэн всегда говорил о позитивном настрое, даже когда ругал своих сотрудников.)
– Ну, например, согласование любого изменения в пользовательском интерфейсе занимает недели. В середине обсуждения вы отдаете распоряжение приступить к разработке, и, похоже, мы тратим больше времени на изменение кода, чем на его написание.
– Правильно. И мы всегда удивляемся, когда команда тестировщиков находит ошибки. Почему-то это происходит постоянно, но мы никогда не находим времени, чтобы их исправить, – добавил Тимати.
Дэн начал злиться:
– Смотри, это такой стиль управления программными проектами. Перестань указывать пальцем на людей и обвинять их. Виноват я или команда тестировщиков.
– Слушай, Дэн! Хватит… – не сдержалась Кэтрин. Все удивленно взглянули на нее: она почти никогда не повышала голоса. – Мы никого не виним. Но есть проблемы, которые происходят снова и снова. Мы встречаемся два раза в день, и наши разговоры звучат как заезженная пластинка. Приходится бесконечно обсуждать одни и те же проблемы, которые почему-то всякий раз вызывают удивление.
Дэн немного опешил от такого напора. Он встал, посмотрел на Кэтрин, затем снова сел в свое кресло.
– Знаете, все это очень важно! Прямо сейчас найдем время и займемся этой проблемой. Это решающий момент.
Принципы Канбана
Давайте подробнее рассмотрим основополагающие принципы Канбана.
• Начните с того, что вы делаете сейчас, уважайте имеющиеся роли, обязанности и должностные инструкции.
• Договоритесь об эволюционном развитии.
• Поощряйте лидерство на всех уровнях.
Первый принцип – начните с того, что вы делаете сейчас, – отличается от всего того, о чем вы читали в этой книге.
Мы потратили много времени на сравнение гибких методологий с традиционными водопадными проектами. Например, Scrum дает полную систему для управления и реализации проектов. Если вы хотите внедрить Scrum, то нужно создавать новые роли (scrum-мастер и владелец продукта) и новые виды деятельности (планирование спринта, ежедневные scrum-митинги, доски задач). Это необходимо, поскольку система Scrum предназначена для управления проектами и поставки программного обеспечения.
Канбан не является системой управления проектами. Это метод улучшения процесса: шаги, которые команда принимает для создания и поставки ПО. Прежде чем вы сможете что-нибудь улучшить, нужна отправная точка, а для Канбана это как раз то, что вы делаете сегодня.
Привычное дело – думать о типичных проблемах.
Когда проектная команда делает то, что в итоге приведет к ошибкам и срыву сроков, это не похоже на ошибку. Позднее вы можете заняться анализом первопричин, ведь, столкнувшись с точно таким же выбором, команда, скорее всего, примет то же самое решение. Таковы люди.
Предположим, что команда всегда поставляет программное обеспечение клиентам только после многократных и непростых встреч с ними, во время которых пользователи таки и не могут найти обещанных функций. Конечно, не исключено, что эти разработчики невероятно рассеянны и всегда забывают об одной-двух функциях, которые обсуждали с клиентами. Но более вероятно, что их преследуют одни и те же проблемы в процессе выяснения требований пользователей.
Главная цель процесса улучшения состоит в поиске повторяющихся проблем, выяснении их общности и создании инструмента исправления.
Ключевая здесь вторая часть предложения: выявление того, что общего у этих проблем. Если вы предполагаете, что разработчик не может вспомнить все то, о чем просили пользователи, или они постоянно меняют свои требования, то вы придете к выводу, что эти проблемы невозможно решить. Но если предположить, что существует реальная и к тому же повторяющаяся причина, то есть шанс справиться с ситуацией.
Вот с чего начинается Канбан: взгляните на то, как вы работаете, и представьте свою текущую деятельность в виде совокупности заменяемых, повторяющихся действий. Канбан-команды называют правила, которым они всегда следуют, стратегией. По существу, это сводится к признанию привычек, тех шагов, которые делаются при создании программного обеспечения и их фиксации.
Иногда сложно записывать правила, которым следует команда, потому что легко попасть в ловушку, если судить о результатах проекта по команде в целом или отдельному ее участнику: если проект успешен, то все члены команды должны быть профессионалами, а если нет – то они явно некомпетентны. Это несправедливо, потому что предполагается, что в проекте все зависит от команды. Бережливое мышление помогает преодолеть это заблуждение, рассказывая, как увидеть картину в целом, что в данном случае означает увидеть большую систему целиком.
Стоит повторить, что каждая команда имеет производственную систему для создания программного обеспечения. Она бывает хаотичной и часто меняется. В основном она живет в головах членов команды, которые никогда не обсуждали, насколько она велика и что они придерживаются именно ее. Для тех, кто использует Scrum, система кодифицирована и понятна. Но многие команды следуют системе, существующей как некое «врожденное» знание: мы всегда начинаем проект беседой с представителями заказчика или составления графика, создания карт с пользовательскими историями либо сразу «погружаемся» в код после встречи с менеджером.
Именно с такой системой Канбан начинает работать. У команды уже есть способ запустить свой проект, а Канбан нужен, чтобы лучше понять систему. То есть начните с того, что вы делаете сейчас. Цель Канбана – сделать небольшие улучшения в этой системе. Вот что значит добиваться постепенных, эволюционных изменений. И именно поэтому Канбан имеет практики совместного улучшения и экспериментального развития. В бережливом мышлении необходимо видеть все целиком, чтобы понять, что требует измерений. А они составляют сердцевину эксперимента и научного подхода. Канбан-команда начнет с исследования того, как производится программное обеспечение, и получит объективное понимание ситуации. Затем она проведет определенные изменения как команда (в этой главе вы узнаете, как именно эти изменения работают) и проверит свои измерения на предмет соответствия желаемому эффекту.
Lean-ценность усиливает обучение и также является важной частью развивающейся системы, которую команда использует для сборки программного обеспечения. В этой книге вы узнали о петлях обратной связи. Когда вы сотрудничаете для измерения системы и экспериментального развития, петли обратной связи становятся очень важным инструментом сбора информации и подачи ее обратно в систему. Канбан-практика внедрения циклов обратной связи должна помочь вам увидеть тесную связь между Канбаном и Lean.
Ускоренное обучение – это также фактор канбан-принципа, который требует уважения текущих ролей и обязанностей участников. Предположим, что каждый проект начинается встречей руководителя проекта, бизнес-аналитика и программиста. Может быть, у них нет запротоколированных правил проведения таких бесед, но, скорее всего, эти правила легко понять, познакомившись с названиями должностей.
Канбан уважает текущие роли и обязанности, потому что все это важная часть системы.
Объединяет все эти принципы то, что Канбан работает только для тех команд, которые не жалеют времени, чтобы понять свою собственную систему сборки программного обеспечения.
Если бы существовал один правильный способ сборки ПО, то все бы просто использовали его. Но мы в