Как правильно имитировать Agile?

Подобная статья должна была появиться раньше, лет десять или -надцать назад, когда Agile только начинал внедряться в компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, если бы менеджеры сразу подходили к вопросу правильно …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

Почему Agile?

На самом деле такой вопрос перед нами не стоит, и обсуждать его здесь я не собираюсь. Топы ли сказали 'надо', или 'рынок порешал', или лишь потому, что программисты – народ дефицитный, избаловались, и первым делом на собеседованиях спрашивают - "вы же по эджайлу работаете? нет?! фи-и...". Не вы выбирали этот путь, но вы в ответе за то, чтобы провести по нему вверенное вам подразделение. А я поделюсь приемами как вам это лучше сделать, не уменьшив по дороге свой годовой бюджет и ОШС (организационно-штатную структуру), но зато, воспользовавшись подвернувшейся возможностью, заработать репутационные баллы, увеличить свое влияние в компании и зарплату.

Почему имитация лучше внедрения?

Вот честно, зачем вам Agile? Для увеличения эффективности ваших команд разработки, что ли? Вы же не хотите сказать, что сейчас вы не эффективный менеджер, да? Воот.

Как нам постоянно твердят бизнес-коучи, правильное целеполагание - ключ к успеху. Поэтому признаемся сами себе (не публично, разумеется), что ваша истинная цель - это не "увеличение эффективности разработки", которое никому не нужно, а "внедрение Agile, которое позволит в дальнейшем …" и дальше подставить пресловутые "увеличить эффективность разработки", "быстрее реагировать на потребности рынка", "вписаться в современный мир", "внедрять инновационные решения", "добиваться потрясающих успехов" и т.п. Запишите, кстати, слова - пригодится для презентаций.

С другой стороны, нельзя просто так взять и сказать, что теперь у вас Agile. Надо приложить некоторые усилия, чтобы человек, непосредственно не вовлеченный в процесс, не смог понять, что Agile-ом у вас и не пахнет. Также очень неплохо, если ваши сотрудники тоже будут убеждены, что работают в Agile компании. Высший пилотаж - когда ваши сотрудники восхваляют ваше видение Agile в статьях на Хабре.

С чего начать?

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

На курсах дадут терминологию, расскажут, как составлять графики - их можно использовать для показа руководству.

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

На обучении вам скажут, что манифест Agile состоит из 4-х ценностей и 12-ти принципов. Оно-то так, конечно, но вам надо твердо знать, что в манифесте, помимо упомянутых, есть еще Основное правило для ценностей, которое говорит, что правая часть ценностей тоже очень важна. Вооружившись Основным правилом, посмотрим на ценности

Люди и взаимодействие важнее процессов и инструментов

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

Работающий продукт важнее исчерпывающей документации

Ценность хорошая, стоит признать, но надо правильно ее понимать. Помните Основное правило? Здесь не сказано, что не надо делать документацию. Наоборот, пока не будет документации, нельзя выпускать продукт. Что, не сходится? Ничего, я объясню.

Вот представьте - команда поднапряглась, быстро, в срок выдала работающий продукт, уникальный на рынке, с хорошим потенциалом прибыльности. Вы уже дырочку для новой звезды собираетесь проделать. И тут появляется клиент, недовольный тем, что не смог разобраться в вашем продукте, а документации нет. И, как назло, он хороший знакомый одного топ-менеджера - того самого, что больше любит кричать, чем слушать. Вот как вы будете объяснять топу, что "документацию пока не успели"? Оно вам надо, этот геморрой? Места, может, и не лишитесь, но репутация будет подмочена.

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

И нет, здесь нет нарушения ценности. Видите слово "исчерпывающей"? Никогда, я подчеркиваю, никогда документация не становится исчерпывающей. Всегда что-то сказано не ясно, не точно, можно понять иначе. Поэтому документация должна быть, и максимально подробная, просто она не будет считаться "исчерпывающей".

Сотрудничество с заказчиком важнее согласования условий контракта

Это даже смешно. Тот, кто это писал, видимо, никогда не закрывал акты выполненных работ по этапу проекта. А если еще заказчик - государство, то как ему объяснить, почему было сделано не то, что записано в условиях контракта?

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

