Стыд и Скрам: взгляд глазами собственника из IT-шников

Основатель и соучредитель группы компаний WiseAdvice Иван Тягунов рассказал на конференции Infostart Event 2019 о том, насколько применимы гибкие подходы Agile и Scrum к разработке ИТ-продуктов при автоматизации на 1С. По мотивам этого выступления подготовлена данная статья.

Применим ли чистый Scrum или Agile (а другого, исходя из канонов самого фреймворка, быть не может) в проекте автоматизации на 1С, если мы говорим о построении системы на базе многофункциональных прикладных решений от 1С:УТ и выше (по широте и сложности этой самой функциональности)?

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

Чистый Scrum

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

• Кросс-функциональная команда разработчиков, собранная на срок от года;
• Scrum-мастер с соответствующими компетенциями (самостоятельная роль);
• Уполномоченный владелец продукта с соответствующими компетенциями (самостоятельная роль).

Процесс разработки по Scrum базируется на 3 важнейших принципах:

• Прозрачность;
• Инспекция;
• Адаптация.

Как это работает:

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

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

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

Звучит классно, но реально ли применение всех элементов фреймворка при автоматизации на 1С?

Scrum-команда

Приведем требования Scrum к команде:

• Преданность;
• Открытость и уважение;
• Смелость и сфокусированность.

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

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

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

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

Scrum-мастер

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

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

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

Знание предметной области и Scrum-подходов, требует от мастера 100%-й занятости, которая допускает, максимум, работу с 1-3 командами (в зависимости от масштаба их работы и схожести контекста).

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

Владелец продукта

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

Управляя элементами бэклога, владелец должен иметь долгосрочное виденье продукта, понимать, как и в какую сторону продукт будет развиваться, и что в итоге выйдет из разработки. Исходя из этого, владелец, наряду с мастером, в контексте автоматизации бизнеса на базе 1С должен владеть техникой анализа требований и знать основы проектирования 1С-систем, знать предметную область автоматизации, без которой не выйдет полноценного «владения», а также разбираться в технологических возможностях «1С:Предприятие» и непосредственно программ, на ней разработанных. Владелец продукта может вести до 3 продуктов в зависимости от объема разработки, но если продуктов больше одного, владельцем придется работать на full time.

В чем заключается сложность появления роли владельца в проекте по автоматизации на 1С? Если автоматизация проводится не из-за проблем бизнеса, когда что-то в системе не работает, и ее нужно «починить», а когда разрабатывается абсолютно новая система, то:

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

…возникает вопрос: как виденье продукта всех этих сотрудников совместить в одном человеке?

Помимо четкого понимания того, что должен собой представлять целевой продукт, владелец продукта на этапе проектирования ( который фреймворк Scrum практически не регулирует, поэтому для данного этапа придется использовать какую-то другую методологию ) должен:

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

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

Команда разработки

Команда разработки по канонам фреймворка не должна включать более девяти человек (но и не менее трех) без Владельца и Мастера. Считается, что только такая численность способна удовлетворить важнейшие требования к команде – обеспечить самоорганизацию и кросс-функциональность.

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

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

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

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

Продукт

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

Каким образом в этих условиях установить четкие границы продукта Scrum внутри прикладного решения 1С? Можно попробовать:

• зафиксировать перечень функциональных подсистем, полностью относящихся к продукту;
• зафиксировать перечень объектов метаданных – систем и подсистем, которые прямо не соотносятся с продуктом;
• расписать интерфейс взаимодействия с другими программами (например, при помощи диаграммы компонент UML с использованием объектов метаданных 1С);
• определить границы уже внутри объектов метаданных, вплоть до реквизитов (закладок), модулей, процедур и функций;
• если учесть, что решения 1С строятся на БСП и прочих стандартных библиотеках, то есть на коде, с которым также придется работать команде разработки, дополнительно придется поделить и БСП.

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

Может ли один человек дать такое описание многопользовательской системы, начиная с уровня системы 1С:УТ, и превосходящих ее по широте и сложности функционала? Ответ вполне очевиден. Но если владелец не описывает границы, это уже не Scrum.

Это все-таки не Scrum

Соотнесение каждого из важнейших требований Scrum с реальностью 1С вызывает ряд вопросов:

• Как на старте проекта описать конечное состояние сложного многофункционального продукта, чтобы сразу же его декомпозировать до уровня элементов бэклога, которые нужно еще и разделить для реализации на спринте? Кто должен этим заниматься?
• Каким образом так сформировать бэклог, чтобы к концу каждого спринта продукт можно было использовать?
• Как вписать в команду роль мастера? Где взять бюджет?
• За какое время до начала проекта должна «собраться» компетентная команда разработки? Опять же, кто выделит на это бюджет?
• Что и как показывать владельцу продукта и другим заинтересованным лицам в конце спринта, чтобы они убедились, что процесс идет, и дали важнейшую обратную связь?
• Что делать с предпроектным обследованием?
• И т.д.

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

