!Вперше в Україні: Thomas Wolf, CSO у HuggingFace🤗, на конференції Data Science fwdays'19
×Закрыть

Как настроить Jira для управления бэклогом: пошаговая инструкция

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

Должен сказать сразу, что эта методика не является эталоном или гарантией того, что ваши проблемы исчезнут. Но я четко знаю и с уверенностью могу сказать, что на момент написания статьи по этой методике было реализовано 4 проекта за последние 3 года, и метод работает! Вы можете модифицировать метод под свои нужды. Если не получается самостоятельно, тогда зовите меня :)

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

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

Основные рекомендации и пререквизиты

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

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

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

Поделитесь принципами работы с бэкклогом со своей командой. Расскажите, как вы будете управлять требованиями:

  • Какие будут процессы?
  • Кто/когда и на какие встречи должен приходить?
  • Что вы ожидаете от команды?
  • Чего команда должна ожидать от вас?
  • Когда и в каком виде вы будете поставлять им готовые требования на разработку?

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

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

Небольшая рекомендация для проектных менеджеров. Не пытайтесь сделать так, чтобы бизнес-аналитики и дизайнеры создавали подзадачи под конкретными пользовательскими историями, чтобы отслеживать затраченные часы. Это бесполезная затея в этом контексте, да и в принципе. Работа дизайнера и бизнес-аналитика достаточно творческая, поэтому четко сказать, куда и сколько времени сегодня уйдет у одного из них практически невозможно. По плану у аналитика на сегодня может быть разбор фичи «Х» на целый день, но по факту на ее анализ и описание может уйти 2 часа, а все остальное — на решение проблем с командой, дизайнером, клиентом и еще бог знает с кем.

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

По каждому из пунктов я буду приводить свои примеры и объяснение.

Доска (board) — используется для отображения «issues» в определенном виде. Есть два вида доски: Scrum и Kanban. Описанный концепт работает для типа Scrum. Поэтому при старте проекта выберете именно эту доску. Нам нужен Scrum из-за специфики того, как визуально разбита информация.

Версии (versions) — представляют временные отметки в проекте. В своей практике я всегда использую названия R.1 / R.Next. Все требования, которые появляются в процессе взаимодействия с клиентом в текущем релизе, должны быть зафиксированы и не теряться, поэтому те требования, которые не входят в текущий релиз, я помещаю в R.Next.

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

Теги (labels) — это ключевые слова, по которым можно легко сгруппировать/находить определенную информацию. Например, в своих проектах, я часто использую теги типа Web, APP, Integration. Чтобы быстро искать нужную информацию по разным запросам от разных участников проекта — QA, Клиента, Dev). Донесите всем, какие теги вы уже создали и зачем, а также расскажите команде, что беспорядочное создание тегов по любому поводу приведет к хаосу.

Компоненты (components) — это подразделы проекта. Они используются для разделения в рамках проекта на более мелкие части. Я использую компоненты для модулей в приложении, а уже внутри модулей есть эпики. Например, модулем может быть процессинг начисления бонусов или ядро по созданию бизнес-процессов.

Фильтр (issues and filters) — просто мощный инструмент, который позволяет упростить процесс поиска данных или аналитики данных на ежедневной основе. Рекомендую вам использовать быстрые фильтры на верхней панели самой доски.

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

Для пользовательской истории у меня вот такой был пример:

Для задач вот такой процесс:

Мы не пытались усложнить себе жизнь. Основной задачей было выполнить работу и минимизировать бюрократию на проектах.

Пользовательская история (story) — это отдельный тип сущностей, который я создаю на своих проектах. Он необходим для того, чтобы никого не путать терминологией. Вы также можете назвать это PBI (Product Backlog Item). Создание данного типа обусловлено внешним рынком. Людям, которые будут приходить на проект, будет намного легче привыкнуть к знакомым словам. Вы не будете путать понятия во время разговора о «тасках». Люди перестанут уточнять: это для разработчика «таска» или все же пользовательская история?

Задача / подзадача (task /sub task) — используется для более детального разделения пользовательской истории разработчиками и QA. О детализации задач идут целые войны! У каждого свой подход и методика, так же, как и по написанию пользовательских историй. Скажу пока одно: чем опытней разработчик, тем детальней описание задач и больше их количество под конкретной пользовательской историей. Задачи нужны в первую очередь самому разработчику, чтобы через неделю он мог вспомнить, что нужно сделать в определенной пользовательской истории.

Баг (bug) — этот тип сущностей служит для фиксирования проблем/недочетов во время разработки. О том, каким должен быть жизненный путь бага, какие должны быть уровни критичности бага и как управлять багами, мы поговорим в отдельной статье.

