Почему Agile не работает и что мы делаем иначе
Agile начинался как набор ценностей. Ценности тонкие и абстрактные, поэтому, как и в случае гибкого распространения, распространялись не ценности, а практика циклической работы. Циклы легко объяснить и легко скопировать.
Люди в нашей отрасли думают, что они перестали делать водопад и перешли на гибкую разработку. На самом деле они просто перешли на высокочастотный водопад.
Agile стал синонимом скорости. Все хотят большего и быстрее. И одна вещь, которую большинство команд делают недостаточно быстро, - это доставка. Так циклы стали «спринтами», а метрикой успеха - «скоростью».
Но проблема не в скорости. И сами по себе циклы не помогут вам в отгрузке. Проблемы заключаются в том, чтобы делать неправильные вещи, строить по спецификациям и отвлекаться.
Утверждение, что где-то в прошлом или будущем существует настоящая Agile ™, тоже не помогает. Когда ваша команда борется с доставкой, вам нужны практические шаги, которые вы можете применить здесь и сейчас. Не просто идеал.
Циклы хороши. Мы работаем циклично в Basecamp. Но в дополнение к циклам вам понадобятся еще три практики, чтобы отправить их вовремя и в хорошем состоянии.
Преднамеренное распределение ресурсов
Дизайнеры и разработчики не смогут добиться прогресса, если люди будут постоянно привлекать их внимание. Не имеет значения, если служба поддержки обнаружит ошибку или отдел продаж нуждается в новой функции. Распределение ресурсов означает выделение ресурсов. Тот, кто выделяет время и деньги на создание функции, должен также защищать команду, чтобы они могли делать то, о чем просили. Требуется мандат сверху, чтобы обеспечить время и внимание команды. Команда делает это и только это в течение цикла.
В Basecamp мы начинаем каждый цикл работы с команды из трех человек: дизайнера и двух программистов. Им нечего делать, кроме этого проекта. Если вы чувствуете, что должны исправлять ошибки сразу же, как только они возникают, выделите для этого ресурсы. Если у вас есть противоречие между продажами и продуктом, сделайте выбор в пользу этого цикла. Если у вас недостаточно людей, чередуйте время цикла между отделами.
Только менеджмент может защитить внимание. Сказать команде, что нужно сосредоточиться, работает только в том случае, если бизнес поддерживает их.
Изменяемые требования
Если команда работает в соответствии со спецификацией, нет смысла повторяться. Цель итеративной работы - менять направление движения. Предварительное определение проекта вынуждает команду перейти к каскадному процессу. Если каждая деталь плана должна быть построена, у команд нет выбора, когда они обнаруживают, что что-то сложнее, чем ожидалось, менее важно, чем ожидалось, или когда реальность противоречит плану.
В Basecamp мы начинаем каждый проект с основной концепции. Мы проделываем домашнюю работу со стороны стратегии, чтобы убедиться, что некоторая версия идеи осмысленно осуществима в то время, которое мы выделяем. Мы также уверены, что будет реализовано менее 100% концепции. Не все подойдет, но самое важное - получится. Если мы не уверены, мы добавим что-нибудь еще в цикл и вернемся, когда достаточно отточим концепцию.
Чтобы создать команду с такой концепцией, вам нужно отделить ядро от периферии. Отделите абсолютно важные вещи от вещей, которые были просто «нашей идеей, как это сделать».
Одно решение пользовательского интерфейса может вызвать неделю ненужной работы. Программист мог изо всех сил провести рефакторинг кучи Javascript только для того, чтобы обнаружить, что детали не лежат в основе концепции. Дизайнер просто случайно выбрал это взаимодействие, не зная стоимости.
На практике это означает, что командам нужно дать новое определение. Некоторые вещи важны, а другие нет. Команда должна знать разницу и делать звонки соответственно. Чтобы подкрепить это, мы даем командам рисованные наброски с низкой точностью в начале цикла и тратим больше времени на мотивацию, чем на детали дизайна и реализации.
Стратегии подъема
Команды, отслеживающие «скорость» и «очки истории», рассматривают разработку как линейный труд. Разработка программного обеспечения - это не перемещение груды камней.
Если бы работа была такой, вы могли бы сосчитать камни, подсчитать время, чтобы переместить один, посчитать и готово.
Работа, требующая решения проблем, больше похожа на холм. Это трудный этап, когда вы понимаете, что делаете. Затем, когда вы доберетесь до вершины, вы увидите другую сторону и то, что нужно, чтобы закончить.
Фаза подъема полна ложных шагов, кругов и тупиков. Здесь вы сталкиваетесь с неожиданным. Программист говорит: «Да, это займет два дня», но затем они начинают трогать код, и реальность становится более сложной. Или дизайнер говорит, что «это взаимодействие будет идеальным», и они тестируют его на устройстве, но это не то, на что они надеялись.
Самый важный вопрос для команды - не «что осталось?» но «что неизвестно?» Вы видите края? Вы зашли туда и увидели все, что нужно изменить? Единственный способ обрести уверенность - засучить рукава и погрузиться в реальность проблемы.
В Basecamp наши команды ищут места с самыми страшными неизвестностями и в первую очередь работают над ними. Эта трудная работа требует стратегии. Об этом мы писали в Getting Real. Откройте код, добавьте что-нибудь, что работает, загрузите в него реальные данные и попробуйте. Когда вся функция слишком велика для прототипа, исключите наиболее важные части и увеличьте их.
Работа в гору - это когда вы узнаете, что сложно и что возможно, и делаете оценочные суждения. Здесь вы принимаете решения относительно этих изменчивых требований, потому что видите реальные затраты и возможности реализации. Обучение в гору требует внимания и времени, уделяемого командам сознательно выделенными ресурсами.
В течение многих лет мы делали это неформально, уделяя особое внимание неизвестным и в первую очередь устраняя их. Недавно мы начали оформлять это с помощью Hill Chart. В наши дни мы часто задаем вопрос: «Где это на холме?»
Вот снимок из проекта Поиск на месте, запущенного в октябре.
А вот несколько моментов из проекта To-Do Groups.
Для доставки требуется целый бизнес
Независимо от того, работают ли команды циклически или нет, это лишь часть истории. «Гибкая» команда не продвинется далеко, если руководство не будет беречь ее время. А если у них нет возможности изменять требования по мере обучения, поздняя ночь и поздняя доставка гарантированы.
Дизайнеры и разработчики могут изучить сложные стратегии из Getting Real, чтобы обрести уверенность, вместо того, чтобы скрещивать пальцы. Тот, кто устанавливает требования, может дать командам возможность отступить на подъеме. Распределители ресурсов могут взять на себя больше ответственности, чтобы следить за фокусом своих команд.
Мы занимаемся этим 15 лет. Надеюсь, что обмен некоторыми из этих техник тоже поможет вам в этом.
ОБНОВИТЬ:
С момента написания этой статьи мы создали и выпустили функцию в Basecamp 3, чтобы вы могли создавать свои собственные диаграммы холмов. Смотрите все подробности здесь:
