Agile Lite: специально против выгорания

Автор оригинала: Dave Sullivan
  • Перевод
Гибкая методология разработки — отличная идея, которую слишком усложнили. 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 заключается в том, что его невозможно сделать правильно.
Поддержать автора
Поделиться публикацией

Комментарии 13

    +2
    Agile-манифест
    Наивысшим приоритетом для нас является удовлетворение потребностей
    заказчика, благодаря регулярной и ранней поставке ценного программного
    обеспечения.


    Agile Lite — это не про удовлетворение потребностей заказчика, это про удовлетворение потребностей разработчиков. Цель методологии совсем другая. Возможно название Scrum Light было бы более уместно.
      –1

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

        +4
        Ни разу не так. Что хорошо разработчику хорошо заказчику ровно на столько на сколько заказчик платит.
          0

          "It's all about struggle" © Uncle Bob, Clean Architecture

            +1
            А мне не надо чтоб было чисто, мне нужно чтобы вы заебались!
        +3
        Мне кажется, эта «новая легкая методология» в очередной раз пытается лечить симптомы, а не причину болезни. Не хотите чтобы разработчики выгорали? Так не заставляйте их работать по 60 часов в неделю, независимо от методологии. Не ставьте невыполнимых сроков, заставляяя команду работать в стрессовых условиях. Эджайл тут ни при чем вообще. Тем более со спринтами в четыре недели и планированием на месяц, какой это эджайл?
          +2
          Agile нельзя сделать правильно потому, что его нельзя сделать вообще. Весь Agile это всего лишь полтора десятка тезисов. Все. Если они вам кажутся разумными, вы пробуете им следовать. Как им следовать в самом манифесте текже не сказано. Scrum предостовляет некий набор инструментов, который может вам помочь в этом. Но и его сделать нельзя.
          Используя видиние того, что надо сделать (Agile) и инстременты (Scrum) вы можете сделать свой метод управления проектом.
          Но для того, чтобы разработать метод управления проектом не обязательно использовать ни то ни другое.
            0

            И я вот всем своим твержу, что Agile это подход, а не методика. И этот подход можно вполне и к и разработке по ГОСТ применять (т.е., например, понимать, что цель разработки не ТЗ написать).
            А вот SCRUM — это уже методика (набор методов). И я ни разу не видел, чтобы скрам по аджайлу шёл (не везёт мне наверное).
            P.S. И по мне так ГОСТ, получше чем "палочный SCRUM". Произвола поменьше.

            –2
            Есть такая методология разработки — «Пиши код б****»
            Одна из лучших. Гибкость методологии — потрясающая.
              +2
              Мне вот нравится. Только как объснить это шефу компании где я работаю? С точки зрения капитализма он старается выжать по максимуму, полагая что потом найдет другого, которого так же выжмет.
                0
                Ну вот у нас заказачик сам попросил Agile. Компания крупная и олдскульная (водопады, команды из десятков говнокодеров разработчиков из стран третьего мира, куча манагеров и т.д.). Естественно с первой попытки все не получается. В итоге у нас проект идет почти также, как в статье описано. Подозреваю, что из-за недостатка планирования. Неделя планирования очень спокойная у разработчиков т.к. демо, ретроспектива, менеджеры собираются в одном офисе и новые задачи не выдают. Мы спокойно рефакторим, подчищаем хвосты, расслабляемся. А вот следующие три недели — вполне рабочие. Не без переработок конечно.
                Заказчик, пока что, очень доволен.
                Разработчики… и да и нет.
                  0
                  Мне как разработчику важна ясность проекта и задач, когда понятно задание работа идет легко. Выгорание получается когда есть задачи «сделай то не знаю что».
                    +2
                    Выгорание оно не об этом.
                    Это, я не знаю, как отношение к мороженному или конфетам. В детстве человечек аж из штанов выпрыгивает от нетерпения в ожидании вожделенного, а для взрослого — он уже испробовал это всё.
                    Так и в программировании: вроде и яснее некуда и заказчики/начальники демократичнее и сговорчивее некуда. Но всё равно «тянешь лямку», а не творишь шедевр. Выгорел, прогорели все дрова и угли — одна зола по ветру рассеивается.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое