Гибкая разработка 1С:Бухгалтерии

Меня зовут Олег Фогель, я уже более 26 лет работаю в фирме «1С». С 1997 года я разрабатываю 1С:Бухгалтерию, а сейчас руковожу отделом, главным продуктом которого является конфигурация 1С:Бухгалтерия.

Кроме этого, я отвечаю за бухгалтерский и налоговый учет в наших программах, потому что помимо 1С:Бухгалтерии мы разрабатываем и многие другие конфигурации, например: 1С:БизнесСтарт – лучшую, на мой взгляд, программу для малого бизнеса, «1С:Бухгалтерию некоммерческой организации» и т.д.

По количеству конфигураций мы, наверное, самый продуктивный отдел в фирме 1С, а по количеству пользователей – вообще зашкаливает.

 

Agile в отделе разработки 1С:Бухгалтерии и его предпосылки

 

Agile мы начали применять с 2008 года. С тех пор многие из тех, кто меня убеждал, что гибкие технологии управления разработкой либо не сработают, либо нужны только для высасывания денег из клиентов, уже давно поменяли свое мнение и говорят: «У нас тоже Agile, а как иначе? По-другому же никак разрабатывать нельзя».

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

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

Главная цель Agile – это не конкретные методики, а стремление быть гибким. Это не я придумал, эти мысли вы можете вычитать и у Адизеса, и у Насима Талеба. Но Agile еще дает и систему ценностей, которой можно руководствоваться, и за это мы его любим.

 

Расскажу, какие предпосылки перехода к Agile были у нас.

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

 

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

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

 

Но есть один нюанс – разработчики работают с разной скоростью.

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

В какой-то момент такое негармоничное развитие программы стало для нас проблемой.

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

 

Первым нашим достижением на этапе внедрения гибких технологий стал общий Backlog – не у каждого ответственного свой Backlog, а общий на всю команду.

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

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

 

Первые результаты применения Scrum нас не обрадовали – все сразу пошло плохо.

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

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

 

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

 

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

 

И, наконец, у нас возникли настоящие проблемы, когда начали приходить разработчики и спрашивать: «Раньше я отвечал за этот участок, и моя работа оценивалась, исходя из работы этого раздела учета. Я понимал, что если здесь все хорошо, я работаю хорошо. А теперь я делаю какие-то задачи там, а какие-то здесь, но за что я отвечаю?»

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

 

С точки зрения выпуска релизов по спринтам все тоже с самого начала пошло плохо:

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

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

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

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

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

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

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

Это добавило нам уверенности, дало силы и привело к успеху.

 

Переход на KANBAN

 

Еще больше уверенности мы почувствовали, когда перешли на Kanban. Я где-то слышал замечательную фразу: «В любой непонятной ситуации переходите на Kanban”.

 

На что хочу обратить внимание?

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

• Релизы стали не привязаны к спринтам.

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

 

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

 

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

 

Выпуск релиза раньше и сейчас. Что помогло стабилизировать процесс

 

 

В чем у нас заключались основные проблемы в разработке?

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

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

• Собиралось много задач.

• Эти задачи влияли друг на друга.

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

• Исправление ошибок тоже приводило к следующим ошибкам.

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

 

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

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

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

 

Что нам помогает в выпуске релизов?

В первую очередь это подключение тестировщиков на ранней стадии разработки: еще даже кодирование не началось, еще только анализ задачи идет – мы уже подключаем тестировщиков. Они уже сразу начинают планировать, как это дальше будет тестироваться, какие тесты нужны. И, кстати, подбрасывают интересные сценарии для анализа.

 

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

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

Дело в том, что у нас одна и та же конфигурация должна работать:

• на разных СУБД;

• в разных режимах – файловом, клиент-серверном;

• через тонкий и веб-клиент – там еще могут быть разные браузеры и т. д.;

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

 

Еще один залог нашего успеха – это 1С:Сценарное тестирование. Продукт, который по воле случая тоже разрабатывается в нашем отделе. Я знаю, что многие из участников этой конференции используют другие продукты для тестирования. Это нормально. Даже у нас в разных отделах используются разные продукты. Но почему я уверен в «1С:Сценарном тестировании»? Потому что есть результат – последние ряд лет конфигурация, 1С:Бухгалтерия получает высшие оценки за качество среди всех конфигураций.

