Как рождается идея перехода к эджайлу
Обычно в компании появляется идеолог, который заражает всех эджайл-вирусом, рассказывая про ценности работы в команде. Всё будет просто и быстро, результат поразит воображение, деньги так и польются в наши карманы, а все сотрудники будут счастливы валяться на пуфиках с кружкой кофе в руке и нескончаемой миской с печеньками, обещает он.
Чтобы закрепить мысли об эджайле, приглашают экспертов, которые прогнозируют пару-тройку сотен дней работы над продуктом, и, как следствие, «протухание» продукта, его кончину. А следом, возможно, и кончину компании. В пример приводят HTC и Blackberry. Как не повторить их судьбу? Консультанты предлагают рецепт, которым воспользовались такие гиганты как Google, Amazon, Apple, — а именно гибкий эджайл.
Что обычно происходит при трансформации
И вот вы узнали все необходимые словечки и фразочки, чтобы иметь право носить гордое имя PMI Agile Certified Practitioner: «стендап, груминг, демо, команда, доска, стикеры, шли все лесом со своими согласованиями». Вы профессионалы своего дела, знаете, что и как работает, знаете все новые необходимые понятия, мероприятия и процессы. Осталось провести agile-трансформацию. Приведем список типичных ошибок.
- Были отделы разработки, а сделали эджайл-команды.
- Бесконечную очередь задач по запросам на изменение в Jira легким движением руки превратили в бэклог из RFC.
- Если раньше на задачу централизованно выделялись ресурсы, то сейчас сделали распределение задач на разработчиков.
- «Чем будет заниматься у нас этот разработчик? А давайте возьмем в бэклог вот эту задачу, он сможет ей заняться»
- Вы поставили цель уйти от оценки задач в один месяц работы. В ответ разработчик говорит: «Окей, начнем делать в этом спринте, а в следующем закончим».
- Задача не согласована со службой безопасности и юристами? Давайте введем нормативные каникулы и проигнорируем этот момент.
- Задачи распределяет начальник? Тогда сделаем эджайл, плоскую структуру, но «я все равно буду начальник».
Что получаем в итоге?
Структура не изменилась. Начальники ставят задачи подчиненным. У людей взрыв мозга, много руководителей, эти руководители параллельно ставят разные задачи с прибитыми сроками. Задачи стали просто измерять спринтами, а не месяцами.
Что делать — непонятно, как делать — непонятно. Документации нет! Вся команда все время сидит на совещаниях, куда приходят старые прожженные технологи и программисты. Они смотрят на сотрудников в команде словно пришли в зоопарк понаблюдать за поведением гиббонов в стае.
Скрам-мастер рассказывает про Definition of Ready и Definition of Done. Все же понимают, что это важно и нужно, почему же разработчики сопротивляются?
В этот момент как назло прилетает важная задача с прибитыми сроками от руководства, и молодой, еще некрепко стоящий на ногах эджайл погибает под натиском врагов и зомби.
А как надо?
Нельзя слепо следовать шаблонам успешных компаний. Здесь проще пояснить через аналогию — например, через футбол. Представьте, что вы тренер, ваша команда проигрывает, пять минут до конца матча. Есть пример безупречного плана, которым пользуется известный тренер Эрнесто Вальверде. Согласно ему, нападающий Луис Альберто Суарес врывается в штрафную, его сносят, судья назначает пенальти. К мячу подходит Лионель Месси и пробивает точно в дальний от вратаря верхний угол. Безупречный план. Но вы не Вальверде, и у вас в команде нет Суареса и Месси. Все. Вы проиграли.
Кроме того, мы начинаем цепляться за процессы, забывая, зачем мы их внедряем в своей работе. Поэтому я бы советовал сформулировать цель и повесить ее на видном месте. Как ставить цели, вы все знаете. Цель должна быть конкретной, измеримой, достижимой, значимой и со сроками. Что все это значит на практике?
На практике это значит, что самый главный во всем этом процессе — Клиент. Поэтому обязательно потратьте время и разберитесь, кто ваш реальный клиент, кто приносит вам деньги. Опишите его персону. Не во всех компаниях ответ на этот вопрос очевиден.
Для клиента вы делаете Продукт, причем такой, чтобы после его использования клиент остался счастлив. Продукт должен быть:
- полезным, то есть решать существенную проблему клиента;
- качественным, то есть соответствовать ожиданиям клиента или превосходить их;
- сделан и предложен вовремя, а не через год.
Продукт в свою очередь создает Команда. На самом деле Продукт и Команда тесно связаны. Как говорила команда утопленников на затонувшем корабле в «Пиратах Карибского моря»: «Часть команды — часть корабля». Хороший продукт без хорошей команды существовать не может, равно как и наоборот. И это главная причина, по которой разваливаются большинство попыток эджайл-трансформации. Чтобы этой ситуации избежать, мы в Промсвязьбанке начали запуск каждой команды с выбора продуктового направления и владельца продукта.
О том, каким должен быть владелец продукта, уже много сказано и написано. Все это правда, основная сложность — это найти нужного вам человека. Вот что делает владелец продукта:
- ставит цель;
- описывает верхнеуровневый бэклог;
- продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели; в том числе не забываем про счастливого клиента;
- рассчитывает, как задачи из бэклога влияют на KPI.
Владелец продукта — это не тот человек, который умеет эффективно транслировать приоритеты чужих хотелок, а тот человек, который сам хочет. Он хочет сделать лучший продукт для клиента, сделать таким, каким он его видит каждый будущий день.
Команда разработки — это ответственные люди, которые могут самостоятельно и независимо разрабатывать продукт. В команде должны быть все компетенции, которые необходимы для достижения результата. Внешними зависимостями нужно не управлять, от них нужно избавляться включением или обучением нужных людей в команде. Однозначно не нужно делать команду с избыточными ролями. Чтобы договориться, команда должна быть как можно меньше размером. Мысленно уберите роль из команды, станет ли без нее хуже?
Самый лучший вопрос команде на старте: «У вас всех хватает, чтобы достигнуть цели?» А самая эффективная практика формирования состава участников — это самодизайн, когда сами сотрудники определяют, кому и с кем работать. Мы попробовали так сделать уже на старте — когда предложили самим сделать ротацию, то получилось хорошо.
Теперь, когда команда есть, она должна стремиться к тому, чтобы в конце спринта был прирост «добра» продукта с понятным бизнес-профитом.
Хорошая аллегория командной работы в Скрам — это соревнование на драгонботах. Барабанщик задает темп для синхронизации коллективной гребли, а в начале лодки есть рулевой, который задает направление. У нас владелец-продукта управляет видением бизнес-направления, а скрам-мастер помогает команде держать нужный темп для синхронной работы по всем фронтам. Барабан – это скрам-доска, общее место встречи для событий команды.
Основная ошибка здесь — это попытка назначить скрам-мастера или даже совместить в одном человеке несколько ролей. Возможно, в зрелых командах это получится, но это точно не ваш случай. И даже в зрелых командах никогда владелец продукта не может быть одновременно и скрам-мастером. Вы должны найти скрам-мастера, а не назначить кого-то из попавшихся под руку людей. Такой человек поможет команде становиться более сплоченной и эффективной от спринта к спринту.
Для развития инженерных практик нужно создавать не отдел, который будет навязывать правильные вещи вроде unit-тестов, а сообщество из заинтересованных в этом разработчиков. Если подобные инициативы будут рождены снизу, то их поддержат на всех уровнях.
Работа команды должна быть прозрачна для всех заинтересованных лиц. Это и обязанность команды, и ее существенное преимущество. Процесс своей работы команда выстраивает самостоятельно, а все вопросы, которые могут возникнуть, будут решены также самостоятельно в процессе ее взросления.
И последний совет: используйте простые инструменты. Любые поля и процессы в Jira легко заменяет физическая доска с набором магнитов.
К чему мы пришли?
У нас регулярно появляются новые продуктовые команды. В них не обсуждают эджайл, а делают новую функциональность. Благодаря людям в командах создаются продукты, которые полезны и удобны клиентам, а банку — выгодны.
Комментарии (30)
velvetcat
10.12.2018 21:55А откуда в банке такие крутые, сознательные, узкие и в то же время все умеющие специалисты, и уже готовые к любым изменениям проекты?
Похоже на очередную фантазию.
KTG
11.12.2018 04:47Скорей откуда в банке столько денег, что бы без согласования юристов, безопасников и руководства внедрять разного рода решения, собранных на скорую руку, без утвержденного ТЗ, а со слов какого-то менеджера Васи, который завтра перейдет к конкурентам?
На мой взгляд все эти манифесты, новые подходы — лишь попытка добавить себе грамм конкурентоспособности, но по факту пыль.
Я не просто программист, я аджаил-программист. Я не просто ИТшник, у меня все по Итил.
Задачи же в JIRA, а не на словах (в аджаил ж главное не инструмент, а хотелки и общение) хорошо показывает как тратятся ресурсы и насколько адекватны те кто ставит задачи. Особенно если менеджер прибегает к программисту в десятый раз с правками. Хотел слона — ему сделали слона, но оказалось что слон то и не нужен, а нужна собака, Потом нужна собака которая мяукает, но это ладно, тут просто «вывод» перепишем, но потом как к собаке приделать голову жирафа? И тут приходит начальник и спрашивает, а где же десяток котят, которых ты должен был предоставить еще вчера? Разводишь руками — тычешь в заявку от менеджера с приоритетом и установленными сроками. Но уже поздно… ни собаки с головой жирафа, ни котят. А где был начальник который должен был правильно распределять ресурсы? Поэтому он втык и получит, если до такого дойдет.
В свою очередь с этим же аджайлом сидел бы он рядом и так же в пене вJOBывал непонятно над чем, и не знал бы кто чего сделать должен и когда.
Потом бы они вместе руководству доказывали что менеджер только с 10-го раза понял чего хочет, и то только когда коллективными силами догадались о его хотелках и ему всё разжевали. Ну а менеджер он же эффективный, это вы ни черта не можете понять с первого раза четко поставленную задачу. А на словах окажется что задачу он поставил еще пол года назад и да же половину кода за вас написал. Ну если не кода, то точно всю логику вплоть до мелочей.
kpi это вообще отдельная история — измерить силу мысли в попугаях, главное что бы вышло не меньше чем три обхода сторожа по территории за смену.
И самое интересное… возврат к доске с магнитиками оказалось эффективней тикет-систем?
Это как вернуться к паровым двигателям и говорить что КПД у них выше.ggo
11.12.2018 09:50Трекер задач — это просто инструмент, не самоцель.
Если нет проблемы выяснения, сколько ресурсов тратится и куда, то и традиционный трекер задач не нужен. Трекеру задач остается только закрыть вопросы координации нескольких команд и взаимозависимости задач.
Аналогично про любой другой инструмент. Используем те инструменты, которые помогают достигать наши цели. Используем инструменты так, как это помогает достижению наших целей.
shumakov_pro Автор
11.12.2018 09:50Юристов и безопасников мы включаем и вовлекаем в нашу работу. Если их игнорировать, то это ошибка указанная в статье.
Эффективен тот инструмент, которым хотят пользоваться, а не тот который навязан для контроля. Чем проще, тем лучше, доска это же всего лишь инструмент.
Cobolorum
11.12.2018 08:14Лучше расскажите нам как Вы «гибкой методологией» а не водопадом внедряли для примера новые бизнес фичи от VISA, а еще лучше требования или отчеты ЦБ РФ? Как вам удалось внедрить ЕСИА и ЕБС?
Наверное написали письмо в ЦБ что мол сроки не важны, и что регламенты не нужны?shumakov_pro Автор
11.12.2018 09:34Работа в командах сроки только сокращает, так как ликвидируются очереди и следовательно время ожидания при передаче между функциональными отделами. Поэтому если надо что то сделать срочно по приоретету от ЦБ, то просто берём и делаем. Так как всё равно в каскаде получится дольше разрабатывать.
KTG
11.12.2018 15:58Тут еще одна загадка.
Чем отличается отдел от команды? Как вы сократили очереди и время ожидания?
Если нужно сделать 10 задач/заявок/фич, а в одно время можно заниматься только 1, то как ты не рви пятую точку, как ты этот процесс не назови, общее время на разработку от этого не изменится.
Помню еще в школе говорили: от перемены мест слагаемых — сумма не меняется.
Чем приоритетные задачи в аджайл отличаются от не-аджайл?
Или вы имеете ввиду под каскадом выполнение задач строго по порядку поступления?
А вот еще.
Пришла вам приоритетная задача: Купить тигра.
А вы только начали клетку строить.
По аджайлу это как? Купить тигра, а потом клетку строить или построить клетку из табуреток и надеяться что не развалиться?
Так оно дороже выйдет, если тигр загрызет кого, пока вы клетку достраиваете.
Или все же надо сначала сварить нормальную клетку?
Как ни крути, а в таком аспекте аджайл выглядит как: «бежать впереди паровоза». Оно конечно можно, но не долго.ggo
11.12.2018 19:17Да, тигр и клетка плохо агилизируются ;)
Что это означает? То что не все может успешно агилизироваться.
А что может быть успешно агилизировано?
Ну например, у вас есть пиццерия.
Тут вам пришла идея, что можно принимать заказы через телеграм, и повысить свои продажи.
Как это реализовать?
Можно детально продумать все технические нюансы, сразу заточиться на 24х7, highload, кучу фишек и плюшек, и потом разом создать все это. И через некоторое время запустить прием заказов через телеграм.
А можно вначале посадить девочку с телефоном и поручить девочке переносить заказы из телефона на доску заказов руками. Потом автоматизировать самую рутинную операцию. Потом, ту где больше всего возникает ошибок. И т.д. постепенно реализовывать тот функционал, в котором больше всего необходимость на момент реализации.
Какой способ лучше?
Успешен может быть любой.
Есть только один нюанс. Бизнес, часто, слабо прогнозируем. Что реально будет болеть, предсказать не всегда можно. Что реально взлетит, аналогично. Что делать в условиях неопределенности? Не планировать детально на далекую перспективу. Много пробовать. Часто оценивать полученные результаты. С учетом этого корректировать планы.
Это и есть agile.
ggo
11.12.2018 10:14Agile не отвечает на вопросы реализовывать ли очередные требования VISA или регуляторов, и как реализовывать. Также как не отвечает на вопросы: нужны ли тесты, и как их внедрять, нужны ли контейнеры, и как их внедрять, нужны ли поездки на конференции и какие конференции, нужен ли root в production девелоперам и для чего, и прочее, прочее, прочее.
Agile в общем случае это способ организации бизнеса. И этот способ не единственный.
Владелец продукта, как лицо отвечающее за продукт, в том числе за риски, связанные с работой продукта, принимает решение, а нужно ли реализовывать нововведение от VISA. А что эта фича даст для его продукта? Если ничего, то что будет если не реализовывать эту фичу? Допустим штраф. А каков размер этого штрафа? Допустим 5000 евро в год. А сколько усилий нужно на реализацию фичи? Допустим 20 человеко-недель, плюс потери от задержки фич, которые реально улучшили бы его продукт. И Владелец продукта принимает здравое решение нововведение от VISA забросить в беклог до следующего года.
Аналогично по другим пунктам.
Новые требования от ЦБ, риски — отзыв лицензии, срок — через 2 квартала, какой профит для продукта — никакого, возможное решение — реализовываем требования ровно так чтобы пройти соответствие новым требованиям. (пройти соответствие != соответствовать)
В обоих случаях — принятие решения никак не связано с тем agile у нас или waterfall.
Просто здравый подход, и правильные приоритеты.
Отличие agile в том, что во главу угла ставятся приоритеты продукта, и его развития. И вся команда буквально пропитывается идеей развития продукта. Никаких целей типа — строим классную ИТ-архитектуру, пишем супер код, и т.д. (это не отменяет того, что архитектура должная быть хорошей, код хорошим — тем не менее, все это инструменты, не цель)
camelos
11.12.2018 08:36продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели; в том числе не забываем про счастливого клиента;
KPI
Отвечу цитатой из своего канала (https://t.me/leonid_lapidus/60):
Железобетонное правило: если ваш руководитель ставит вам KPI, значит он мудак.
Замечательный «Фитиль» про нормы выпуска продукции: youtu.be/gNWyKf--jVE?t=143
Поделитесь этим постом с теми, у кого есть KPI.shumakov_pro Автор
11.12.2018 09:23Вы прочитали, то что я не писал. KPI ставится на продуктовую группу для достижения целей и стратегии бизнеса. Подумывает KPI сам владелец продукта. Я ничего не писал про неоптимальный индивидуальный KPI, навязанный сверху.
camelos
11.12.2018 10:22Окей, переформулирую.
Если кто-то ставит KPI (человеку, команде, проекту, продукту), то он мудак.ggo
11.12.2018 10:30Хорошо, чем плох KPI?
— привлечь по продукту Х новых клиентов в размере Z.
— по продукту Х из числа существующих клиентов через год должны остаться активными не менее Y%.
У тех кто отвечает за KPI есть свой бюджет, свои ресурсы, что и как делать, решают сами.camelos
11.12.2018 10:37Дело в том, что привлечь Z клиентов в продукт — не проблема. Более того, это даже не цель компании. KPI по определению (см. например, определение в википедии) не учитывает ценность и цель компании.
Допустим, вы поставили маркетологам задачу: привлечь N клиентов. Они привлекут. Каждого за $1000. Клиенты зарегаются, что-то подулают в продукте. Но главный вопрос — а что дальше? Зачем нам нужны были эти клиенты.
Можно начать жонглировать понятиями — ну мы же помнимаем, что нам нужны клиенты, чтобы принести в компанию прибыль, давайте это вошьём в KPI: «привести N клиентов, за $1 за каждого, каждый принесёт по $20 в первые полгода использования продукта». И что дальше? Зачем нам эти клиенты? Какая у нас цель и ценность? Как исполнение этого KPI связано с целью компании? Никак.
Поэтому, тот кто полагается на KPI — поступает крайне неразумно.ggo
11.12.2018 10:48Есть бюджет. Нет печатного станка для банкнот. Привлекать по 1000$ долго не получится. И цель не у маркетологов, а у всех кто причастен к продукту Х.
И да, хороший KPI связан с общими целями конторы, вы правы.
И допустим в данной конторе, цель увеличить клиентскую базу и не сильно растерять существующую.camelos
11.12.2018 10:50Не могу согласиться, что цель может быть такой: «увеличить клиентскую базу и не сильно растерять существующую». Это скорее возможное решение некой задачи.
zam0th
11.12.2018 15:17Человек цитирующий сам себя тоже не светоч virtue. Что впрочем не отменяет того факта, что много лет назад подход к мотивации через KPI действительно был признан провалом в управлении. Что в свою очередь не отменяет того факта, что burndown — это самый настоящий KPI.
shumakov_pro Автор
11.12.2018 17:39Согласен. Погоня за метриками и показателями как самоцелью полностью убивает этот инструмент. KPI может работать только, если это простой индикатор для достижения настоящих целей. Приведу пример аллегорию. KPI подобен термометру в комнате, который можно использовать для достижения комфортной температуры. Если целью станут показания термометра, то его можно локально нагреть, но самому при этом в комнате замёрзнуть. Получается что всё дело не в термометре, а в том что считаем целью.
zam0th
12.12.2018 00:11А слона-то мы и не заметили. Planning poker и управление burndown — основные инструменты scrum, коий является единственной применимой в IT реализацией agile (ибо lsd, toc и прочий xp нигде и никем не используются ввиду своей излишней инновационности и/или ортодоксальности). Если ваши команды не используют ни то, ни другое, то я не очень понимаю, о каком реальном применении методологии вы рассказываете. Вы хоть scrum-колоду видели вживую?
ggo
12.12.2018 04:23burndown — очень плохой kpi.
хороший kpi — то что показывает насколько мы близки к нашей цели.
burndown — это тактика, типа а сколько мы пробежали. kpi — а в правильном ли направлении бежим.
alatushkin
11.12.2018 12:19Глубинные причины проблем, которые традиционно пытаются решать насаждением «эджайл» вовсе не в «богомерзком водопаде». (В конце концов и в rup никто не запрещает двигаться более короткими итерациями и корректировать план.) А причины, как правило, в «незрелости» людей в управлении (либо, что в управлении «времянщики»: любой ценой получить рост показателя, получить бонус и свалить -дальше хоть потоп).
И соответственно — какой «эджайл» ни внедряй — пока не заменить людей — результата (при аккуратном измерении) не будет. И обратно: если есть участки с осознным линейно-среднем менеджменте — там и без «коучей» — дело спорится и «ценность доставляется».
Вот был psb-батл — itшники пришли в одинаковых костюмах синего оттенка, белых рубашках, галстуках бордовых оттенков — вот он реальный показатель глубины «трансформации» ценностей.
Уже пол года экспериментируют с вендорными решениями в стремлении перейти к децентрализованным решениям. Пол года экспериментов в стол.
Зато наверно радар ценностей красивыйshumakov_pro Автор
11.12.2018 12:50RUP хорош, но это методология, которая всегда приходит сверху и поэтому её внедрение встречает сопротивление. Это одна из причин, почему RUP часто работает далеко от задуманного в реальной организации.
В Agile скорее говорят про правила и практики, которые рождаются в команде разработчиками.
teecat
11.12.2018 15:51+1Поскольку вы ориентированы на удовольствие клиента, то если не сложно — реализуйте 2 вещи:
— если ваш оператор позвонил один раз с предложением и ему сказали, что данное предложение не интересует — не повторять звонки с увеличением размера кредита
— если приставы по ошибке блокируют счет, не посылать клиента в экспедицию, в которой на стене написано, что претензии она принимать не будет
Спасибо
bromium
А вы вычитку перед публикацией делали?
Гибкий эджайл — это не масло ли масляное?
Про «продумывает KPI, по которым можно было бы постоянно отслеживать приближение к цели» — можно ли поподробнее. А то я по наивности думал, что выполнение спринтов, юзер сторей и позволяет отслеживать выполнение.
Про сберджайл слышал, а у вас какой-то промсвязьбанкэджайл — с kpi и… еще чем-то там.
И еще: у вас правда все такие ответственные, самостоятельные, самоорганизующиеся?
Можете не отвечать, это был риторический вопрос
shumakov_pro Автор
KPI на продуктовую группу — это оптимально для достижения целей и стратегии организации. KPI в этом смысле очень помогает PO.
bromium
Приведите примеры, пожалуйста, таких kpi
boblenin
Самый хороший KPI — это квартальные и годовые отчетности о прибыли. По ним хорошо смотреть как работает PO, так же как и смотреть за тем как работают разработчики.