Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта. Управление Бэклогом Продукта включает в себя: • описание Элементов Бэклога Продукта ясным и понятным образом; • управление порядком Элементов Бэклога Продукта для наилучшего достижения целей и миссий; • оптимизацию ценности работы, выполняемой Командой Разработки; • обеспечение доступности, прозрачности и ясности Бэклога Продукта для всех участников процесса. Бэклог Продукта при этом отражает, над чем Скрам-команда будет работать дальше; • гарантию, что Команда Разработки в достаточной степени понимает Элементы Бэклога Продукта. Владелец Продукта может выполнять эту работу как самостоятельно, так и делегировать её выполнение членам Команды Разработки. Тем не менее ответственность за Бэклог Продукта лежит на плечах Владельца Продукта.

Спасибо, а с чем вы именно не согласны?Что это на спринт вперед происходит или что это аналитик делает?

А что там нет для канбана?

Например, нельзя разделить столбцы на подстолбцы. Нельзя выставить WIP-лимиты по свимлэйнам.

Например, нельзя разделить столбцы на подстолбцы. Нельзя выставить WIP-лимиты по свимлэйнам.

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

А как Вам такая интерпретация Scrum? Взято отсюда https://profilib.net/chtenie/33077/boris-volfson-gibkoe-upravlenie-proektami-i-produktami-13.php

Зависит от того куда поместить аналитика. Он может выступать как PO/PM на своем уровне и готовить бэклог с командой, либо быть в команде и работать с PO и помогать ему составлять backlog. Главное чтобы аналитик не бегал от PO до команды, передавая требования на бумаге

Спасибо, а с чем вы именно не согласны?Что это на спринт вперед происходит или что это аналитик делает?

Что есть какие-то аналитики и они работают на спринт вперед. Это задача команд. И это делается на PBR.

Что думаете?

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

Что думаете?

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

И да это пример того, где скрам нельзя использовать, вышли за границы применимости

Ну если аналитик выполнять роль proxy-PO - то выглядит уже получше, тем более у вас там написано, что PO может делать это и один :)

Я дальше этого автора почитал. Там все сложно со Скрамом.

Ну если аналитик выполнять роль proxy-PO - то выглядит уже получше, тем более у вас там написано, что PO может делать это и один :)

На количестве команд больше восьми в Huge LESS появляются Area Product Owner. Но PO остается одним человеком.

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

Речь про удобство

Речь про удобство

Я просто про канбан мало знаю, поэтому удивляюсь таким требованиям. Не думал, что в канбане есть такие штуки.

На количестве команд больше восьми в Huge LESS появляются Area Product Owner. Но PO остается одним человеком.

Одним человеком для команды?

На количестве команд больше восьми в Huge LESS появляются Area Product Owner. Но PO остается одним человеком.

Про Area спасибо, почитаю.

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

Я дальше этого автора почитал. Там все сложно со Скрамом.

Бориса Вольфсона?

Ага

Я просто про канбан мало знаю, поэтому удивляюсь таким требованиям. Не думал, что в канбане есть такие штуки.

Посмотрите доклады Алексея Пименова. Там много чего интересного

Посмотрите доклады Алексея Пименова. Там много чего интересного

Спасибо

Ага

Хм.. Я начинал свое знакомство с гибкими фреймворками с его книги 2014 года "Гибкое управление проектами и продуктами." И мне она хорошей книгой, наверное нужно перечитать и посмотреть статьи которые Борис сейчас пишет.

Одним человеком для команды?

Для всех команд!

Хм.. Я начинал свое знакомство с гибкими фреймворками с его книги 2014 года "Гибкое управление проектами и продуктами." И мне она хорошей книгой, наверное нужно перечитать и посмотреть статьи которые Борис сейчас пишет.

Там как-то странно. Сначала все норм идет про Скрам. А потом начинаются эти мысли про аналитиков, про Спринт 0, про несколько Владельцев продукта ... и пр.

Для всех команд!

Неужели есть ещё люди которые удивляются, что может быть один владелец продукта на 6-7 команд :)

У нас уже 8

Готовимся на Huge LESS уходить ...

