Привет. Мы дизайнеров вынесли за пределы команды разрабов и сделали команду PO, которая готовит истории для спринта. То есть, на момент старта спринта либо дизайн уже есть, либо, если история пришла в последний момент, то рисуем на бумажке ручкой, что будет примерно вот так - это дает понимание какими данными мы будем оперировать и позволяет сделать бэк и на клиенте пилить все, что надо для связи с этим бэком. То есть, фактически, дизайн идет на спринт вперед: в этом готовим на следующий.

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

Привет. Мы дизайнеров вынесли за пределы команды разрабов и сделали команду PO, которая готовит истории для спринта. То есть, на момент старта спринта либо дизайн уже есть, либо, если история пришла в последний момент, то рисуем на бумажке ручкой, что будет примерно вот так - это дает понимание какими данными мы будем оперировать и позволяет сделать бэк и на клиенте пилить все, что надо для связи с этим бэком. То есть, фактически, дизайн идет на спринт вперед: в этом готовим на следующий.

То бишь "dual-track agile"

ну да. так немного похоже. буду знать)

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

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

Например, тестеры по ui/ux советую сейчас, и часто полезно бывает

А кто сказал, что не участвует?

когда начинается подгттовка беклога и все готово крупными наборсками (или на словах). мы собираем встречу с представителями команд разработки

и им рассказываем

и вот тут начинается самое интересное. они начинают задавать вопросы. и иногда всплывают моменты, которые быстро нельзя решить. грубо говоря: вот тут не впишется в логику или еще что-то. и у команды PO если время подумать и что-то изменить

Ну вот и получается, как мне кажется, 2 варианта 1. Команда разработки среди спринта отвлекается от задач, чтобы заранее обсудить с командой дизайнеров что и как делать. А на этапе планирования спринта обсуждает ещё раз 2. Или дизайнеры делают что и как хотят (а иногда это реально излишний функционал для красоты) и в итоге с ним команда просто соглашается и берет в работу

Среднее время работы дизайнера над задачей у нас около 3 дней, наверно... если он сделал что-то плохо то в начале спринта это переделывать нужно будет (а команда в это время тупо ждёт...), поэтому я подключаю команду к обсуждению в ходе работы дизайнера. Поэтому они и живут в команде

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

А потом да, каждая команда при планировании все это обсуждает

Точнее не все, а свои истории

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

Не понимаю, в чем проблема. PBR ни кто не отменял. Так что, если надо то надо.

Ну это ответ Евгению..

Коллеги, а как расшифровывается PBR?

Уход за продуктовым беклогом

Вольный перевод)

Коллеги, а как расшифровывается PBR?

product backlog refinement видимо

Теперь буду изучать магию этого процесса :) первый раз слышу такой термин. Спасибо!

«Псевдо-аджайл» только поначалу выглядит круто – разрушаем популярные мифы https://rb.ru/opinion/agile-myths/

product backlog refinement видимо

Точно

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

Смущает что сейчас дизайнеры работают в спринте 70%, а ещё 30% идёт работа для следующего спринта. Если работать иначе то они будут дизайнить для спринта действующего, но тогда в начале дня 3 другие разрабы будут курить, ожидая макеты и графику

Чем это плохо?

Какой класс закончил, юноша?

Обратите внимание - exe весит 1.8 метров. На чем он его писал и как? Нормальный троян весит копейки.

У меня на телефоне не запустилось

Обратите внимание - exe весит 1.8 метров. На чем он его писал и как? Нормальный троян весит копейки.

Берешь дотнет...

На делфи, известно на чём

На делфи, известно на чём

Дельфи хоть и отличается громоздкостью, но не сильно. Средний размер. Должен был бы весить около 300кб. А тут аж 2 метра.

И как это побороть не представляю