Плюс наши специалисты читают курс по управлению качеством бизнес-приложений в МФТИ и «Высшей школе экономики» – это чего-то да стоит.

 

Как организован процесс разработки

 

Самое важное в процессе разработки – это анализ задачи.

 

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

• Иногда анализ показывает, что вообще ничего делать не надо – и это большое счастье, это большой праздник.

• Иногда мы понимаем, что если делать пожелание, как написано – это огромный объем работы. А выяснение с пользователями показывает, что даже 10% от того, что написано, осчастливит большинство пользователей.

И это круто, это экономит огромное количество человеко-часов.

 

В общем, без анализа и без общения с пользователями не начинается ни одна задача. Это самый важный момент.

 

На этом же этапе мы анализируем и конкурирующие программы.

Здесь хотелось бы отметить следующее:

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

 

• Залог конкурентной борьбы – это понимать задачи пользователей лучше, чем конкуренты. В этом наша сила.

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

Этот специалист поговорил с каждым разработчиком и удивленно сказал: «Они все знают о пользователях и общаются с ними. О все знают о конкурирующих программах и анализируют конкурентов. Более 50% команд не делают этого!»

 

 

В чем залог хорошего решения? Как разработчику сделать хорошее решение?

 

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

 

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

 

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

 

Он отвечает за то, чтобы был удобный, понятный интерфейс.

 

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

 

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

 

Также разработчик отвечает за быстродействие.

 

И он отвечает за сбор обратной связи – когда задача выпущена, хорошо бы потом собрать обратную связь: помогло ли наше решение разобраться с той проблемой, которая была изначально?

 

В общем, что надо сказать? Быть разработчиком 1С:Бухгалтерии – это непростая задача, надо много всего уметь.

Когда-то давно я прочитал книгу «Роман об управлении проектами». Там была такая одна очень ироничная мысль: «Когда разработчики делают ошибки? Когда они пишут код. Как делать меньше ошибок? Надо меньше кодировать. В идеальном проекте кодирование должно занимать не больше 10% времени разработки».

Я посмеялся тогда, но запомнил.

А сейчас посмотрите – где здесь кодирование? Действительно, по многим задачам 60% времени уходит на анализ и на общение с пользователями.

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

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

 

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

• общее число пользователей;

• кому может быть полезен ваш механизм;

• кто справился;

• и из тех, кто справился, кто доволен, а кто недоволен – кому понравилось, а кому не понравилось.

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

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

 

Ретроспектива – как измерять эффективность и есть ли универсальные метрики для анализа производительности команды

 

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

У нас ретроспектива очень трансформировалась – даже был такой период, когда полтора года вообще не проводилась ретроспектива, потому что старый формат нас уже не устраивал, а новый мы не могли найти.

И я горжусь нашей ретроспективой, потому что она развивается, как живой механизм – живет в согласии с текущими задачами, с текущей ситуацией, с текущей командой.

Это круто – можно двигаться вперед и менять все так, как вам нужно.

 

На ретроспективе мы обсуждаем и метрики – это очень важный и сложный вопрос.

Метрики с самого начала применения Agile стали для меня камнем преткновения.

 

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

 

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

 

Я мучился с этими метриками – и так и сяк.

В какой-то момент я просто отчаялся и написал письмо гуру Agile – попросил его встретиться и обсудить этот вопрос.

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

И у меня прямо как камень с души упал.

 

 

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

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

 

Единый образ цели – как доверять команде и двигаться в одном направлении

 

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

Если коротко: «никому нельзя верить» – мы часто невольно обманываем кого-то или сами чувствуем себя обманутыми.

 

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

Это, конечно, печально.

 

Более того, бывает важно согласовать не только направление, но и исходную точку.

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

• Но при этом один считает, что все уже сделано хорошо и понятно.

• А другой считает, что все сделано отвратительно, и надо все переделывать.

Как с этим бороться?

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

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

 

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

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