Готовность к изменениям важнее следования первоначальному плану

Мое любимое на десерт. Ценность прямо говорит, что можно в команду разработки можно вкинуть новое пожелание в любой момент, команда такие вбросы любит и ценит. Особенно, если это пожелание высказано почти-топ-менеджером в приватной беседе, и не вам. Такие пожелания надо не забывать маркировать "срочно в номер!". Понятно, что команда готова к такому повороту не будет, поэтому надо усилить команду разработчиками из других команд. Временно, разумеется. Месяц-два, ну полгода соседи переживут без разработки. Пусть пока пользовательскую документацию к еще не созданному продукту пишут, это полезно для проработки требований.

Но зато, представляете, выпускаете продукт, а там это пожелание уже есть! Да, не полностью в таком виде, как ожидалось, сроки же ставились сжатые, да и с заказчиком общения не было, так как делалось практически подпольно, сюрпризом. Но ведь есть! Почти-топ-менеджеру приятно, а когда ему приятно, то, как говорил Фрунзик Мкртчян, и вам приятно. И можно в резюме вставить новое достижение, когда следующую работу будете искать.

Чуть не забыл сказать про вторую часть - ценность еще говорит, что первоначальный план существует только один день - в день его представления руководству. А дальше следить за ним не надо, актуализировать не надо, ресурсами управлять не надо - красота! Все-таки что-то полезное в этом Agile есть.

Приступаем

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

По Scrum-у (это один из вариантов Agile, вообще-то их много, но этот самый популярный, а значит его проще всего продать топ-менеджменту) команда должна быть небольшой, скажем, 7-9 человек. А у вас сейчас 25 человек в команде? Это слишком много, надо резать. Не бойтесь, я не собираюсь уменьшать вам количество подчиненных, совсем наоборот. Как говорил один известный эффективный менеджер, кадры решают всё, а я добавлю, что от их количества особенно зависит должность, зарплата и влияние руководителя.

Вопрос разделения команды не простой, поэтому используем золотое правило решения сложных вопросов - Делегируй Это! То есть надо найти того, кто это сделает квалифицированно, вместо вас. Можно выбрать из команды, но гораздо лучше наймите со стороны ваших будущих Владельцев Продуктов. Владельцы продуктов, сокращенно ВП (или по импортному Product Owner, PO) - это те, которые будут отвечать перед руководством (вами) за результат работы команды и все остальное (но кроме денег, конечно, деньги только ваши).

Для понимания - раньше были заказчики и руководители проектов, а теперь в Agile таких людей называют владельцами продуктов и скрам-мастерами, или ВП и SM. В принципе, всё то же самое, только как бы помельче. Если раньше заказчик был важной фигурой, у которого много денег, много больших проектов, и он выбирал фирму-подрядчика, кто будет делать его заказной интернет-магазин, то ВП - узкий специалист в бизнесе, его ответственность уровня "показать сумму товаров в корзине". Соответственно и спрос с такого человека меньше.

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

Скрам-мастера подбираются аналогично. Как и от ВП, от них не требуются глубокие технические знания, ведь их основная деятельность - следить за формальным порядком в команде. Чтобы тикеты открывались и закрывались своевременно, быстро переводить тикеты на другие команды вместо исправления, находить работу для членов команды, когда работы нет, согласовывать отпуска, вот такое всё. Поэтому на роль SM надо брать человека исполнительного, с ярко выраженными административными и командными качествами. То есть ручного.

Итак, вы набрали ВП и SM, дали им список людей, они разобрали специалистов себе по командам. Кому-то не хватило. Что надо сделать? Правильно, расширить ОШС и заполнить вакансии. Я же говорил, что в Agile у вас подчиненных станет больше. А если вы будете создавать команды по минимальному возможному количеству, то заметно больше, так что проявите воображение. И пора ставить вопрос перед руководством о переезде в более просторный офис.

В этом процессе ничего не может пойти не так - в Agile команды самоорганизующиеся, поэтому не беспокойтесь, если вы поделите их неправильно и они не смогут работать, они всё равно должны самоорганизоваться. А если и это не поможет - можно обвинить ВП или SM и быстренько его/их поменять.

Процесс разработки

Коучи расскажут (я их еще не раз упомяну), что в Scrum-е вся работа делается спринтами - двухнедельными, плюс-минус, циклами. Типа в начале спринта взяли объем работы, в конце спринта все доработки сделаны, внедрены и уже работают. И к этим задачам мы больше не возвращаемся, в следующем спринте будут новые задачи и новые внедрения.

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

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

Как должен быть устроен спринт? Это просто. Помимо собственно работы, в спринте должны быть обязательные ритуалы. Да-да, я сказал "ритуалы". Видимо, я забыл сказать, что Scrum - известная религия, и, как положено всякой порядочной религии, в ней есть свои святые, жрецы, заповеди и ритуалы. Вообще-то есть и другие конфессии Agile, но они маргинальные, кроме разве что одной, но это потом, пока не берите в голову. Главное, что нужно правильно понимать свое отношение к религии - верить не требуется, но правила и ритуалы обязательны.

Ритуалы в Scrum, еще их называют церемониями - это просто митинги, их в каждой команде нужно завести несколько:

• дэйли

• ретро

• грумминг

Ну и хватит пока, остальные факультативны.

Дэйли (он же скрам-митинг или просто скрам) - ежедневная утренняя встреча на 15 минут. Естественно, она за 15 минут не заканчивается почти никогда, растягивается минимум на час, так что, если вы решили прийти на дейли, ничего важного для себя не планируйте сразу после него.

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

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

В конце спринта проводится ретро - самая важная встреча в Scrum-е, как любят говорить коучи. Типа на ней команда совместно анализирует свою работу за спринт, делает выводы и принимает решения, как ее улучшить. Демократия, ага.

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

Еще не надо искать виноватых. Никто не виноват, что сроки сорваны, это проблема сроков.

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

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

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

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

Так, с ритуалами разобрались, приступим (та-дам!) к разработке. Поскольку Agile еще внедряется, а команды только образовались, то нужно определить чем, собственно, каждая команда собирается заниматься. Тут нам поможет ещё одна содружественная религия, известная как микросервисы, неофициальным девизом которой можно считать слова "мы старый мир разрушим до основанья, а затем...". Берем все нашу систему, которую в компании много лет разрабатывали, и режем её на столько частей, сколько у нас команд. Каждую часть называем микросервисом и Продуктом, и отдаем его очередной команде. То есть теперь эта команда отвечает за часть системы, а за всю никто не отвечает. Видите, как красиво? Не зря же Agile так популярен.

Команда получила свой кусочек работы и первым делом должна определить MVP. MVP - это первая версия продукта. Так просто, да. Хотя в команде найдется человек, такие всегда находятся, который не преминет уточнить, что это Минимально Жизнеспособный Продукт (Minimal Viable Product) и должен содержать только минимальные функции. Не спорьте с ним, формально он прав, но не учитывает жизненные реалии. А жизненные реалии таковы, что не существует второго первого впечатления у руководства, поэтому в первой версии продукта должны быть все самые лучшие и потенциально вау- и киллер-фичи, которые только можно придумать. Лучше задержать выпуск продукта на год, чем выпустить на рынок продукт, который не покажет ваши достоинства, как менеджера, перед руководством.

Особенно надо подчеркнуть, что в MVP не должно быть багов, по той же причине. Нулевая толерантность к багам в MVP! - вот ваш девиз. Сдвинутая на пиксель кнопка, "е" вместо "ё", или наоборот - и всё, у вас репутация временщика, гонящего халтуру вместо Продукта. Поэтому нельзя выпускать продукт без тщательнейшего всестороннего тестирования. Сроки важны, но ошибки недопустимы.

Впрочем, я отвлекся. Итак, MVP = первая версия. Что войдет в эту первую версию, как-нибудь само собой определится по ходу пьесы, а пока заведем стори (User Story) - это тикет в джире. Можно назвать его просто "MVP". Всё, теперь у команды есть задача, которой она будет заниматься все ближайшие спринты.

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

