Искусство гибкой разработки ПО», вышедшей по мотивам его давней статьи из блога. Помимо распространенных инструментов, список задач бэклога можно хранить и в табличке excel (облако гугла) с доступами к редактированию для команды. И тут, значит, ловлю себя на мысли, что уже немало статей написал по продуктовой тематике, а про него забыл. Бэклог, король разработки, ее начало, то место, где у задачи появляется шанс “выйти на свет” к пользователю.

Владелец Продукта может отражать пожелания заинтересованных лиц в Бэклоге Продукта, но любой, кто хочет изменить приоритет элемента, должен обращаться к Владельцу Продукта. Для успешного выполнения обязанностей Владельцем Продукта все сотрудники составить бэклог организации должны уважать его или её решения. Решения, которые принимает Владелец Продукта, отражены в содержании и порядке Элементов Бэклога Продукта. Никто не может заставить Команду Разработки работать над другим набором требований.

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

Планирование Спринта

User Story (пользовательская история) — это упрощённый список требований клиента в виде истории, рассказанной на языке пользователя. По сути, это доходчивое описание, которому должны соответствовать новые фичи продукта, в противовес объёмной и сложной документации. В основе требований — удобство и ценность для пользователей. Требования в бэклоге продукта более абстрактные, поэтому эпик разделяется на пользовательские истории, они, в свою очередь, на отдельные задачи.

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

Как Вести Бэклог?

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

Сейчас немного непонятно, я не всех вижу каждый день, но уверен, что все выкладываются. Я просто стараюсь не грузить людей совещаниями – пускай все время, которое у них есть, они поработают. Но кто-то 12 часов поработает, кто-то не в настроении и только 5 часов.

Изменения Между Редакциями Руководства По Скраму 2016 И 2017 Годов

Реализована одна фича, но ее наполнение и результат — разные. Артем развивал продукты в финтехе (банки «Открытие», «Росбанк», «Россельхозбанк»), логистике и e-commerce, также консультировал компании «Лукойл» и «Работа.ру». Сейчас менторит перспективные IT-проекты в Preppy Incubator. Чтобы не утонуть в потоке задач, в первую очередь нужно выполнять те, которые помогут продукту быстрее «взлететь».

При этом важно, чтобы датчик температуры работал исправно и верно показывал температуру (обеспечивая прозрачность). Скрам – это фреймворк1, предназначенный для разработки, поставки и поддержки сложных продуктов. Это Руководство содержит описание Скрама, оно рассказывает о ролях, событиях, артефактах2 и правилах фреймворка. Создателями Скрама являются Кен Швабер и Джефф Сазерленд, которым также принадлежит авторство этого Руководства. — Не знаю, как вести разработку продукта по продуктовым гипотезам.

Это делается посредством управления работой, которая поступает команде, выбором и уточнением элементов Бэклога Продукта. Product Owner поддерживает Бэклог Продукта и заботиться о том, чтобы все знали, что в нем находится и какие приоритеты расставлены. Также стоит заметить, что Product Owner типично является человеком, наиболее приближенным к «бизнес стороне» проекта. Этот информационный элемент, в свою очередь, делится на несколько эпиков, содержащих требования пользователя и пользовательские истории.

Как Воскресить Бэклог Продукта, Чтобы Он Стал Идеальным?

Для каждого требования определяется приоритет (например, от 1 до 5). Самые приоритетные описываются детально, чтобы команда смогла оценить их и протестировать. Если говорить просто, то владелец продукта — центр принятия решения для проектной команды. Он должен быть единственным в рамках проекта, иначе принцип быстрого принятия важных решений нарушается. То есть приходил заказчик, описывал задачу, команда планировала реализацию и приступала к работе, следуя установленному техническому заданию.

