Всем привет! Поделитесь, пжлст, инфой в чем отличие Product Owner от Area Product Owner. В частности какие задачи, функционал, полномочия у APO? В этой статье https://less.works/less/less-huge/area-product-owner.html , например, говорится, что APO не приоритезирует бэклог. Какие еще есть особенности?

Добрый день, а у вас, кроме этого элемента LeSS, что еще есть?

Добрый день, а у вас, кроме этого элемента LeSS, что еще есть?

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

Надо понимать, что Apo это конкретно роль из less huge А не просто клевое название

Надо понимать, что Apo это конкретно роль из less huge А не просто клевое название

ок, и в чем его отличие от PO? бывают ли под APO еще PO?

ок, и в чем его отличие от PO? бывают ли под APO еще PO?

Ну вы же сами ссылку прислали, там всё подробно описано PO всегда один, не может никого быть ПОД APO

Ну вы же сами ссылку прислали, там всё подробно описано PO всегда один, не может никого быть ПОД APO

понятно. может еще какие-то материалы есть или кто-то в работе сталкивался. Спасибо.

Если у вас над продуктом не работает 90+ человек, то вам не стоит заводить APO Сам LeSS говорит о том, что до LeSS Huge лучше не доводить

Если у вас над продуктом не работает 90+ человек, то вам не стоит заводить APO Сам LeSS говорит о том, что до LeSS Huge лучше не доводить

👍 или поделить на несколько компаний))

Норм, только po не команда..

PO, DT и SM составляют Скрам Команда. Она самоорганизующаяся.

Коллеги, добрый вечер!, есть вопрос - agilealliance пишет, что defenition of done позволяет Limits the cost of rework once a feature has been accepted as ‘done’. Как можно трактовать данный пункт, критерии готовности позволяют снизить возможные расходы на переработку фичи?

надеюсь еще не было =)

Всем привет

может кто в двух словах пояснить что такое conwip?

@EgorSmolkin еще один репост из этого канала – в бан

@EgorSmolkin еще один репост из этого канала – в бан

А, что не так с этим каналом? Где посмотреть список каналов с которых репосты можно делать?)

реклама запрещена постоянные репосты боянов с одного и того же канала, с целью нагнать туда аудиторию == реклама

от вас в этом чате с самого вступления только репосты

от вас в этом чате с самого вступления только репосты

Это не так

Но вы админ, не спорю

Просто было интересно...

Добрый день! Мы - компания, только только внедряющая у себя Agile-принципы. В одной из команд происходит следующая ситуация. User story написанные совместно с product owner'ом на время спринта - успешно закрываются и будут показаны на презентации, но при этом - технические специалисты не полностью покрыли код тестами. Я понимаю, что это своего рода нарушение требований о внутреннем качестве продукта, в результате чего у нас возник - "технический долг". Мне понятно, что в будущем нужно более четко относиться к планированию, но нужно что-то сделать с текущими задачами. Подскажите, пожалуйста, практику решения таких ситуаций. Нужно ли их выносить в отдельный спринт, или просто закладывать их как задачи мимо User Story от PO?

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

Денис, спасибо за ответ. Правильно ли я понимаю, что нужно сформировать ещё одну User Story - "Ликвидация технического долга", для данного случая?

Добрый день! Мы - компания, только только внедряющая у себя Agile-принципы. В одной из команд происходит следующая ситуация. User story написанные совместно с product owner'ом на время спринта - успешно закрываются и будут показаны на презентации, но при этом - технические специалисты не полностью покрыли код тестами. Я понимаю, что это своего рода нарушение требований о внутреннем качестве продукта, в результате чего у нас возник - "технический долг". Мне понятно, что в будущем нужно более четко относиться к планированию, но нужно что-то сделать с текущими задачами. Подскажите, пожалуйста, практику решения таких ситуаций. Нужно ли их выносить в отдельный спринт, или просто закладывать их как задачи мимо User Story от PO?

1) Есть такая штука Definition of Done, нужно их сформулировать и не считать историю "выполненой", если DoD не соблюден (туда же попадают тесты и тд) 2) текущий долг: можно в бэклог отдельными задачами (как верно заметили выше), можно правилом "когда делаешь историю, которая затрагивает кусок кода с техдолгом – изволь пофиксить его" зависит от требований к качеству лучше вариант 2, но зависит от ситуации, конечно

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

Верно. При использовании 1, таких ситуаций не будет. Иначе кого вы обманываете? Сами себя? А если DoD позволяет, то значит такое качество кода для вас приемлемо и идете дальше

Господа, какие общие подходы существуют к разработчику, который стабильно выдает завышенные естимейты при планировании спринта?

Господа, какие общие подходы существуют к разработчику, который стабильно выдает завышенные естимейты при планировании спринта?

иголки под ногти?👀

Господа, какие общие подходы существуют к разработчику, который стабильно выдает завышенные естимейты при планировании спринта?

Понять и простить

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

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

Не использовать эстимейты, использовать статистику

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

Можно сказать, что он занимается ниокром, потому что делаем продукт для стартапа в новой для мира отрасли

