SCRUM по-белорусски

Компания, в которой я работаю, – ЗАО «Интеллектуальные системы» – находится в Минске. Наша основная специфика – автоматизация бюджетных учреждений.

Мы – авторы конфигурации «Управление бюджетным учреждением 8». Благодаря тому, что в нашей конфигурации разработано большое количество модулей, мы можем автоматизировать бюджетные учреждения от «А» до «Я» через полный цикл автоматизации.

Какие проблемы в разработке ПО были вначале

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

Но по мере того как я стал знакомиться с процессами разработки ПО поближе, картинка немного изменилась.

Изучая процессы разработки, я столкнулся с рядом проблем:

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

• Проблемы с тестированием. Выпущенный релиз разработчики передавали в отдел тестирования. Тестировщики писали замечания на бумаге и возвращали все программистам. Программисты что-то исправляли, затем возвращали обратно тестировщикам. Цикл повторялся. Проблема была в том, что многие замечания терялись и никто не мог сказать, все ли доработки проверены. И в релиз часто попадали непроверенные доработки, потому что разработчики сделали какую-то новую функциональность, и она осталась незамеченной.

• Проблемы с бэклогом. Были устные постановки задач и ручная приоритизация задач, поэтому планы по разработке не выполнялись.

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

Нужно было исправлять ситуацию, принимать какие-то решения.

На слайде изображена ситуация, в которой кто-то может узнать себя.

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

• На мне были задачи по выпуску версий.

• Новости к релизу собирались вручную.

• Кроме того, от меня требовался постоянный оперативный менеджмент – нужно было контролировать и организовывать работу программистов.

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

Какой план действий мы разработали, чтобы устранить проблемы разработки

Мы решили действовать в двух направлениях:

1. Настройка процессов по методологии. Мы взяли за основу каноническую схему SCRUM, где:

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

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

Начнем с самого начала.

• Как вы знаете, в начале было слово.

• И было это слово требованием.

• Но требование должно фиксироваться, а не так, как на картинке:

Основная цель бэклога – собрать все замечания и требования в одном месте.

Это же является и проблемой бэклога, потому что замечания и требования поступают со всех сторон:

• от заказчика,

• от сотрудников,

• от руководства и так далее.

Требования поступают разным способом:

• фиксируются на бумаге;

• передаются устно.

Основная задача при формировании бэклога – все зафиксировать и положить в одно место.

Мы зафиксировали все в собственной учетной системе

Мы пришли к тому, что все задачи фиксируются в нашей собственной учетной системе.

В системе мы создаем документ «Вопрос», где описываем задачу по требованию клиента.

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

• Также мы привязываем задачи к объектам метаданных – благодаря этому происходит определенный эффект синергии.

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

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

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

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

Таким образом, мы работаем по заявке и чек-листу и выполняем все требования от заказчика, ничего не пропуская.

Мы оцениваем требования в часах

Мы оцениваем требования в часах и фиксируем три оценки:

• от автора (постановщика задачи);

• от тимлида;

• от исполнителя.

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

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

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

И также оценивают задачу тимлид и исполнитель.

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

Тогда тимлиду приходит сообщение о превышении трудозатрат – он коммуницирует с разработчиком и решает этот вопрос.

На слайде показана классическая картина «Лебедь, рак и щука».

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

• Я приходил к руководству, мне говорили: «Александр, вот эта задача очень важная. Ее нужно решить в первую очередь». Я говорил: «Хорошо» и шел на рабочее место.

• В коридоре со мной сталкивался сотрудник линии консультаций и говорил: «Слушай, клиент плачет, работать не может. Вот эту задачу нужно сделать в первую очередь!». Я говорил: «Хорошо» и шел дальше.

• Приходил к себе на рабочее место, смотрел планы разработки и думал: «Так. Нам нужно разработать функциональность к этому релизу. Значит будем делать ее в первую очередь».

• Я все время разрывался между противоборствующими сторонами – не знал, что делать в первую очередь и в каком порядке.

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

Помимо меня, такая же проблема была и у программистов.

• У каждого программиста был свой список задач.

• Но если дать программисту возможность выбирать себе задачи, он будет это делать полдня.

• Для него все эти задачи – хорошие и важные. А какую сделать в первую очередь – он не знает.

Нужно было исправлять ситуацию.

Мы создали систему приоритетов

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

• Каждое требование нужно расценить по ряду критериев и с учетом того, для кого эти критерии представляют ценность: для клиента или для компании.

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

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

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

