25 Авг 2020

Перевод оригинальной статьи

Привет, дорогие друзья!

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

Читайте об этом в данной статье!

…

Когда-то в начальной школе на меня снизошло озарение.

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

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

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

Вот несколько рисунков, которые я делаю на постоянной основе.

Риск и частота релизов

Небольшие, но частые релизы более безопасны, чем большие и редкие релизы.

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

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

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

Более быстрые релизы = более низкий риск.

Итерации

Итеративные улучшения лучше больших целей.

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

Чтобы проиллюстрировать эту идею, я хотел бы использовать метафору гольфа.

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

Вы бы предпочли иметь большую и мощную клюшку, способную с легкостью покрыть большое расстояние, или маленькую и быструю клюшечку, идеально подходящую для небольших дистанций?

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

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

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

Бэклог и размер истории

Хорошо продуманные истории означают меньше напрасной работы.

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

Один из способов ограничить расточительство — контролировать, как быстро меняются приоритеты. Если вы когда-нибудь слышали: “это не входит в рамки нашего следующего спринта”, то вы наблюдали этот подход в действии. Фиксирование объема работы хорошо помогает ограничить временные затраты, но за счет снижения гибкости. Для большинства команд эта цена слишком высока.

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

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

Истории должны быть как можно меньше, но при этом иметь некоторую потребительскую ценность.

Если история слишком велика, когда приоритеты меняются, вы вкладываете кучу времени в работу, которая не может быть запущена в производство. Если история слишком мала, то при смене приоритетов у вас останется куча фрагментов работы, которые “выполнены”, но не полезны без дополнительных временных затрат времени.

Истории верного размера сделают вашу работу менее трудоемкой, ваш риск низким, а ваши команды гибкими.