Меня зовут Иван Тягунов. Я – основатель и соучредитель группы компаний 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. Больше статей можно прочитать здесь.
Приглашаем всех принять участие в тематических митапах Инфостарта: infostart.ru/events/