1. Кнопка «х2». Что это значит? Например, когда консультант выслушивает клиента, который говорит, что их требование самое важное, работать по-другому они не могут, и вообще клиент плачет ему в трубку, консультанту нужно куда-то выплеснуть эмоции.
   Сухая система приоритетов не позволяет этого сделать, человек только должен ответить на какие-то формализованные вопросы. Чтобы выплеснуть эмоции, мы дали ему кнопку «х2». Если возникла подобная ситуация, можно нажать эту кнопку и по какому-то из приоритетов увеличить числовое значение в два раза, тем самым выплеснув свои эмоции.

2. Особые случаи. Также мы учли особые случаи, которые не укладываются в общую схему типовых вопросов. Сюда подходят такие варианты как:

• Обучение разработчиков, которое должно выполняться наряду с рабочими задачами. Пока мы не выделили обучение в «особые случаи», оно болталось где-то в середине приоритетов. Разработчики забывали планировать свое обучение, забывали обучаться и т. д.

• Переносы данных – мы им тоже выделяем повышенное внимание. Требования по переносам должны были всплывать вверх в приоритетах.

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

Как строятся планы на спринт

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

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

• Важно, что все требования сгруппированы по объектам метаданных. Благодаря этому разработчик за один релиз исправляет по максимуму все замечания, связанные с данным объектом метаданных. Т.е. работает эффективно, в контексте этого объекта. Также группировка требований по метаданным упрощает тестирование, потому что тестировщик работает не с 10 разными объектами, а с одним, который прогоняет по всем функциям от «А» до «Я». Т.е. благодаря тому, что мы группируем требования по метаданным, повышается эффективность работы разработчиков и тестировщиков.

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

Практика. Дежурство на ЛК

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

Я заходил в отдел к разработчикам, а они все висели на телефонах. Некоторые и на двух телефонах сразу.

Суть в том, что у нас есть линия консультации, бизнес-анализ, но все равно много звонков переключалось на программистов. Из-за этого вместо программирования они занимались консультированием клиентов.

Нужно было придумать решение для этой проблемы.

Мы реализовали дежурство на линии консультации.

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

• Линия консультации – это первая линия, где решают простые вопросы.

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

Таким образом, мы освободили программистов от косвенных задач по консультированию клиентов. Они сосредоточились на коде.

Какие инструменты помогут сделать код качественным

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

Расскажу, какие инструменты мы рассматривали, и какие у них есть плюсы и минусы:

Автоматизированная проверка конфигурации (АПК).

Плюсы:

• Позволяет проверить вашу конфигурацию на соответствие стандартам 1С.

• В ней реализовано большое количество проверок.

• Все ведется в одной базе. Есть отчеты и отметки о выполнениях.

Минусы:

• Долго производит проверку.

Код-ревью.

Плюсы:

• Как известно из теории Макконела, код-ревью в 8 раз эффективнее, чем тестирование.

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

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

Минусы:

• Практика требует внедрения, решения каких-то организационных вопросов. Просто так она не заработает. Здесь нужно провести подготовительную работу.

Хранилище.

Плюсы:

• Простой и понятный инструмент.

• Обеспечивает линейность разработки: захватил объект, поместил изменения и так далее.

Минусы:

• Линейность одновременно является и минусом. Если кто-то захватил объект, нужно дождаться, пока он его отпустит.

• На больших конфигурациях и при работе большого числа пользователей хранилище работает медленно.

GIT

Плюсы:

• Лишен недостатков хранилища, поскольку обеспечивает нелинейность разработки, если мы полностью переходим на GIT.

• С помощью GIT можно проводить быстрый код-ревью.

• Известен автор каждой строки.

Минусы:

• Сложность объединения веток. Если мы полностью переносим разработку в GIT, нам нужно как-то мержить ветки. Это стоит больших трудозатрат.

Мы все эти инструменты рассмотрели, объединили и взяли лучшее из них.

Как мы подружили лучшие практики из разных инструментов

Мы подружили хранилище и GIT.

Разработка ведется в хранилище. Используется одно хранилище, но чтобы на время выпуска релиза в него не попадали непроверенные изменения, мы его захватываем, т.е. оно фиксируется.

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

Подружили код-ревью в VS Code.

Так мы максимально наглядно видим, какие строки добавлены и изменены. И самое главное – код-ревью проходит очень быстро.

Если вы сравнивали в конфигураторе какие-то версии, то знаете, что это очень долго: сохранить конфигурацию, сравнить, объединить. Теряется время. Если инструмент сложный и работает медленно, им не будут пользоваться.

Код ревью в VS Code работает быстро, и программисты очень любят им пользоваться, потому что это удобный, хороший и наглядный инструмент.

Мы подружили разработчиков и тестировщиков.

• Мы стали фиксировать все замечания в учетной системе и разработали для этого специальный документ.

