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

Меня зовут Иван Тягунов. Я – основатель и соучредитель группы компаний WiseAdvice.

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

У нас достаточно крупная компания – где-то 800 человек, расположенных в разных городах страны – в основном, в Москве.

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

Стыд и Scrum

Стыд – именно такое чувство должны испытывать те руководители ИТ-подразделений, которые бескомпромиссно утверждают: «Мы работаем по Scrum» или «У нас Agile». Я утверждаю, что 99% тех, кто об этом говорит бескомпромиссно и без всяких оговорок, на самом деле не читали эти фреймворки и концепции и вообще очень мало знают об этом. Поэтому в большинстве случаев они не используют этот фреймворк в его чистом виде, а используют что-то иное, притом чаще всего не используют то, что нужно.

Но Scrum и Agile сейчас в моде. Они в тренде, по ним хайп. Каждый хочет быть Scrum. Каждый хочет быть Agile. Эта вся история начинает передаваться от одного к другому, и уже говорить обратное как-то не модно – на тебя странно посмотрят: «Ты что, работаешь не по Scrum? Как такое может быть?»

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

Scrum-команда

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

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

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

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

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

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

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

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

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

Scrum-мастер

Scrum-мастер. Следующий ключевой элемент этого фреймворка.

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

Языком фреймворка – это «лидер-слуга», коучер, фасилитатор.

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

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

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

Что это означает?

Я сейчас не буду рассказывать чистую теорию про Scrum, я буду рассказывать, как это применяется в нашей жизни. Наш контекст – это автоматизация бизнеса на платформе 1С. Поэтому для оказания услуг владельцу продукта Scrum-мастер (кроме того, что он должен быть мастером Scrum) обязан знать как техники анализа требований и проектирования ИТ-систем, так и основы автоматизируемой предметной области. И, конечно, основы платформы 1С.

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

Обратите внимание, Scrum-мастер должен заниматься только этой деятельностью 100% времени, без совмещений, на full time. Если вы назначили кого-то Scrum-мастером, ничего не получится. Все строится на том, что этот человек постоянно общается с коллегами из других компаний, постоянно занимается именно этой деятельностью, чтобы как можно лучше понять Scrum и научиться его применять.

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

Поэтому если вы хотите работать во фреймворке Scrum, Scrum-мастер вам нужен обязательно на full time.

• Не смогли продать идею руководству, что нужен Scrum-мастер?
• Не удалось выделить бюджет на него?
• Не получилось выделить время кого-то, чтобы он научился Scrum?

Тогда просто забываем о фреймворке Scrum, потому что работать он в чистом виде не будет.

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

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

• Он занимается описанием элементов бэклога продукта в понятном виде (формулирование этих элементов)
• Управляет порядком элементов бэклога и структурой
• И он отвечает за то, что команда разработки в достаточной степени понимает весь этот бэклог.

Это очень трудоемкая история.

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

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

Это очень трудоемкая роль.

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

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

Это очень сложная роль.

Один владелец продукта может вести от одного до двух-трех продуктов максимум, в зависимости от объема команд разработки.

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

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

• Сотрудник ИТ-службы? Ему не хватит видения продукта, знаний предметной области, маловероятно, что ему будут даны полномочия на приоритезацию задач (элементов бэклога).
• Если же это будет бизнес-заказчик, ему не хватит времени, у него будет недостаток ИТ-компетенций.

Поэтому владелец продукта – это очень сложная роль во фреймворке Scrum.

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

В данном случае:

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

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

Проектирование. Владелец продукта должен

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

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

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

Команда разработки – следующий важный элемент Scrum. В чем суть? Тут показаны формулы:

1 бэклог = 1 владелец продукта

1 владелец продукта = 1-3 продукта

1 команда разработки = 1 бэклог

Это такая система уравнений, которая дает нам итог – одна команда разработки должна заниматься одним (максимум до трех) продуктом при условии, что у них один владелец. То есть команда разработки не может работать с двумя владельцами продуктов. Поэтому 2-3 продукта еще может быть, но владелец у них должен быть один.

И тут начинается ситуация – команда разработки, если мы посмотрим на фреймворк, должна состоять от 3 до 9 человек. Менее трех считается, что все это бессмысленно. Более 9 считается, что там резко падает эффективность.

Напомню, что в эти 3-9 человек не включается ни владелец продукта, ни Scrum-мастер. То есть, если мы посмотрим на общий масштаб всей этой истории, в контексте которой она должна нормально работать, то общая численность коллектива должна быть от 5 до 11 человек. Это – одна команда, включая дополнительные роли в виде Scrum-мастера и владельца продукта.

Дополнительные требования к команде разработки

Команда разработки должна быть самоорганизующейся и кроссфункциональной.

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

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

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

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

Продукт

Тут начинается самое интересное – что же такое продукт в терминах Scrum? Это вообще самый мутный и сложный вопрос.

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

