Каталог решений - История внедрения 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 от этой большой фичи» – как цель звучит не очень хорошо. Но, конечно, бывало и так.