Элементы вверху списка обычно лучше детализированы, чем элементы внизу. Чем детальнее и яснее описание Элементов Бэклога Продукта, тем точнее может быть их оценка. В свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем меньше они детализированы. Элементы Бэклога Продукта, которыми будет заниматься Команда Разработки в будущем Спринте, прорабатываются так, чтобы их можно было реализовать за время одного Спринта. Эти элементы считаются “Готовыми”, чтобы быть взятыми в Спринт на Планировании. Такой уровень прозрачности Элементов Бэклога Продукта достигается благодаря процессу Уточнения Бэклога Продукта.

Бэклог спринта — это список определенных задач по воплощению в жизнь выбранных элементов бэклога продукта. Это список для оптимизации, которой команда займется в ближайший спринт, а также описание, каким образом они эту оптимизацию будут реализовывать. Все члены команды собираются, оценивают бэклог продукта в целом и выбирают приоритетные задачи, которые необходимо выполнить в рамках текущей итерации. Так формируется список задач (бэклог) текущего спринта. Элементы бэклога продукта с более высоким приоритетом обычно более понятны и детализированы, чем те, что находятся дальше по порядку.

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

2 Продукт И Его Артефакты

Согласно этой теории, источником знаний является опыт, а источником решений – реальные данные. Мы собрали крупнейшее сообщество менеджеров продуктов и всех, кто занимается созданием полезных и прибыльных продуктов, чтобы вы могли учиться вместе с лучшими и делиться опытом. Создатель первого в России продуктового курса 360 Product Owner Binary District 2018. Методист и преподаватель с любовью к подходам, облегчающим жизнь, и полезным практическим знаниям.

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

Закон Конвея наводит нас на мысль о том, что использование разных инструментов для управления работой и стратегией, таких как JIRA для бэклога (ага!) и для дорожный карт – это плохая идея. Такой подход превращает бизнесы и организации, специализирующиеся на разработке, в подобие амбаров. Так сломайте эти амбары, увеличьте прозрачность и предоставьте своей команде контекст, который ей нужен для создания отличных продуктов. Чтобы это сделать – положите один единственный бэклог на видное место, и позаботьтесь о том, чтобы в нем было не больше 20 пользовательских историй.

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

Участники миитинга делают выводы о том, как шел процесс в команде и предлагает решения по его улучшению. Скрам Мастер отвечает за организацию и проведение этого митинга. Команда помогает ему составить адженду и распланировать кто и в какой последовательности что представляет. Человек, который владеет видением продукта, отвечает за то, что продукт движется в нужном направлении. Он ответственный за определение того, что же будет являться наиболее ценным и возможным продуктом к желаемой дате.

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

Обзор Спринта

Авторам останется только разработка, развитие и внедрение. Чем именно готов помочь Инфостарт, рассказал руководитель корпоративного отдела компании Рамин Курбанов. Не все, кто употребляют понятия Agile и Scrum, понимают, что они означают. Ходят слухи, что информационные технологии должны делать всех людей счастливей, приносить им удовольствие.

В общем, все руководствуются собственным видением и опытом. Scrum-команда в большинстве случае состоит из 5-9 человек, реже — из 3-4. В рамках скрама коллектив не может быть больше, потому что усложняется взаимодействие между каждым звеном, что негативно сказывается на эффективности работы. Поработав над списком задач в бэклоге, вы получите инструмент, который покажет вам ключевые приоритеты и поможет понять, над чем необходимо работать в первую очередь. Можно использовать любые удобные условные обозначения трудоемкости.

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

Все внесенные пункты и требования по проекту можно трансформировать, менять, классифицировать. Так в спринт отбираются самые приоритетные задачи и учитывается общая нагрузка. В Scrum это происходит на груминге, или разборе бэклога, — мероприятии, которое специально выделено программист ios на оценку задач и их отбор на следующий цикл. Обычно в их основу берутся “user story” они же пользовательские истории. Это позволяет использовать человеческий язык и не ограничивать команду в выбранном решении. Еще помогают лучше представлять использование продукта.

Автор: Ivan Sorochan