Схематическая структура Jira для управления бэклогом

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

Плюсы работы с пользовательскими историями прямо на «борде»:

  • Перетаскивание истории из одной секции в другую при помощи drag & drop.
  • Быстрый поиск информации через поиск самого браузера.
  • Быстрая фильтрация по нескольким параметрам: Релиз + Эпик + настраиваемый быстрый фильтр (Customer OK, Customer Review и так далее).
  • Быстрая работа с определенной пользовательской историей после ее нахождения.

Минимальный набор требуемых секций в моем концепте: Backlog, BA in Progress, Ready for Grooming, Ready for Development, Next Sprint #N, Current Sprint #N. Такая структура позволит вам решить множество проблем, которые связаны с поставкой требований на разработку. Любому члену проекта, будет понятно, что происходит с бэклогом, на какой стадии каждая фича или отдельное требование, где есть проблемы в процессе разработки требований.

Секции и их предназначение

Пользовательские истории двигаются снизу вверх (Backlog => Next Sprint #N).

Название секцииПредназначениеКомментарий
Backlog

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

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

Это могут быть пользовательские истории, к которым прикреплен имейл от кого-то с конкретными требованиями, фотографии из каких-то сессий. Может быть просто большой текст с рассказом о том, чего бы хотелось, или список.
BA in Progress (более детальное видео)В этой секции находятся пользовательские истории, над которыми идет активная работа клиента и вендора. Это, так сказать, рабочая область BA/PO, с которой он взаимодействует на ежедневной основе.Бизнес-аналитик берет в разработку одну фичу, над которой начинает работу. Обсуждение с клиентом, создание мокапов и декомпозиция фичи на пользовательские истории.
Ready for Grooming

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

На каждой сессии пленнинг покера, BA/PO выбирает подготовленные истории из этого списка и обсуждает с командой. Истории в этой секции уже должны быть проверены клиентом и получено согласие на их реализацию в таком виде.

Истории отсортированы сверху вниз по бизнес-приоритетам.

Для пользовательских историй, которые находятся в этой секции, должен быть прописан «Definition of Done».

Как минимум следующие пункты:

  • требования четкие и недвусмысленные;
  • мокап;
  • тестовые данные, если необходимо.
Ready for development

Эта секция нужна, для чтобы каждый участник проекта видел состояние готового бэклога на разработку.

В ней находятся пользовательские истории, которые уже утверждены и согласованы со всеми стейкхолдерами, а также команда предоставила свою оценку по каждой из них. Истории, которые успешно прошли «Grooming».

Истории отсортированы сверху вниз по бизнес-приоритетам.

Пример: велосити проекта составляет 100 сторипоинтов. Есть 3 команды, которые разрабатывают по 20/20/60 сторипоинтов в спринт. Общее количество пользовательских историй в данной секции — 15 на сумму 90 сторипоинтов.

Выводы:

  1. Вашей команде не хватает 10 сторипоинтов для полной загрузки каждой из команд.
  2. Вероятность того, что все эти пользовательские истории пойдут в следующий спринт — 50/50. Там могут быть технические зависимости или фичи с низким приоритетом.
  3. Вам необходимо иметь в данной секции в 1,5 больше сторипоинтов для ваших команд, чтобы они имели возможность выбрать и создать равномерную загрузку каждого из членов команды.
Next Sprint #NВ этой секции находятся пользовательские истории, которые BA/PO считает рациональным взять в разработку в ближайший спринт. Наполнение секции может меняться в любое время. Это так называемая буферная зона, чтобы ответственному человеку было легче понять, сколько и каких историй можно будет сделать для команды.Истории/дефекты отсортированы сверху вниз по бизнес-приоритетам, а затем и техническим.
Current Sprint #NЭто текущий спринт определенной команды. В нем находятся пользовательские истории и дефекты, которые ранее были выбраны командой на планировании. В этот спринт попадает большинство историй из «Next Sprint #N».Истории/дефекты отсортированы сверху вниз основываясь на технических зависимостях.

Каждая история разбита на задачи для FE, BE, QA.

Отдельно нужно сказать о секции «CR Bucket». Ее наличие зависит от того, оперируете ли вы таким термином, как «Change request», у себя на проекте или нет.

Критериями хорошо организованного бэклога являются следующие характеристики: Deep, Invest, Dive. Приоритизация, декомпозиция, определение зависимостей и прочее — достаточно большие темы для обсуждения. Я буду отдельно рассказывать о каждой из них. А пока более детально вы можете почитать тут.

Наполнение будущего спринта должно контролироваться ответственным человеком. Почему я не указал конкретную роль? Потому что в зависимости от проекта эта роль может называться по-разному и человек будет выполнять разные обязанности.

Для поддержания работоспособности такого решения вам необходимо использовать теги, а также рассказать о них своему клиенту (тем, кто будет отвечать за утверждение/подписание) требований. Я предлагаю следующий набор тегов и простенький процесс:

  • CR (Change request) — используется для того, чтобы помечать те пользовательские истории, которые считаются изменениями на требования. Ставится бизнес-аналитиком вендора.
  • HLE (High level estimate) — используется для того, чтобы показать, что оценка пользовательской истории является высокоуровневой и там есть определенные допущения. Ставится бизнес-аналитиком вендора.
  • Customer_Review — используется для указания клиенту, что пользовательская история готова к рассмотрению и обсуждению с клиентом. Ставится бизнес-аналитиком вендора.
  • Customer_Hold — используется для того, чтобы показать, что конкретная пользовательская история нуждается в доработке командой вендора. Ставится человеком со стороны клиента.
  • Customer_Approved — используется, чтобы отметить конкретную пользовательскую историю как утвержденную. Ставится человеком со стороны клиента.

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

Как это выглядит в реальности

Многие из вас могут сказать, что этот подход классный только на бумаге и схемах. Привожу вам пример реальной Jira:

Концепты похожего типа обговариваются на таких конференциях, как Atlassian Summit U.S. 2017 (вот видео) Если вы хотите идти в ногу со временем, вам просто необходимо начать разбираться в том, как это построить и как получить максимальную выгоду для своего проекта.

Почему это нужно

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

Команда разработки — это завод, который выпускает продукт итерациями. Чем хуже будет сырье для вашего завода, тем хуже конечный продукт или выше издержки на само производство продукта. Задумайтесь над тем, чтобы перестать разрабатывать программное обеспечение на аматорском уровне и перейти в высшую лигу с четкими процессами и оптимальными трудозатратами. Для этого не обязательно сразу звать Scrum/Agile coach или какого-то сертифицированного специалиста. Достаточно собраться командой внутри своего проекта и поговорить о проблемах, которые у вас сейчас существуют.

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

LinkedIn

49 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Достаточно наглядно

Должно быть два статуса open и closed.
Остальные можно добавить разноцветными метками.

✔️💯☕🎉🌲🍺🍭🍦💪🚂🎄👍🎁👺😎

Та можно и без статусов вообще :) кому как лучше ;)