Что, маловато задач в спринте? Не вопрос, можно создавать задачи (но не стори) вроде "Подготовить доску в кабинете", "Переезд Васи на новое место", "Установить стенд", "Собрать сборку", "Развернуть pipeline развертывания сборки", "Ответить заказчику на письмо" и т.д. Можно каждый день создавать и закрывать задачи десятками. Чем больше задач, тем больше обоснований, почему первая версия еще не выпущена. Главное, чтобы исполнители не забывали закрывать задачи. Закрывать можно с любой резолюцией - "Отменена", "Передана на уточнение требований заказчику", "Создана другая задача", "Не соответствует". Если заказчик все же спросит, почему его задачу закрыли, то переоткрывать ее не стоит, лучше создать новую.

Когда первая версия вот-вот начнет разрабатываться, а к ней уже возникают вопросы, можно завести вторую стори, скажем "Расширение функциональности MVP" или "MVP 2.0" или еще как-то, и скидывать туда всё, чем команда сейчас не хочет заниматься. Тогда в любой момент, когда станет понятно, что сроки вывода первой версии окончательно сорваны, можно будет переключиться на вторую версию, а всем сказать "мы подумали и решили, что лучше будем разрабатывать целевую архитектуру продукта вместо легаси". И так далее, на третью, четвертую...

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

Траблшутинг

Процесс идет, но со временем могут возникнуть небольшие проблемы, поэтому стоит упомянуть некоторые известные приемы для их решения.

Не достигаются цели спринта

Коучи могли вам сказать, что у каждого спринта должна быть цель. Может они даже они упоминали, что цель спринта придумывается в ритуале Планирование Спринта (он же грумминг), а ее достижение потом проверяется в ритуале Ревью Спринта (почти как ретро). И может быть ваш неопытный владелец продукта (или это был скрам-мастер?) это запомнил и даже решил применять.

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

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

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

Второй способ чуть более радикальный, но тоже достаточно простой - перейти на Канбан. Я выше упоминал, что есть несколько конфессий Agile, так вот Kanban - это еще одна. Она гораздо, значительно проще Scrum-а - в ней весь процесс сводится к одной доске, на которой задачки идут по этапам. Доска расчерчена на колонки, каждая колонка - этап. Новая задача появляется слева, идет по колонкам слева направо, потом убирается с доски. Всё! Это весь процесс. Ни ритуалов, ни спринтов, ни целей. Двигаем задачи и радуемся Agile. Слава разработчикам Атлассиана, в джире переход со Scrum на Kanban делается легким мановением руки.

Но не рекомендую внедрять с самого начала Kanban вместо Scrum. Именно из-за его простоты продать топ-менеджменту в качестве современной, совершенной, блестящей методологии всего одну доску будет сложновато. Там и обучения всего на день, ну два, а не на месяц, и ритуалов практически нет. Лучше "внедрить" Scrum, потом тихонько переползти на Kanban. И то, и то Agile, так что подмены никто не заметит.

Жизнь по KPI

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

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

Если это не прокатило, и топ-менеджменту зачем-то нужна метрика, более приближенная к их бизнесу, они наверняка вспомнят показатель Time-To-Market, то бишь время от зарождения идеи до вывода на рынок. Это опасно, чисто механический расчет может привести к разочарованиям в вас, поэтому здесь нужен сработать аккуратно.

Правильная методика опирается на правильное определение начала работы и окончания. Например, если принять за начало работы сборку готового релиза, а за окончание работы - передачу на финальное тестирование, то можно добиться отличного результата.

Напротив, если за начало брать первую презентацию руководству, а за окончание - получение первых отзывов от клиентов, то результат расчета T2M будет не столь хорош. Думаю, вы уже поняли, что нужно делать - определять начало работы как можно позже, а окончание как можно раньше. И пусть весь мир подождет.

Полезное

Мини-справочник и руководство по Scrum - Полезно для расшифровки терминологии и для прямого использования, когда нужно ввернуть в разговор умный англоязычный термин. Не стоит использовать как практическое руководство для имитации Agile - для этого есть данная статья.

How to mimic Agile correctly? - то же самое на английском.