Я утверждаю, что прикладных решений на основе типовых 1С:УТ и выше (выше по широте и сложности функциональности) не может быть всего одного владельца продукта. Особенно, когда речь идет о многих десятках и сотнях пользователей. Это слишком крупные системы, чтобы один человек управлял бэклогом вплоть до его формулирования, а это – неотъемлемая, неделегируемая обязанность владельца продукта.

Хотел бы я увидеть такого владельца, который сформулирует весь бэклог на систему с 200 пользователями, которые работают в десятке функциональных областей (10 отделов различных компаний). И какой-то абстрактный человек формулирует бэклог на всю эту историю? Мне кажется, это нереально.

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

И тут начинается самое интересное – как установить границы этого продукта внутри прикладного решения? Это «танцы с бубнами». Потому что нужно:

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

Это очень сложный вопрос – выделить внутри одного прикладного решения границы.

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

Другие значимые элементы Scrum

Какие еще есть элементы Scrum?

Scrum опирается на три кита:

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

Предполагается, что:

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

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

Что же происходит в реальном мире автоматизации бизнеса на платформе 1С?

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

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

Можно ли в мире автоматизации бизнеса выполнять вышеуказанные требования Scrum?

Вопросы по бэклогу.

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

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

Это – вопросы. Некоторые ответы на них мы сейчас получим.

Что важно понимать? Роли, артефакты, правила и события Scrum не подлежат изменению. Это означает (прямая цитата из Scrum), что «Scrum является цельным фреймворком. Если вы оттуда взяли только некоторые элементы или какие-то элементы видоизменили, то это уже не будет считаться Scrum».

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

Итоговый чек-лист по применимости фреймворка Scrum.

• Возможность установления границ продукта.
• Кросс-функциональная команда на срок от года.
• Компетентный и уполномоченный владелец продукта как выделенная роль.
• Компетентный Scrum-мастер как выделенная роль.
• И четкая определенность по другим ключевым и взаимосвязанным вопросам.

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

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

Потому что эта эффективность может стать отрицательной.

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

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

Что ценного можно взять из Scrum

Что же самое ценное в Scrum?

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

В Scrum есть что взять.

Что самое главное стоит заимствовать из общих ценностей и принципов Agile

Вы знаете, что в Agile у нас четыре ценности и 12 ключевых принципов, которые мало кто читал. Я рекомендую брать в работу следующие принципы:

• Готовность к изменениям важнее следования первоначальному плану. Изменение требований приветствуется, даже на поздних стадиях разработки. Лучше вовремя поменять требования, чем сделать не то, что нужно.
• Непосредственное общение как одна из ценностей Agile – это наиболее практичный и эффективный способ обмена информацией. Не нужно этих длинных переписок, много букв. Личное общение – самый эффективный способ коммуникации.
• Простота – искусство минимизации лишней работы. Важно только различать простоту как силу компетенций и опыта и простоту как неконструктивное упрощение из-за недостатка ума или лени.

Какие еще принципы Agile я рекомендую использовать в работе?

• Работающий продукт важнее исчерпывающей документации. Что я рекомендую? В части пользовательской документации использовать видео и записывать его только при первичном обучении (эффективнее всего обучать по ролям, основываясь на user story).
• Еще интересный принцип – строить документацию от обратного – от частых запросов на Service Desk. Ну и, соответственно, желательно в формате видеоинструкций.
• В части анализа требований рекомендую документировать только то, что реально важно. Не нужно использовать какие-то чужие шаблоны (если не понимаете, зачем). Формулировать в документированном виде нужно только самое главное, как можно короче.

Другие источники для создания собственного фреймворка

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

Рекомендую использовать:

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

Для этапа сбора и анализа требований (эти этапы вообще никак не формализованы во фреймворке Scrum) рекомендую:

• Использовать mind-карты, как impact-технику (технику извлечения знаний).
• Рекомендую ознакомиться с набором лучших практик BABOK – этот фреймворк содержит техники сбора требований с менеджмента.
• На стыке этапов анализа требований и проектирования системы очень рекомендую ознакомиться с фреймворком SWEBOK. Его мало кто знает, но если вы его загуглите и почитаете, вас он, я думаю, очень заинтересует. Наверное, это наиболее полный фреймворк на этапах анализа требований к проектированию системы.
• Для укрупненного планирования, если вам так нравится слово Scrum, рекомендую ознакомиться с методологией Scrumban, потому что она хорошо закрывает более длительные этапы и их декомпозицию по принципу так называемых «ведер». Ознакомьтесь с ней подробнее – в данных доклад это не уместится.

Что необходимо знать для этапа проектирования системы

Что еще из нашей практики рекомендую использовать?

• Для бизнес-процессов – там все понятно, BPMN или Aris.
• Для пользовательских интерфейсов – прототипы на основе user story или JTBD.
• Для отчетов тоже есть несколько хороших техник – они описаны на слайде.
• Для интеграций тоже есть свои различные нотации, диаграммы и т.д. Надо просто копать и делать свои правила использования лучших практик и других знаний.

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

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

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.