Scrum: серебряной пули не существует

Справка:

Дмитрий Кирилкин, ведущий разработчик 1С в торговой сети Реми (Владивосток). С недавнего времени также является техническим лидером во внутреннем отделе разработки. Ранее 6 лет руководил отделом информационных технологий большой фармацевтической компании. В ИТ работает почти 20 лет.

Предисловие

Сразу хочу сказать, что мой доклад не имеет никакого отношения к команде «Серебряная пуля». Она существует, все в порядке, не переживайте.

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

Что заставило нас искать новые подходы?

Компания Реми – это крупнейшая сеть продуктовых супермаркетов на Дальнем Востоке. Штат компании составляет более 3 тысяч человек в разных городах Дальневосточного региона. Компания начала бурно развиваться в последние два года, до этого отдел разработки состоял из двух человек – меня, как программиста 1С, и руководителя. И в течение буквально 6 месяцев количество разработчиков в отделе увеличилось с 1 до 4.

Представьте мой шок (культурный), когда я сижу, никого не трогаю, не шалю, и тут нас стало в четыре раза больше. Соответственно, появились предпосылки для использования Scrum в нашей команде.

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

Также в нас проснулся интерес к новому, желание работать не как все. С  течением времени появляется такое понятие, как профессиональное выгорание. Становится неинтересно работать, потому что все одно и то же – 1С, задачи, бухгалтерия, управленческий учет. Хочется попробовать что-то другое, хочется работать не как все. Тем более, есть такой миф в профессиональной среде разработчиков, что программисты 1С «несерьезные», мол, у нас даже код на русском языке. Поэтому хотелось приобщиться к профессиональному сообществу разработчиков.

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

Знакомство с методологией

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

И что мы сделали? Первым делом мы просто поставили Kanban-доску, насоздавали там колонок «бэклог», «в работе» и «готово». Начали вписывать задачки, двигать их по колонкам. Вот, вроде как, мы по Kanban и работаем.

Но дальше предстояло разобраться, что собой представляют Scrum и Agile. Долгое время, честно сказать, я считал, что Agile – это такое же направление гибких методологий разработки, как и Scrum. Я думал, что в Agile одни правила, а в Scrum – другие. Но потом я разобрался, что Agile – это в принципе сборник методологий, некий брендбук, если можно так сказать, в котором собрано все, что касается гибких методик экстремального программирования. А Scrum и Kanban – это просто направления Agile.

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

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

И решил я поискать еще, потому что статьи, которые есть в сети по Scrum, не отвечали моим потребностям. В них, как правило, Scrum подается через личное восприятие автора этого материала, либо статья поверхностная. А мне нужна была именно инструкция по каноническому Scrum. Я наткнулся на книгу, которую должен прочитать каждый, кто хочет у себя попробовать гибкие методологии разработки. Это книга Джеффа Сазерленда «Scrum. Революционный метод управления проектами».

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

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

Что мы хотели получить от методологии?

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

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

Повышение производительности. Про это ожидание говорить много не буду, только напомню сакраментальное: «делать два раза больше за половину времени».

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

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

Популяризация и понимание Scrum в команде

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

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

И я говорю ребятам: “Представьте, что у вас есть ограниченный отрезок времени – две недели – спринт, в течение которого вы выполняете задачи, набранные на этот отрезок времени, не больше. По окончании этого отрезка времени вы набираете на следующие две недели новый пул задач, которые вы тоже обязаны выполнить за две недели. И тогда вы сможете сказать пользователю, что у нас через две недели закончится спринт, и в следующий спринт мы возьмем твою задачку, соответственно, мы сможем с ней начать работать через 2 недели, а закончим ее еще через 2 недели. То есть ты получишь свой функционал через месяц. Пользователя такой ответ устроит? Скорее всего, да. Потому что он и не ждал от нас конкретной даты, все ведь понимают, что это практически невозможно угадать.”

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

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

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

- что ты сделал вчера?

- что ты сделал сегодня? (именно в прошедшем числе)

- что тебе мешает?

