Справка:
Дмитрий Кирилкин, ведущий разработ пользователь чик 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 – это в принципе сборник методологий, некий брендбук, если можно так сказать, в котором собрано все, что касается гибких методик экстремального программиров1Сания. А 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 отраслевые конфигурации, в спринт, как правило, набирается огромное количество всевозможных маленьких задач. И провести какое-то демо с пользователями практически не представляется возможным. Они просто не придут: кто-то находится на Сахалине, кто-то в Хабаровске. Поэтому на обзоре спринта, мы, как правило, рассказываем про технические решения для своих же коллег в отделе. Допустим, внедрили мы в продакшене автодеплой, рассказали, как это работ пользователь ает. Внедрили интеграционную шину, рассказали, как работ пользователь ает. Т.е. основная цель обзора спринта у нас – это повышение инф обраб внешние компонентыоткиормиров1Санности сотрудников команды, чтобы они знали, чем мы занимаемся.
Новый подход к работ пользователь е с задачами
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. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.