Владелец один

Сейчас читаю про Нексус, там тоже один.

Неужели есть ещё люди которые удивляются, что может быть один владелец продукта на 6-7 команд :)

Сейчас заполучить одного PO на проект (вместо 2-3 как у нас) считается удачей )

Сейчас читаю про Нексус, там тоже один.

Да :)

Там как-то странно. Сначала все норм идет про Скрам. А потом начинаются эти мысли про аналитиков, про Спринт 0, про несколько Владельцев продукта ... и пр.

Подгонка под реальность

В SAFe у каждой команды свой PO

Пока не копал туда. В планах.

Неужели есть ещё люди которые удивляются, что может быть один владелец продукта на 6-7 команд :)

Мелкие продуеты просто

Не всегда один PO в состоянии работать с всеми командами и появляется звено, которое закрывает эту пустоту

Это зло.

Тогда немного холиварный вопрос. Кто какими инструментами пользуется для организации процесса по Канбану? Мы, например, пытаемся YouTrack приручить. Но там много нет.

Кайтен же :)

Не всегда один PO в состоянии работать с всеми командами и появляется звено, которое закрывает эту пустоту

А потом ещё звено и ещё звено и хлоп у нас вырастает прослойка менеджеров среднего звена

РО работает с Бэклогом.

А потом ещё звено и ещё звено и хлоп у нас вырастает прослойка менеджеров среднего звена

Я согласен, это ужасно и чем меньше этого тем лучше

Я уже постил.

Я согласен, это ужасно и чем меньше этого тем лучше

А ещё хуже, когда Тим лид с хррошими знаниями становится диспетчером задач

Помогает пониманию.

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

Да и да

А ещё хуже, когда Тим лид с хррошими знаниями становится диспетчером задач

А когда нету такого тим лида?)

Ничего не делай сам, если есть хороший зам :)

Менеджмент 1.0

Кайтен же :)

https://archive.hnsa.org/ships/img/kaiten.jpg

хорошее название выбрали, в общем.

хорошее название выбрали, в общем.

Ага :)

Внутри торпеды человек который крутит педали :)

Кайтэн (тж. кайтен, яп. 回天, букв. «изменяющие судьбу») — название нескольких типов торпед, управляемых пилотами-смертниками (тэйсинтай). 

У нас уже 8

А много зависимостей между командами?

А много зависимостей между командами?

Неа. Фиче-команды кросс-фукциональные. Там полный комплект по всем компонентам, включая дизайнера и верстальщика. Т.е они способны сделать любую работу по продукту. Все зависимости они сообща решают. Нет в общем такой проблемы.

Учитывая что по сложным задачам (8 и 13 SP) они сообща проводят PBR , зависимости выявляются до Спринта.

В качестве обзора моделей управления требованиями можете посмотреть мое видео с ЛАФ-2011: https://vimeo.com/channels/laf2011/27122901 Обзор неполный, но пара дюжин методов там упоминается.

Что касается типов производственных цепочек и проблем с ними, начните со статьи Голдратта: стоя на плечах гигантов.

"Статья очень интересная, в ней рассмотрен пример Hitachi Tool Engineering, где Lean в том виде, в котором он живет в Toyota ведет к ухудшению ситуации. Все потому, что Lean - это конкретное прикладное решение ..."

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

команда должна быть кроссфункциональной. спецы могут быть разными

команда должна быть кроссфункциональной. спецы могут быть разными

Нет. В этом то и проблема. Если у вас в команде разные спецы, то вам канбан нужен, скрам вам не подходит

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

ну и я слабо себе представляю что можно набрать такую команду, где все superfullstack

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

Да, не... T-shaped рулит в любом случае. Коммуникации от этого только выигрывают. Сложно команду сделать или нет, не зависит от кроссфункциональности отдельных участников. Но требования про кроссфункциональность членов в скраме, конечно, нет.

Да, не... T-shaped рулит в любом случае. Коммуникации от этого только выигрывают. Сложно команду сделать или нет, не зависит от кроссфункциональности отдельных участников. Но требования про кроссфункциональность членов в скраме, конечно, нет.

