Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Similar to Work with requirements in terms of Agile transformation
Similar to Work with requirements in terms of Agile transformation (20)
Work with requirements in terms of Agile transformation
- 1. Работа с требованиями в условиях Agile трансформации Мандрика Андрей, CSPO Product owner,
- 2. Мандрика Андрей Contacts: • andrii.mandrika@gmail.com • andrey.mandrika@betlab.com • linkedin.com/in/andrii-mandrika • Skype: mandrikaandrew
- 3. «Трансформация». Что же это такое? Термин «Трансформация» или синоним «Метаморфоз» толковый словарь тракутет, как – «глубокое преобразование строения организма (или отдельных его органов), происходящее в ходе индивидуального последовательного развития.»
- 4. «Гибкая организация». Что же это такое? Гибкая организация – это культура, базирующаяся на ценностях и принципах Agile, которая поддерживается экосистемой организации и проявляется через персонал и его организационные привычки
- 5. «Agile Трансформация». Что же это такое? Процесс изменения организации для перехода из одной доминирующей культуры в другую.
- 6. Channels SportsbookTrading ToolsMath Core CRM Payments Wallet Marketing Risks management
- 8. Этап № 1: Scrum, but… • Две команды – два новых продукта. • Куча непонятных митингов. • «Супер кросс-функциональные» программисты: ПО, Скрам-мастер, дизайнер, верстальщик и программист в одном лице. • Сами придумали продукт, без виденья, целей и требований • Непроработанные задачи без критериев приемки и готовности. • Смысл показывать заказчику и пользователям разработанные фичи?
- 9. Этап № 1: Scrum, but… Сбор требований • Ключевые заинтересованные лица и инициаторы идей: • СТО&PO • Команда разработки • Источники требований: • Собственный предыдущий опыт • Конкуренты • Проверка гипотез: • Что?! Каких гипотез?! • Ограничения: • Отсутствие понимания основ бизнес анализа и текущих бизнес процессов клиента ?
- 10. Этап № 1: Scrum, but… Организация беклога • Используемые типы задач: • User stories • Tasks • Инструменты работы с задачами: • Jira (Backlog only) + физическая доска • Виденье и цели: • На основе своих предположений • Эскизы и детализация: • Отсутствовали
- 11. Этап № 1: Scrum, but… Проблемы и решения Проблемы Непонимание предметной области Отсутствие виденья продукта Отсутствие коммуникации с бизнесом Плавающие процессы Требования недостаточно проработаны для имплементации Требования не соответствуют ожиданиям Решения Изучение текущих бизнес процессов клиента. Составление высокоуровневого роадмапа продукта Выделение ключевых лиц со стороны бизнеса Четкое соблюдение всех процессов и практик DoR, DoD и AC для задач перед разработкой Просмотр реализации в середине спринта
- 13. Этап № 2: Scrum • Четыре команды – 3 новых продукта. • Собрания: грумминг, планирование, daily scrum, scrum of scrums, sprint demo, retro • Отдельный ПО и Скрам-мастер, но дизайнер, верстальщик и программист в одном лице. • Сформировали виденье продукта, построив высокоуровневый роадмап • Иногда отсутствие критериев приемки и готовности. • Первые демо представителям клиента
- 14. Этап № 2: Scrum Сбор требований • Ключевые заинтересованные лица: • СТО&PO • Консультант от клиента • Источники требований и идей: • Фокус группа • Консультант от клиента • Функционал текущей версии продукта • Проверка гипотез: • Консультант от заказчика • Ограничения: • Не полное понимание текущих особенностей бизнес процесса
- 15. Этап № 2: Scrum Организация беклога • Используемые типы задач: • Activities -> Epics -> User stories -> Sub tasks • Инструменты работы с задачами: • StoriesOnBoard • Jira (Backlog only) • Виденье и цели: • Создали высокоуровневый roadmap всего продукта • Цели: разработать 1й модуль продукта • понять настоящую «глубину кроличьей норы» • Эскизы и детализация: • Начало работы с дизайнером • Предварительная подготовка задач перед разработкой
- 16. Этап № 2: Scrum Проблемы и решения Проблемы Непроверенные гипотезы в разработке Сопротивление изменениям в текущем бизнес процессе Отсутствие интереса пользователей к незаконченному продукту Все еще не до конца ясен объем и функционал продукта Как интегрировать новый продукт? Решения Согласование всех идей и требований с клиентом Совместно с компетентным представителем бизнеса определяем приемлемый бизнес процесс Постоянно информировать бизнес о состоянии разработки продукта Выделение MVP продукта Технический анализ текущего решения
- 18. Этап № 3: ??? • 4 продуктовых группы: 7 команд – 2 новых продукта – 2 на продакшене • Появились первые меж командные взаимодействия. • Необходимо как-то синхронизировать и управлять требованиями на разных уровнях и от разных заинтересованных лиц
- 20. Этап № 3: Sсaled Agile • Portfolio Planning, Program increment planning, System demo, Inspect and Adapt session • Infrastructure team, DevOps team, UX team, System architect, RTE • Сформировали виденье + MVP продукта + roadmap +зависимости • Несколько точек входа требований от клиента • Постоянные сессии демо и валидации требований • Первые интеграции внутри новой платформы
- 21. Этап № 3: Sсaled Agile Сбор требований • Ключевые заинтересованные лица: • Источники требований и идей: • Проверка гипотез: • Функциональные руководители клиента • Продакт менеджер клиента • Консультант от клиента • Рядовые сотрудники бизнеса • Функционал текущей версии продукта • Системный архитектор • Программисты текущей версии платформы • Представители других команд • Ограничения: • Много входов для идей и требований • Непомерные желания клиентов • Разные приоритеты задач в разных командах
- 22. Этап № 3: Sсaled Agile Организация беклога • Используемые типы задач: • Themes -> Initiatives -> Epics -> User stories • Инструменты работы с задачами: • Jira (Backlog + Structure + BigPicture) • Confluence • Balsamiq + Sketch • Виденье и цели: • Вся структура проекта отображена в Structure • Намечены промежуточные цели проекта • Большинство зависимостей показаны в Gantt • Клиент имеет доступ к высокоуровневому беклогу
- 23. Этап № 3: Sсaled Agile детализация и валидация требований идея BRD
- 24. Этап № 2: Sсaled Agile Проблемы и решения Проблемы Несколько входов для идей и требований Большое количество зависимостей Несовпадение приоритетов у команд Готовность клиента работать только с готовым продуктом Решения Фасилитация заинтересованных сторон Раннее определение и информирование о зависимостях и рисках всех заинтересованных Квотирование работ Вовлекать клиента в разработку продукта
- 27. Спасибо за внимание! Andrii Mandrika Business Analyst / Product owner Contacts: • andrii.mandrika@gmail.com • andrey.mandrika@betlab.com • linkedin.com/in/andrii-mandrika • Skype: mandrikaandrew
Editor's Notes
- Всем доброго утра и продуктивного дня. Меня зовут Мандрика Андрей. И сегодня я вам предлагаю поговорить об особенностях работы с требованиями в условиях Аджайл трансформации.
- Но сначала расскажу пару слов о себе. Последние 2 года я работаю в одной молодой и перспективной Украинской продуктовой компании под названием Бетлаб на позиции Продакт овнера. До этого прошел путь от техникал райтера, тестировщика, затем дотНет разработчика, скрам мастера и вот дошел до продакт овнера. В общем попробовал себя во всем.=) Ну хватит обо мне, давайте уже начинать.
- Итак работа с требованиями в условиях, так называемой аджайл трансформации. Если с термином «Работа с требованиями» у ПМов и продакт менеджеров более менее все понятно, то с аджайл трансформацией у многих могут возникнуть вопросы. Поэтому предлагаю, дабы немножечко проснуться, сначала разобрать ЭТО понятие. Данный термин состоит из 2, на первый взгляд, волне понятных слов. Трансформация и аджайл. Но для того чтобы лучше прочувствовать их взаимосвязь давайте все же рассмотрим эти 2 термина отдельно. Итак, Трансформация или же, мне больше нравится его такой синоним как Метаморфоз, трактуется толковым словарем, как – «глубокое преобразование строения организма (или отдельных его органов), происходящее в ходе индивидуального последовательного развития.» Довольно актуальное описание. Ведь, действительно, можно сопоставить организм – бизнесу или конкретной организации, где бы отдельными органами были подразделения или команды. Что еще характерно – это индивидуальное последовательное развитие. Рано или поздно, но абсолютно любая организация начинает развиваться, а как следствие – изменяться и адаптироваться к новым условиям, или же погибать. И в большинстве случаев такое развитие является последовательным или эволюционным. Изменение не может произойти спонтанно. Это естественный процесс. Такую же проекцию можно сделать и на процесс управления проектом, например, по разработке программного обеспечения. Ну а, как мы знаем, в современных условиях, в большинстве случаев лучше всего помогает справится с различного рода изменениями в организации именно гибкая методология разработки или Аджайл.
- Тогда что же такое гибкая организация? Гибкая организация – это в первую очередь культура, базирующаяся на ценностях и принципах Agile, и которая поддерживается экосистемой организации и проявляется через персонал и его организационные привычки. Это говорит нам о том, что аджайл это не определенные практики и методы – это целая культура и мировоззрение. При чем доминирующая культура. И эту культуру в организации необходимо растить и развивать. Это дает свои плоды в виде улучшения уровня взаимодействия между конкретными людьми в организации, а как следствие - улучшение эффективности работы всего бизнеса, который, в том числе, и отражается на работе с требованиями.
- Таким образом, аджайл трансформация – это процесс изменения организации для перехода из одной доминантной культуры в другую. Еще одним подтверждением правильности объяснения данного процесса является одно ключевое слово в трактовке термина «Трансформация» – «Глубокое преобразование», что подразумевает всеохватывающее изменение на всех уровнях организационной структуры. Это высказывание касается как отношения с заказчиками и клиентами, так и эффективной работы с требованиями ради их преобразования в готовый продукт, который удовлетворяет ожиданиям бизнеса. А как оказывается, работа с требованиями может поддаваться изменениям наряду с изменениями культуры в организации. И не всегда эти изменения ведут к позитивным результатам. Поэтому сегодня я хочу поделиться с вами своим опытом работы с требованиями в условиях постоянных изменений в проекте и в организации.
- Перед тем как рассказать о основных этапах изменений в нашей компании и как они влияли на подходы, применяемые для работы с требованиями, я бы хотел сначала рассказать ее небольшую предысторию. Наша компания занимается разработкой комплексных решений для автоматизации иГейминг бизнеса, в частности спорт беттинга. Мы на 100% украинская компания. Идея создания подобной организации обусловлена тем, что на данный момент, на мировом рынке программного обеспечения отсутствует полновесное и гибкое решение для обеспечения всего цикла функционирования букмекерского бизнеса, которое бы удовлетворяло современным условиям работы в этой сфере. А имея сложенную команду профессионалов, которые хорошо знают предметную область и бизнес – такая задача показалась вполне под силу. Целью проекта является написание букмекерской платформы, которая бы охватывала все аспекты данного бизнеса. Этим и обусловлена структура платформы, которая состоит из таких частей как кор, в который входит и срм, управление платежами, кошелек, маркетинг, анти-фрод, и т.д., затем спортсбук – часть которая отвечает за подготовку и ведение операционной деятельности связанной с процессом беттинга, Трейдинг тулз – это такой себе рабочий инструмент трейдера, с помощью которого он управляет процессом приема ставок, Затем модуль математики – который осуществляет разработку и поддержку неких математических алгоритмов для расчета коэффициентов для трейдинга, и собственно сайт, через который игроки смогли бы сделать свою заветную и победоносную ставку. Выглядит все достаточно просто, но поверьте – это только верхушка айсберга. Проект очень амбициозный и масштабный. Это большое ентерпрайз решение, которое должно работать быстро и сообща. И перспективой такого продукта есть выход с ним на мировой б2б рынок. Ибо спрос на него есть. И в этом стремлении у нас уже есть пока 1 потенциальный клиент, который согласился перевести свой текущий бизнес на эту новую платформу. Данный клиент на момент начала проекта работал на системе, которая разрабатывалась более 10 лет назад. Система уже очень с трудом модифицируемая и медленная. За счет ее неповортливости бизнес терял и продолжает терять каждый день реальные деньги и достаточно немаленькие. Вот тут то мы и вызвались помочь. Новый продукт стал разрабатываться с самого нуля. В общем мы собрали команду людей, каждый из которых в прошлом так или иначе сталкивался с букмекерскиим бизнесом. Работать мы решили по скраму, при этом не имея раньше подобного опыта. Хотя уже тогда определенные участники команды разделяли принципы аджайл. Но отдельные – это еще не все. Поэтому дальше нас ждала долгая и безумная дорога на пути к полноценной аджайл трансформации. До текущего момента за полтора года работы нам пришлось пройти несколько этапов нашего развития. Дальше мы кратко пройдемся по каждому из них и определим ключевые особенности каждого.
- Этап номер 1, от 1 сентября 2014 года. Итак собрались мы с коллегами и давай думать, как же нам поднимать такой проект? С чего начать? Очевидно, что с выбора процесса.
- Тогда под руку очень кстати подвернулась книга Майка Кона «Scrum. Гибкая разработка ПО». Детально прочитав ее наш СТО взял ситуацию в свои руки и давай внедрять направо и налево. Даешь спринты, стенд-апы, юзер стори, грумминги, планнинги и т.д. Часть из этих практик мы и до этого применяли в прошлых проектах, но как-то это все было непринудительно. А тут миллион разнообразных митингов и мероприятий. Программисты жаловались на то, что им некогда работать. Для всех это было реальным шоком, но тем не менее вызывало интерес. Около 2 месяцев длился наш шторминг. Нас меняли, а мы сопротивлялись. Людей сразу не хватило на все обязательные роли, поэтому достаточно часто мы слышали фразы типа: а сейчас я снимаю шапку СТО и одеваю шапку скрам мастера или продакт овнера или архитектора. Часть практик не давалась нам вообще и мы от них отказывались. Именно поэтому этот период именуется достаточно распространенным термином в аджайл сообществе СкрамБат. То есть вроде скрам, но что-то не делается или что-то не работает так как должно. Хотя мне больше нравится немножечко преобразованный термин СкрамНо=)
- К 9му слайду наконец-то добрались до требований.=) Значит, что касается требований – то их не было никаких и не в каких проявлениях. Хотя все же одно требование от клиента было. Сделайте мне новую платформу, которая была бы как старая, только лучше=) И вроде имея свободный доступ к клиенту и к его работающему бизнесу надо было начать с самого начала и проанализировать, из чего же состоит данный продукт, как на этом продукте работают люди и какие проблемы у них возникают. Но зачем? У нас же скрамно. И так сойдет. И мы решили придумать продукт на основании своих каких-то гипотез и предположений, которые базировались на вроде как богатом предыдущем опыте отдельных членов нашей команды, а также на основании беглого изучения продукта конкурентов. Нам пришлось это сделать, ведь мы же как-то определили, что наш продукт нужен на рынке. Поэтому мы приблизительно прикинули, что должно быть первым и сразу же начали это разрабатывать. На удивление, первый спринт прошел успешно и мы немного расслабились и думали, что и дальше все будет отлично. Но на результат надо работать и достаточно усердно. Поэтому уже со 2 спринта все начало систематически рушиться. Этому сопутствовало отсутствие понимания основ бизнес анализа, а также текущих бизнес процессов клиента. Мы хорошо знали только 1 маленькую часть текущего бизнес процесса, в которой были задействованы во время предыдущего проекта с этим же клиентов, и только догадывались как дела обстоят с остальными частями.
- Задачи для программистов были соответствующего уровня детализации. Хотя мы уже тогда договорились, что все задачи мы описываем в формате юзер сторей. Сначала мы по классике записывали истории на маленьких стикерах в классической формулировке и без всяких дополнительных деталей и хоть каких-то предварительных эскизов. Это же скрам=) НО. Детали добавляли уже программисты в процессе разбора этих историй, но поскольку у программистов было еще меньше понимания предметной области, бизнес процессов клиента, та и не было предыдущего опыта работы с таким процессом, то порой ожидания от сделанного отличались от реализованного функционала.
- Таким образом, можно выделить основные проблемы этого периода и их возможные решения. Которые мы внедрили на следующем этапе нашего развития на пути к Аджайлу. Итак, первое, и я считаю – самое главное – это непонимание предметной области. Ну нельзя делать хорошо то, что ты не понимаешь до конца. Или понимаешь но с точки зрения определенного ограниченного контекста. Далее идет последствие первого пункта. Поскольку ты не понимаешь как оно работает сейчас, то ты и не можешь понимать, как оно должно работать и что туда должно входить. А третий пункт, на самом то деле, является причиной первых 2. Надо понять простую истину, что бизнес – это ваш друг. Который при успешно выстроенных отношениях может помочь и вам и себе самому. Та и с другой стороны, зачем мы разрабатываем те или иные продукты – чтобы ими кто-то пользовался и чтобы они приносили пользу. И для разработки, как минимум, приемлемого решения необходимо знать кто им будет пользоваться и что он ожидает получить от этого использования. Далее, плавающие процессы. Процесс будет только тогда успешных, когда он превратится в некую привычку у участников этого процесса. А как мы знаем, привычки не формируются за 1 день. А для ее выработки необходимо безукоризненно выполнять одни и те же действия на протяжении некоторого времени. То же самое и с процессами. Только после того, как вы хорошо поймете текущий процесс вы сможете начать его модифицировать и улучшать.