по моему скромному мнению, бороть не надо. PBR - это процесс, а не только лишь митинг. Есть цель спринта, по ней идёт работа, и до 10% capacity всего спринта можно и даже нужно всей командой (!) потратить на подготовку к следующим спринтам. Это может включать в себя как митинги с маркетологами, дизайнерами, даже юзерами, так и разработку на коленке какого-нибудь скрипта, чтоб проверить, что вон та хреновина, которую мы собираемся сделать через пару спринтов, в принципе заведётся. Сюда же входит и разработка дизайн макетов. И я лично не вижу ничего зазорного, что пока все разработчики работают по цели спринта, дизайнер сидит в скетче и доводит до ума wireframe, который он на PBR митинге с разработчиками сочинил.

+1

Ну в целом, Evgeniy, советую накурить статью New New Development Game 1986 года про Scrum. Она даёт понимание принципов, которые в скрам-гайде не описаны, к моему глубокому сожалению.

Всем привет! У меня вопрос, у кого сколько спринтов заняло, чтобы "пристреляться" по срокам? Ну вот первые пять спринтов мы оцениваем задачи в собаках и бегемотах, потом десять, и уже какбэ неудобно говорить начальству "наберитесь терпения, команда разгоняется, мы вот щас разминаемся". Задают понятный вопрос: "Вы блин проект закончите раньше, чем у нас кончатся деньги, или позже?" По коллективному опыту, кто за сколько спринтов выходил на предсказуемость сроков?

Есть ощущение, что проблема в ценности продукта. Смысл ведь в том, что бы дать нечто работающее и одновременно удовлетворяющее реальную потребность клиента как можно раньше. А потом итерационно довести до состояния 'дайте две!'. Тут нет задачи сдать в срок, такой проблемы нет - рабочий продукт есть намного раньше дедлайна.

А в целом да, соглашусь с коллегами. Если мерить относительными функциональными единицами (собаками, майками, попугаями), то 3-5 спринтов дают хорошую картинку для burnup chart-а. Один раз мы с помощью стори-поинтов дали очень реалистичный прогноз даже не начав первый спринт. Но я не уверен что сможем повторить.

Коллеги, все понимаю, со всем согласен, спасибо.

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

И да, буду признателен , если кто нибудь сможет поделиться материалами про PBR. Очень желательно на русском(

Поищу пока статью New New Development Game 1986 года про Scrum.

И да, буду признателен , если кто нибудь сможет поделиться материалами про PBR. Очень желательно на русском(

https://www.youtube.com/watch?v=b_WeHcZcx1w - лучшее на тему PBR, из всего, что я видел. Сожалею, на английском. Но настолько наглядно, что в принципе поможет даже с плохим владением английским.

Супер! Спасибо

Поищу пока статью New New Development Game 1986 года про Scrum.

https://hbr.org/1986/01/the-new-new-product-development-game - оригинал на английском (конечно лучше читать именно его) http://agilerussia.ru/methodologies/%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%BD%D0%BE%D0%B2%D0%BE%D0%B3%D0%BE-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D0%B0-%D0%BD%D0%BE%D0%B2%D1%8B%D0%B5-%D0%BF%D1%80%D0%B0/ - перевод статьи

я скачал и проверил Битдефендером - там вирусняк какой-то нашёл. Забаньте автора!

Максим Полетаев, один из директоров Сбербанка, объясняет Agile : "Например, служба вкладов придумала новый вклад, спросила у кредитного департамента, можно ли кредитную карту вшить в продукт, написали техническое задание, отдали на разработку. "

Народ, объясните, где тут Agile? Написали ТЗ -> Отдали на разработку - это обычный водопадный процесс :)

это ж СберДжайл

гайз, а в это группу за вакансии нельзя постить?

гайз, а в это группу за вакансии нельзя постить?

@agile_jobs

Народ, объясните, где тут Agile? Написали ТЗ -> Отдали на разработку - это обычный водопадный процесс :)

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

@agile_jobs

