Абырвалг — Аджайл, который мы заслужили

Автор Telegram-канала "Золото Бородача" Никита Колмогоров делится системой, которую внедряет во все компании, с которыми работает. Эта система поднимает все метрики компании. Продукт начинает развиваться, таски начинают выполняться, разработчики перестают выгорать, время экономится, все рады, всем хорошо. Как? Читайте дальше.

В закладки

Привет всем! Меня зовут Никита, и я, время от времени, консультирую IT-стартапчики эти ваши. Первое время я был немного ошеломлен количеством методологий, которые используют менеджеры всех пород — и в скором времени даже начал применять канбаны, аджайлы, скрамы, четко следовал всем правилам и терпеливо наблюдал, как команды медленно, но верно приходят к застою.

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

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

И тут начались проблемы: споры, негодование, возмущения разработчиков о невероятной неэффективности ежедневных стендапов; появились явные «любимчики» у всех менеджеров, мешки под глазами разработчиков усугубились, кофе начали пить больше, продуктивность падала, разработчики начали «обманывать» систему — а менеджеры пытались показать рост эффективности на бумаге. Самый страшный кошмар любого руководителя на яву, в общем.

Почесав голову, я упростил классический скрам и внедрил упрощенную систему в ряд предприятий, с которыми тогда сотрудничал. И абсолютно чудесным образом разработка снова зашевелилась, как будто ей снова включили кислород. Менеджерам больше не приходилось врать о цифрах, разработчики внезапно начали любить свою работу, а таски начали выполняться. За полгода работы с новой системой, команда закрыла в два раза больше бизнес-задач, а в офис снова стало приятно приходить утром.

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

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

Сразу отвечу на ряд возражений: да, метод неидеален; да, он не универсален; да, вы можете сколько угодно аппелировать к недостаткам этой идеологии; в конце концов — вы можете даже просто начать поливать автора помоями, потому что вам нужно выпустить пар. Делайте все это — пишите, насколько эта система не работает и насколько автор не придумал ничего нового, это самое правильное, что вы можете сделать на данный момент.

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

Под звуки фанфар я открываю занавес — встречайте…

Абырвалг

Идея названия пришла ко мне в голову, как шутка, вот в этом посте в Телеграме.

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

Абырвалг, в отличие от скрама, прост и не требует учиться на скрам-мастера два месяца. Принципы Абырвалга максимально просты:

1. Есть только 2 командных митинга: час в понедельник и час в пятницу. В понедельник смотрим, что будем делать в эту неделю, в пятницу закрываем неделю и смотрим, что сделали. Раз в две недели понедельник — это еще и планирование спринта.

2. Спринт — это две недели или 10 рабочих дней. Задачи спринта замораживается на момент начала спринта. Если появляются новые задачи — они идут в беклог. Если что-то в спринт не успели к концу спринта — это идет в беклог. Повторяю: ничто не добавляется в задачи спринта после его начала.

3. Есть четыре столбца в табличке спринта: беклог, спринт, в работе, сделано. Первый — это вообще все таски, которые существуют, всегда отсортированные по приоритетности. Второй — это задачи текущего спринта. Третий — это то, над чем человек работает. В четвертый столбец задача переносится только, когда она протестирована, замержена и готова к релизу; то есть в самом конце жизни таска.

4. Каждая задача должна быть либо сама призывом к действию (actionable), либо должна быть разбита на действия с обязательным наличием следующего действия, которое нужно предпринять. "Сделать красиво", "Поправить кнопку" и тому подобные задачи в беклог никогда не попадают. Только конкретные "Изменить яркость с 90% до 50%" и "Сместить кнопку на 10 пикселей влево".

5. Нет никаких поинтов для разработчиков и градации задач по сложности. Если вы хотите поставить задаче что-то выше "легко", то вам нужно разделить задачу на несколько, каждая из которых будет "легко". Задачи должны щелкаться, как семечки, а не тянуться в течение нескольких спринтов.

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

7. Каждое начало спринта — это раздача задач каждому отдельно. У каждой задачи в спринте должен быть исполнитель.

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

9. Каждый день утром менеджер должен индивидуально пройтись по задачам, которые сделал каждый работник вчера — и что он будет делать сегодня. Руководствуйтесь роадмапом из пункта 8. Меняйте роадмап, если нужно. На каждого работника должно быть потрачено на этом этапе не более 3-5 минут. Это просто "что сделал и что сегодня будешь делать", а не разбор полетов.

Вот и все. Все остальные метрики и свистелки вам больше не пригодятся. Девять пунктов выше — это упрощенный скрам. Переставайте переусложнять методологии и начинайте упрощать. От добавления сложности продуктивность никогда не поднимется.

Решайте корень проблемы с научным Абырвалгом. Хватит пытаться лечить симптомы гомеопатическим скрамом. Переставайте тратить время на никому не нужные совещания и начинайте выстраивать индивидуальные роадмапы для каждого разработчика.

