Pavel по теме чата вопрос. Мы как то дискутировали на тему как жить UX/UI людям в командах, если и Scrum и LeSS нам говорят о том, что никаких отдельных команд или подкоманд создавать нет смысла. Из опыта работы с командами, поначалу были случаи, когда дизайнеры пытались себя утилизировать и работали «наперед»по «сговору» с РО. Они уговаривали его и втихушку делали макеты якобы для будущих задач, но по факту 90% этих макетов либо устаревали или просто никогда не заходили в спринт. В общем работа для работы. &О это дело прикрыл, поняв гиблость этой затеи. Но сейчас пошла новая волна и сообщество дизайнеров на меня начало «давить» по доброму, рассказывая истории, что вот у других все по другому. Что другие херачат дизайн в отдельной команде и при этом себя утилизируют на 100%. И что еще другие типа сидят в командах, а делают дизайн наперед, чтобы команда в следующем спринте флаг подхватила и понесла. При этом понимают, что так примерно и делали тайком, но не вышло. Но самы главный аргумент это невозможность делать исследования с потребителями за двухнедельный Спринт и все это пускать в работу по этой этой задаче. Хотя по факту они этого сейчас и не делают. Я пока привял аргументы по прошлому опыту. Они отступили. Но сильно попросили поспрошать о практиках в других компаниях. Как кто с этой темой живет? Сейчас проблема в том, что они чувствуют себя обделенными и ненужными. Так как не всегда загружены работой. Протухают короче.

я с пашей соглашусь про отдельную команду и дискавери тиму)

у нас компромис. большие истории, сложные с точки зрения проектирования интерфейса берутся на исследование на спринт раньше. Понятные истории (без необходимости анализа) делаются в спринте сразу. пропорция примерно 40/60

у нас компромис. большие истории, сложные с точки зрения проектирования интерфейса берутся на исследование на спринт раньше. Понятные истории (без необходимости анализа) делаются в спринте сразу. пропорция примерно 40/60

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

Вся команда да. Даже не вся команда, а все команды. И аналитики и дизайнеры в том числе. Частично кстати делается проработка и на PBR. Но такой элемент с очень большой вероятностью зайдет в Спринт. Это оправданно.

Вообще это исслдеование можно отнести к PBR по большому счету. Если на выходе понимание и наброски макетов - то допустимо, разве нет? Понижаем вариантивность)

Нет в LeSS отдельных команд. Не работает. Бас и Крейг против :)

В LeSS нет, на практике есть. Напише Грегу вопрос, может ответит :)

@DasBotrek у вас как это сделано? Дизайнеры в командах?

У нас еще интересное наблюдение. Мы проводим обзоры спринта с конечными пользователями. Уже больше полу года. Паралельно было заказано исследование на фокус группах разрабатываемого продукта за кучу бабла. На выходе получилось, что 80% того, что обнаружили эти исследовали мы отлавливали на обзорах)

Нет в LeSS отдельных команд. Не работает. Бас и Крейг против :)

Не. Андоре департмент зло.

Я посмотрю завтра в гайдах. Там есть про это. Но там именно про то, что все должно быть в командах. Перечитаю.

Дизайнеры у Вас как работают?

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

Сергей, смотри на эту команду, как на расширение возможностей PO. Тем более, что имено он и будет ее фасилитировать :)

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

Не. Ему некогда ее фасилитировать.

Сергей, мне не кажется, что мой ответ тебя порадует: пока из всего, что я видел на практике, работает выделение UX дизайнеров и аналитиков в отдельную команду, которая работает над прототипами и фидбэком отдельно от dev team

Брщ это такой суп, который почти фреймворк - ингридиетны не фиксированы и у каждого модет получиться свой борщ :)

А можно в борщ варенье добавить? А шоколад? Ещё апельсины и мандарины? И ложечку меда

это не аджайл

Аджайл это вообще набор принципов и практик :)

Ценностей и принципов :Р

тот же scrum можно отлично сделать не-agile и он даже работать будет :)

Я ее называю дискавери командой и добавляю туда бизнес-аналитика и архитектора, чтобы не путались под ногами у деливери команды, итогом их работы считается нормально (но не как в водопаде) описаная сторя с прототипом, но финальный дизайн за дизайнерами внутри команд по состоянию на момент

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

Pavel по теме чата вопрос. Мы как то дискутировали на тему как жить UX/UI людям в командах, если и Scrum и LeSS нам говорят о том, что никаких отдельных команд или подкоманд создавать нет смысла. Из опыта работы с командами, поначалу были случаи, когда дизайнеры пытались себя утилизировать и работали «наперед»по «сговору» с РО. Они уговаривали его и втихушку делали макеты якобы для будущих задач, но по факту 90% этих макетов либо устаревали или просто никогда не заходили в спринт. В общем работа для работы. &О это дело прикрыл, поняв гиблость этой затеи. Но сейчас пошла новая волна и сообщество дизайнеров на меня начало «давить» по доброму, рассказывая истории, что вот у других все по другому. Что другие херачат дизайн в отдельной команде и при этом себя утилизируют на 100%. И что еще другие типа сидят в командах, а делают дизайн наперед, чтобы команда в следующем спринте флаг подхватила и понесла. При этом понимают, что так примерно и делали тайком, но не вышло. Но самы главный аргумент это невозможность делать исследования с потребителями за двухнедельный Спринт и все это пускать в работу по этой этой задаче. Хотя по факту они этого сейчас и не делают. Я пока привял аргументы по прошлому опыту. Они отступили. Но сильно попросили поспрошать о практиках в других компаниях. Как кто с этой темой живет? Сейчас проблема в том, что они чувствуют себя обделенными и ненужными. Так как не всегда загружены работой. Протухают короче.

Все что они делают заранее уходит в корзину. Никто не знает куда повернем завтра. Если макеты лежат пару спринтов, они протухают. Ибо команда сделав PBR рушит их макеты, прояснив задачу.

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

У меня дизайнер так же учавствует в груминге и планнинге, но работает со сторями на спринт-два вперёд. В конце концов, дизайнер вместе с PO, больше других кастдевит и валидирует идеи заранее. Главная его задача максимально валидировать UX стори, а UI из либы быстро собрать можно.

Блин, неужели никто не провобовал делать строить интерфейсы на основе предметки и заранее заготовленной либы компонентов? Я как собиратель просроченных продуктов С целью найти бак с самыми ценными продуктами Хочу чтобы каждый бак был подписан его содержимым. Модель: Бак 1к1 подпись Подпись 1кМногим Просроченный продукт Действия - выбрать бак - посмотреть подпись - забрать продукты Для того чтобы сделать выбор бака мне нужно знать степень наполнения бака (издалека это все что можно разглядеть) Для того чтобы решить стоит ли копаться в баке мне нужно по каждому продукту в баке владеть информацией: когда срок годности прошел, количество, распакован или выброшен в упаковке. Все, функциональный макет уже продиктован потребностью пользователя. Дальше разработчики могут брать этот подразумеваемый макет, брать библиотеку компонентов и стайлгайды и делать без участия дизайнеров. Дизайнер только проверяет по ходу дела и конечный результат. В такой ситуации дизайнер это часть PO

Аналитика, архитектура и дизайн, рожденный вне команды это мертворожденный ребенок имхо. Во первым мы получаем тот самый корпоративный пинг-понг, когда идет перепихивание ответственности между отделами (командами), во вторых мы теряем скорость поставки, в третьих мы получаем зависимости, в четвертых мы получаем некислые риски в виде того же архитектора - «власть» специалиста. И мы все это уже проходили. Эта субоптимизация в нашем случае приносит вред. Хотя я могу допустить, что где-то ее можно применить как временный вариант в переходный период ...

Это вполне работающая схема в случае большой интеграционной составляющей, когда в спринт толком что ни возьмешь то "мы ждем реакции от билинга, доработка будет чернз пару месяцев" или "нам еще не ответили из шины данных, как лучше к ним подключиться", это может развалить любой спринт. Поэтому когда мы строили LeSS-like мы себе поставили задачу делать так, чтобы попавшее в спринт в спринте и исполнялось, и это было нереально сложно с учеьом интеграционной сложности ландшафта. В итоге нарастила с 1 архитектора интеграционного до 4х и сделала 4 бизнес-аналитиков-продактов в дискавери команде, а весь процесс завернули в канбан-систему и сокращали лид тайм. В среднем один тикет тогда проходил 6-12 месяцев сначала, и вообще никакие спринты не получались.

Павел, спасибо. Мне именно этого не хватало для полной картины объяснения заказчикам, почему сроки по "проекту", который делался через итеративно-инкрементальную разработку "съехали" в оптимистичном прогнозе на год, в пессимистичном - на два. :) Как раз потому, что обратная связь от пользователей начинает "давить" на скоуп в процессе поставки. Если бы всю функциональность одним большим куском зарелизили в конце "проекта", то сроки стали бы оптимистичней, а пользователи печальней. Гениально. :)

Не знаю как в теории, на практике я строила много чего, в частности в 13-15 году мы 20 команд в единый процесс запихнули, 12+8, десктоп и мобайл и я даже поработала деливери менеджером с функцией аджайл коуча, хотя должность называлась прожект менеджера в группе релизов. Мы тогда переизобретали LeSS по факту. Построить можно и заставить работать что угодно, главное понимать зачем, и чтобы людям в этом было приятно. Не понимаю этих историй про то, что и как НЕ работает. Это скорее всего просто с целеполаганием не проработано что-то и люди не вовлечены.

Коммунизм

Чего почитать? Возможно наши также работают, я пока не сильно погружался.