
Решаем задачи автоматизации
На базе программ 1С
И собственных решений
А потом обслуживаем
По разумным ценам
Основатель и соучредитель группы компаний WiseAdvice Иван Тягунов рассказал на конференции Infostart Event 2019 о том, насколько применимы гибкие подходы Agile и Scrum к разработке ИТ-продуктов при автоматизации на 1С. По мотивам этого выступления подготовлена данная статья.
Применим ли чистый Scrum или Agile (а другого, исходя из канонов самого фреймворка, быть не может) в проекте автоматизации на 1С, если мы говорим о построении системы на базе многофункциональных прикладных решений от 1С:УТ и выше (по широте и сложности этой самой функциональности)?
Давайте разберемся, без чего Scrum невозможен, и какие элементы необходимо использовать, чтобы с уверенностью сказать, что это не Scrum, а «срам». По ходу мы сделаем выводы, возможна ли вообще автоматизация с применением методик Scrum, или неScrumные пути для 1С – все же более оптимальный выбор.
Вкратце рассмотрим терминологию и идеологию Scrum безотносительно к проектам 1С. Самое важное, что стоит знать про Scrum – его роли, артефакты, правила и события не могут быть скорректированы или заменены, поскольку это цельная, полностью описанная структура. Она подразумевает, что в проекте будет участвовать сплоченная команда, в состав которой обязательно должны войти:
Процесс разработки по Scrum базируется на 3 важнейших принципах:
Как это работает:
Все работы происходят строго по Бэклогу продукта – списку задач по разработке, ранжированных по важности. Составление бэклога требует установки четкого определения границ продукта и понятных всем участникам проекта показателей готовности его как в целом, так и его частей.
«Время приготовления» отдельно взятого элемента бэклога – спринт, который по рекомендации Scrum не должен превышать 5 недель. В течение спринта разработчики должны получать максимально полную обратную связь. Исходя из этого, определяется, нужны ли еще итерации в рамках данного спринта, или та часть продукта, которую за этот спринт разработали, уже соответствует критериям готовности, то есть готова к сдаче в непосредственную эксплуатации.
Каждый раз на кону стоит лишь один спринт, и если результат его не удовлетворителен, команда откатывается назад ровно на один спринт, поскольку результат предыдущего гарантированно принят к эксплуатации.
Звучит классно, но реально ли применение всех элементов фреймворка при автоматизации на 1С?
Приведем требования Scrum к команде:
Очевидно, что рабочая атмосфера, соответствующая данным требованиям, не складывается за один день. В реальности (и Scrum этого не отрицает) необходимо от 1 до 3 месяцев с момента сбора команды до начала полноценной, 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С? Можно попробовать:
Представить эти действия на практике довольно сложно, но отсутствие границ у целевого продукта не позволит составить бэклог и определиться с приоритетами, а также приведет к зависимости команды от внешних факторов. Описать границы системы автоматизации и схему ее взаимодействия с другими продуктами должен единственный владелец продукта. Это его прямая обязанность и важнейшее правило Scrum.
Может ли один человек дать такое описание многопользовательской системы, начиная с уровня системы 1С:УТ, и превосходящих ее по широте и сложности функционала? Ответ вполне очевиден. Но если владелец не описывает границы, это уже не Scrum.
Соотнесение каждого из важнейших требований Scrum с реальностью 1С вызывает ряд вопросов:
Ответы на эти вопросы подразумевают модификацию Scrum и нарушение его базовых принципов, что неминуемо снизит его целостность и эффективность. К тому же Scrum этого не допускает.
Что же делать, если Scrum все-таки не Scrum, то есть проект автоматизации на 1С не соответствует критериям Scrum?
Какие принципы Scrum стоит взять с собой в реальную жизнь?
Agile базируется на 4 ценностях и 12 принципах, из которых в реальной жизни применимы:
Где черпать вдохновение и какими инструментами стоит пользоваться, при разработке собственного фреймворка:
Для этапа предпроектного исследования:
В проектировании системы поможет:
Подпишитесь на рассылку и получайте самые свежие статьи 1 раз в месяц специально для вас