Как понять, что Agile работает
Асхат Уразбаев (ScrumTrek)
Прежде, чем начнем говорить, как это все выглядит изнутри, с какими проблемами мы сталкиваемся, когда тренируем команду, вопрос: те, кто работает по Agile, что для вас значит, что Agile команда является Agile командой? Как вы это определяете?
Меня зовут Асхат Уразбае в, я из компании «ScrumTrek». Занимаемся мы тем, что помогаем компаниям, организациям внедрять те самые гибкие методологии. Проблемы, с которыми мы сталкиваемся.
Внутри вашей организации может быть несколько команд. Некоторые команды считают, что они работают по Agile. У некоторых руководителей возникает вопрос, какая команда действительно работает по Agile, и что это физически означает? Т.е. как можно определить, что ты работаешь по Agile?
Например, есть всякие формальные вещи, типа sprint, velocity. Не знаю, есть ли у вас в компании такие люди, которые очень любят такие термины, любят ими бросаться и говорят: «Мы проводим ежедневные стендапы. Мы работаем по Agile или нет?».
И, вообще, что такое Agile? Предсказуемые результаты, приспособляемость к изменяющимся требованиям, быстрая реакция на изменения, короткие итерации. Это идеи. Какие там есть практики? У меня, например, на слайде sprint, velocity, story points; еще какие-то вещи, которые используют для того, чтобы все это обеспечить.
Приходишь иногда в организацию или компанию, где несколько команд — некоторые работают по Agile, некоторые нет. Как судить, какая команда круче, исходя из того, как они работают, какие бы практики они не использовали — sprint, velocity или любые другие? Очень тяжело сказать, какая команда более эффективна, исходя из того, что ты просто смотришь на то, как это работает.
Как это очень часто выглядит? Приходишь в контору, там две команды — у одной есть все, прям все, что можно, напихано — от технологий до методов, практик, подходов. Но они не деливерят, они не в продакшне, результата нет. Или деливерят в продакшн какой-то отстой. Плохо, медленно. Видно, что они работают не эффективно. И другая команда, которая ничего не использует, у которой нет ни sprint, ни velocity, ни всех этих модных терминов, но они деливерят качественный результат, и заказчики, конечный пользователь и т.д. ими довольны.
Получается, никакой 100%-ой корреляции между тем, какие подходы вы используете, и тем, какой результат вы получаете, нет. И это такой грустный факт. Получается, достаточно трудно уследить за тем, насколько это эффективно просто по тем цацкам, или бейджикам, или еще по чему бы то ни было, что люди на себя навешивают.
У нас был такой случай. В одной из компаний, с которыми мы взаимодействовали, они решили, что будет клево, если ребята будут использовать геймификацию, выдавать бейджики. Используешь velocity? На тебе бейджик. К чему это приводит? У всех бейджиков до фига, все в бейджиках, но толку от этого никакого нет. Получается чистый карго культ.
Еще одно частое определение, что такое Agile — Agile манифест:
Это быстрые реакции на изменения. Можно ли его использовать как определение Agile?
В нем есть определенный минус. Дело в том, что если ваша команда работает по методу «как получится», т.е. вы не пишете документов, никаких процессов и инструментов у вас нет, вы ничего не используете, никакой документации и контрактных отношений с заказчиком у вас тоже нет, никакого плана вы сроду не создавали — можно ли исходить из этого, что вы Agile? Судя по этому определению, в принципе, да. Получается, что эта штука — Agile Manifesto — не за что-то, а против чего-то. Он против водопада. Против того, когда требования пишутся, проектирование долгое и т.д. И получается, что как хорошее четкое определение его использовать нельзя.
Я попытался понять, если все это выкинуть, все эти нюансы, что же такое, на самом деле, Agile? Я постараюсь об этом рассказать.
Получается, Agile-практики ради Agile-практик — это абсолютно бессмысленная вещь. Да, они для чего-то нужны, но надо понимать для чего, какую задачу они выполняют. Agile манифест как определение тоже не работает, или работает не во всех случаях. Какое же определение эффективности?
Возникает вопрос: какую команду можно считать крутой? Я специально использую слово «крутой», а не «эффективный». Какая команда для вас крутая? Которая бабло зарабатывает? Но она может быть инхаус, внутри вашей компании, она автоматизирует бизнес-процессы, какое там бабло? Бабло, если вы в стартапе, а если не в стартапе? Качество, сроки, результат, деливерит, короче говоря. Довольный заказчик — тоже хорошее определение.
Я попытался свое сформулировать, потому что все эти вещи — они ситуативны, где-то есть, где-то нет. Я старался придумать определение, которое более-менее подходит к любой ситуации. Что же такое крутая команда?
С моей точки зрения, крутая команда определяется умением справляться с проблемами, с которыми встречается. Т.е. если вы, например, руководитель такой команды, к вам бегают за решением проблемы каждый час, каждый день, вы все время что-то разруливаете, то это не очень крутая команда.
Еще крутость команды определяет масштаб проблем, которые она способна решать. И способность быстро реагировать на постоянно меняющиеся условия. Что-то поменяется, команда адаптируется, двигается дальше. Это, с моей точки зрения, и есть эффективность.
Если нам нужно, чтобы заказчик был доволен… Заказчик недоволен — это проблема, которую команда умеет решать. Если мы говорим «команда деливерит» — это просто одна из проблем, которую команда должна решать. Она должна уметь приспосабливаться быстро, эффективно справляться с такого рода проблемами, несмотря на постоянно меняющиеся условия.
Пример. Очень типичная проблема.
Мы все доделали! А что еще осталось? Пофиксить баги, задеплоить… Не знаю, бывает ли у вас так, но это очень распространенная проблема.
Как с этой проблемой справляться? Возвращаемся к Agile. Иначе говоря, даже если вы работаете по Agile или по иному продукту, вы работаете, работаете, работаете, потом закончили, но еще кучу всего не доделали. Как Agile с этим справляется? Одна из вещей, которая существует в Agile, называется Definition of Done. Это критерий готовности, некоторая определенная договоренность внутри вашей компании, команды, что означает, что задача доделана до конца. Пример Definition of Done:
Есть специально обученный человек скоромастер, который помогает команде следить за тем, чтобы это было сделано. Как эта штука делается? Собираетесь командой и вашим project-менеджером, садитесь и вместе это делаете, пишете. И потом следите за тем, чтобы это выполнялось.
Уже наличие таких договоренностей вам сильно помогает, потому что у вас есть возможность, прийти к человеку, который чего-то не делает, и сказать: «Юра, почему ты этого не сделал? Мы же договаривались». Юра говорит: «Ну, постараюсь, да-да». В общем, есть возможность давить на совесть, скажем так.
Эти штуки стараются писать в не сильно большом количестве, т.е. ровно о том, с чем есть проблема. Например, «код закоммитчен». Это не надо писать, это понятно, что он будет закоммитчен. Т.е. ключевые вещи пишутся.
Есть еще одна интересная вещь, которую тоже наблюдаешь, когда такие вещи погружаются и проходят. Через какое-то время эти вещи начинают отмирать. С точки зрения человека, который внедряет Agile, выглядит так: «Ребята, я вам клевую штуку придумал, Definition of Done. Вы говорили, что она классная, почему вы перестали делать Definition of Done?». Все такие: «Да чего-то как-то не нужно уже». Это правда, эта штука начинает постепенно отмирать.
Цикл начинается с неосознанной некомпетенции — вы не знаете, что у вас есть проблема. Потом у вас осознанная некомпетентность — вы знаете, что у вас есть проблема. Потом вы ее решаете — осознанная компетентность. Вы знаете, как ее решать, у вас есть подход, вы им горите, вы о нем думаете, вы тратите на него безумное количество энергии, что бы это ни было. Ваш фокус внимания на этом. Через какое-то время вы научились. И эта штука уходит в неосознанную компетентность.
Возвращаясь к тому, какая команда является эффективной. Было понятно, у кого с чем проблемы, на что фокус внимания направлен. Кто-то говорит: «Мы никак не можем выпустить код — мы выпускаем, но заказчик ничем не доволен». Этот фокус внимания для вас является ключевым. И это у вас сейчас происходит в состоянии осознанной некомпетентности — кажется, что мы это не умеем.
Что получается после того, как вы научитесь? Например, вы научитесь деливерить. Вы умеете поставлять качественный результат в продакшн вовремя и прогнозируемо, несмотря на постоянно меняющиеся требования. Получается часто, что вы использовали безумное количество вещей, для того, чтобы научиться это делать — вы там в story point’ах оценивали, вы использовали какой-то story mapping, у вас какие-то разные подходы и т.д. Это как леса в строящемся доме. Вы их поставили, поставили, поставили, вы над этим думали, вы этим болели (Agile’ом менеджеры болеют в среднем три года). Когда научились, уже внимание на другие вещи переключается. Как только вы научитесь, это все надо убирать. Не надо держать это балластом. Просто заставлять людей, прибегать: «А чего это вы не делаете? А ну-ка делайте!». Если они деливерят, и заказчик ими доволен, убираем это все. Убираем все эти леса.
Есть такая штука — называется #NoEstimate подход. Это как раз об этом. Можно перестать оценивать, отказаться от оценки, если заказчик вами доволен. Есть подходы, принципы, которые позволяют от этого отказаться. Если вы при этом не умеете деливерить, конечно, этого не надо делать, речь идет только о тех, кто умеет, научился деливерить, можно перейти к этой фазе.
Для этого нужно непрерывно доставлять ценность заказчику, избавиться от внешних зависимостей, которые вас тормозят, из-за которых заказчик вами недоволен, и уравнять возможности и потребности. Ваши возможности с точки зрения результата, который вы деливерите заказчику, и потребности, которые есть у конечного заказчика, пользователя и т.д. Если это все равно, а те штуки равны, заказчик перестает к вам приходить с вопросом: «Когда?». Вы просто делаете то, что ему нужно в разумные для него сроки, вот и все.
Т.е. эти леса убираем, тогда другие штуки можно притащить в ваш фокус внимания, да они и сами всплывут. Это как ваш кружок сейчас, вы об этом думаете: «Как бы нам заделиверить?», через какое-то время ваш кружок постепенно увеличивается и выясняется, что проблем намного больше. Но выглядит, если поговорить с такими людьми, один в продакшн никак не выйдет, другие думают о стратегии продвижения на рынок… Я про команды говорю. Это, знаете, у кого-то суп жидкий, а у кого-то жемчуг мелкий — такого рода разговоры идут. Т.е. да, у нас много проблем, выглядит так, будто их больше, но уровень крутости этих проблем намного выше. И такая команда намного более эффективна.
Но с точки зрения стороннего наблюдателя, такого как я, такого менеджера, который внедряет Agile и следит за тем, чтобы внутри команды могли деливерить, крутая команда и некрутая команда выглядят одинаково. Вне зависимости от наличия каких-то практик, используют ли они те же самые velocity, они выглядят одинаково. Но одна деливерит, другая — нет.
Что тут важно? Важно избегать такой штуки как карго культ.
Идея карго культа такая. Во время Второй Мировой Войны, когда Америка боролась с Японией, они строили аэродромы на островах в Тихом Океане, чтобы иметь возможность маневрировать своими силами. Строили аэродромы, прилетали самолеты, сбрасывали одежду, еду и т.д. Иногда они промахивались мимо аэродромов, и аборигены были счастливы, потому что выглядело это так — как только появлялся аэродром на острове, с неба начинает падать еда. Прямая понятная связь. И они начали строить аэродромы, примерно такие, как на слайде. После того, как Вторая Мировая Война кончилась, они продолжили строить «аэродромы», это превратилось в религию. Они начинают в это верить.
Так вот, когда приходят люди со стороны менеджеров и говорят: «Ребята, вы не деливерите, нате вам такую практику», то иногда это превращается в карго культ. Временами это действительно работает, но у команды нет заработанности результата. Например, вы запустили Definition of Done в первый день, как только начали работать с командой, а она еще не натолкнулась на проблему, которая была в виде комикса, просто еще не встретила эту проблему, понимаете? Но вы запустили Definition of Done — вроде, эта штука работает… Отказаться от этих лесов бывает достаточно тяжело — вроде как, они приносят пользу, давайте все это делать. От всего можно отказаться, это и есть гибкость.
Какую проблему решает команда А? Sprint, Velocity, Story Points. Мы видим, она не деливерит, не поставляет, поэтому т.к. это здорово, и она фокусируется на этом. Чем занимается команда B пока не понятно.
Какие существуют зоны роста? Куда можно нам развиваться?
В принципе:
- поставка,
- качество с точки зрения technical exams, не просто качество с точки зрения тестирования, а технического качества, как результата,
- и продукт — делаем ли мы то, что нужно конечному пользователю?
В каждом из этих направлений можно развиваться.
И каждый раз один единственный дракон, с которым мы боремся. Поэтому дефокусировать такую команду, возвращая их на предыдущие завоеванные позиции, бессмысленно.
Как правило, первый ваш дракон — поставка. Если вы не деливерите, непредсказуемо деливерите для заказчика, этим приходится заниматься в первую очередь, потому что качественная поставка означает дисциплину внутри команды, способность команды деливерить, в том числе технические задачи, которые нужны на следующем уровне для обеспечения качества.
Следующее. Качество, продукт. Я так условно в лесенку их расположил, они, конечно, с большим перехлестом находятся. Но если, например, поставка не обеспечена, то говорить о том, что мы можем сфокусироваться на том, чтобы команда могла делать качественный продукт, не получается. Например, параллельные стартап вещи. В течение двух месяцев вы должны заделиверить фичу, чтобы мочь экспериментировать. Или трех недель — зависит от того, какой у вас бизнес. А если вы не поставляете? Если непредсказуемо поставляете? Выглядит это как постоянный конфликт между product-менеджерами команды, и менеджер приходит и говорит: «Ну, где?». Вы говорите: «Знаете, требования у вас говно, если честно». А он говорит: «Какая разница, если вы все равно не поставляете?». Вы виноваты в этой ситуации. Какие бы плохие требования он вам не предоставил, виноваты вы, согласны? Все равно, вы сделали слишком долго. Может быть, требования успели поменяться за это время? Нужно поставлять быстрее, чем требования успевают поменяться. Тогда можно двигаться в эту сторону.
Итак, мы возвращаемся к теме — что означает Agile на практике?
Есть цикл Деминга, он слева, не перепутайте. Plan, do, check, act. А справа — это то самое «как получится», просто побежали. И в принципе, граница между ними, с моей точки зрения, отличает Agile-команду от не Agile-команды. Если мы просто фигачим в запарке, и все плохо — это не очень Agile, а такой способ более структурирован, такой способ быстрее приводит к более эффективному результату. Plan, do, check, act.
Plan — cпланировали. И batching (я не смог подобрать нужного слова) — мы делаем маленький план. Если мы говорим про Scrum, это две недели вперед. Если мы говорим про какие-то технические улучшения, тоже очень короткие сроки. Если мы говорим про lean startup, там тоже очень короткие сроки — дни, может быть.
Do — мы это делаем. Здесь важна дисциплина, мы добиваемся результата. Мы не просто фигачим, чтобы если потом не получилось, то переносим следующий sprint. Давайте определим, что готовы сделать, пусть это будет меньше, но до конца. Маленький скоп, доделанный до конца.
Check — обратная связь и метрики тоже очень важны. Мне кажется, это, как раз, отличает эффективную гибкую команду. Потому что в предыдущем случае — вы так работаете, у вас не всегда есть обратная связь, так можно бесконечно крутиться в цикле, никаких реально достижимых результатов у вас не будет.
Эксперимент — надо пробовать новые вещи, просто делать их в виде эксперимента. И этот короткий цикл улучшений постоянно крутить. Постоянно пробуем какие-то улучшения.
Так выглядит типичный Scrum: Backlog, Sprint, работа в классическом Scrum'е 30 дней. Получается примерно такой же цикл.
Sprint, если говорить про sprint планирование, доска задач, стендапы, Definition of Done обеспечивает дисциплину, мы проводим демо для обратной связи в Scrum, у нас есть velocity/cycle time для того, чтобы померить, насколько мы эффективны.
Итак, мы можем провести эксперименты и посмотреть, приводят ли они к нужному результату или нет. Вы можете попробовать парное программирование, и посмотреть приносит оно пользу вам или нет. Это одиозный пример, есть много таких примеров, вещей, которые можем попробовать, посмотреть, даст ли улучшения нашей производительности, просто выбрав себе какие-то метрики, на которые мы можем смотреть.
Это Scrum, это деливери. Если мы не умеем деливерить, Scrum — это один из способов, второй из распространенных — Kanban, которые обеспечивают вам постоянный цикл улучшений.
Про техническую часть — Red, Green, Refactor, если говорить про Test Driven Development.
Если говорить про Agile, про все эти принципы, короткие циклы, то следующий вопрос. Допустим, вы пересматриваете архитектуру вашего продукта. У вас есть тяжелый, запутанный кусок кода внутри (спагетти-код называется), и вы хотите его редизайнить. С чего вы начнете? Это большой цикл, это не Agile, как нам сделать маленький цикл? Как нам что-то маленькое сделать, чтобы проверить, работает или нет, и выбрать себе какую-то понятную, разумную метрику, на которую мы можем ориентироваться? Оставляю это вам в качестве домашнего задания, можем потом отдельно обсудить.
Поставка. Что у нас получается? Навыки, которые мы хотим воспитать.
В принципе, с моей точки зрения, ключевой навык — умение декомпозировать на небольшие пользовательские истории, которые инкрементально улучшают ваш продукт. С этим огромная проблема в индустрии, с этим постоянно приходится сталкиваться. В вас фигачат ТЗ, вы делаете по ТЗ. Насколько это инкрементальный подход? Ни фига не инкрементальный. Вы потом говорите: «Блин, заказчик козел, он нами не доволен. Хотя мы сделали все точно по ТЗ». Подход был не инкрементальный, в инкрементальном подходе мы разделяемся на пользовательский story, делаем в первую очередь работающий прототип, который постоянно у нас улучшается. Так проиграть невозможно.
Умение заканчивать их быстро и совместно и до конца — это второй навык, которому мы должны научиться. У нас существуют метрики, которые показывают, насколько эффективно мы работаем — cycle, velocity и другие, и всякие инструменты типа User Story, Story Mapping, Estimation, Definition of Done и т.д.
Lean Startup выглядит точно так же. Это идея, продукт, мы получаем данные, цикл learn, build, measure.
У вас есть какой-то продукт для конечных пользователей, например, веб-сайт, у вас есть welcome-сценарий с плохой конверсией, вы хотите конверсию улучшить. Welcome-сценарий переписать. Вы нашли лучших юзебилистов, они вам говорят: «Юра, это займет три месяца». Команда тебе говорит: «Юра, это три месяца». Юра говорит: «Нет, это очень важно, давайте делать. Ну, реально, там срочный welcome-сценарий, все переписываем». Они его три месяца переписывают, вы деплоите это в продакшн, и конверсия падает. Что делать? Lean startup означает, что мы выпускаем Minimum Viable Product, маленькие улучшения, которые инкрементально позволяют вам протестировать, правильно ли вы понимаете, что происходит в башке у вашего конечного пользователя. И прямо посмотреть на ту же самую конверсию просто в real time. Вы выпустили фичу, посмотрели на конверсию, посмотрели, как она влияет на разные типы, когорты пользователей и т.д. Т.е. можно такой цикл постоянно крутить, если вы понимаете, что происходит в голове у вашего пользователя, при этом у вас есть обратная связь, у вас в голове появляется модель вашего пользователя, эмпатия с ним возникает. Проиграть так невозможно.
Если фича вам не нравится, вы тут же ее убиваете. Это тот же самый Agile цикл внутри продукта. Как только у нас нормально отстроенный деливери, мы можем переключиться сюда. Мы можем начать работать по такому циклу, это следующий наш фокус. Научились деливерить, учимся выпускать классный продукт.
Умение чувствовать эмпатию с пользователем, умение получать обратную связь от рынка.
Опять-таки, циклы эти должны быть очень коротенькими. В Lean Startup это несколько дней, это даже не Scrum’овские две недели. Всякие метрики существуют. И инструменты Customer Development, Lean Startup, Design Thinking.
Качество — это умение поставлять без багов, качественный код, автоматизировать рутинную работу. Это достаточно очевидные и понятные вещи. Опять-таки, пробуем это делать маленькими кусочками. Возвращаясь к тому же рефакторингу, вы не можете остановить бизнес-девелопмент, пока вы рефакторите этот кусок, хотя очень хотелось бы. Ключевая особенность такого рода реиндженирингов, можем ли мы работать маленькими кусочками, это означает, что ваш продукт Open Running. Вы пишете новый кусочек компонента и постепенно переключаете на него функционал до тех пор, пока все не перепишете. У вас может одновременно работать несколько дублирующих функционалов. Пока все у вас не будет доделано.
Метрики, которые нас интересуют. Обычно это стоимость транзакций, выкладки, если говорить про улучшения time to market, это обычно, сколько времени вам нужно, чтобы фичу выдать в продакшн, если у вас есть большой объем автоматизации или ручной автоматизации. Стоимость такой транзакции не так сложно просчитать, грубо говоря, сколько человеко-дней вы тратите на полное регрессионное тестирование вашего продукта, и количество дефектов в продакшне, которое у вас возникает. Сбалансированные вещи в том смысле, что вы можете просто зафигачить в продакшн «как получится», не тестировать вообще, у вас будет много продакшн дефектов, и наоборот.
Test Automation, Continuous Integration и Continuous Delivery, DevOps — это отдельная тема. Там идея такая, что вы можете выпустить все в продакшн, не тестируя, и проверяя на конечных пользователях. Если ваши метрики падают, с помощью мониторинга можете дать обратную связь. Но это тоже очень коротенький цикл, можно коротенькие циклы гонять очень быстро.
Контакты
» askhat@scrumtrek.ru
» Facebook
» Twitter
» Zibsun
» Блог компании Scrumtrek
Этот доклад — расшифровка одного из лучших выступлений на конференции по управлению и предпринимательству Whalerider.
Мы уже начали подготовку к 2017 году, кстати :)Дополнительные материалы прошлых лет Вы можете получить, подписавшись на список рассылки конференции WhaleRider.
Асхат Уразбаев представляет компанию ScrumTrek, которая организует самые популярные конференции по agile — AgileDays
Автор:
