История внедрения Scrum в отделе внутренней разработки 1С

С чего все началось?

Что было в моей жизни до того, как я начал внедрять Scrum? 

Была работа, которую надо было делать. И был интерес к Agile. И в один прекрасный момент, в 2010 году, когда я проходил тренинг AgileBaseCamp, работа и хобби сошлись в одно, и я как-то резко понял, что у нас в команде нужно внедрять Scrum. Мне показалось, что это сможет нам помочь. 

Что у нас было на тот момент, когда мы начинали?

• У нас была команда внутренней разработки – 4-5 человек.
• Задачи к этому моменту уже «трекались». В качестве трекера мы использовали Mantis.
• Документация для пользователей составлялась в Wiki.
• Было понятие релиза.
  Несмотря на то, что у нас была внутренняя разработка, мы не имели доступа к базе. И значит, мы не могли залезть в базу и поправить, если что-то было не так. Мы выпускали релиз и выкладывали дистрибутив на внутренний открытый источник, а люди, которые сопровождали нашу базу 1С на филиалах (или на подразделениях холдинга), брали релиз оттуда. Получается, у нас было больше общего с внешней разработкой, потому  что, если находились какие-то баги, приходилось выпускать баг-фиксы и выкладывать новый релиз.
• Был форум поддержки.
• Также было несколько владельцев продукта (Product Owners). Это были заказчики так называемых профильных департаментов.

И был один руководитель (так называемый proxy-Product Owner), который собирал от них требования и выступал в качестве единого владельца продукта для нашей команды (собственно, так и рекомендуется в Scrum). 

Первые шаги

Начинали мы на внедрении. Многие говорят, что внедрение – это стресс. Но так как мы в тот момент внедряли учет на одном из предприятий, нам было удобно использовать внедрение для некоторой практики. И мы попробовали – начали с доски и со стенд-апов.

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

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

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

Если говорить про этапы процесса внедрения методологии Scrum снизу, то это было так:

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

Второй этап. Что изменилось?

У нас появилась электронная доска (мы сами ее сделали). Сначала нам специально выделили время и сказали: «Ребята, есть много продуктов по Scrum, Agile (например, Redmine, Jira), все поддерживается. Подберите себе что-нибудь для работы». Но мы, как настоящие 1С-ники, решили изобрести велосипед и сделали для этого свою конфигурацию.

Трекер никуда не делся (на рисунке показан наш трекер Mantis), но путь вопроса преобразился. Если раньше вопрос попадал в трекер и там же отслеживалось его состояние (плюс было какое-то обсуждение), то теперь стало немного по-другому. Трекер по традиции остался, туда собирались все требования, а в дальнейшем Product Owner принимал решение, пойдет требование в разработку или нет.

Если Product Owner решал, что требование должно пойти в разработку, то оно автоматически попадало в другой трекер, который мы назвали ScrumWork. Там расставлялись приоритеты, давалась оценка. 

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

Что еще поменялось в процессе? В форме тикета появились специальные подсказки, критерии готовности задачи. Например, мы ввели обязательное заполнение описания для первого демо, чтобы конкретизировать, как продемонстрировать решение для этой задачи.

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

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

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

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

Следующий этап. Поддержка

Доска менялась, становилась больше. 

Какая еще практика появилась?

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

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

И как только мы это сделали, все сразу рухнуло. Потому что разработчики начали брать эти красные тикеты, их пошло еще больше, все стало плохо, и мы стали думать, как сделать так, чтобы стало хорошо. И сделали.

Что мы сделали? Мы выделили одного разработчика, который занимался поддержкой. Но решили его менять по неделям. То есть, какой-то несчастный человек на неделю назначался в качестве саппорта. По возможности он брал задачи из основной итерации, но главным его приоритетом было решение вопросов по поддержке.

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

Причем одной из практик, которая тоже принесла пользу, была торжественная передача этой пожарной машины, потому что в ходе передачи можно было попутно сообщить: «Ты знаешь, у меня на прошлой неделе были вот такие вопросы, я их не решил, ты жди, они к тебе тоже прилетят».

Собственно, практика пожарного, дейли-митинги, доска.

Кстати, поначалу с дейли-митингами было очень тяжело. Scrum говорит о том, что они должны быть не очень длинными, и должны играть роль «пульса команды» (синхронизировать команду). Но выяснилось, что мои разработчики (и я в том числе) очень любят поговорить. И даже если устали стоять, все равно очень любят поговорить. То есть стенд-апы не всегда спасают от длительных совещаний.

Но нам удалось решить эту проблему. Что помогло? Когда начинался разговор «за жизнь», мы говорили так – давайте про это отдельно, на пост-дейли-митинге. Кому интересно, тот остается. Это переносило все лишнее на потом, и дейли-митинг становился «пульсом команды» – собрались, синхронизировались, поняли, кто что делает. Правда, иногда, если это действительно было нужно, пост-дейли-митинги затягивались до нескольких часов.

Планирование

Дальше еще одна хорошая практика в Scrum, одна из самых главных, – планирование.

Собственно, ничего особенного про планирование сказать не могу. Оно проводилось классически:

• На начало планирования Product Owner имел приоритезированный Backlog продукта, где у него набирались задачи на итерацию.
• Для тех задач, которые еще не были оценены, выставлялась оценка с помощью Planning poker.
• Что было интересного на планировании? Мы стали ставить на итерацию некую цель, имеющую определенную бизнес-ценность. Не просто «давайте за следующую неделю повесим как можно больше тикетов, и всем будет отлично». От генерирования огромного числа тикетов обычно никому отлично не бывает. Имеется в виду какая-то конкретная цель: внедрить блок учета конкретно для того-то или запустить давно желаемую «фичу» (что-то, что имеет ценность для заказчика). Это было важно для того, чтобы мы могли что-то показать заказчику на демо и соотнести поставленную цель с реальностью – выполнена она или нет. Я всем советую на планировании пытаться поставить цель итерации. Хотя надо сказать, что это не всегда возможно, особенно если делается большая «фича». Запустить «1/28 от этой большой фичи» – как цель звучит не очень хорошо. Но, конечно, бывало и так.

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

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

Тут есть пункт Velocity – это стоимость одного Story Point («попугая») в часах по результатам предыдущей итерации. Соответственно, взяв эту стоимость, мы понимали, что при планировании следующей итерации мы можем взять задач на 54 Story Point. Мы старались брать немного больше (с запасом). Некоторые, наоборот, перестраховываются, берут меньше.

Соответственно, фактически в конце итерации мы понимали, сколько по факту было сделано (здесь 65). И, соотнося с реальными часами, проводили фактический расчет Velocity. У нас по факту получалось 0,12. Вот это вот 0,12 шло уже на следующую итерацию как планируемая скорость команды.

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

Состав итерации

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

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

• Демо. Во время демо ответственный за проект (так называемый архитектор проекта) становился, показывал, что в проекте поменялось. Даже если заказчика не было, демо проводилось «для себя», для того чтобы сама команда понимала, какие изменения произошли. И если кто-то всю итерацию пилил свою гайку, особо не обращая внимания на дейли-митинги и на окружающих, то на демо он имел возможность посмотреть, что же поменялось. И это было важно, в том числе для поддержки.
• Дальше, после демо, проводилась ретроспектива. Мне вообще кажется, что ретроспектива для команды – это такая вещь в процессе, которую можно улучшать практически бесконечно. Сколько она у нас ни шла, я как Scrum-мастер ей никогда не был доволен. Хотелось, чтобы она проходила лучше, эффективнее, быстрее двигала процесс вперед.
  Какие сложности возникали на ретроспективе? Для нас, как для команды, которая изначально внедряла Scrum «снизу», обсуждение того, что у нас было в процессе сложного, плохого или хорошего, обычно выглядело так: «Ну вот, такая-то обработка была сложная». – «Нет, подожди, не обработка сложная, что в процессе было сложного? Или что можно улучшить?» С самого начала было очень тяжело объяснить, что ретроспектива – это не про код, а именно про сам процесс.
• Code-review. Не буду долго останавливаться. Есть такая инженерная практика, когда из кода вычитываются определенные интересные места. У разработчиков друг в друга летят тонны конфетти – все же любят, когда его код вычитывают и критикуют.
• И планирование. Поначалу, когда этих активностей не было, планирование занимало полтора дня: понедельник и часть вторника. Было тяжело, непонятно было, как это делать. А потом мы привели его в чувство, оно стало занимать полдня – все планируется, итерация набирается, приоритеты расставляются, заказчик доволен. Важное выполняется в первую очередь, неважное – во вторую. Все замечательно.
• Конец итерации – это релиз. Какие-то абсолютно рутинные активности: собрать cf-ник, md-шник, выложить его, упорядочить. Все это делается в четверг, потому что все знают, что плохая примета выпускать релиз в пятницу, поскольку это испорченные выходные.
• Ну и пятница – инженерный день. Это даже не из Scrum. Мы могли себе позволить какой-то день, отведенный под то, чтобы разработчик мог почитать мануалы, сделать какой-то прототип для следующей итерации, попробовать какую-то новую функцию или установить себе свежий релиз платформы 8.3, который пока заказчику не нужен, но можно что-то там для себя поковырять. Я не знаю, наверное, не все могут себе позволить инженерный день. Но мы могли, хотя это и дорого – это целый день работы программиста. Но считается, что в долгосрочной перспективе это очень полезно, на самом деле.

Вот такой у нас был состав итерации, так мы ее проводили.

Заключение

И вот… так у нас в конечном итоге стало (мне эта картинка самому очень нравится).

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

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

Вот такое личное, очень дорогое мне замечание.

***********

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.