Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban (pdf+epub) Коул Роб
ДАТА ДОСТАВКИ
БУДУЧИ НЕПОСТОЯННЫМ ПОКУПАТЕЛЕМ
МНЕ НУЖНА ГАРАНТИРОВАННАЯ ДАТА ДОСТАВКИ В МОМЕНТ СОВЕРШЕНИЯ ЗАКАЗА
ПО ПРИЧИНЕ ТОГО, ЧТО Я ДОЛЖЕН ЗНАТЬ, КОГДА ОЖИДАТЬ СВОЙ ЗАКАЗ, ЧТОБЫ ОН НЕ СГНИЛ ПОД ДВЕРЬЮ
В ходе этих обсуждений определяются ключевые аспекты главнейших характеристик продукта. Помните, записи сами по себе ничего не значат, однако живое коллективное общение позволяет нам не только выработать основополагающие детали, но и сохранить свежий взгляд на проект. Выигрышно во всех отношениях.
Выработка критериев принятия
Как мы узнаем, что мы сделали все? Это ключевой вопрос, и именно с него следует начинать дискуссию, следующую за обсуждением пользовательской истории. Чтобы действовать эффективно, нужно знать, когда остановиться. Когда заканчивается наш проект? Сколько сил мы должны вложить в него? Как избежать переработки и неизбежной фрустрации? Для успешного использования пользовательских историй мы должны выработать критерии принятия – предпосылки к проекту, которые должны быть реализованы, чтобы история была оценена как выполненная.
Не существует единственно правильных критериев принятия. Они могут быть как простыми, вроде условий удовлетворенности работой, так и очень подробными. В рамках Agile лучшими критериями принятия являются односложные оценки, написанные простым и понятным языком. Рассмотрим пользовательскую историю, связанную с датой доставки, и применим к ней критерии принятия:
• Дата доставки – всегда будет на следующий рабочий день после заказа.
• Если заказ был оставлен в субботу, то доставка будет в понедельник.
• Заказы на следующий рабочий день принимаются до трех часов по полудню.
• Клиент получает подтверждение о заказе по электронной почте.
• Все продукты в наличии доставляются по этим правилам.
• Мы сообщаем день заказа, но не точное время.
• У пользователя должна быть возможность оставить комментарий для курьера.
• Ожидаемый день доставки будет показан на экране при заказе.
Критерии принятия, написанные командой разработки, являются самым предпочтительным способом учесть все мелочи. Под руководством владельца продукта или бизнес-представителя команда может обсуждать пользовательские истории, устранять любые двусмысленности и определять конечный результат. Это лучший способ добиться согласованной работы, и эти обсуждения не должны быть длительными или трудоемкими. Их можно сделать как раз перед началом основной работы над проектом; цель состоит именно в том, чтобы начать с конца!
Кроме того, по критериям принятия можно отслеживать прогресс выполнения работ. Зачастую бизнесменов беспокоят расплывчатые фразы вроде «мы почти закончили» или «полагаю, мы на верном пути». Поэтому критерии принятия могут служить вехами на пути к завершению работ: мы реализовали половину из заявленных критериев принятия. Если критерии сформулированы должным образом, отслеживание прогресса будет легким – и все будут понимать, следует беспокоиться или нет.
Разделяя истории
Иногда в результате плодотворных обсуждений появляется очень много материала. Это хороший признак, не волнуйтесь и продолжайте записывать обсуждение. Некоторые идеи могут не подходить пользовательской истории, над которой вы сейчас работаете, или быть для нее слишком продвинутыми. Как только вы это поймете, сможете такие идеи отфильтровать и в дальнейшем добавить в более подходящие истории.
Другой подход заключается в том, чтобы написать новую историю – так называемое разделение историй. Типичный пример – ситуация, когда владелец продукта считает некоторые из критериев принятия необязательными и хочет выработать новую историю, включающую в себя дополнительные характеристики продукта. Как только новая история написана, она может быть включена в журнал требований (бэклог) вместе со всем остальным.
При написании историй очень важно знать, когда остановиться. Чем сложнее история, тем меньше вероятность того, что она будет полезна. Чрезмерно широкие критерии принятия – важный индикатор того, что что-то пошло не так. Обычно это значит, что историю надо разделить. Нередко вам придется разделять истории несколько раз, и в этом нет ничего плохого – наоборот, это прекрасный способ сделать работу над проектом более реалистичной.
– И нашему пользователю сразу будет понятно, где аварийный выход!
Когда размер имеет значение
Итак, у нас есть видение, бэклог, MVP, также набор продуманных пользовательских историй вместе с четкими критериями принятия. Отличная работа. Теперь стоит задаться вопросом: сколько времени и сил потребует практическая реализация всего этого? Обычно ответ на этот вопрос дают руководители проекта или профильные специалисты. Однако в Agile-проектах этим вопросом занимаются люди, непосредственно ответственные за реализацию проекта. Они не только смогут предоставить более реалистичную оценку. Это также позволит сплотить команду. Конечно же, от размера каждой пользовательской истории зависят сроки реализации MVP, как и проистекающие из этого характеристики. Тем не менее это все еще прекрасный способ оценить возможные проблемы с реализацией конкретных этапов проекта. Если вы видите, что члены команды чешут затылки, тяжело вздыхают и качают головами, то это не очень хороший знак.
Ряд оценочных техник исключительно хорошо подходит для Agile-проектов, например:
• Размеры одежды. Присвойте ярлычки S, M, L, XL и XXL каждой составляющей проекта, чтобы оценить приблизительное количество ресурсов, которое потребует ее реализация. Отличный способ для начинающих, который, впрочем, далеко не всегда точен.
• Оценочный подход. Используйте фиксированную шкалу, чтобы оценить трудозатраты для реализации составляющих проекта, например, на шкале от одного до ста 1 будет означать «очень легко», а 100 – «исключительно сложно». Данный подход начинает работать далеко не сразу, но у него много приверженцев.
• Принцип схожести. Распределите все истории в зависимости от их размера – от малых до больших. Затем присвойте значение 1 самой маленькой истории, после чего оцените все последующие истории соответственно. Прекрасный способ, чтобы оценить MVP.
Лучший способ выработать здравые оценки:
• Используйте открытый журнал требований.
• Не игнорируйте запутанные пользовательские истории.
• Большие, сложные и многофункциональные истории делают все интереснее.
• Надейтесь на лучшее.
• Не позволяйте сомнениям остановить вас.
• Не беспокойтесь – оценки все равно обычно бывают неверны.
Меньше значит больше
За пределами мира Agile-проектов практически всегда начинаются с игры в кошки-мышки. Бизнес-команда инстинктивно чувствует, что она должна просить все на свете и немножечко больше, потому что когда еще это делать, как не в начале проекта. Она также осознает, что, когда проект летит под откос – а это происходит всегда в той или иной форме, – это негативно скажется на количестве и качестве результатов. Поэтому основная стратегия бизнеса – просить все, чтобы на выходе получить хоть что-то.
Разработчики прекрасно понимают это и вполне положительно относятся к закладыванию в проект пространства для маневра. Проблемы начинаются тогда, когда проект предсказуемо катится в тартарары, но ряд изначально заложенных результатов уже находится в стадии реализации, и перед разработчиками встает дилемма относительно того, что делать с вложенными в эти промежуточные результаты ресурсами и усилиями. Когда время и (или) деньги разработчиков начинают подходить к концу, нередко оказывается, что самые важные задачи до сих пор не выполнены: например, в случае с реновацией дома не имеет смысла вкладывать последние деньги в высокотехнологичную кухню, если в ванной еще даже не начиналась побелка. Конечно же, здравый смысл подсказывает нам, что всегда стоит начать с реализации самых минимальных требований к проекту, но не стоит думать, что после их выполнения работа автоматически заканчивается. Обе стороны – и заказчик, и разработчики – должны быть уверены в том, что проект не заканчивается после первого рабочего прототипа и процесс улучшения и доведения до ума финального продукта продолжится и в дальнейшем. Доверие – важный залог успеха, но понимание важности поэтапной реализации задачи является основой Agile. При наличии этого понимания вероятность того, что проект скатится под откос вместе со всеми ресурсами, затраченными на его реализацию, сравнительно невелика, если, конечно же, первоначальная идея проекта не была абсолютно нереалистичной – но в этом случае проблема отнюдь не в Agile.
MVP – это абсолютный минимум, необходимый для начала использования или работы. Использование каждой функциональности или нюанса должно быть результатом рационального выбора. Критерий отбора прост: если MVP работает без этой характеристики, то она не нужна. На практике вы безусловно можете допустить наличие пары не совсем необходимых характеристик – до тех пор, пока их реализация не начинает отнимать ресурс у основной цели. Ваша цель – выработать набор требований к проекту, который можно быстро и беспрепятственно реализовать.
Как только команда и заказчик привыкают использовать этот подход, его преимущества становятся абсолютно очевидны: ускоренное время выхода продукта на рынок является ключевым элементом конкурентоспособного бизнеса. Кроме того, очень сложно предсказать идеальный профиль будущего продукта, поэтому гораздо разумнее вносить изменения в уже реализованный продукт. Гораздо приятнее обсуждать возможные улучшения продукта после того, как он вышел на рынок и его основные характеристики уже реализованы. Ничто не помешает команде вернуться к длинному списку дополнительных характеристик, которые ожидают своего воплощения.
Блистательная мысль
Отдел финансов редко выступает инициатором перехода к Agile, но его работники обычно очень положительно воспринимают данный переход, если объяснить им все его преимущества. Сокращение периода адаптации проекта для выхода на рынок, поэтапная реализация проекта и быстрый возврат инвестиций – все это звучит как райская музыка для людей, которые привыкли работать с деньгами. Достаточно сказать им, что гибкие подходы положат конец бесконечным спиралям бессмысленных бюджетных трат, – и эти люди ваши. Не забывайте о том, что они могут быть очень полезными союзниками!
Менеджмент рисков и ожиданий
В случае правильной реализации Agile-проекты должны быть избавлены от типичных проблем, которые преследуют обычные проекты. Менеджмент рисков и ожиданий является неотъемлемой частью Agile-подходов, которые построены на максимальной прозрачности рабочего процесса. Основной риск для Agile-проектов заключается в отсутствии понимания того, как именно функционирует гибкая разработка, поэтому повторите это еще раз.
• Не забрасывайте испробованные и надежные практики. Многие разработчики пытаются менять слишком многое слишком часто. Придерживайтесь плана и вносите изменения по одному. Если изменения не работают, откажитесь от них.
• Говорите. Говорите. ГОВОРИТЕ. Отсутствие взаимодействия между людьми – источник всех зол. Отсутствие информации является не менее губительным, чем плохая информация. Используйте регулярные отчеты о проделанной работе для гарантии того, что вы обсуждаете что нужно и когда нужно.
• Избегайте чрезмерно масштабных задач. Чем больше требований, тем сложнее их понять. Всегда старайтесь разбить большие задачи на несколько маленьких и более доступных задач.
• ПРОДОЛЖАЙТЕ ГОВОРИТЬ. Лучший способ избежать рисков при использовании гибкой системы разработки – это постоянно поддерживать контакт с окружающими вас людьми.
Блистательная мысль
Лучший способ привести все к краху – это формально адаптировать проект под Agile, продолжая работать с ним, как с обычным проектом. Бойтесь овец в волчьих шкурах.
Ведение журнала требований
Значение журнала требований невозможно переоценить. Это краеугольный камень вашего проекта. Тем не менее даже самый лучший журнал требований будет бесполезен, если вы его не ведете. Журнал требований – это живой организм, требующий внимания. Если использовать его должным образом, то журнал требований поможет вам понять, что происходит, найти общий язык с другими участниками проекта, уменьшить риски и контролировать ожидания. Если вы не уделяете журналу достаточно внимания, он будет просто отнимать время и сбивать с верного пути. Ведите ваш журнал требований!
В начале проекта журнал будет полон функциональных требований и характеристик, записанных в виде пользовательских историй. По мере развития проекта там будут появляться новые записи и пользовательские истории – это лишь один из возможных примеров создания элементов журнала. Основная задача журнала – сделать работу над проектом видимой, включая неудачи, бесполезные характеристики, возможные улучшения, новые идеи – вообще все. Записывайте и перерабатывайте их, а затем сортируйте в зависимости от их ценности.
Журнал требований принадлежит владельцу продукта, который несет за него ответственность. Владелец продукта не должен прекращать работу над журналом, он должен постоянно обновлять и использовать его как основу для ведения дел со всеми заинтересованными сторонами. Вносить изменения в журнал постоянно нелегко, но плюсы перевешивают неудобства. Прозрачность разработки – залог доверия, и лучший способ ее добиться – вести открытый для всех журнал.
Лучше всего, если владелец продукта и команда просматривают журнал каждый день. Это может быть частью постоянной рабочей практики или частью любой презентации, посвященной проделанной работе. Иногда ведение журнала занимает часы, а иногда минуты, однако важно обновлять записи постоянно.
Создание рабочей среды
Успех проекта, использующего Agile, в наибольшей степени зависит от его участников и того, как они взаимодействуют друг с другом. Нередко заставить людей эффективно взаимодействовать друг с другом довольно трудно, и рабочая среда играет в этом процессе ключевую роль. Самые успешные проекты – это те, участники которых сфокусированы на результате, работают в одном офисе и не имеют проблем с доступом к владельцу продукта. Не менее важно, чтобы у разработчиков перед глазами всегда была доска с задачами и, что особенно важно, журнал требований продукта. Работа в одном помещении снимает основную часть проблем, связанных с коммуникацией, позволяя не только эффективно взаимодействовать, но и налаживать личные связи, обсуждая то, кто и как провел выходные.
Блистательная мысль
Статичный журнал требований – признак грядущих неудач. Стоит обеспокоиться, если журнал не обновляется.
Впрочем, давайте будем реалистами. В идеальном мире мы все работаем в одном офисе, часто смеемся, остроумно шутим и не имеем проблем с зубами, но на практике некоторые из нас регулярно опаздывают на работу, мы часто работаем в разных городах и нередко целыми днями пропадаем в офисе заказчика. Независимо от обстоятельств, видимость и прозрачность взаимодействия является залогом успеха, но добиться этого на практике часто оказывается нелегко. Видеозвонки, электронные списки задач на гигантских тачскринах и переговоры в Скайпе далеки от идеала, однако лучше иметь что-то, чем ничего. Если, и это действительно очень важно, при всем при этом мы регулярно делаем записи в журнал, то все эти ухищрения могут сработать.
Для тех команд, которые не уверены в достижимости целей проекта и члены которых не знают своих точных обязанностей и последовательности выполнения задач, нет оправданий. Если между собой команда не разговаривает, значит, что-то пошло не так, и горькая правда состоит в том, что из-за этой рабочей среды падает производительность. Значимость эффективной коммуникации сложно переоценить; если у команды есть желание обсуждать рабочий процесс, они обязательно найдут способ, как это сделать.
Если вы не знаете, куда идете, то и придете куда-нибудь.
Йоги Берра (американский бейсболист)
Завершающие слова
Любая попытка начать проект без четкого видения приведет к неудаче, так как в этом случае вам придется вырабатывать видение на лету. Прочный фундамент исключительно важен для любого созидательного процесса. Даже самая лучшая команда не сможет добиться успеха, не имея точной цели с самого начала. Выработать представление о конечном результате до начала проекта нелегко, но это единственный вариант.
Однако даже при наличии фундамента реализация проекта не похожа на легкую прогулку. Для успешной реализации поставленных задач вам понадобится журнал требований продукта; к счастью, для его создания вам не нужно составлять полный и детальный список требований. Не имеет смысла тратить время на создание гор документации для проекта, который, возможно, не увенчается успехом. Создание журнала требований может быть относительно быстрым примером коллективной работы, которая, при должной реализации, может оказаться интересной.
В случае с Agile-проектами сдача первых результатов не должна восприниматься как приговор. Первый результат представляет собой тот минимум, который необходим для того, чтобы запустить бизнес. Чем быстрее вы сможете реализовать последующие этапы проекта, тем продуктивнее будут первые результаты. Не откладывайте на завтра то, что можно сделать сегодня. Следите за развитием бизнеса и с удовольствием включайтесь в новый мир Agile.
Блистательный итог
• Начните с конкретного и рационального видения. Избегайте неясных и нереалистичных целей.
• Бизнес-ценность превыше всего, поэтому убедитесь, что вы и ваши коллеги имеют общее представление о том, что это такое.
• Любите ваш журнал требований продукта. Поддерживайте журнал на должном уровне и убедитесь, что в нем хватает пользовательских историй, понятных всем.
• Определитесь с MVP! Успех проекта зависит от того, как хорошо и быстро вы справитесь с этой задачей.
• Выработайте критерии принятия и всегда держите в голове конечный результат.
Глава 4. Использование Канбана
Введение
Есть множество причин для того, чтобы перейти на Agile-подходы. Возможно, работа над проектами едва движется или вообще не доходит до стадии выпуска продукта или стимулом стал услышанный где-то рассказ об Agile. Причины, по которым вы пришли в Agile, могут различаться, но важный вопрос состоит в том, что нужно откуда-то начинать. Ничто не помешает сразу нырнуть туда с головой, и есть успешные примеры именно такого подхода, но бывают ситуации, когда сначала воду хочется попробовать – и нет ничего плохого в том, чтобы применять Agile постепенно. Один из прекрасных вариантов такого начала – Канбан.
Канбан – это слово переводится с японского как «вывеска» или «рекламный щит» – был разработан как система расписаний работ в автомобильной промышленности, а сейчас представляет собой одну из самых быстрорастущих областей Agile. Его легко понять, просто применять и можно внедрить практически без затрат. Большим плюсом Канбана является то, что он может быть использован как командами для полномасштабных проектов, так и индивидуумами, чтобы контролировать объемы работ.
Не считайте Канбан просто очередной ступенькой на пути к Скраму. Да, это может быть частью путешествия по Agile, но Канбан имеет свою собственную ценность. Это не дополнительная возможность или легкий путь. Это прекрасный способ начать работу над проектом по-гибкому, и у Канбана есть масса скрытых достоинств.
Жизнь – игра. Если вы хотите добиться чего-то, вам стоит довериться своему сердцу и инстинктам и сделать первый шаг.
Алисса Урбано (блогер)
Основы Канбана
Канбан появился как система расписания для автомобильной индустрии. Первоначальная задача Канбана заключалась в обеспечении высокого уровня производительности на заводах «Тойота» посредством предоставления возможностей для самосовершенствования и адаптации в ходе рабочего процесса. Со временем Канбан трансформировался в набор общих принципов работы, использующихся в различных бизнес-секторах.
Несмотря на эти изменения, Канбан верен своей первоначальной философии; с течением времени он улучшался и адаптировался, чтобы стать надежным и гибким инструментом. Изначальная простота основополагающих принципов остается важным преимуществом, и основой Канбана является идея плавного перехода от планирования к реализации. Суть Канбана в том, чтобы добраться из точки А в точку Я.
Это эволюция, а не революция. Канбан предлагает командам начать с существующего статус-кво и развиваться уже оттуда, советуясь с людьми, уже вовлеченными в процесс.
Изменения происходят по обоюдному согласию, что увеличивает вероятность добровольного использования Канбана. Помните три основополагающих принципа:
1. Определитесь с постановкой задачи.
2. Выработайте последовательные этапы задачи.
3. Следуйте согласованным процессам, ролям, обязанностям и условностям.
Блистательная мысль
Будьте внимательны, если предложение перейти к Канбану исходит от команды, которая уже использует один из фреймворков Agile.
Это может быть отличным знаком, потому что Канбан недостаточно оценен и его кажущиеся простыми процессы скрывают в себе значительный потенциал. Однако есть люди, которые считают, что главной особенностью Канбана является отсутствие необходимости планировать задачи или оценивать риски, и именно это положительно отличает Канбан от Скрама.
Попытки забивать гвозди микроскопом не приводят ни к чему хорошему. Канбан не исключение.
В сущности, реализация Канбана состоит из пяти ключевых этапов: сначала необходимо визуализировать рабочий процесс, затем определить рабочую нагрузку для каждого момента времени, а потом выработать меры контроля, оценивания и улучшения рабочего процесса.
1. Визуализация рабочего процесса. Начните с представления рабочего процесса от статуса «сделать» до статуса «сделано». Многие предпочитают включить как минимум еще один дополнительный этап в эту схему: «работа в процессе». Другие стараются разбить рабочий процесс на серию процедурных, таких как план, разработка, прототип, сборка, тестирование, имплементация, помимо начального и завершающего шагов.
2. Определение рабочей нагрузки. Попытки сделать все и сразу – лучший способ потерпеть неудачу как на индивидуальном, так и на командном уровне. Канбан ограничивает количество задач, которые находятся в работе в момент времени – этот показатель также известен как «работа в процессе» (work-in-progress WiP), – чтобы добиться максимальной эффективности. На этом этапе достаточно руководствоваться здравым смыслом, и со временем вы легко сможете выработать сбалансированную оценку WiP.
3. Контроль рабочего процесса. Ваша основная задача – добиться плавного перехода от начала и далее, вплоть до завершающего этапа. Это обычно означает, что рабочий процесс должен иметь максимальную эффективность, что, в свою очередь, позволяет добиться максимальной бизнес-ценности в кратчайшие сроки. При этом все ваши действия должны быть воспроизводимы и логичны.
4. Конкретизация рабочего процесса. Конкретные представления о рабочем процессе исключительно важны для объективного оценивания его успешности. При наличии коллективного понимания сути проекта гораздо легче обсуждать его непредвзято и достигать консенсуса относительно его развития. В конце каждого этапа у вас должны быть четкие критерии оценки его успешности и того, что вы будете делать следующим.
5. Совместная работа. Как только вы сосредоточитесь на рабочем процессе, у вас начнут появляться идеи о том, как можно его улучшить. Показатель WiP играет ключевую роль в подобных дискуссиях, позволяя команде сконцентрироваться на приоритетных задачах. Начальный максимум не более чем двух задач на человека позволит идентифицировать проблемы, замедляющие рабочий процесс; после этого команда может сосредоточиться на этих проблемах и решить их.
Канбан отлично подходит для
• введения в Agile с минимальными затратами и рисками;
• характеристики имеющихся рабочих процессов и идентификации проблем для их реализации;
• контроля над множественными и несвязанными задачами;
• ограничения количества задач для их успешной реализации;
• привития гибкого мышления команде.
К доске!
В центре метода – интересный инструмент: канбан-доска. Называть такие доски «визуализированным списком дел» – слишком большое упрощение, но они могут стать хорошей отправной точкой. Доска – это графическое представление работы от статуса «делать» к статусу «сделано». Простейший вариант канбан-доски состоит из трех колонок: «Сделать», «В процессе» и «Сделанное». Такой простой формат универсален и подойдет любому проекту.
Со временем вы станете быстрее определять, как распределить задачи по статусам работы. Популярным является вариант, когда еще не принятые в работу идеи выделяются в отдельный столбец. Имеет смысл отделять задачи со статусом «в процессе работы», если над ними работает не один человек. Также изменение статуса каждой задачи в процессе работы должно быть понятным и заметным. Начните с четырех колонок: «Идеи», «Сделать», «В процессе» и «Сделанное». Границы между этими колонками обозначают условие для перемещения задачи в следующую зону.
1. «Идеи» – сюда помещаются задачи, которые могут пойти в дальнейшую разработку, а могут и нет.
2. «Сделать» или «в процессе» – уже принятые идеи, насчет которых нужно определить, кто именно будет над ними работать.
3. «В процессе» – как только исполнитель (или группа) для задачи определены, задача отправляется в эту колонку, чтобы обозначить, что работа над ней идет.
4. «Сделанное» – полностью завершенная задача.
Рис. 4.1. Канбан-доска
Блистательный пример
Каждый год The Sunday Times публикует в декабре список под названием Fast Track 100. Этот список включает в себя наиболее быстро развивающиеся частные компании Великобритании за последние три года. Критерием оценки является рост продаж.
Однажды одна из этих компаний была выставлена на продажу, что вызвало незаурядный интерес в бизнес-кругах. Интерес был настолько значителен, что повлек за собой ожесточенное противостояние инвесторов.
Следуя стандартной процедуре, каждый из инвесторов должен был оценить офисы и производственные мощности в ходе экскурсии, которую проводил менеджерский состав. Маршрут экскурсии не был прописан заранее, но каждый из главных менеджеров использовал канбан-доску для представления стратегических внутренних проектов.
Это еще одно свидетельство того, что несколько колонок могут представить потенциал компании.
Определение «сделанного»
В управлении проектами одна из самых больших проблем – присвоение задаче статуса завершенной. Крайне важно определить критерии того, когда задача выполнена, для каждой задачи. И всегда уточняйте способы доставки продукта и способы оплаты. На этом этапе зачастую возникает непонимание – Agile заостряет на этом внимание отдельно.
Единственный способ сделать все верно – советоваться с заказчиком или бизнес-представителем; это еще одна крайне здравая идея, лежащая в основе Agile. Простой пример можно привести из области розничных продаж. Когда вы заказываете новую посудомоечную машину в магазине, включает ли это доставку и установку? Предполагается ли самовывоз, или, наоборот, сделка включает в себя все, даже быструю демонстрацию основных функций? Когда местный водопроводчик приходит к вам с предложением сделать ванную вашей мечты, входит ли в это определение облицовка стен плиткой?
Определение четких критериев «сделанного» — совместный процесс и зачастую достигается путем проб и ошибок. Не пренебрегайте возможностью выделить время для определения этих критериев, но и не слишком углубляйтесь в эту проблему – в процессе работы все шероховатости будут устранены.
Блистательная мысль
Никогда не перемещайте задачу в колонку «Сделано» преждевременно. Почти сделано, на 99 % сделано – это еще не завершено. Не спешите, даже если продемонстрировать прогресс кажется необходимым.
Больше чем просто доска
Когда начальный формат канбан-доски определен, первый и, практически, важнейший аспект, который должен быть определен, – будет ли это физическая доска или цифровой вариант. И то и другое имеет свои плюсы и минусы. Доступ к виртуальной доске может быть осуществлен отовсюду – не нужно ничего, кроме смартфона или планшета. Но, по нашему мнению, главная характеристика доски – это то, что она в центре внимания, в этом плане физическую доску ничто не заменит.
Качественная и заметная доска притягивает взгляд, как камин в гостиной. Спустя некоторое время она станет центром действий команды. Задачи планируются, перемещаются и определяются на доске. Кроме того, физической доской заинтересуются и другие – руководству очень понравится наглядность доски и возможность отслеживать ход работ напрямую, не через среднее руководящее звено и не по еженедельным отчетам, так что ожидайте визита директора в течение недели.
Для начала достаточно будет старой доброй пробковой доски, ручек, бумаги для заметок и кнопок; или белой доски и стикеров. Можно даже попробовать найти лучшее применение вон той доске объявлений, на которой полтора года висит всеми забытый и совершенно неразборчивый график. Трех или четырех колонок будет достаточно, но помните, что вам может понадобиться еще пространство.
Блистательный пример
Как сделать идеальную канбан-доску:
• Приобретите два рулона разноцветных обоев 3 1 метр, набор из 50 разноцветных карточек 12 8 сантиметров и 6 маркеров.
• Выберите центральную стену, которая хорошо видна всем сотрудникам из любой части офиса. Важно, чтобы на стене было два-три метра свободного пространства и перед ней было достаточно места, чтобы там могло стоять несколько человек.
• Приклейте две полосы обоев параллельно полу одну над другой.
• Разбейте получившееся пространство 6 2 на четыре колонки, используя хорошо заметные цветные полосы.
• Прикрепите карточку над каждой колонкой: «Идеи», «Сделать», «В процессе» и «Сделанное».
• Оставьте достаточно места для расширения доски; вам может понадобиться изменить количество колонок, чтобы отобразить этапы рабочего процесса.
• Запишите задачи на карточки и прикрепите их на колонки «Идеи» или «Сделать».
• Переместите карточки в колонке «Сделать», пока они не окажутся в нужной последовательности.
• Готово!
Поместите вашу доску в приметное место, а не туда, где коллеги бывают редко. Доска скоро станет центром для действий команды, поэтому убедитесь, что около нее осталось достаточно места для тех, кто будет к ней подходить. Вне всяких сомнений, реальная доска понравится всем.
Будьте решительны: мы во всеуслышание заявляем, что переходим на Agile.
Дешевые и высокотехнологичные альтернативы
Несмотря на то что мы отдаем предпочтение старомодным физическим доскам, бывают ситуации, когда цифровые варианты предпочтительнее или даже являются единственным вариантом. Когда члены вашей команды постоянно в разъездах или работают в разных городах, технологичный вариант становится более привлекательным.
Но прежде чем отказаться от реальной доски, подумайте дважды – особенно если эт ваш первый опыт в Agile. Цифровая доска более функциональна, но менее заметна, поэтому многие выгоды от ее использования будут утеряны. Не переходите на цифровую версию только потому, что некоторые члены вашей команды любят иногда поработать дома; обдумайте все лишний раз, чтобы в конечном счете вместе с грязной водой не выплеснуть и ребенка.
Если цифровая доска – единственно возможное решение, рассмотрите вариант совмещения ее с реально существующей доской на стене, продублированной в электронной форме. Проблемы с синхронизацией двух разных вариантов будут с лихвой компенсированы преимуществами реальной доски. Но даже если и это не вариант, можно отыскать несколько программ для создания доски с хорошим функционалом. Некоторые из них бесплатны, а у других есть пробный период, так что их можно протестировать, прежде чем покупать.
Блистательный совет для сохранения времени
Программы для электронной доски для Канбана или Скрама довольно востребованы, поэтому есть из чего выбрать. Trello – бесплатная, легкая в использовании и совместима со многими устройствами. JIRA – больше чем просто доска, и те, кто ее использует, расходятся в оценках этой платформы, но в ней есть возможность приобретения надстроек для распечатки пользовательских историй, что делает синхронизацию с реальной доской куда проще.
Создание журнала требований работ
Список «Сделано» – ключевой для канбан-доски и используется для создания журнала требований в различных гибких подходах. Все задачи, прямо или косвенно, должны быть направлены на выпуск продукта и достижение высокой результативности рабочего процесса. Установка канбан-доски – важный этап, но совещания для обсуждения хода работ – только часть рабочего процесса. Конкретные задачи должны быть сосредоточены на результатах, а не на их обсуждении. Если задача на доске не направлена на конкретное действие, ее оттуда нужно убрать.
Журнал требований в Канбане очень похож на журналы в прочих методологиях Agile, задачи так же каталогизируются, как и пользовательские истории. Тем не менее в Канбане есть некоторые важные отличия:
• Задачи должны быть равного размера. Лучше иметь истории меньше, но примерно одинакового размера. Разделение больших объемов работы на меньшие, приблизительно равные куски – подтвержденный метод для улучшения производительности и прогнозирования времени завершения работы, как и сравнение аналогичных показателей.
• Журнал требований обновляется регулярно, и в Канбане он куда более динамичен, особенно если работа идет хорошо. В других средах Agile журналы требований изменяются часто, но не настолько. Журнал в Канбане может обновляться каждый день.
Блистательная мысль
Переход на Agile не всегда проходит гладко. Иногда даже получить проект для того, чтобы опробовать на нем техники Agile, – недостижимая мечта. Но, даже если вы столкнулись с противниками гибких подходов, не отчаивайтесь. Начните с малого и просто сделайте свою собственную канбан-доску. Все аспекты вашей работы станут видны коллегам, что позволит упредить вопросы насчет того, над чем вы сейчас работаете.
Сомневающихся можно переубедить, продемонстрировав им на личном примере, как работает Канбан.
• Задачи выбираются, а не навязываются. Команда ориентируется не по следующей задаче, а по жесткому расписанию – задаче будет присвоен наивысший приоритет, как только ресурсы для ее выполнения станут доступны.
Перетасовка колоды
Как только вы обсудили идеи, сформировали доску и журнал требований, следующий шаг – организовать разумную последовательность работы. Никто в здравом уме не расставит задачи в алфавитном порядке, но просто удивительно, как часто приоритет задач присваивается в случайном порядке – в зависимости от того, что вам нравится, или под давлением со стороны, или даже и то и другое, но совсем не по разумным и взвешенным поводам.
Главная идея всех гибких подходов – обеспечение результата, и именно эта мысль должна быть основной в определении приоритетности задач. Задача, которая направлена на результат, должна выбираться первой. Если две разные задачи кажутся одинаково равными по бизнес-ценности – выбирайте ту, которая легче.
Не тратьте много времени на определение бизнес-ценности задачи – сравнения ее с другими должно быть достаточно; на этом этапе значение имеет сравнительная оценка, а не детальный анализ. Проведите простой подсчет расходов на реализацию задачи, включающий в себя такие факторы, как время, необходимые усилия и затраты. Перемножив эти цифры, получите некий общий балл, который будет определять приоритетность задачи.
Блистательный пример
Существует пять простых шагов для определения приоритета задачи:
• Разделите истории в журнале на равные по объему задачи.
• Присвойте каждой бизнес-ценность (от 1 до 10, где 10 – максимальная).
• Определите расходы на реализацию (от 1 до 5, где 1 – самая «дорогая» и 5 – самая «дешевая»).
• Найдите произведение «бизнес-ценность расходы на реализацию» и упорядочите полученные результаты в порядке убывания.
• Просмотрите полученный список с точки зрения здравого смысла!
– А еще вы обещали сварить мне чашечку кофе!
Одним из больших преимуществ канбан-доски является легкость перераспределения карточек во время группового обсуждения. Это будет очень важно после того, как возникнет необходимость изменить порядок задач после согласования их приоритетности.
Одним из краеугольных камней Канбана является совместная работа бизнеса и команды, работающей над реализацией идеи, и когда все вместе собираются у доски, обсуждая задачи и определяя, что дальше, это становится особенно очевидно.
Контроль работ в процессе (WiP)
В идеальном мире каждая задача вверху списка «В процессе» должна перейти в список «Сделано», прежде чем будет начата работа над следующей. На деле все не так просто, и большинство решает сразу несколько задач в одно время. Это не многозадачность, а простая необходимость.
Канбан устанавливает лимит на количество задач, одновременно находящихся в работе. Это значение можно применять и при одиночной работе, и для команд. Одному человеку не рекомендуется работать более чем над тремя задачами в один момент времени; для команды это значение равняется количеству членов команды, умноженному на два.
Периодически можно заметить тенденцию работать с удовольствием над задачей в самом начале и терять к ней интерес по мере продвижения к завершению. Канбан справляется именно с этим установкой предела WiP. Это помогает не утонуть во множестве задач, которые застряли в состоянии «завершено на 99 %». Обеспечение надлежащей результативности работы невозможно без ее завершения.
Для успешного применения Канбана установление предела WiP совершенно необходимо. Без этого колонка «Сделано» на доске так и не превратится во впечатляющий список завершенных дел. Предел WiP обеспечивает непрерывность рабочего процесса вплоть до его завершения и получения выплат. Члены команды будут вынуждены разбираться со сложными задачами, а не задвигать их в дальний угол.
Постоянное совершенствование процесса работы является важной частью Канбана и в основном будет происходить само по себе. Предел WiP вынуждает команды быть более вдумчивыми, когда это необходимо, и понимать, что тормозит производственный процесс. Это создает атмосферу постоянного поиска улучшений и всевозможных корректировок, чтобы машина работала более плавно, – прямо как в индустрии, из которой Канбан появился.
Канбан страдает от
• Ни от чего, если подойти к нему с умом.
Управление проектами с Канбаном
Еще один ключевой тезис Agile – непрерывный выпуск продукта. Не нужно долго ждать улучшений – продукт выпускается постоянно. Канбан схвтывает самую суть этой идеи, потому что каждая часть проекта обрабатывается по отдельности. Это и будет лакмусовой бумажкой для идеальной пользовательской истории. Сохраняется ли в ней смысл, если осуществить ее отдельно? Порадует ли она в таком виде кого-то?
Конечно, и весь проект можно осуществить, использовав Канбан. Проект можно разделить на меньшие части или пользовательские истории, работа над которыми будет вестись поэтапно. Канбан побуждает бизнесменов рассматривать и составные части проекта, и ориентироваться на выпуск таких продуктов, которые обеспечат отдачу сами по себе, а не только как часть общего проекта. В этом случае отличным примером служит добавление новых характеристик к уже созданному продукту.
Жизнь, проведенная на краю пирса, – это жизнь, полная сожалений и страха.
Райан Лилли (бизнес-спикер, автор)
Завершающие слова
Одна из прекрасных особенностей Канбана – это то, что он приносит минимальные изменения в статус-кво. Отталкиваясь от уже существующих принципов рабочего процесса, гораздо легче избежать ситуаций, когда процесс окажется нарушен или его положительные стороны окажутся утеряны. Канбан отдает предпочтение эволюции, а не революции, стремясь не потерять то, что уже есть.
Изменения, привносимые Канбаном, на первый взгляд незаметны, но их влияние сложно переоценить. Кто в здравом уме будет спорить с ограничениями на число рабочих задач? Использование Канбана приводит к непосредственным улучшениям в работе и нередко сопряжено с рядом внезапных озарений. Возможно, вы столкнетесь с несколькими фомами неверующими, но результаты очень быстро сумеют их переубедить.
Переход к новой революционной методике работы нередко оказывается неординарной задачей. После пары бокалов вина довольно легко убедить собеседника в преимуществах Agile, но на практическом уровне адаптировать работу коллектива к гибким подходам сложнее. Некоторые люди сумеют адаптироваться очень быстро и будут рады это сделать, но остальных придется подталкивать в нужном направлении. Вопрос заключается в том, как.
Канбан – отличный способ это сделать. Его легко понять и еще легче использовать. Несмотря на свою легкость, Канбан не является компромиссным решением. Он вполне способен фундаментально изменить командную работу и продемонстрировать преимущества Agile. Использование Канбана может быть самостоятельным решением или промежуточным этапом на пути к Скраму или любому другому гибкому фреймворку.
И последнее важное замечание: Канбан очень легко понять и применять, но его также довольно легко применять неправильно. Не стоит обманываться его простотой. Начать использовать Канбан довольно просто, но, чтобы извлечь из него максимум эффективности, понадобится приложить некоторые усилия.
Блистательный итог
• Канбан-доска – центр всего проекта.
• Начните с визуализации рабочего процесса.
• Определитесь с пределом WiP для наибольшей эффективности.
• Несмотря на кажущуюся простоту, Канбан – исключительно мощный инструмент.
• Канбан может быть вашим пунктом назначения или остановкой на пути к чему-то большему.
Глава 5. Просто лучшее: основы Скрама
Введение
Скрам (Scrum) стал популярен, потому что он работает. Правда, эта техника достигла нынешней известности не мгновенно. Скрам развился как технология разработки продуктов в середине 1980-х годов в Японии и был усовершенствован в США в 1990-х годах. Скрам пробовали, писали о нем – и статьи, и просто в блогах, – но наиболее важным было то, что в процессе этого он постоянно улучшался. В конечном итоге была получена какая-то критическая масса успешных проектов, и про Скрам заговорили.
Теперь Скрам занял свое заслуженное место среди других фреймворков Agile и остается самым популярным прежде всего потому, что он имеет достаточно директивный характер, но не топит команду в обременительных правилах, процессах и догмах. Более того, это один из самых удачных способов начать работу с новичками в Agile, поскольку Скрам четко определяет роли и обязанности, но при этом обеспечивает достаточную гибкость в их реализации, чтобы позволить своим пользователям чувствовать поддержку, но и не запутаться.
В настоящее время Скрам является наиболее распространенным фреймворком Agile, поэтому есть много вариантов, чтобы научиться ему – от сертифицированных и несертифицированных учебных курсов до внутригруппового или индивидуального обучения и множества вариантов для самообразования. Опытные пользователи согласны с тем, что легко начать работать в Скраме, но нелегко в нем преуспеть, потому так важно хорошо разобраться в ключевых моментах.
Блистательная мысль
Нет плохого способа начать работать со Скрамом – главной ошибкой будет вообще не пробовать.
Рис. 5.1. Фреймворк Скрам
Читать бесплатно другие книги:
