Size: a a a

Agile, Scrum, Lean, Kanban, XP

2020 January 23

NP

Nikita Poselyanov in Agile, Scrum, Lean, Kanban, XP
Почему-то никого не настораживает строчка из гайда
источник

NP

Nikita Poselyanov in Agile, Scrum, Lean, Kanban, XP
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
источник

G

Gleb in Agile, Scrum, Lean, Kanban, XP
Nikita Poselyanov
Почему-то никого не настораживает строчка из гайда
там есть строчка что то в стиле "скрам можно применить к любой сфере", вот на ней некторые заканчивают читать гайд
источник

NP

Nikita Poselyanov in Agile, Scrum, Lean, Kanban, XP
Gleb
там есть строчка что то в стиле "скрам можно применить к любой сфере", вот на ней некторые заканчивают читать гайд
я тут общался с группкой знающих про скрам "те дочитали до строчки - Purpose of the Scrum Guide
Scrum is a framework for developing, delivering, and sustaining complex products."
источник

NP

Nikita Poselyanov in Agile, Scrum, Lean, Kanban, XP
ну и дальше можно как бэ не читать, итак всё понятно
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
Опять чтоли сркам обсуждаете
источник

NP

Nikita Poselyanov in Agile, Scrum, Lean, Kanban, XP
тут Лёха вбросил, мы сагрились :)
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
Мув он же, бизнес агилитики, алайнмент, энвайромент, со2
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
я тут смотрю на ивенты канбан-юниверсити, и они то в бильбао то в haro, и что-то я начал подозревать что не с проста эта все... haro кстати винная столица
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
почему в россии нет такого... agile retreat kamchatka
источник

S

Slava in Agile, Scrum, Lean, Kanban, XP
или какой-нибудь (в хорошем смысле) Мурманск 🙂
источник

V

VP in Agile, Scrum, Lean, Kanban, XP
Slava
или какой-нибудь (в хорошем смысле) Мурманск 🙂
Санаторий?
источник

AB

Anton Bevzuk in Agile, Scrum, Lean, Kanban, XP
Кстати могу поделиться как в Додо построена работа с дизайнерами. Дизайнеры в отдельной команде а не в фичакомандах. Почему? Потому что у них очень плотная коммуникация между собой, выше чем между дизайнером и командой. В команде дизайнеров есть разные люди. Одному дай идею и он набросает тебе 50 вариантов интерфейсов как ее реализовать. Второй покритикует и выберет 10 наиболее UX-ных. А третий копает "вглубь". Он пиксельдрочер и доведет любой из предложенных вариантов до совершенства.

Команда дизайнеров очень тесно работает с PO в фазе Discovery. Они создают кликабельные прототипы в figma.io и проверяют на них гипотезы. Находят из 50 самый перспективный вариант.

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

PO

Pavel Ozolin in Agile, Scrum, Lean, Kanban, XP
Anton Bevzuk
Кстати могу поделиться как в Додо построена работа с дизайнерами. Дизайнеры в отдельной команде а не в фичакомандах. Почему? Потому что у них очень плотная коммуникация между собой, выше чем между дизайнером и командой. В команде дизайнеров есть разные люди. Одному дай идею и он набросает тебе 50 вариантов интерфейсов как ее реализовать. Второй покритикует и выберет 10 наиболее UX-ных. А третий копает "вглубь". Он пиксельдрочер и доведет любой из предложенных вариантов до совершенства.

Команда дизайнеров очень тесно работает с PO в фазе Discovery. Они создают кликабельные прототипы в figma.io и проверяют на них гипотезы. Находят из 50 самый перспективный вариант.

Когда команда разработки берется за фичу, которую проработали дизайнеры, дизайнер пересаживается в команду и сидит с ними, пока идет активная работа над фронтом, обычно 1-2 спринта. Рано или поздно фронт более менее успокаивается и команда допиливает всякие мелочевки. Дизайнер участвует в приемке фич, может сказать фи. Но за PO решающий голос, он может выпустить фичу даже если дизайнер недоволен.
Ну вот да, формат discovery team/PO team
источник

YS

Yuriy Smirnov in Agile, Scrum, Lean, Kanban, XP
Anton Bevzuk
Кстати могу поделиться как в Додо построена работа с дизайнерами. Дизайнеры в отдельной команде а не в фичакомандах. Почему? Потому что у них очень плотная коммуникация между собой, выше чем между дизайнером и командой. В команде дизайнеров есть разные люди. Одному дай идею и он набросает тебе 50 вариантов интерфейсов как ее реализовать. Второй покритикует и выберет 10 наиболее UX-ных. А третий копает "вглубь". Он пиксельдрочер и доведет любой из предложенных вариантов до совершенства.

Команда дизайнеров очень тесно работает с PO в фазе Discovery. Они создают кликабельные прототипы в figma.io и проверяют на них гипотезы. Находят из 50 самый перспективный вариант.

Когда команда разработки берется за фичу, которую проработали дизайнеры, дизайнер пересаживается в команду и сидит с ними, пока идет активная работа над фронтом, обычно 1-2 спринта. Рано или поздно фронт более менее успокаивается и команда допиливает всякие мелочевки. Дизайнер участвует в приемке фич, может сказать фи. Но за PO решающий голос, он может выпустить фичу даже если дизайнер недоволен.
А были какие-то еще варианты? Какие плюсы и минусы?
источник

AB

Anton Bevzuk in Agile, Scrum, Lean, Kanban, XP
Yuriy Smirnov
А были какие-то еще варианты? Какие плюсы и минусы?
Было много вариантов. Пробовали дизайнера в команде. Не очень получилось. Пробовали разные модели взаимодействия коианда/дизайнеры. Эволюционно нашли.

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

YS

Yuriy Smirnov in Agile, Scrum, Lean, Kanban, XP
Ясно, спасибо), а discovery team привлекает devteam к проверке гипотез?
источник

AB

Anton Bevzuk in Agile, Scrum, Lean, Kanban, XP
Yuriy Smirnov
Ясно, спасибо), а discovery team привлекает devteam к проверке гипотез?
Нет, не особо. Девелоперы подключаются когда гипотеза проверена. Но вот тут иногда начинается "Ну вы конечно и напридумывали. На iOS так не делается" :)

Кстати о T-Shape. У многих iOS разработчиков дизайн скиллы очень развиты. Они общаются на равных с дизайнерами, часто предлагают свои решения. Так что решение, которое получено на Discovery - не окончательное, это отправная точка для дальнейших обсуждений с командой.
источник

YS

Yuriy Smirnov in Agile, Scrum, Lean, Kanban, XP
Anton Bevzuk
Нет, не особо. Девелоперы подключаются когда гипотеза проверена. Но вот тут иногда начинается "Ну вы конечно и напридумывали. На iOS так не делается" :)

Кстати о T-Shape. У многих iOS разработчиков дизайн скиллы очень развиты. Они общаются на равных с дизайнерами, часто предлагают свои решения. Так что решение, которое получено на Discovery - не окончательное, это отправная точка для дальнейших обсуждений с командой.
В теории если делать аналогичный процесс из дев в дискавери выглядит перспективно, на практике неизвестно)). Такой вариант пока не попадался)
источник

AB

Anton Bevzuk in Agile, Scrum, Lean, Kanban, XP
Они сидят рядом, если что прибегают спрашивают ))
источник