а почему он один?)

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

Распределение чего?

Ну времени выполнения задач

по-моему, planning poker решает задачу выравнивания оценок)

по-моему, planning poker решает задачу выравнивания оценок)

https://blog-ru.kaiten.io/%D0%BF%D0%BE%D1%87%D0%B5%D0%BC%D1%83-agile-%D0%BD%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82/ посмотрите главу про S, M, L =)

Он один пилит свой стек. Нет ни одного человека, который может с ним в этот покер сыграть

Нет ни одного человека, который может его код ревьюить и вразумлять его естимейты

ждать чего-то полезного от экспертной оценки ниокра – ну такое себе я бы все же ставил на статистику) можно сделать статистику по S, M, L, если хотите поточнее

Нет ни одного человека, который может его код ревьюить и вразумлять его естимейты

А зачем надо? И если он один, то кто может сказать, что они не верны?:)

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

И ты ему завидуешь?:)

В чем бизнес цель?

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

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

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

И ты ему завидуешь?:)

Я ему не завидую. Я ему бабки плачу, которые для меня вообще не казенные

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

Так у него бэклог переполнен и хочется быстрей его закончить, или у него бэклог переполнен, но команде это не мешает?

Просто "по камерам видно, как играет" мякго говоря не повод считать, что эстимейты завышены.

Разработка - далеко не механичский процесс и методы "обдумывания" у всех разные.

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

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

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

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

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

Разработка - далеко не механичский процесс и методы "обдумывания" у всех разные.

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

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

Но человека сохранить, он хороший разраб и эту практику начал недавно

с такими подходами вам не сюда agile – про доверие людям, а не про слежку по камерам и попытками выдавить из человека максимум соков за ту же зп

Вопрос быстрый на засыпку! Сколько лет существует сертификация по аджайл в рф?

Не обязательно дату, можно приблизительно лет

Пишет мне 22 летний парень: Видите как классно работают? А Грефа в Сбербанк с моей подачи взяли, он тогда часть совета директоров снял ещё. Это я ему посоветовал омолодить состав

😂

Вопрос быстрый на засыпку! Сколько лет существует сертификация по аджайл в рф?

сертификация есть только международная, ее нету российской а если речь про тренеров официальных, то вроде Илья в 2012 стал, думаю примерно тогда

Господа, какие общие подходы существуют к разработчику, который стабильно выдает завышенные естимейты при планировании спринта?

Ты смотришь со своей стороны и вся дискуссия пошла в этом русле. Попробуй встать на его место, понять его выгоды, вторичные выгоды, и почему он перезакладывается, помимо игрушек. Возможно ему не интересно програмить и приносить пользу. Тогда этот человек не разделяет ценностей Agile. Здесь однозначно методики психологии. И лучше если эту работу постепенно начнёт делать скрам мастер, а не ты. Если есть такой. Методы контроля точно не улучшать ситуация. Хотя для некоторых метод морковки сзади может быть достаточно эффективным

сертификация есть только международная, ее нету российской а если речь про тренеров официальных, то вроде Илья в 2012 стал, думаю примерно тогда

Ну да, я про то

Ну да, я про то

а если вообще про тренинги, то скрамтрек че-то типа с 2008 тренирует

Господа, какие общие подходы существуют к разработчику, который стабильно выдает завышенные естимейты при планировании спринта?

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

Если ретроспективы нет, то не надо задавать вопросы в этой группе. Здесь про аджайл.

Но человека сохранить, он хороший разраб и эту практику начал недавно

Unreal. Вы хотите изменить другого - это не работает :) Есть всего два варианта: 1. Создать такие условия, в которых он сам должен будет измениться, 2. Расстаться. В пункт 1 входит, например, спокойный и аргументированный разговор "выхлоп от тебя меньше, чем твоя зарплата" (если это так) или, ещё более корректно, "выхлоп от тебя меньше, чем мне нужно от человека на твоём месте". Ну и договоариваться ) Если не получается - менять. Всё остальное - манипуляции, они никогда не приводят к цели а лишь создают проблемы для обеих сторон.

с такими подходами вам не сюда agile – про доверие людям, а не про слежку по камерам и попытками выдавить из человека максимум соков за ту же зп

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

Unreal. Вы хотите изменить другого - это не работает :) Есть всего два варианта: 1. Создать такие условия, в которых он сам должен будет измениться, 2. Расстаться. В пункт 1 входит, например, спокойный и аргументированный разговор "выхлоп от тебя меньше, чем твоя зарплата" (если это так) или, ещё более корректно, "выхлоп от тебя меньше, чем мне нужно от человека на твоём месте". Ну и договоариваться ) Если не получается - менять. Всё остальное - манипуляции, они никогда не приводят к цели а лишь создают проблемы для обеих сторон.

Хм, пожалуй самый дельный совет

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

в какой аджайл вы верите-то?

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

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

в какой аджайл вы верите-то?

В тот который про 4 ценности и 12 принципов

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

а команда на него никак не пробует "воздействовать" в этом вопросе?

В тот который про 4 ценности и 12 принципов

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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