• Мы ввели АВС-ранжирование замечаний. То есть каждому замечанию присваивается какой-то класс – А, В или С. А-замечания выполняются в первую очередь, В-замечания – потом, а C-замечания – в конце. Причем, если у нас поджимают сроки выхода релиза, то С-замечания мы можем отложить на следующий спринт. Мы понимаем, что замечание записано, но оно С-класса, с ним можно жить. Мы переносим его на следующий релиз. Благодаря этому мы не срываем сроки выпуска релиза и делаем все вовремя.

• Когда тестировщики записали замечание, программист его исправил, то это тоже нужно проверить. Важно убедиться, что все работает так, как просили. Важно сделать контроль проверки помещения в хранилище. Также должен быть контроль того, что мы не забыли поместить в хранилище. Думаю, вы слышали от своих программистов: «Я делал, но забыл поместить в хранилище».

а слайде показано, как замечание от тестировщика выглядит в учетной системе.

Здесь мы видим текст, результат работы программиста, статусы, даты, ответственные. И по результатам проверки можно проставить флажки «Проверено», «Работает», чтобы ничего не потерялось, а все замечания были протестированы и вошли в релиз.

Дружба практик привела к четкому спринту

Сочетание практик и методик позволило прийти к четкой и управляемой структуре спринта. У нас спринт длится 2 недели:

1. Первая неделя – разработка. Программисты максимально погружены в процесс разработки. Это происходит эффективно, и решается большое количество задач.

2. Вторая неделя – тестирование и выпуск релиза. Здесь работает АПК, проводится код-ревью, проводится запуск дымовых тестов и ручное тестирование.

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

Поэтому мы продолжили автоматизировать нашу учетную систему дальше.

Зачем ежедневно фиксировать работы

Благодаря тому, что разработчики ежедневно фиксируют свои работы в учетной системе, мы можем:

• Учитывать трудозатраты по проекту.

• Автоматически создавать новости к релизу, потому что все зафиксировано в базе: кто и что делал, какие объекты метаданных исправлял, в чем суть доработки.

• Наполнять базу знаний. Когда мы все вопросы и решения привязываем к объекту метаданных, у нас появляется полная картина по объекту;

• Когда мы все ежедневно фиксируем, мы можем оперативно контролировать и помогать программистам, если возникают проблемы или нужна помощь.

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

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

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

Текст группируется по каждому объекту и выводится в определенную секцию.

В конечном итоге мы пришли к тому, что новости формируются по одной кнопке.

Благодаря тому, что все привязывается к объектам метаданных, появляется эффект синергии.

Если мы зайдем в объект метаданных, то:

• на закладке «Решения» увидим, что сделали программисты по этому отчету, справочнику или документу;

• на закладке «Вопросы» увидим, какую функциональность клиенты просили в объекте;

• на закладке «Вопросы ЛК» фиксируются все вопросы, которые были заданы пользователями;

• на основании вопросов составляются статьи в базе знаний, которые тоже привязываются к объекту метаданных. Все это очень помогает консультанту на горячей линии. Он может открыть форму и из нее получить исчерпывающую информацию: что сделано, что планируется сделать, какие по объекту были вопросы;

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

Как мы клонировали менеджеров

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

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

На слайде в верхней части мы видим табличное поле, где для конкретного разработчика описано порядка 20-ти задач четырех типов. Например:

• Две задачи «Ответить на сообщение»

• Шесть задач «Рассмотреть новые вопросы»

• И пять задач «Выполнить код-ревью по коммитам в хранилище».

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

Внизу показа план задач на сегодняшний день из спринта. Это удобно, чтобы ничего не забыть и не потеряться.

Если разработчик выполнил запланированную задачу и внес по ней трудозатраты, он видит факт и так отслеживает свое рабочее время.

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

Как мы разгрузили задачи по выпуску релиза

Я долго не знал, что делать с выпуском релиза. Эта работа была на мне, и она отнимала много сил и времени.

Я принял единственное правильное решение – делегировать работу программистам. Теперь выпуском релиза занимаются все программисты по очереди – введена практика дежурства по выпуску релиза.

Благодаря этому теперь каждый разработчик понимает, почему важно все делать своевременно:

• своевременно вести разработку;

• вовремя помещать изменения в хранилище;

• вовремя проводить тестирование;

• и зачем нужна документация.

Теперь программист понимает всю картину в целом. Благодаря этому, команда становится более ответственной, самодостаточной и самоорганизованной.

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

К каким результатам мы пришли

1. У нас появилась уверенность в качестве кода. Обратите внимание на слово «уверенность». Я, как руководитель, теперь уверен, что любое изменение программиста будет просмотрено другим программистом, проверено на ошибки и попадет в релиз тогда, когда нужно.

2. Мы получили управляемый бэклог, когда все замечания стекаются в одно место, зафиксированы, отсортированы, и бэклог записан в нашей учетной системе.

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

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

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

Желаю вам прийти к такому же результату, к которому пришел я.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.