Если скрам мастер видит искусственное затягивание, наступает его звездный час защиать принципы и ценности agile :)

Главный принцип, без которого аджайл не работает, периодические показательные порки ;)

Главный принцип, без которого аджайл не работает, периодические показательные порки ;)

А можно подробности, как это проходит?

На откуп менеджменту)

это полный аджайл 😂

Это единственный, работающий) все остальное сказки

Потому что, кроме слова Agile нужно использовать фреймворки и инструменты

Инструменты опциональны.

Использовать инструменты которые нужны командам

Крайне странное определение. Таким образом команда получает теоретическую возможность оттягивать взятие задачи в работу неопределенно долго. Собственно, об этом и мой вопрос, есть ли примеры Дор? Или все на уровне красивых слов?

пример DoR: стори может быть взята в спринт если: 1. по ней проведен grooming (product backlog refinement), то есть ее обсудили командой и все участники команды представляют о чем эта стори 2. в стори явно прописан Definition of Done 3. стори оценена командой (или нет препятствий ее оценить - если оценка производится на планинге, а не на PBR например) это лишь пример, но эти договоренности формирует сама команда и фиксирует где то на видном месте :) корректируя после каждого спринта, если требуется :)

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

Крайне странное определение. Таким образом команда получает теоретическую возможность оттягивать взятие задачи в работу неопределенно долго. Собственно, об этом и мой вопрос, есть ли примеры Дор? Или все на уровне красивых слов?

С другой стороны у аналитика (po) есть возможность втолкнуть в спринт "сырую" задачу. Почему сказал что по результатам ретро , потому что именно там команда начинает возмущаться что вот приносят непонятно что, поэтому результат неточен или оценка... Dor даёт возможность закрепить договоренности между командой и po по полноте задачи

Есть обратный негатив - po и stackholders недовольны видом готовых задач. Постоянно идут возвраты. Тоже обсуждается на ретро перечень обязательных шагов, которые задача должна пройти. Можно делить для бага такие критерий, для истории такие ...

Тут заключается соглашение dod (difinition of done)

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

Что это?)

Без кризисов не бывает прогресса

Важно чтобы они исполнялись. А то сделают, повесят где нибудь , а потом классика "у нас мало времени для того чтобы их исполнять". в результате po приходит на планинг без понимания что делать, а команда срывает сроки

Главный принцип, без которого аджайл не работает, периодические показательные порки ;)

Какой то свой у вас agile ;)

Была идея собрать книги для продактов уже давно, но просто взять и засунуть чей-то список совесть не позволяла. Включал в первую очередь самые практичные, про "взял и сделал". Что-то заговорился, вот же сама подборка http://www.alexcouncil.com/knigi-dlya-prodaktov/ Кстати, если будут предложения, какие еще творения добавить, то пишите в комментариях, включим.

Какой то свой у вас agile ;)

Ну это правда жизни такая) аджайл аджайлом, но ближе к реальности быть полезно. Иначе появляются рассуждения, а что если команда задачи брать не хочет или ещё что-то. Если не хочет, значит связь с реальностью потеряна, и пора ее вернуть.

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

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

Это dor

Если задача не прошла весь цикл разработки - разработка, код ревью, автотесты, что то ещё - она не готова и не нужно пытаться даже ее пытаться выпускать - она не готова

Это дод

Если задачу нужно сделать, она должна быть сделана вне зависимости от DOR

Это правило жизни такое. Вот представь себе, ты на Марсе, и у тебя скафандр пробило. Или ты его как-то заделаешь, или помрёшь. Будешь dod прописывать?

Есть подход, что демо - это пленарное заседание, в котором определяются виновные, степень их вины, отчётность о проделанной работе итд итп. Однако, мне кажется, это уже не про agile.

Есть подход, что демо - это пленарное заседание, в котором определяются виновные, степень их вины, отчётность о проделанной работе итд итп. Однако, мне кажется, это уже не про agile.

Ты прав

Демо это вообще не про то. Демо это про достижение целей

И в разработке,поверь мне, большая часть задач ровно такие. Все понятно, надо делать

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

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

Ну как со скафандром то все ясно: наличие клея момент, бензина, пылесоса, скафандра и резины. - Дор для ремонта скафандра

Короткие итерации и надо общаться. Решает эту проблему

Просто перекладывать риски не надо на продактов и называть это аджайл.

Как-то это уже попахивает подходом "к пугавицам есть притензии?"

Аналитик?

Ты продакт?

Если DOR не готов - значит вся команда его не сделал. Не помогли аналитику и продакту

Ты продакт?

В данный момент как идеолог выступаю) продакт, биздев отчасти.

Жизнь это боль

Это правило жизни такое. Вот представь себе, ты на Марсе, и у тебя скафандр пробило. Или ты его как-то заделаешь, или помрёшь. Будешь dod прописывать?

если вы такие аналогии делаете, то похоже у вас не agile, а обычная русская штурмовщина. если хотите долгосрочного эффекта, нужен горизонт планирования чуть дальше, чем "нужно вчера".

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

И чья ответственность этот горизонт?

А также, наличие горизонта убирает все случайные факторы в мире?

хороший вопрос. если в огранизации бардак и "нужно вчера" с самого верха, но никакого процесса не построить. ни agile, никакого другого;

хороший вопрос. если в огранизации бардак и "нужно вчера" с самого верха, но никакого процесса не построить. ни agile, никакого другого;

Все же ответь на вопрос.

Чья ответственность?

Если "неких людей за пределами аджайл" то поздравляю, у вас даже близко не аджайл, а заповедник гоблинов

А также, наличие горизонта убирает все случайные факторы в мире?

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

Случайный фактор случается каждую секунду.

Вопрос умеете ли вы из них выгоду извлекать или нет

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

Про ответственность то ответишь?

Важный вопрос, самый важный в этой дискуссии

Если ответственность вне команды, это вообще не аджайл

Типа кто-то там, эти "менеджеры" там косячат, а мы, светлые войны ажлайла не будем с их кривыми додами руки марать, у нас АДЖАЙЛ!

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

@omin1 вы пили вчера?

нет :)

но не спал последние пару дней, тут вы правы)

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

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

нет, странный вывод.

Опять же, форс-мажор это одно, случайность или возможность другое,

если вдруг что-то произошло и можно хайпануть, но из-за аджайла не хайпануть, это хреново

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

они вообще могут код не писать, если придумают лучше способ бабки рубить)

Демо это вообще не про то. Демо это про достижение целей

Не про инспекцию?

хорош флейм разводить

вы про разные вещи говорите и совершенно игнорируете слова друг друга это не продуктивный спор

Тут монолог с нескольких сторон)

Не про инспекцию?

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

а какие особенности 2го этапа формирования команды? тоесть когда все плохо) было б круто примеры со скрам)

Приветствую всех, а есть кто из Саратова у меня к местным вопрос не большой

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

Как вы планируете то что ещё не видели и когда могут всплыть проблемы?

Приветствую всех, а есть кто из Саратова у меня к местным вопрос не большой

+

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