Оффтоп Alexandra Klimenko
989

​Кейс: Как дойти до скрама своим умом

Как небольшая компания делала agile-трансформацию без привлечения дополнительных бюджетов и коучей.

В закладки

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

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

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

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

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

Это что, я могу сам решить, сколько времени у меня займет задача? А дедлайна сверху, как раньше, правда не будет?

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

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

Дело пошло. Второй спринт уже планировали всего четыре часа и заранее. Начали проводить ретроспективы, обсуждать, что нам не хватает уже в новом процессе. Подняли дополнительный стенд для предварительной (до передачи в тест) интеграции фронта и бекенда, стали даже робко посматривать в сторону Test Driven Development.

А когда будет работать все, что я просил?

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

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

Этого не было в требованиях!

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

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

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

— А как ты думаешь было бы более правильно?

— Наверное, да, так как он есть при выводе на экран.

— Согласна, и давайте теперь всегда применять этот принцип.

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

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

Допилим на следующей неделе или в следующем году?

В предыдущем процессе разработки многие замечания по реализованному функционалу заносились в список доработок и оставались там очень надолго. Теперь команда старается учесть важный фидбек на сделанное как можно раньше. Мы стараемся балансировать между двумя крайностями: чтобы работа была сделана с учетом важных деталей с одной стороны, и чтобы новые требования, которые появились во время разработки, тестирования или демонстрации, не «раздували» изначальную задачу и выполнялись как отдельные улучшения. Для этого мы оставляем «доделочный буфер»: после того как фича целиком готова и доступна всем внутри в компании, еще 1-2 спринта мы оставляем время на внедрение небольших улучшений именно в нее, пусть даже это не самые важные запросы по приоритету.

Тут все еще куча непонятных слов. Кто-то понял, что такое velocity?

Сегодня мы все еще оцениваем задачи в человеко-часах и не можем уйти от довольно узкой специализации разработчиков. Каждый из них хорошо знает 1-2 модуля и плохо понимает что-то про остальные модули-программы. Несколько спринтов назад мы открыли для себя Burndown chart в джире и ужаснулись тому, как он у нас выглядит. Теперь работаем над внутренней культурой ведения задач в джире: вовремя открыть/закрыть спринт, вовремя занести в него задачи и списать время. Выделяем время на обсуждение новых фич «с высокой степенью неопределенности» на все более ранних этапах. Дизайнер начал разговаривать с разработчиками чуть ли не ежедневно и учитывать их замечания до финализации макетов. Каждый день у команды появляются новые идеи, как применить ту или иную практику скрама, так что нам приходится выбирать, что раньше внедрить и превратить в привычку, прежде чем двигаться дальше.

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

Этап 1. Перед началом работы по скраму

  • Перенести рабочие места команды по возможности рядом, в одну комнату или хотя бы часть офиса. Это необязательно, но очень удобно, когда вопрос можно задать вслух человеку, сидящему в метре от тебя, а не идти на другой этаж.
  • В самую середину посадить человека, представляющего бизнес-экспертизу и имеющего права принимать решения по продукту. Если этого права нет — стоит его сначала добиться, иначе любые вопросы команды могут потянуть за собой волокиту согласований. Этого человека (знакомьтесь: ваш Product Owner) еще желательно освободить от 70% текущих обязанностей на ближайшие 2-3 месяца.
  • Определить длительность спринта и назначить скрам-мастера. Лучше, чтоб это был человек, имеющий авторитет и внутри команды, и снаружи. Внутри он будет напоминать о приоритетах и дирижировать скрам-процессами, а снаружи должен иметь достаточно веса в компании, чтобы отогнать от членов команды их непосредственного начальника с «очень важным заданием». Например, у нас в эту роль прекрасно вписался проектный менеджер.
  • Собрать первую 4-часовую встречу по разбору беклога. Я называю эту встречу «крушение надежд». На ней команда слушает мои планы и задает мне вопросы по задачам, которые мне в голову не приходили, оставляя меня в глубокой задумчивости и согласии, что эту задачу в этот спринт не сделать.
  • Найти несколько задач, которые сделать кажется возможным всей команде. Взять одну из них и ;попросить рассказать будущих исполнителей, что и как он будет делать. В процессе рассказа родятся отдельные задачи, скрам-мастер только и будет успевать записывать и спрашивать волшебное «сколько же это займет времени?»
  • Также для задач очень помогает простой чек-лист, эти вопросы следует задавать к каждой, даже казалось бы самой простой строчке беклога: что сделать на фронте; что сделать на бекенде; какие ручные тесты написать или переписать; какие автотесты исправить; какие данные в базе менять или мигрировать; что задокументировать?
  • Нагрузку на первый спринт рассчитывать так: количество рабочего времени каждого из команды за полспринта, минус еще немного. То есть если спринт двухнедельный, то загружайте команду где-то на 35 рабочих часов каждого. Остальное время уйдет на недооцененные доработки задач, блоки, совещания и т.п. Эта цифра чуть вырастет на следующие спринты, но не сильно.

Этап 2. Первые спринты, начало работы

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

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

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

  • · Начинайте планировать следующий спринт с первого дня текущего, и лучше не в один заход. Тогда будет время продумать те задачи, которые еще «сыроваты», но вместе с тем их важно взять в реализацию.

  • · Не расстраивайтесь, когда в конце спринта вы все равно все не успели. Сноровка приходит с опытом.

Этап 3. Scrum-As-Usual

После нескольких спринтов поймите вашу действительную загрузку по времени. У нас так:

  • 60% — выполнение запланированных задач;

  • 10% — планирование и организация следующего спринта, разбор/оценка задач из беклога;

  • 5-10% — подготовка и демонстрация результатов спринта. У нас это — сборка версии и накат на отдельный стенд, проверка конфигов, правки в последнюю минуту, пересборка;

  • 20-25% — запас на риски: болезнь или внезапное отсутствие членов команды, обнаружение критичного и срочного дефекта, устранение которого нельзя отложить на потом, нашествие марсиан и другие возможные неурядицы. Если случается, что все задачи спринта сделаны, в это время всегда есть чем заняться — отлов багов, обновление документации, автотесты.

Сейчас в двухнедельном спринте мы накидываем задач для каждого на 48-50 часов. Еще 8 часов в общей сложности уходит на планирование спринтов. Мы делаем две-три общекомандных встречи по полтора — два часа, плюс отдельные обсуждения: дизайн с фронт-разработчиками, структурные изменения с архитектором и бек-разработчиками.

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

И напоследок

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

Научитесь задавать друг другу самый важный вопрос: «Как тебе помочь?». Этот вопрос творит настоящие чудеса: заставляет людей задуматься не о том, что плохо, а о том, чего они хотят. Представьте: вы жалуетесь на проблему, а вам в ответ предлагают помощь. По сути, вас ставят перед выбором: честно признать, что вам просто хочется поныть (что тоже абсолютно нормально), или сформулировать четкую потребность и искать пути ее удовлетворения вместе, всей командой.

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

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

Написать
{ "author_name": "Alexandra Klimenko", "author_type": "self", "tags": [], "comments": 4, "likes": 15, "favorites": 1, "is_advertisement": false, "subsite_label": "flood", "id": 35566, "is_wide": false }
{ "id": 35566, "author_id": 158420, "diff_limit": 1000, "urls": {"diff":"\/comments\/35566\/get","add":"\/comments\/35566\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/35566"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791 }

4 комментария 4 комм.

Популярные

По порядку

1

Очень интересная статья, большое спасибо!

Ответить
0

Блин, ну "скрам - agile - спринт - дедлайн - беклог - фидбек - фичи" это хорошо, но что Вы делали фактически, я так и не понял.
 
Я не знаю, позволяет ли HTML редактор vc ставить a href=# title="Технология усовершенствование продукта путем общего ритмичного бубнежа, биться в барабаны и эротических танцев", но что-то такое уже для первого слова - скрам - точно бы понадобилось, ну и дальше тоже.
 
Даже в простом варианте - как Вы работали до этого, и как стали потом, и то понимания не прибавилось. Из статьи складывается впечатление, что просто приходили на работу и пили чай (кофе), мало кто с кем здоровался, а потом решили познакомить людей друг с другом, хоть иногда общаться и обсуждать что нужно сделать - и тогда началась работа :)

Ответить
0

HTML-редактор? Каково вам там, в 2005 году?

Ответить
0

Раньше конечно тоже работали, только цикл был длинный, поэтому у бизнеса как раз и закрадовалось ощущение - а не чай ли там сидят пьют? :)
А на самом деле: запрос продавцов, ТЗ, согласование ТЗ в ИТ, совместная проверка на полноту, перепись ТЗ по итогам, выставление оценок и торг по срокам и составу работ, потом наконец разработка, потом результат и очень неохотное внесение изменений в готовую версию.
Внедрение нового тяжелого функционала могло идти 2 или больше месяцев без видимых изменений в продукте, для бизнеса это непрозрачно и долго.

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

Над изложением будем работать, в общем. Спасибо за отзыв!

Ответить

Комментарий удален

0

Прямой эфир

[ { "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": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "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, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Приложение-плацебо скачали
больше миллиона раз
Подписаться на push-уведомления