Что же делать, если Scrum все-таки не Scrum, то есть проект автоматизации на 1С не соответствует критериям Scrum?

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

Полезные «для жизни» инструменты Scrum и Agile

Какие принципы Scrum стоит взять с собой в реальную жизнь?

• Сыгранная, кросс-функциональная команда специалистов будет преимуществом на сложном проекте по автоматизации;
• Принцип формулировки задач через соответствие показателям готовности даст возможность четко определить момент выполнения;
• Декомпозиция проекта на сколь возможно короткие итерации, с организацией достаточной и регулярной обратной связи от причастных со стороны заказчика сотрудников;
• Коучинг и фасилитация взамен директивного стиля управления командой проекта;
• Организация ретроспективного обзора работ и обратной связи для их разбора и анализа упростит преодоление трудностей и поможет отыскать резервы для повышения эффективности.

Agile базируется на 4 ценностях и 12 принципах, из которых в реальной жизни применимы:

• Реакция на изменения важнее изначального плана. Корректировка требований, даже на финальных этапах разработки, приветствуется, поскольку лучше поздно, чем в результате получить ненужный продукт;
• Общение «лицом к лицу», позволяющее избежать длительной переписки – главная ценность и ключевой фактор эффективной коммуникации;
• Упрощение благодаря компетенции и опыту команды как инструмент минимизации ненужных действий;
• Не столь важна исчерпывающая документация, сколько работающий продукт. Замену пользовательской документации сегодня может легко составить запись первичного обучения (проведенного по ролям, опираясь на User Story). При этом пользовательские инструкции проще создавать по обратному принципу – от частых запросов на Service Desk, так же в видеоформате;
• На этапе предпроектного обследования и даже проектирования системы, в виде документов оформлять только данные, требующие формализованного согласования, а также информацию, которую можно будет использовать как НСИ при эксплуатации системы. При этом избегать шаблонов и придерживаться точных и коротких формулировок.

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

Где черпать вдохновение и какими инструментами стоит пользоваться, при разработке собственного фреймворка:

• Концепция минимально-жизнеспособного продукта (minimum viable product, MVP);
• Прототипирование интерфейсов – самый быстрый путь к визуализации, а значит, и к презентации будущей системы;
• Kanban-доска и принцип лимитирования работы (WIP) для работы над «узкими местами»;
• Agile Practice Guide – совместная разработка PMI и Agile Aliance о возможностях гибкого подхода к управлению проектом;
• Если речь идет о крупнейших внедрениях, стоит потратить время на план управления рисками и коммуникации с акцентом на обратную связь.

Для этапа предпроектного исследования:

• Mind-карты как технику извлечения знаний;
• Фреймворк BABOK с рекомендациями по получению требований от руководящего состава;
• Методология Scrumban для укрупненного планирования на длительные периоды, их декомпозиция по принципу «ведер»;
• После постпроектного обследования, на стадии подготовки требований к целевой системе, пригодится фреймворк SWEBOK.

В проектировании системы поможет:

• Для построения новых или корректировок существующих бизнес-процессов традиционно применяют BPMN или Aris;
• Разрабатывать прототипы пользовательских интерфейсов проще, опираясь на User Story или JTBD;
• Разрабатывая отчеты, в первую очередь следует точно определить, точно ли мы имеем дело с отчетом, а не дашбордом, уведомлением или списком. Далее определяемся с подходом к формированию отчета – от контроля метрик/KPI или от гипотез, а разработку производить уже в ключе виртуализации – от диаграмм, а не от таблиц;
• Разрабатывая простую схему интеграции, можно ориентироваться на расширенные User Story (начинающиеся с «Когда..»), а сложную – с помощью eEPC(Aris);
• Для исследования имеющихся сущностей системы, учета взаимосвязей и проектирования изменений стоит использовать модифицированную диаграмму классов с использованием терминов объектов метаданных 1С (на основе нотации диаграммы UML);
• Масштабные изменения в действующей информационной системе (со множеством объектов метаданных) поможет реализовать модифицированная диаграмма компонентов с использованием терминов объектов метаданных 1С (на основе нотации диаграммы UML);
• Для сложных состояний (статусов) объектов системы – диаграмма состояний UML;
• Для проектирования новых сложных структур данных (множество новых объектов метаданных) ER-модель (в нотации Чена), а в особо сложных случаях – IDEF1X (Extendid).