Есть большое число успешных github проектов. Основное внимание уделяется тэгам. А статусов два open и closed. Вот пример: github.com/google/guava/issues

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

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

Именно эту работу я выполняю, потому и отписал, что уровень статьи рассчитан на непонятно кого. Даже джун БА должен уметь юзать джиру, это азы

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

неужели джира настолько сложная?

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

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

Вот и я с такой мыслью писал.
Спасибо

Почему в workflow нету on hold/rejected/blocked ?

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

Данные статусы не нужны лично мне были все это время.
HOLD — использую лейбл «Customer_Hold»
Rejected — если требование кем-то отклонено, то оно просто либо закидывается в конец бэклога либо удаляется вообще. Зачастую все требования всем нужны :) Если у вас есть такой кейс, значит можно добавить чтобы отследживать что конкретно было реджекнуто.
Blocked — работая с бэклогом каждый день, аналитик и так знает что от чего зависит.

Напишите свой опыт, будет классно.

Какая знакомая боль — настройка процессов...)
Такие вопросы:
1. Получается вся спецификация проекта хранится в юзер сторях в джире? Есть какой-то общий индекс? Пришел новый менеджер/разработчик — как структурировано можно смотреть/искать эти стори?
2. Насколько детализированы юзер стори? Описание фичи или ещё и сценарии, тест кейсы, критерии приемки?
3. Если фича меняется — это новая юзер стори или редактирование существующей? Если нет, как строится взаимосвязь с предыдущей и как понять что прошлая версия уже не актуальна?
4. Как понять что юзер стори реализована и выложена в лайв? Через связи к таскам и проверка что у них стоит статус done? А если юзер стори была плохо декомпозирована, и появилось ещё новые девелоп таски для стори?
5. Тимлид / Архитектор на каком этапе привлекается? Если фича была заапрувлена клиентом, а архитектор сказал что это «анриал» без мега рефакторинга — как стори возвращается назад на переработку (и повторное обсуждение с клиентом)?
5. Баги. Если баг в несоответствие с АС юзер стори, тут всё просто. Но как быть если баг — это просто неожиданное (необговоренное) поведение системы которое не понравилось клиенту — опять редактируем/уточняем уже реализованную юзер стори??