спасибо, но жаль что там 200 юзеров всего

если тут запушу, меня сразу кикбанипощщам?

Да тут спам годами гуляет))

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

Зная сбербанк, скорее всего забыли на полгода

Про "Сбербанк"

Крупнейшая по количеству сотрудников IT-компания в России — «Сбербанк-Технологии» («СберТех», 100-процентная «дочка» Сбербанка) — в скором времени сменит генерального директора. Свой пост покидает Алиса Мельникова, пишут «Ведомости» со ссылкой на её знакомого. В пресс-службе Сбербанка подтвердили информацию, но воздержались от комментариев по поводу причин ухода и дальнейших планах руководителя. По данным близкого к «Сбертеху» источника издания, Мельникова покинет компанию в июне. Кандидатура её преемника пока не известна. http://servernews.ru/953591/?utm_source=nova&utm_medium=tg

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

"Сделали ТЗ" уже определяет, что разработка не итерационная с обратной связью. А следовательно — точно не agile

"Сделали ТЗ" уже определяет, что разработка не итерационная с обратной связью. А следовательно — точно не agile

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

Конечно, именно в этом суть agile!

А не продукт оунер должен проработать это, а затем обсудить с разрабами?

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

Не будет ли это описание изменений называться ТЗ в терминах не сильно погруженного в IT бизнесюка?

Конечно, именно в этом суть agile!

в итоге получат не то и не там, падающее на проде под реальной нагрузкой

itanalyst, это был сарказм

бизнес вообще не должен ТЗ писать

Он и не пишет ТЗ

дай бог чтобы бизнес-требования, концепцию и бизнес-обоснование отработали

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

https://www.change.org/p/%D0%B7%D0%B0%D0%BA%D0%BE%D0%BD%D0%BE%D0%B4%D0%B0%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE-%D0%B7%D0%B0%D0%BF%D1%80%D0%B5%D1%82%D0%B8%D1%82%D1%8C-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8-scrum-%D0%B2-%D1%80%D0%BE%D1%81%D1%81%D0%B8%D0%B8

Денис меня опепедил :)

Ахаха. Я даже подписал )

Нужно больше баянов

Все можно найти в этих наших интернетах и совершенно бесплатно. Я сначала пользовалась этим бложиком http://tim.com.ua/blog/

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

Подскажите был ли у кого опыт использования SCRUM/Канбан методологий в рамках ТОЛЬКО отдела/группы качества(QA) Интересно: - Как визуализировали процесс (колонки) - Как поступать с регулярными задачами (регрес кажые 2 недели например) - Как отслеживали работу Dev для старта qa.

Скрам работает только на кросс-функциональных командах. Т.е. на моно-функциональной группе (например только QA) точно не заведется. Да и смысла нет. Если хочется локальной оптимизации, то подойдёт Канбан Дэвида Андерсона.

Друзья, у меня есть довольно нубский вопрос, поэтому может быть подскажете куда можно копать, что фундаментального почитать/посмотреть? Собственно, история такая: работаем по канбану, но проект длится уже какое-то неприличное количество времени (софтланч довольно сложного продукта). Чувствую, что команда выдыхается и работает как конвейер в плохом смысле этого слова: ребята совершают довольно досадные ошибки и подчас не очень внимательно читают джоб стори, а потому и перетестировать приходится по несколько раз — в общем, тяжко. Вопрос такой: что имеет смысл делать в данном случае? Опыт подсказывает, что можно было бы ввести более короткие итерации и таким образом "встряхнуть" команду, но здравый смысл говорит, что итерации без релизов - это чушь собачья. Может быть есть какие-то общеизвестные и более здравые способы?

Или же такие монструозные релизы в целом с AGILE несовместимы по определению?

Точнее вопрос звучит так, наша разработка моб-приложений и внедрение нового функционала это проект или наша операционная деятельность?

Если у вас там есть scope, cost и time, то проектная.