Гибкая методология разработки — отличная идея, которую слишком усложнили. Agile Lite — попытка упростить ситуацию. Вам не нужны книги или семинары, чтобы объяснить Agile Lite. Нужен только небольшой текст с несколькими пунктами. Вот этот текст.

Agile Lite довольно прост. Его можно применить к любому проекту при условии, что работа разбивается на более мелкие задачи (issue). Как и другие гибкие методологии, он использует короткие циклы разработки  — спринты. Но в отличие от них, Agile Lite явно признает распространённость выгорания в индустрии разработки программного обеспечения и пытается смягчить его напрямую путём внедрения цикла «три недели разработки/одна неделя отдыха.

Основные правила:

• Первую неделю каждого цикла руководители проектов, разработчики и другие заинтересованные стороны определяют предстоящий спринт. Хотя выделена неделя, планирование спринта займёт не более двух часов, а с правильной организацией — около 45 минут. Это намеренно лёгкая неделя: многие могут просто взять отпуск, чтобы заниматься сёрфингом, живописью или чем-то ещё.
  
• Спринт проходит в течение оставшихся трёх недель. В течение этого периода инженеры работают над задачами, которые выделены им во время планирования. Поскольку сотрудники могут быть удалёнными и распределёнными по часовым поясам, «живые» встречи происходят нечасто, и большая часть общения идёт через трекер (который работает быстрее, чем электронная почта). Общая канбан-доска вроде Trello вполне подходит, а электронная таблица вряд ли. Ежедневные планёрки не поощряются: общий пульс проекта вполне отслеживается по обновлениям трекера.
  
• После начала спринта нельзя добавлять задачи в спринт, но их можно удалять. Это уменьшает переключение контекста, что хорошо.
  
• Незавершённые задачи рассматриваются на следующем сеансе планирования спринта — и решается, переместить задачу в следующий спринт, вернуть в список пожеланий или переназначить другому разработчику.
  
• Каждая задача находится или в списке пожеланий, или в текущем спринте. Выполнение каждой задачи должно занимать 4?8 часов.
  
• Как уже упоминалось, в течение недели планирования разработчикам рекомендуется отдохнуть, чтобы мозг восстановился после предыдущего спринта. Это не крестовый поход. Разработчики не работают по выходным. Всё это помогает избежать выгорания, что полезно для всех.

Хотя основную работу в спринте можно запланировать, иногда происходит что-то неожиданное. Эти неожиданные проблемы называются задачами поддержки (Support Issues).

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

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

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

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

Agile Lite для разработчиков

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

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

Желая уйти в отгул или отпуск, вы покажетесь бездельником, который не поддерживает команду. Возможно, вы работаете в открытом офисе; все знают, когда кто приходит и уходит, и все подписывают негласный контракт не работать меньше других. Поэтому люди хорошо умеют выглядеть занятыми. Когда кто-то спрашивает, как дела, вы просто отвечаете: «Занят! Я ТАК занят!»

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

Я предлагаю решение. Это форма Agile, которая явно разработана, чтобы избежать выгорания: Agile Lite. Здесь не бывает сверхурочной работы. Инженерная работа поставлена на поток, а у разработчиков достаточно времени, чтобы перезарядить мозги. Накладные расходы на менеджмент минимальны.

Почти вся система описана в шести пунктах выше. Её можно изменить в соответствии с вашими целями. Но я хотел бы выделить одну особенность Agile Lite. Здесь мы явно говорим: «Эй, гибкие команды выгорают так же, как и в других методологиях разработки. Возможно, стоит прописать явные правила, чтобы предотвратить перегрев двигателя, которым является инженерной командой».

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

Agile Lite для менеджеров

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

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

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

Основные принципы системы Agile Lite описаны выше и могут изменяться в соответствии с вашими целями.

FAQ + типичные утверждения

Единственное общее правило в мире гибкой разработки — это то, что все делают её неправильно. @fwip

Так значит, инженеры получают 12 недель отпуска в год для сёрфинга и живописи? Как это будет работать в мире, где работа с 9-00 до 21-00 шесть дней в неделю становится нормой?

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

Отмечу, что 40-часовая рабочая неделя когда-то считалась радикальной идеей. Google начинал с 80% рабочего времени для основных проектов, сейчас у нас 75%, я хотел бы снизить это до 10% (метод Ферриса) к концу 2020-х годов.

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

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

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

Сёрфинг и живопись никоим образом не обязательны, они приведены просто в качестве примеров. Я сам даже не занимаюсь сёрфингом и живописью.

Людям назначают задачи или они сами прогнозируют, что получат?

Они прогнозируют. Ничего страшного, если ваши оценки ошибочны. Это часть процесса, и все в одной команде.

Можно назвать это итерациями вместо спринтов?

Конечно! «Спринт» подходит лично для меня.

Можно ли сделать скользящую итерацию в стиле канбана, где даты начала и окончания варьируются и зависят от обстоятельств?

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

Почему именно три недели спринтов?

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

Означает ли это, что даты начала и окончания спринтов часто попадут на середину календарного месяца?

Да.

Разработчики участвуют в планирование спринта?

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

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

Неужели на планирование спринта уходит неделя?

Нет, в том-то и дело. Это лёгкая неделя.

Стендапы действительно проблема?

По моему опыту, да. Обычно все стоят в кругу, слушая одного человека в течение 20 минут. Конечно, это «неправильный» подход, но я никогда не видел, чтобы кто-то делал их правильно, и предпочёл бы вообще отказаться от ежедневных планёрок. Ещё сложнее (или, по крайней мере, неудобнее) их проводить, когда ваша команда распределена географически. Но если для вас они очень ценны, не позволяйте мне остановить вас.

Мы должны сделать всё именно таким образом?

Нет. Никто вас ни к чему не принуждает. Это рекомендации, а не правила.

Это не религия.

Эти правила политические только в том смысле, в каком пропаганда 40-часовой рабочей недели была политической.

То, что работает для вас, может не работать для других. Вы знаете об этом?

Я в этом уверен!

Частые утверждения

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

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

Разработчикам нельзя доверять, и нужно отслеживать всё их время, потому что именно так делается работа.

Я действительно не согласен, но не могу быстро объяснить почему. У нас фундаментальные различия в мировоззрении.

Это не Agile.

Конечно Agile, он ведь прямо в названии.

Это нереально.

И всё же оно работает.

Вы делаете Agile неправильно.

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