Недалек тот момент, когда вы раздадите все таски — и окажется, что их хватит всего на неделю из необходимых двух. Дай Бог вам такие проблемы.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Nikita Kolmogorov", "author_type": "self", "tags": [], "comments": 17, "likes": 16, "favorites": 85, "is_advertisement": false, "subsite_label": "life", "id": 99483, "is_wide": false, "is_ugc": true, "date": "Fri, 27 Dec 2019 20:37:56 +0300", "is_special": false }
0
{ "id": 99483, "author_id": 60968, "diff_limit": 1000, "urls": {"diff":"\/comments\/99483\/get","add":"\/comments\/99483\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/99483"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123, "last_count_and_date": null }
17 комментариев
Популярные
По порядку
Написать комментарий...
3

Из того что вы писали, 4й пункт ключевой. Четко поставленную задачу понятно как решать. Соответственно и решаться она будет быстрее. Но обычно, в болотистых компаниях, либо нет людей способных четко поставить задачу, либо у них 7 пятниц на неделе. И вот тут как раз теряется связь между всегда логичной разработкой и хаотичным развитием продукта. А если команда общается не с лицом, принимающим решения, а с очередным чайка-менеджером... Автоматом получаем отсутствие логики в развитии продукта, планов, невыполнение договоренностей и другой сумбур. В таких условиях теряется мотивация и вовлеченность команды. А это самое страшное в разработке: все толковые разбегутся а остальные будут отбывать номер.

Ответить
0

Согласен полностью, что 4 пункт ключевой. Внедрение его одного приведет к 80% результата — оставшиеся пункты нужны для еще 20% буста эффективности. Спасибо за комментарий!

Ответить
2

Есть известный способ мозгового штурма: плюсы, минусы, интересное (то, что нельзя отнести к первым двум и то, что может привнести новое для ситуации и принятия решения) .

Ответить
0

Спасибо за комментарий. Ценная информация.

Ответить
2

Добавлю немного от Линуса Торвальдса (создателя Linux и Git, например).

 
/ The Linux Foundation и конкретно ядро Linux,  это пожалуй, самый большой из успешных коллективных проектов, который делается полностью удаленно и распределенно.

C 2005 года в проекте участвовало более 13 тысяч разработчиков, ежедневно добавляющих около 10 тысяч строк кода, удаляющих 8 тысяч строк и изменяющих чуть больше полутора тысяч (для справки) /
_
Это особенно интересно, в проекции на тему всяких "живых совещаний", генерации "покерных бэклогов" и прочей "живой agile-интерактивности".

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

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

Проект структурирован так, что люди могут работать независимо, объяснил Торвальдс: “Мы разбиваем код на небольшие модули, и это даёт возможность распараллеливать работу”.

На самом деле наш рабочий процесс устроен так хорошо, что даже становится скучно.

Ответить
1

Чет легкий когнитивный диссонанс в терминологической базе (у меня или у автора).

Насколько я помню, Agile - это термин, означающий парадигму, т.е. подход, а точнее идею подхода (в корне которого создать "подвижность" в противовес "костности классических управленческих иерархий"), своего рода обобщающий термин для целого ряда подходов и практик, и выхолощенный в итоге некоторый набор принципов, позволяющих прицелиться в Agile.
_
То есть, фраза "я взял стандартный Agile и сократил метрики", наверное должна звучать, "я взял стандартный scrum  (потому что это популярная имплементация Agile-подхода)."
_
Т.к. в самом Agile никаких скрам-мастеров нет и быть не может, это парадигма. И есть по меньшей мере 3-4 другие методологии на равне со scrum, конкурирующие за идею приготовить Agile.
_
Поправьте, если я что соврамши.

Ответить
1

Конечно же, это у автора когнитивный диссонанс от новогоднего недосыпа. Вы правы, статью поправил. Спасибо!

Ответить
0

"1. Есть только 2 командных митинга: час в понедельник и час в пятницу. В понедельник смотрим, что будем делать в эту неделю, в пятницу закрываем неделю и смотрим, что сделали. Раз в две недели понедельник — это еще и планирование спринта." - ничего не смущает? 

Ответить
0

А что должно смущать? То, что митинг на 1 час в понедельник — это планирование спринта раз в две недели?

Ответить
0

между этими событиями только выходные?

Ответить
0

Между пятницей и понедельником, да, два дня выходных.

Ответить
1

а если объединить, скажем в пятницу?

Ответить
0

Думаю, это вполне себе возможно сделать. Благо, Абырвалг расширяем и полностью видоизменяем. Мне, наверное, просто удобнее было чисто морально разделить митинги на начало и на конец — чтобы у команды были четкие психологические "закрытия" и "открытия" рабочих недель.

Ответить
2

Маяковский вспомнился: Утро раннее.
Мечтой встречаю рассвет ранний:
«О, хотя бы
еще
одно заседание
относительно искоренения всех заседаний!»

Ответить
1

Ну, что могу сказать, Абырвалг — это видоизмененный Аджайл, в котором, к слову, каждый день стендап митинги :) Соглашусь, что гораздо лучше искоренить все заседания разом. Но, что есть — то есть.

Ответить
0

понедельник  который всегда после обеда лучше на утро вторника перенести.. 

Ответить
0

Плюсанул, хотя я и не разработчик. Эти ваши аджайлы, скрамы и кабаны мимо меня летят. Но я сегодня добрый. Почему? Просто я начал прибухивать по утрам) Совет на все времена. Пей винчик — топи токсичность, еееее!

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwcm9qZWN0SWQiOiI1ZTRmZjUxODYyOGE2YzcxNDUxNWY0ZGEiLCJpYXQiOjE1ODI1MzY0NDB9.AwBBnUWMy3RR1xtAoaXVr81WvqxdlD4C8CBpwFiONzw", "release": "3c305b26" } { "page_type": "default" }