Поиск задач в JIRA (простым языком). Часть 2: Продвинутый поиск
Структуру JQL-запросов без примеров сложно понять специалистам, не знакомым ранее с JIRA.
Мы уже успели рассказать про быстрый и базовый поиск. Теперь же прейдем к самому мощному из трех методов — к продвинутому поиску.
В этом режиме вы можете указывать критерии, которые нельзя задавать в остальных предыдущих двух режимах (например, сортировку ORDER BY). Но придётся освоить создание структурированных запросов с помощью JIRA Query Language (JQL).
А если вы находитесь в режиме «базового» поиска, нажмите кнопку «Продвинутый»
1. Создание JQL-запросов
Простейший запрос на JQL состоит из поля, за которым следует оператор, а затем одно или несколько допустимых значений для этого поля. Например:
Такой запрос поможет найти все задачи проекта «YAT». Здесь использовано поле «project», оператор эквивалента «=» и допустимое значение «YAT».
Более сложный запрос может выглядеть так:
project = «YAT» AND assignee = currentuser()
Так мы отберём все задачи проекта «YAT», назначенные на текущего пользователя
(то есть на вас). В запросе содержатся: логический оператор «AND», поле «assignee» для отбора задач по текущему пользователю, оператор эквивалента «=» и функция «currentuser()», возвращающая имя текущего пользователя системы.
При создании запроса в режиме «продвинутого» поиска JIRA показывает список всех возможных операторов для поля запроса.
Также JIRA показывает список доступных значений для полей «AffectedVersion«, «FixVersion«, «Components«, кастомных полей формата «Version» и выпадающих списков.
При использовании в поиске полей формата «User» JIRA позволяет найти необходимого пользователя по его фамилии.
Вы можете использовать круглые скобки в сложных JQL-запросах. Например, если хотите найти все разрешенные задачи в проекте «SysAdmin», а также все задачи (любого статуса, любого проекта), назначенные в настоящее время системному администратору (admin), то можете использовать круглые скобки, обозначая приоритет логических операторов в запросе.
(project=SysAdmin AND status=resolved) OR assignee=admin
В JQL есть зарезервированные символы.
Внимание!
Также в JIRA есть зарезервированные слова.
Если в тексте поиска упомянуто одно из перечисленных ниже слов, этот текст нужно выделить либо двойными кавычками («. «), либо одинарными (‘. ‘).
Список зарезервированных слов:
| A | «abort», «access», «add», «after», «alias», «all», «alter», «and», «any», «as», «asc», «audit», «avg» |
| B | «before», «begin», «between», «boolean», «break», «by», «byte» |
| C | «catch», «cf», «char», «character», «check», «checkpoint», «collate», «collation», «column», «commit», «connect», «continue», «count», «create», «current» |
| D | «date», «decimal», «declare», «decrement», «default», «defaults», «define», «delete», «delimiter», «desc», «difference», «distinct», «divide», «do», «double», «drop» |
| E | «else», «empty», «encoding», «end», «equals», «escape», «exclusive», «exec», «execute», «exists», «explain» |
| F | «false», «fetch», «file», «field», «first», «float», «for», «from», «function» |
| H | «having» |
| I | «identified», «if», «immediate», «in», «increment», «index», «initial», «inner», «inout», «input», «insert», «int», «integer», «intersect», «intersection», «into», «is», «isempty», «isnull» |
| J | «join» |
| L | «last», «left», «less», «like», «limit», «lock», «long» |
| M | «max», «min», «minus», «mode», «modify», «modulo», «more», «multiply» |
| N | «next», «noaudit», «not», «notin», «nowait», «null», «number» |
| O | «object», «of», «on», «option», «or», «order», «outer», «output» |
| P | «power», «previous», «prior», «privileges», «public» |
| R | «raise», «raw», «remainder», «rename», «resource», «return», «returns», «revoke», «right», «row», «rowid», «rownum», «rows» |
| S | «select», «session», «set», «share», «size», «sqrt», «start», «strict», «string», «subtract», «sum», «synonym» |
| T | «table», «then», «to», «trans», «transaction», «trigger», «true» |
| U | «uid», «union», «unique», «update», «user» |
| V | «validate», «values», «view» |
| W | «when», «whenever», «where», «while», «with» |
2. Использование шаблонов для поиска по тексту
Специальные символы могут быть использованы для определения шаблонов поиска по тексту. Рассмотрим несколько примеров:
| Знак | Область применения и описание | Пример |
|---|---|---|
| ? | «?» используется для замены одного символа в шаблоне. Например, написание слов «text» и «test» отличается одним символом. Для поиска обоих вариантов достаточно задать шаблон: te?t | summary |
«te?t»
нуля или нескольких символов. Например, для отбора текста
«Windows», «Win95» или «WindowsNT» можно использовать
шаблон: win*
Для отбора текста «Win95» или «Windows95»
можно использовать шаблон: wi*95
» может быть использована для задания
нечетких поисковых шаблонов. В этом случае символ «
»
подставляется в конце нужного слова. Например,
чтобы найти термин, орфографически похожий на «roam»,
используйте шаблон: roam
В результате могут быть найдены слова «foam» или «roams».
3. Логические операторы JQL
| Оператор | Описание | Пример |
|---|---|---|
| AND | Логическая операция «И», соединяющая два или несколько условий. Используется для уточнения условий отбора. | project = «YAT» and status = «Оpen» — отобрать все задачи проекта «YAT» в статусе «Open» |
| OR | Логическая операция «ИЛИ», соединяющая два или несколько условий. | reporter = demo_1 or reporter = demo_2 — отобрать все задачи проекта, автором которых является пользователь demo_1 или пользователь demo_2. |
| NOT | Для реверсирования результата логического условия. | not assignee = demo_1 — отобрать все задачи, исполнителем которых не является пользователь demo_1. |
| ORDER BY | Сортировать по. |
По умолчанию будет использоваться собственный порядок,
применяемый для этого поля. Вы можете переопределить направление сортировки —
по возрастанию («asc») или убыванию («desc»).
отобрать все задачи, у которых пустые поля «Due date» (Срок исполнения),
отсортировать результаты выборки по полю «Created» (Создано).
duedate = empty order by created, priority desc —
отобрать все задачи, у которых пустые поля «Due date» (Срок исполнения),
отсортировать результаты выборки по полю «Created» (Создано)
в собственном порядке, затем по полю «Priority» (Приоритет)
в убывающем порядке.
| Оператор | Описание | Пример |
|---|---|---|
| = | Эквивалент. |
Используется для задания
критерия полного соответствия.
либо можно использовать запись
NOT reporter = demo_1
Используется для создания выражений
с полями формата «Version»,
формата дата-время и числовых полей.
duedate > now()
Используется для создания выражений
с полями формата «Version»,
формата дата-время и числовых полей.
duedate >= «2008/12/31»
created >= «-5d»
currentLogin()
Внимание
Самая ранняя не выпущенная версия определяется порядком, а не датами.
Применяется для создания выражений с полями «AffectedVersion» (Проявляется в версиях»), «FixVersion» (Исправлено в версиях), кастомными полями формата Version.
Unreleased
Version(project)
earliestUnreleased
Version
(ABC)
fixVersion =
earliestUnreleased
Version
(ABC)
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата даты-времени.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 день.
Внимание
Самая последняя выпущенная версия определяется порядком, а не датами.
fixVersion =
latestReleased
Version(ABC)
Внимание
LinkType чувствителен к регистру.
(issueKey)
linkedIssues
(issueKey,linkType)
(ABC-123,
«is duplicated by»)
Используется для создания выражений с полями «Reporter» (Автор), «Assignee» (Исполнитель), «Voter», «Watcher» и кастомными полями формата «User».
(Group)
in membersOf(QA)
Для отбора задач JIRA Service Desk, требующих согласования текущего пользователя или уже согласованных текущим пользователем.
Применяется к полям типа «Approvals».
myApproval()
Для отбора задач JIRA Service Desk, требующих согласования текущего пользователя.
Применяется к полям типа «Approvals».
myPending()
created >
startOfDay
(«-3d») – задачи,
созданные за
последние три дня.
Month()
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата дата-время.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 месяц.
created > startOfMonth
(«+14d») — задачи,
созданные с пятнадцатого
числа текущего месяца.
Week()
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата даты-времени.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 неделя.
created >
startOfWeek
(«-1») — задачи,
дата создания которых
старше начала
прошлой недели.
Year()
Используется в выражениях с полями
«Created»
(Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата дата-время.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 год.
created >
startOfYear
(«-1») — задачи,
дата создания
которых старше
начала прошлого года.
IssueTypes()
IssueTypes()
subtask
IssueTypes()
Versions()
Применяется для создания выражений с полями «AffectedVersion» (Проявляется в версиях), «FixVersion» (Исправлено в версиях), кастомными полями формата Version.
используется
для отбора задач
по всем проектам.
unreleased
Versions
(project)
unreleased
Versions(ABC)
Issues()
votedIssues()
Issues()
watchedIssues()
Надеюсь, что разбор продвинутого режима поможет вам при поиске задач.
Пользуйтесь и не теряйтесь 😉
Антипаттерны Agile-команд
Рассмотрим бытовые трудности и антипаттерны, подсмотренные у реальных команд, — без философии про ценности и личностный рост. Поговорим о причинах их возникновения и о последствиях, к которым они приводят.
Доклад на конференции AgileDays 24 марта 2017 года. Слайды доклада
Дмитрий Павлов. Директор по инженерным практикам, Dodo Pizza
Доклад будет полезен начинающим скрам-мастерам, чтобы не наступать на «детские» грабли, а опытные команды смогут критическим взглядом оценить свой процесс. Все совпадения с реальными командами специальные. Надеюсь вы меня не убьёте после доклада.
Цель моего доклада: не просто потролить и посмеяться. Но также, чтобы вы вытащили что-то для себя, нашли «косяки» у себя в процессе. И на ближайшем ретро договорились, как вы с командой будете их исправлять.
Меня зовут Дмитрий Павлов. До того, как наша компания объединилась с «Додо Пицца», я работал в компании Smart Step Group. Мы занимались двумя вещами: заказной разработкой, а также консалтингом и тренингами. Всё то, что мы у себя применяли (экстремальное программирование, простой дизайн и так далее) мы также продавали клиентам. И показывали, как это хорошо. В феврале 2017 года мы объединились с компанией «Додо Пицца». Теперь это IT-компания. По сути она и была IT-компанией. Мы — пиццерия XXI века, где все решения оцифрованы в облачном сервисе: можно сразу смотреть выручку по кассе, смотреть трекер, доставку и т. д. — всё подключено к единому облачному решению.
Новые роли, прежние обязанности
Начнём с первого антипаттерна.
«Мы услышали что-то модное про Agile, Scrum. Есть существующие роли в команде. Есть маркетолог или продажник, который общается с пользователями, есть менеджер проекта, есть техлид. Давайте мы внедрим scrum или agile – не важно. Мы просто им бейджики заменим.
Можно, собственно, на этом Agile-трансформацию завершать. У нас всё готово. Внезапно работаем по scrum. Всё круто!»
В продолжение этого антипаттерна, есть еще один. Называется «совмещение ролей» или Agile Project Manager — когда волк в овечьей шкуре.
«А давайте введём в должность scrum-мастера. У нас будут две схемы управления: одна через scrum-мастера, другая классическая — через проджект-менеджера. Не очень понятно, как эти две схемы будут сосуществовать. Но две должности лучше, чем одна. Правда же?».
Идея в том, что мы должны выбрать одну схему. И если мы решили жить по Scrum, то давайте жить по Scrum.
Какой бы инструмент мне купить?
Представьте себе такую ситуацию: звонит вам знакомый менеджер и говорит так.
«Я узнал, что Agile — это круто, модно, молодёжно. Хочу у себя в компании внедрить. Я слышал, что jira — хороший инструмент. Есть ещё target process, есть redmine с плагинами. Куча всего. Подскажи, что лучше купить? Куда свои 2000 долларов всунуть?»
Действительно, “важный” вопрос. Без него никак. И если мы решим, какую программу купить, то тут у нас и попрёт. Нужно ещё должности переназвать на бейджиках, тогда точно попрёт. Понимаете, да?
Мне кажется, сейчас Jira – enterprise standard сейчас, но не важно.
Я смею напомнить, что у нас написано в Agile-манифесте: “Люди и их взаимодействие важнее процессов и инструментов”. Так что люди сами должны своим взаимодействием выбрать инструмент.
Я не отрицаю того, что инструмент важен. Но инструмент должен помогать. А если мы начинаем всю нашу трансформацию с того, что выберем инструмент — это не есть хорошо.
Отчет вместо стендапа
ОК, с инструментом определились. Пусть это будет Jira. Пришли на первый stand-up (Daily Scrum). А он у нас такой… верифицированный. Алексей Кривицкий вывел специальный термин для этого. Stand-up превращается в Status report. Как это происходит? Приходит scrum-мастер, он же бывший проджект-менеджер с переписанным бейджиком. Открывает Jira-доску, active sprint.
«Расскажи, Вася, что ты сделал за текущий спринт, такой-сякой?»
Остальные сидят и «втыкают» в телефоны, пока до них очередь не дошла. «Сказали придти на stand-up – мы пришли».
«Вася ладно, присядь. Вот ты! Ты уже 2 дня бот чинишь. Расскажи, почему ты 2 дня бот чинишь?»
И дальше такой вот опрос. Не происходит общения человека с командой. Не происходит общения команды друг с другом. Вместо этого происходит отчёт команды scrum-мастеру. Это мне это напоминает журналы посещаемости и рабочего времени на заводах, когда ты записывался, во сколько ты пришёл, потом в конце дня звенел звонок и ты выходил, и записывал, сколько времени прошло.
При этом stand-up становится абсолютно бесполезным. Становится без разницы, кто что делал и какой баг чинил. «Меня спросят — я скажу. А потом дальше уткнусь в телефон, буду читать Фейсбук и постить котов.»
Jira-фикация и Scrum-турбация
Если развивать тему Jira, то Алексей Кривицкий придумал термин Jirafication. Суть очень простая: все командные встречи деградируют до уровня, когда мы просто «апдейтим» всё в Jira — просто для того, чтобы «проапдейтить» всё в Jira. Когда Jira не доступна, то всё — мы не можем планировать, мы не можем работать. Мы становимся людьми-роботами. Мы приносим ей жертвоприношения в виде tasks, user stories и burndown charts. Типичные фразы, которые приходится слышать, к сожалению:
Знакомая ситуация? Не переживайте — это наша общая боль. Надо всё поставить в Jira. Идёшь на обед — ставишь task в Jira. Оцени её. Возвращаешься — проверь, план с фактом совпал или не совпал. Без этого вообще нельзя работать. Никакой scrum не пойдёт.
Разовьем идею Алексея Кривицкого: «Скрам-турбация» или «Джира-турбация». Посмотрим на команду, где есть стендапы и есть доска (физическая или виртуальная). Scrum-мастер сертифицирован на PSM I или PSM II. Либо в Scrum Alliance, либо ещё где-то. На стендапы ходим, делаем демо и ретро.
На первый взгляд может показаться, что в таких командах всё ОК. Идея в том, что механику мы всю соблюдаем, но про ценности напрочь забыли. То есть, стендапы превращаются в статус-репорты. Мы на ретро не видим улучшения. У нас же всё круто в команде. У нас проблем нет. Пользователя не зовём, но демо показываем. Все и так всё видели, зачем их звать на демо?
Всё есть, но Скрамом тут и не пахнет.
Водопадные спринты
У нас же должна быть аналитика какая-то. Мы же не можем аналитику оставить без проработки. Давайте объявим нулевым спринтом спринт аналитики. В конце этого спринта у нас будут какие-то документы. Я как Product Owner приду к вам в конце спринта и спрошу: «А что у вас готово?». Вы ответите: «У нас есть документы». Я: «Ну, круто!». Но где-то в голове у меня червоточинка сомнения будет. Что-то вы меня как-то обманываете. Прихожу к вам через второй спринт. И абсолютно не важно, какая у вас продолжительность спринта: две или четыре недели. «Мы дизайн сделали! У нас дизайнер работал. Экраны офигенные!». Я: «Ок… А я могу что-то выкатить в продакшн?». «Нет. Пока не можешь. Тут только документация и дизайн». Прихожу на третий спринт — там спринт доставки в интеграцию. То есть процесс настолько кривой, что нам нужен целый спринт, чтобы «запинать» вот это в интеграцию. При этом желательно ещё не обломать смежные команды (бывает, что тестовые среды «шарятся» между командами).
Ну, и где-то по итогам пятнадцатого спринта я что-то увижу. Но самое прикольное, что в разработке — где больше всего неопределённости, где самая рискованная тема, — когдам мы начинаем что-то делать, оказывается, что оно совсем не так, как в документации. Framework не завёлся. Есть неточность. Документация устарела.
Водопадная итерация
Мы можем собраться на ретро: «Что-то не то! Давайте мы сделаем один водопадный спринт из этого всего». То есть, всё то же самое, только в рамках одного спринта. Казалось бы, всё нормально. В конце спринта есть готовый результат. Но тестировщики курят бамбук почти весь спринт, так как нечего делать. Девелоперы в начале спринта пока ничего не делают. Аналитики пока работают. Потом дизайнер включается, с чувством прекрасного делает экраны.
Где-то в середине спринта девелоперы начинают что-то делать. Тестировщики чувствуют себя некомфортно, так как несколько недель им ничего на тестирование не прилетает. Они начинают нервничать. Они же в конце цепочки находятся. И когда мы не успеваем с разработкой – что происходит? — правильно, у тестировщиков время забираем. Мы же код без багов пишем. И тестировщикам бывает совсем не сладко.
А потом: «Не успели? Давайте в следующем спринте это сделаем».
Симптом водопадного спринта известен. Команда стремится максимально удлинить спринт, например, 4 недели, чтобы этот водопад у них конкретно по неделям укладывался.
Оценка на каждый чих
Есть тенденция у нас оценивать всё и вся. И количество багов, и сколько story points каждая задача займёт с точностью до 15 цифры после запятой. 
А самое интересное, как мы эту информацию используем. У нас очень долгое планирование, мы упарывались, разбивали на сабтаски, оценивали и каждый task, и даже subtask. Но к следующему спринту совершенно забываем про то, что планировали в прошлом, и сколько в нем сожгли стори пойнтов. Scrum-мастер спрашивает: «Как вы думаете, мы сможем это сделать за спринт?» Ответ: «Да! Мы сможем!». То есть, мы упарывались с оценками, все учитывали, а потом забили на это. А зачем это было, если в итоге всё решает «Мы сможем!»?
Не надо так делать. Мы помним, что у нас в Agile — не оценка, а скорее прогноз (forecast). Мы лишь примерно можем сказать, что команда примерно такого состава более-менее похожие задачи сделает примерно за столько-то. При этом абсолютно идентичных задач — очень мало.
Ресурсное планирование
Мы садимся на планирование. Есть разработчики разных типов, люди разных специальностей. Есть аналитик, есть front-end разработчик, есть дизайнер, есть разработчики тестов и т. д. Мы начинаем распределять задачи: здесь «фронтовая», здесь «бэковая» и т. д. Раскидываем по людям. По результатам планирования весь бэклог у нас нарезан: у каждого свой набор task.
Здесь мы можем разойтись и не ходить на стендапы, так как у каждого свой набор задач, и делать он может их в любом порядке, он ни от кого не зависит.
Если посмотреть на burndown таких команд, то он будет очень ровный! Стабильный. Причём если на эту картинку взглянет ресурсный менеджер, скажет — идеально! Все чем-то заняты. Работа не несколько недель вперёд расписана. Чёткий план. Правда, немного забыли про приоритеты, про интеграцию и про пользователей. Но в результате мы все задачи выполнили. А если не выполнили — переносим на следующий спринт и продолжаем. И график идёт прямо, а в конце резко падает. Повезло. Наверное, все сынтегрировались и выполнили.
При этом «фронтовики» же молодцы. Они всегда задачи доделывают. И то, что при этом «бэк» не готов, то это java-программист виноват. Его надо уволить. Или как-то наказать. А «фронтовики» молодцы. И аналитики всегда молодцы. Они всегда выдают документацию. Которая, иногда бывает, расходится с тем, что в коде написано, но в этом ничего страшного. Мы же написали документацию. Кто же в код будет лезть потом?
Карго-культ идеального burndown
Burndown — это зеркало процесса. Мы говорим: «Давайте сделаем идеальный burndown». Идеальный — это когда работа сгорает равномерно, маленькими кусочками, ценность доставляем чаще. Но сейчас у нас из-за разных причин burndown скачет и прыгает. Появляются возгласы в команде — карго-культ burndown: «Не добавляйте больше task – у нас burndown скачет». Или возглас от владельца продукта: «Что-то идет не так: у нас burndown не идеальный». И тогда приходит кто-то и говорит: «Чуваки! Я вас сейчас спасу. Давайте заведём новый тип task. Он в нашей калькуляции учитываться не будет. Но зато burndown будет ровный, без скачков.»
Это обман системы: по факту у нас работа будет добавляться, но мы про это не узнаем. Хуже только, если burndown используется для целей оценки «эффективности» команды: делаем работу, не учтенную в эффективности.
IT-шники — они люди творческие. Они придумают как обойти любую метрику или KPI. И у них даже появляется элемент соревновательности: кто как хитрее эту метрику обойдёт.
Бухгалтерия с оценками
Работаем мы по водопадному спринту. Всё здорово. Но в конце спринта ничего не готово. И мы обсуждаем самый важный вопрос. У нас была история на 13 story points. Мы её не доделали. Но мы же сделали какую-то часть.
Засчитать или нет? На этот вопрос очень хорошо ответил Алексей Кривицкий: «Давайте от механики отвлечёмся. Вспомним про пользователя. Мы можем какую-то бизнес-ценность ему «заделиверить»? Если да, то считайте, как угодно!». Тут не важно, как вы посчитаете: пять или ноль. Оно в среднем сойдётся через несколько спринтов. Velocity выровняется через несколько спринтов. И без разницы, какую мы тут бухгалтерию ведём. Как проще, так и считайте. Нравится переоценивать — переоценивайте.
Местечковый Scrum
Чуть-чуть отвлечемся от антипатеррнов команд. Поднимемся чуть выше. Посмотрим на иерархию организации или IT-департамента. IT-директор говорит: «Я услышал что-то про Scrum. Прочитал книжку. Хочу также, но чтобы в остальной организации мы по-прежнему работали. Давай только у разработчиков Scrum настроим. По-моему, они работают медленно. Сериалы смотрят на работе. Надо их взбодрить. Scrum, дисциплина, хорошие результаты и в срок.».
К сожалению, Scrum у разработчиков не настроить. Как бы мы не старались, мы либо будем продолжать заниматься «скрамтурбацией», либо произойдет следующее. Допустим, у разработчиков есть подобие кросс-функциональной команды, и они способны что-то «деливерить» сами, и есть «кнопка» Deploy to Production, которую они сами могут нажимать, и это не нужно ни с какими безопасниками согласовывать и писать заявок. Тогда Scrum заработает, и они начнут потихоньку вытягивать из других отделов к себе либо компетенции, либо выделенных людей, чтобы эти компетенции с них взять. Если нужен безопасник — давайте его в команду, если из техподдержки — давайте его обучим.
Scrum заставляет делать организационные изменения. А местечковый Scrum — либо быстро загнётся, если нет сверху поддержки, либо будем продолжать играть в фейк.
Индивидуальные KPI
В крупных организациях нужно оценивать эффективность людей. Странная ситуация. KPI ставятся менеджерами, а менеджеры не в команде и не знают специфику продукта. И KPI — это способ распределить деньги в конце года между людьми. Причём scrum-команды состоят из 5-7 человек, поэтому они людей, которые не тянут — быстро вычисляют. Но нам все равно нужен сложный процесс с индивидуальными KPI, индивидуальными планами развития и т. д. При этом у нас есть продакт, который формирует бэклог, исходя из бизнес-приоритетов. Подходит конец года, и тут у разработчика встаёт дилемма: «Что взять?». С одной стороны, продакт с понятными требованиями по продукту, с другой стороны, у меня личный KPI и премия в конце года. А я уже айфон себе новый захотел. Что делать? Я говорю: «Сегодня у меня эти дни. Меня не трогайте. В четверг я ухожу делать свой личный план». Продакт: «Как же так? Куда у меня человек из команды свалил? Я за него деньги плачу, а он что-то не то делает?».
Роль Backlog Facilitator
Владелец продукта — это очень сложная и недооцененная роль. И не только в Scrum. Очень часто у продукт-оунера нет выделенного бюджета, он ничем не распоряжается, он не может нанимать/увольнять людей, он не может купить железа, Он не может назначать даты релиза, так как сверху все обо всё договорились, он не может сказать «нет». В этом случае Product Owner превращается в Backlog Facilitator. Не понятно, зачем нужен в таком случае продукт-оунер: он выполняет чисто административную функцию. По факту продуктом он не владеет. И начинается карго-культ продукт-оунерства. Формально мы вроде в Scrum работаем. Но полномочий никаких нет.
Подведем итоги
Обратите внимание, о чём вы спорите на ретро: либо обсуждаете механики типа правил для стори-поинтов, либо, опираясь на ценности, вы смотрите на эффективность вашего процесса с точки зрения клиента.