Спасибо за вопросы :) Видно что у вас хватает или хватало боли ;)
Тут расписывать ничего не буду, поскольку не обойтись двумя предложениями.
Следите за видео и статьями и все поймёте.
А вообще, могу приехать за отдельную плату и рассказать все )

После этого забавно выглядит приглашение задавать вопросы.

А вопросы то крайне правильные и актуальные. Интересно было бы послушать ваши ответы

Еще один велосипед, вполне разумный, но некоторые вещи достаточно специфичны.

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

Это вынуждает создавать очень искусственные stories с заранее ограниченным (и определенным) implementation scope. В итоге большая часть stories не будут иметь истинной ценности для клиента, а будут лишь supplementary/dependency для какой-нибудь верхнеуровневой story "показать пользователю цифры (которые мы рассчитали в story X, данные для расчета получили в истории Y, а права пользователя нарезали в Z)

Спасибо Александр. Все совершенно верно в том что

большая часть stories не будут иметь истинной ценности для клиента

. Это уже давно не так в мире разработки. Мы строим неприрывное производство.

Давайте рассмотрим вариант ремонта в ванной комнате.

Вам как человеку, который платит деньги за ремонт и будет пользоваться ванной, все предельно ясно. Должен быть душ, унитаз. раковина, стиралка и разные другие ништяки. Цвет ванной определили и места каждого из удобств тоже. То есть вы понимаете, что через 2-3 месяца вы сможете ходить в туалет, мыться и чистить зубы. Верно?

Теперь берем прораба и ремонтную бригаду. Им не обязательно реализовать вашу нужду хождения в туалет сразу и целиком. Вырвать себе волосы на голове, пока все что связано с хождением в туалет не сделано, они не уйдут из объекта. Звучит не логично? Верно?

Прораб принимает решение, разбить работы на некоторые части «Юзер стори». Устанавливаем унитаз, прикручиваем его к стояку и ставим бачок. Все, можно пописять и какать. А прикрутить болты, крышку унитаза можно и завтра. В спокойном темпе.

Так и тут. Это внутренняя кухня разработки продукта. Клиент так или иначе получит то что он хотел и в той последовательности в которой договорились.

Надеюсь вы предоставите другие примеры

Еще один велосипед

Хотелось бы взглянуть.

Да бог с ней, с ценностью для клиента, законченную фичу действительно не всегда так просто «впихнуть в спринт». Я вижу тут ряд других проблем:
— у вас нет репрезентации «настоящей истории-фичи», хотя бы для трекинга требований и связывания разрозненных разбросанных «беклог айтемов»
— вы делаете декомпозицию «фичи» на «беклог айтемы» без участия команды
— я вижу огромные риски при дальнейшей интеграции результатов имплентации разрозненных «беклог айтемов» в стиле «к пуговицам претензии есть» и «с моей стороны пули вылетели». это требует огромного оверхеда при детализации требований для каждого «беклог айтема» и очень больших усилий при изменении требований.
Хотя если есть цель раздуть штат менеджеров или разрабатывать студентами под руководством опытных лидов, то работать будет.

Суть в том, что современное качественное айти — это все еще не конвеер с прорабом и сложные задачи очень плохо декомпозируются на «в компоненте А Вася сделает это» а «в компоненте Б Петя сделает это». Отсюда и спрос на фуллстеков и распространенный (в том числе в FAANG) подход «пофиг на спринты, Петя берет таску и делает ее до упора сам, от сбора требований до релиза»

Спасибо. Попытаюсь прояснить ситуацию.

— у вас нет репрезентации «настоящей истории-фичи», хотя бы для трекинга требований и связывания разрозненных разбросанных «беклог айтемов»

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

— вы делаете декомпозицию «фичи» на «беклог айтемы» без участия команды

Да, совершенно, верно. Я могу себе это позволить в силу моих знаний, не только в бизнес анализе но и технических. Опять же, это делается для того, чтобы все делали свою работы. Разработчики писали код/ дизайнеры рисовали, а тестировщики тестировали. Я отнимаю время у команды только на груммингах в течение часа, где мы обсуждаем нюансы требований, а не как разбить фичу на юзер стори и что в каждой из стори должно быть. Я видел как это тяжело дается начинающим BA/PO, когда они приходят на встречи с командой и совершенно не понимают как построена разработка, задают глупые вопросы и обижаются на разработчиков за то, что они их заставляют что-то выкинуть из юзер стори или переписать ее в принципе.