Скинул эту статью в нашу группу в Telegram и думаю: «Сейчас меня точно закидают помидорами, скажут, что им работать некогда, а я тут со своими статьями, со своими митингами какими-то каждое утро. Делать больше нечего нам что ли, только отвечать на эти три непонятных вопроса?». Но к моему удивлению, утром следующего дня люди пришли и сказали, а давайте попробуем. Причем сами. Их никто об этом не просил. И с этого момента у нас начались ежедневные стендапы, как оно и положено в Scrum.

Это был еще неполноценный Scrum, но это были уже стендапы, на которых мы старались правильно, в прошедшем времени, ответить на все вопросы.

Самый сложный из них был, конечно, последний – «что тебе мешает?».

Выбор владельца продукта и Scrum-мастера

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

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

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

И чем хорош Scrum: никто не заставляет людей выполнять какие-то роли. Как правило, они сами на себя их берут, потому что им становится интересно.

Обязательные события Scrum

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

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

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

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

Ретроспектива спринта – это очень сложно. Картинка отлично демонстрирует, как это происходило у нас в первое время.

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

Что касается обзора спринта. К сожалению, из-за того, что у нас нет продукта, как такового, а 4 отраслевые конфигурации, в спринт, как правило, набирается огромное количество всевозможных маленьких задач. И провести какое-то демо с пользователями практически не представляется возможным. Они просто не придут: кто-то находится на Сахалине, кто-то в Хабаровске. Поэтому на обзоре спринта, мы, как правило, рассказываем про технические решения для своих же коллег в отделе. Допустим, внедрили мы в продакшене автодеплой, рассказали, как это работает. Внедрили интеграционную шину, рассказали, как работает. Т.е. основная цель обзора спринта у нас – это повышение информированности сотрудников команды, чтобы они знали, чем мы занимаемся.

Новый подход к работе с задачами

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

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

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

Оценка задача в Story Points нужна обязательно. В начале начинаешь без нее, но тут Scrum изящно решает проблему оценки задач, он вводит ее относительность. Мы используем числа Фибоначчи для оценки задач, точность при этом нам не очень нужна, потому что главное – оценить количественную сложность задачи.

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

Жизненный цикл задачи

Расскажу про жизненный цикл наших задач. На картинке – вид текущей Scrum-доски, которая у нас есть сейчас на проекте.

Там есть колонки: «нужно сделать», «непонятное ТЗ», «тестирование не пройдено», «в работе», «ожидает тестирования», «идет тестирование», «готово». И задача в принципе так и движется – слева направо. У нас все задачи тестируются разработчиками. Разработчик, который выполнил задачу, перемещает ее в «ожидает тестирования», а следующий разработчик берет эту задачу в тест. Этим мы решаем две задачи. Во-первых, проводится сразу же Code review, во-вторых, разработчик сразу же входит в курс дела, и в случае если тестирование не пройдено, он переводит задачу в «тестирование не пройдено», пишет свои комментарии. Поскольку в задаче сохраняется последний исполнитель и последний тестировщик, это позволяет не передавать работу из рук в руки. И когда в следующий раз разработчик увидит задачу в колонке «тестирование не пройдено», он ее вернет назад в работу, а в тестирование эту задачу возьмет тот сотрудник, который ее проверял до этого.

Еще. Спринту желательно создавать цель. Этим занимается Scrum-мастер. Но из-за того, что у нас 4 конфигурации, мы не можем часто задавать цель спринта.

Программное обеспечение, которое мы используем

Последнее, о чем хочу рассказать – программное обеспечение, которое мы используем: Jira Software, Confluence, а со стороны пользователей – 1С:Документооборот.

Дополнительное программное обеспечение – GIT, OneScript, Jenkins.

Вместо заключения

К чему мы пришли?

• Повысился уровень самоорганизации в команде.
• Коллективная ответственность за результат растет. Действительно, приятно видеть, как люди сами, никто их не просит, берут работу, предлагают что-то новое.
• События Scrum создают атмосферу, в которой каждый сотрудник чувствует, что он работает не один.
• Благодаря  оценке задач в Story Points мы знаем производительность команды и можем более точно оценить свои возможности.

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

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

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.