T-shaped рулит - это золотые слова. конечно когда все узкоспециализированы, то очень сложно scrum делать. Это другая крайность. Но и говорить про кроссфункциональность каждого участника команды - это грешновато. T-shaped вам bus factor повышать должен. А мощь команды в сильных компетенциях каждого учасника

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

Не спецы кроссфункциональны, а команда ведь, разве нет? https://www.scrumguides.org/scrum-guide.html#team-dev Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;

Не спецы кроссфункциональны, а команда ведь, разве нет? https://www.scrumguides.org/scrum-guide.html#team-dev Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;

Команда имеет все компетенции для создания продукта. Кто сколькими компетенциями обладать будет - зависит от команды, естественно :)

Если компетенции нехватает, команда решает, кого качать и куда и с какой силой :) Очень помогает простой инструмент, как Звёздная карта :) но это тоже не обязательный инструмент, но оч хороший :)

Звёздная кара - прекрасная опечатка :D

Команда имеет все компетенции для создания продукта. Кто сколькими компетенциями обладать будет - зависит от команды, естественно :)

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

Звёздная кара - прекрасная опечатка :D

👍

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

Я такие команды, кстати, не встечал :) потому что, имхо, впихнуть всё во всех и во всем иметь максимум, это не Т-shape, это уже "гребешок" какойто, а не человек :)

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

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

Я такие команды, кстати, не встечал :) потому что, имхо, впихнуть всё во всех и во всем иметь максимум, это не Т-shape, это уже "гребешок" какойто, а не человек :)

😂

ШШШШШШ-shape :)

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

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

Не спецы кроссфункциональны, а команда ведь, разве нет? https://www.scrumguides.org/scrum-guide.html#team-dev Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;

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

ШШШШШШ-shape :)

Кстати да, у скипи была отличная статья на эту тему

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

Мне непонятно вышеизложенное. Мы говорили чисто про dev team. Роль аналитика в скраме - это отдельный вопрос. Я - аналитик в скраме. Могу рассказать свой опыт: - я работаю как прокси-РО (РО делегирует мне свои задачи), помогая РО оформлять бэклог в виде user stories - на PBR мы вместе с РО доводим "ЧТО" нужно сделать до команды - все вместе обсуждаем, команда задает вопросы, на них сразу же даются ответы, всё записывается в JIRA/Wiki прямо на месте (ну либо делаются наброски, чтоб не забыть, а потом берется небольшая отсрочка, если материала много, и надо его поподробней где-то расписать) - в любом случае, если понимание "что нужно сделать" достигнуто, то команда дает оценку и готова идти с этим в спринт, не дожидаясь детальный описаний - если уже в спринте возникают отдельные мелкие вопросы или кто-то что-то подзабыл из договоренностей или тупо недочитал, все уточняется в рамках спринта по месту (это нормальный рабочий процесс, идеально вылизанных и запротоколированных требований никогда нет и не будет)

Если подытожить, на моем опыте: 1. аналитик не часть dev team, а proxy-PO 2. до того, как идти к команде, бэклог оформляется надлежащим образом (это и есть "постановка", наверное, если говорить вашими терминами) 3. на PBR все уточняется "на месте" 4. dev team в спринте не "бросается помогать" аналитику оформлять задачи (просто нет такого кейса, т.к. все покрыто в 1-2-3)

С одной командой проще. У нас их восемь :) РО у нас формирует Бэклог и расставляет приортеты. На Общем PBR с представителями команд они периодически актуализируют накопившиеся элементы. Они уточняют функционал (в объеме, достаточном для оценки), оценивают элемент. Если он больше 13 SP, то команды забирают его на дальнейшую актуализацию с экспертами и заинтересованными лицами, делят на фичи и оценивают их. Такая же судьба (только без разбивки) постигает все элементы с оценкой 8 и 13 SP. Потом все стречаются и презентуют актуализированный элемент. Условие Sprint Ready - оценка бизнес-ценности от РО, оценка трудоемкости от команды <= 13, список приемочных критериев по задаче в Redmine. Только такая задача идет в Спринт.