— я вижу огромные риски при дальнейшей интеграции результатов имплементации разрозненных «беклог айтемов» в стиле «к пуговицам претензии есть» и «с моей стороны пули вылетели».

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

это требует огромного оверхеда при детализации требований для каждого «беклог айтема» и очень больших усилий при изменении требований.

Могу вас огорчить, в этом и заключается работа BA/PO — делать качественные документы, чтобы команда без лишних проблем могла разработать то, что необходимо. Представьте, вам разработчик вам будет говорить, что документировать код или писать тесты это оферхэд :) Возможно вам это ничего не скажет, но больших и профессиональных проектах это мастхэв.

Надеюсь, я донес мысль. Сложно в письменном виде обо всем рассказать.

Статья хорошо структурирована, довольно доходчиво, в меру техническая. Единственный момент который смущает, это трекинг сторей из «Секций» в виде отдельных спринтов. Разве не эффективней применять статусы?
Пишу это, так как планирую работу команды на 5-6 спринтов вперед и понимаю, что если на доске кроме основных спринтов будут ещё другие стори, но не в беклоге, это будет ту мач.
В остальном спасибо, ждем статью джира/конфлюенс. Интересно кто как настраивает внутренние вики-тулы)

Спасибо
Назар, для меня данный механизм намного удобней чем просто статусы. Так как я могу одним движение перетащить юзер стори туда куда мне надо :)
Самый большой плюс данного подхода — это визуальное понимание того, что твориться с бэклогом.
Есть отчеты, но в отчетах вы можете посмотреть в определенном виде, а дальше вам надо идти в джиру и менять все руками или использовать массовые изменения.
Буду на видео дальнейших показывать как это работает у меня.

Видео — было бы очень круто.
Спасибо за труд, очень хорошая статья!

Вадим спасибо! В принципе видео уже есть, но в другом контексте
youtu.be/ZNJOhrPw5GY?t=672
Тут я целый воркшоп сделал )))

Еще один аргумент, ты можешь сворачивать секции и работать только с той, которая нужна именно в данный момент.
Конкретно в твоем случае секция «Ready for development» будет примерно такого вида.
Если в среднем твоя команда делает 3-5 сторей в спринт, то у тебя в «Ready for development» должно быть около 30 юзер сторей.

Ну, это уже чисто дублированние функционала вкладки issues с заданным фильтром. Но у каждого свои методы :)

Как-то сложно все выглядит, но разумно. Получается у вас на проекте только специально обученные люди могут двигать таски в джире в определенный момент?

Только БА/ПО и все
а разработчики только внутри спринта.

Спасибо, хорошая статья!
У вас заказчик аппрувит стори, уже видя перед собой high level estimate по ней или нет?

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

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

У нас T&M, но тут дело не в доверии, а в том, что один из заказчиков часто ставит приоритеты по принципу «скажите мне, что будет быстрее готово — то и первый приоритет» :) поэтому нужно приходить сразу с оценками

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

Есть отдельный лаф хак, кторый называется "

High level estimation

". То есть на верхнем увровне вы даете оценку в сторипоинтах например 20 / 50 / 100 / 300.

Затем после того, как выбрали что делать первым, делаете нормально шаг за шагом.

Да, мы примерно так и делаем. Интересно было ,насколько часто это встречается в природе

Что именно? Хайлевел эстимейт?
У меня все время и на всех проектах ))
Причина тому, фикс прайс проекты и проданный скоуп )))

Хорошая статья!
Давайте попробуем продолжить эту историю:
Допустим, Фикс прайс проект состоит из 5 фич, оценили High level estimation 2,5 месяца (каждая фича по спринту (по 2 недели)). Подписали контракт.
Начинаем работу, декомпозируем первую фичу оказывается заказчик хочет летающих единорогов в 3Д. Что по оценкам займет вместо 2 недель — 4 недели. Что делать? вроде и в скоупе, вроде и обговаривали, но единственный выход списывать на непредвиденные риски и сьедать бюджет?

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

Для этого существует процесс «change management», который до начала проекта вы должны были согласовать с клиентом, ну или как минимум рассказать о нем :) Вот он и является инструментом, который помогает отсекать растущий скоуп.

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

Интересно, почему QA задают вопросы, а БА нет? )))

Ніколи не настроював, але завжди було цікаво, як це робиться.
Тому автор, дуже тобі дякую! :)

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

Так, я розумію, мене цікавило в тому числі і це теж.
Дякую)

Спасибо за статью. Лайк! ;)

Когда лайкает CEO — это в тройне приятно )))

Подписаться на комментарии