Отдых после стометровки

В одной из моих команд, в которой мы работали по Скраму, мы пришли к такой формуле:  спринт длится 2,5 недели, а потом 3 дня отдыха.

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

Практика имела в нашей команде исключительно положительный эффект и – я думаю – вот почему:

1. Небольшой отдых между спринтами позволяет команде перевести дыхание и сбросить эмоциональное напряжение. После такого отдыха в следующем спринте работа идет гораздо бодрее.
2. Во время перерыва можно полностью разгрузить мозг и освободиться от завершившегося спринта. Команда подходит к планированию и грядущей итерации более сконцентрированной.
3. Если есть несколько дней официального отдыха, команде проще начать новый спринт "с низкого старта". За два-три дня разработчики успевают морально подготовиться к новой итерации, и соблазн раскачиваться в начале спринта уменьшается. Деятельность команды становится честнее и прозрачнее, производительность – более ровной и предсказуемой.
4. У команды теперь есть специально отведенное время, чтобы подготовиться к планированию – заглянуть в беклог, внимательно изучить будущие истории, добавить к ним недостающую информацию, подготовить вопросы к планированию.
5. Теперь, когда для митингов есть отдельный день (или несколько), они не отвлекают от разработки. Возможно, у кого-то по-другому, но по своему опыту могу сказать, что если у меня в какой-то день планирование или груминг, то работа работается в лучшем случае наполовину.
6. В свою очередь, и разработка не отвлекает от других важных активностей: планирования, ретроспективы, обзора спринта и работы с беклогом. Перед ретроспективой появляются несколько часов обдумать предыдущий спринт. Перед планированием и грумингом теперь можно вгрузиться в контекст (см. п. 4). Перед обзором можно заново прокликать свои истории и подготовить приличную презентацию. Все это делает митинги более осмысленными и продуктивными

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

Бегуны наслаждаются заслуженным отдыхом после стометровки

Более того, давайте еще раз заглянем в "Скрам Гайд" и вспомним, какую продолжительность митингов нам рекомендуют. А рекомендуют немало: например, на месячный спринт отводится целых 8 часов планирования. Для спринтов меньшей длины значения будут уменьшаться пропорционально, но даже в этом случае получается довольно много. При таком раскладе отдельный день на планирование больше не кажется чем-то ненормальным.

Сколько времени выделять на подобные передышки? Я бы предложил начать с такого соотношения:

• 1 день на двухнедельный спринт,
• 2-3 дня на трехнедельный спринт,
• 3-4 дня на месячный спринт,

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

Личное планирование с помощью камбана, Скрама и Trello

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

Основные принципы

Идея системы возникла благодаря Trello - сервису "организации всего". В основе сервиса лежит обыкновенная доска-камбан. На доске можно создавать сколько угодно списков (столбцов), а контроль процесса сводится к перетаскиванию карточек из одного списка в другой или вверх-вниз по списку (удобный drag-n-drop прилагается). Сервис похож на многие другие инструменты планирования, но с той лишь разницей, что он не перегружен излишней функциональностью. Предельно просто и крайне удобно. Вдобавок, он доступен на любой платформе, включая мобильные, и бесплатен (платные функции вам точно не понадобятся, они ориентированы на корпоративное использование).

Я сформулировал для себя несколько ключевых правил, которые позаимствовал из некоторых известных техник Agile:

1. Единый бэклог для всех задач. Размер, тип или важность не имеют значения.
2. В начале дня задачи на текущий день переносятся в список "Сегодня".
3. В конце дня все незавершенные задачи отправляются обратно в бэклог, все завершенные попадают в "Done".
4. Любые идеи, которые могут стать задачами, фиксируются тут же на доске. Для это существует специальный список "Котел".

И добавил несколько исключений:

1. Только задачи, которые растягиваются на несколько дней, могут оставаться в "Сегодня" в конце дня, тем самым напоминая мне, что я над ними активно работаю. Их, как правило, не больше одной одновременно.
2. Для долгосрочных проектов по мере необходимости создаются отдельные задачи наподобие "Работа над проектом, 3 часа".
3. Для выходных удобно иметь дополнительный список "Завтра". Он упрощает планирование сразу на оба дня, которые можно рассматривать как единый интервал времени. 

Пример доски для личного планирования

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

Замечания

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

Удобный интерфейс побуждает к использованию

Удобство интерфейса и доступность Trello сыграли не последнюю роль в создании моего способа планирования. Раньше я пытался использовать для этих целей Evernote, OneNote, Outlook и Гуглокалендарь. У каждого из них были свои существенные недостатки. Бумажный блокнот я даже не рассматривал: я практически никогда не заглядываю в свои записи второй раз.

Бэклог продукта © www.informit.com

Бэклог

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

Сегодня

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

Done

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

Долгосрочные задачи

Мне нужен был простой подход в рамках моей системы, поэтому для долгосрочных задач я начал выставлять крайний срок (Trello позволяет это сделать). В какой-то момент при пересмотре приоритетов я просто перевожу их вверх бэклога. Таким образом регулируется срочность задач.

Крупные проекты

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

Все в одном месте и под рукой

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

Все без исключения

Я добавляю в бэклог абсолютно все: бытовые дела, рабочие вопросы, личные проекты - все, что требует хоть малейшего усилия воли, чтобы начать это делать. Отчасти, я делаю так из-за предыдущего пункта. Отчасти, потому что я пришел к выводу, что гораздо проще и эффективнее приоретизировать общий список, не разбивая его на части. А отчасти, потому что на силу воли полагаться нельзя вообще ни в чем. Более того, когда я вижу в конце дня в Done список из 5-6 задач, пускай даже некоторые из них были не особенно важны, это помогает мне формировать привычку воспринимать себя как человека, способного к действию.

Скрам: "это не то, что ты думаешь!"

Поводом к написанию поста стал недавний спор с коллегой о том, отличаются ли доски в Скраме от камбана. Для коллеги оказалось сюрпризом, что в Скраме нет ничего про доски.

Цена простоты

Когда простота может быть сложной

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

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

От философии к реальности

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

Как камбановские карточки, зачастую подобные вещи - это некие заимствованые практики, которые глупо было бы игнорировать, но без которых вполне можно справиться, если найти им  равноценную замену. Практики можно и нужно изменять под свои нужды. Ядро изменять нельзя (конечно, только пока вы не достигли "ри", как Коуберн), потому что это основа процесса, его фундамент. Если не следовать принципам, описанным в ядре, бессмысленно говорить о применении Скрама, и в этом случае никто не сможет ответить на вопрос, почему что-то пошло не так, когда что-то пойдет не так. Покупателя, который залазит внутрь изделия, производитель закономерно лишает гарантии, потому что покупатель делает это на свой страх и риск и теперь только он знает, в каком состоянии находится изделие.

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

Myth Busted

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

Скрам - каркас, а не полновсеная методология.

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

Скрам содержит только самое важное.

Ничего лишнего

Авторы методично убрали из Скрама всю шелуху, оставив только действительно самое важное, эффективное и простое для понимаиня. Имейте четкое осознание, что когда вы от чего-то отказываетесь, вы отказываетесь от ключевого, потому что не ключевое уже было исключено. Если за вашими плечами двадцатилетний успешный опыт, вероятно, вы достигли уровня, когда лучше других знаете, что вам нужно (впрочем, гарантий нет), и сможете эффективно менять даже эту ключевую часть. Но до тех пор - забудьте. Положитесь на опыт Швабера и Сазерленда - ребята не дураки.

Цель Скрама - продуктивность и прозрачность

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

Самое известное о Скраме вообще не Скрам

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

В заключение

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

Напоследок, в поддержку моего мнения то же самое, но более кратко, словами Алистэра Коуберна.