« Rev
@agile_ru   508
Fwd »


Pavel
Кому? :) уже вроде давно все попризнавались
В скрам гайд только включить забыли. И на курсах csm не учат
Mikhail
Я, простите, практик. И рассказываю из личного опыта. Именно такие ПО наиболее успешны
Pavel
Я, простите, практик. И рассказываю из личного опыта. Именно такие ПО наиболее успешны
Какие именно? Которые знают, где бюджет достать, или которые команду нанимают?
Mikhail
В скрам гайд только включить забыли. И на курсах csm не учат
Не забыли кстати в гайд. Носом не ткнули - это да
Pavel
Угу, забыли написать, что сму нужны кросс-дисциплинарные скалы и знания, и что скрам-команда без коучинга не работает.
Sergey
PO это вообще территория непознанного :)
Vladimir
Владелец бюджета это ж не босс. Это владелец бюджета
По-моему вся беседа между Михаилом и Павлом после этого сообщения не стоит того чтобы ее читать )
Mikhail
Какие именно? Которые знают, где бюджет достать, или которые команду нанимают?
Которые вместе с командой набирают эту самую команду
Egor 😈
А тут, не? У меня восемь команд. Интересно же.
не хотелось писать то что возможно большинству не интересно..
Никита
Всем привет, занимаемся логотипами, сайтами и вирусными видео. Раньше работал у Артемия Лебедева. Теперь сам занимаюсь брендингом
Anonymous
Звучит не так круто, как хотелось бы лол
Aleksandr
если бы теперь АЛ работал у тебя, вот это было бы огонь)
Dmitry
Сначала хотел удалить как рекламу, потом понял, что это хуиз
Артем
Коллеги, а кто как справляется со срочными тасками, прилетающими на доску? Ну вот прям которые не могут ждать, высокий приоритет. Останавливаете у кого-то текущую задачу и даете эту срочную или в очередь как все? И стараетесь такого не допускать. У нас канбан если что.
Dmitry
отдельный класс сервиса и дорожка для срочных задач с минимальным лимитом на дорожку
Dmitry
типа "не более одной срочной задачи одновременно на доске"
Dmitry
ну тут смотрите сами, насколько у вас критичность таких задач высокая. И делайте соответствующую политику либо "все бросаем , херачим срочную, как только появилась" либо "втягиваем ее, как только освободился хоть кто-то"
Dmitry
и тд
Артем
Ок. Принцип понятен. Так и решили делать.
Sergey
Ок. А если все в команде уже заняты?
Берет первый кто освободится, хотя, такие таски оч редко прилетают, обычно "срочнопрямсейчасбыстрее" бывает в 2х случаях: - недопонимание со стороны постановщика задачи - плохой QA перед релизом = куча багов, что уж грешить, и такое бывает. Оба случая лечатся амбулаторно, и оба не смертельны
Артем
Спасибо
Aleksandr
срочность бывает разная. и принимать решение должен отдельный человек.
Aleksandr
бывает горящая Ж когда в любом случае просается таск и делается этот. а есть срочно но как в ролике про вагоны
Oleg
Из фитиля?😂
Артем
Да, и такое бывает
Oleg
Расставляйте приоритеты и сами поймёте как сделать правильно
Глебка
Есть у меня вопросик) В скрам надо как бы делать все слоями, сделали-улучшили и тд
Глебка
Так вот вариант сейчас такой: Дизайнеры сделали поиск ахреневший. С выпадашками и тд. Разработчики увидели на груминге и попытались разбить на строи
Глебка
Получилось плохо ибо надо поднять поисковой сервис и тд, долго в общем и не просто.
Глебка
Правильней ли было так: поиск, поиск с выпадашкой, поиск ещё с какой то фичей и тд
Levon
Угу, куски торта вкуснее есть целиком, а не по слоям
Глебка
Отрисовали- сделали. И в первой итерации было б база с как раз полнятием сервиса
Глебка
С точки зрения торта- куски, если по стори маппингу то слои :)
Глебка
Короче когда дизы сделали крутой слишком- это водопад некий
Levon
У меня возникает вопрос - а почему они вообще что-то делают отдельно?
Глебка
Ну потому что у нас так
Глебка
Мы к этому пришли
Глебка
Вопрос то подтвердить/ опровергнуть мои предположения
Pavel
Глеб, нет единственно правильного меода работы с требованиями. Нарезать поиск на логические блоки, каждый из которых можно доставить пользовтателю - отличный вариант.
Pavel
Нарезать на технические enablers, к которым уже цепляются стори - тоже норм.
Levon
Правильней ли было так: поиск, поиск с выпадашкой, поиск ещё с какой то фичей и тд
по описанию, если я правильно понял, это более правильно. Если это итеративно-инкрементально получается, то Scrum не противоречит
Sergey
Имхо дизайнеров в команды. Сами в команде разберутся.
Sergey
Они, кмтати, неплохо Юзер стори мэппинг делают. Вместе с командой пусть рабоиают. Будет норм.
Pavel
Имхо дизайнеров в команды. Сами в команде разберутся.
Это в общем виде правильно, но не всегда оптимально
Глебка
Ну я уже говорил было так
Глебка
У нас бомбящий проект с точки зрения методологий
Глебка
И неумеющий прОдукт
Sergey
Это в общем виде правильно, но не всегда оптимально
Угу. Ибо их утилизировать сложно. У нас они и аналитикой и тестированием занимаются. Отлично все получается.
Pavel
В моей практике выделенная requirement elaboration team чаще не из-за утилизации нужна, а из-за тяжелого наследия псевдо-вотерфола с кучей стадий аппрува.
Pavel
Т.е. толку иметь дизайнера в команде, если в пределах спринта он из-за кучи переделок и согласований ничего сделать не может.
Pavel
В итоге проще объединить аналитиков, UI и UX в команду, убедить в пользе канбана и синхронизиовать со скрам-командами через рейфайнмент и плэннинг.
Pavel
Минус подхода очевиден: cycle time задран в небеса, очередь растет, фиговые практики менеджерского аппрувала и HIPPO приоретизации цветут буйным цветом.
Глебка
И плюс продукт не хочет писать стори маппинг чтоб как раз дать базу а не фигачить дизайнеру все и вся
Pavel
Ну это вопросы к продукту. Суб-оптимальное поведение лучше не поощрять, иначе ничего к лучшему не изменится.
Sergey
Золотые слова.
Pavel
Ну да, кросс-функциональные команды по cycle time всегда бьют специализированные. Хотя бы потому, что нет handsoff delay
Levon
Я думаю, Глеб получил ответ на свой конкретный вопрос. То, что там есть проблемы в имплементации идеального Scrum, Глеб знает и сам.
Pavel
Но к кросс-функциональным командам еще надо прийти и очень часто на пути становятся корпоративные нормы, менеджерские привычки и т.п. impediments, борьба с которыми занимает отнюдь не пару спринтов :)
Pavel
В такой ситуации для оптимизации работы всей системы приходится принимать суб-оптимальные решения.
Игорь
Ок. А если все в команде уже заняты?
если еще актуально - мы делаем так: если прилетел критикал таск, от выполнения которого много-много юзеров облегченно вздохнут, то мы попросту просим ответственного аналитика выкинуть что-то менее важное из релизных задач, произвести своеобразную замену задач, но только после того, как команда оценит данную критическую задачу, чтобы можно было понять, на что торговаться с аналитиками, в случае если все задачи УЖЕ в работе/проверке, то тут ситуация сложнее, выкинуть уже нечего, но функционал надо чинить кровь из носу, при таком раскладе мы всегда оставляем некий запас сторипойнтов на вот такие важные хотелки, так как скорость команды более-менее однородна из релиза в релиз, то можно это спрогнозировать
Артем
Коллеги, еще вопрос. Кто-то знаком с Cynefin framework? Есть что-то хорошее почитать?
Sergey
А кто мне расскажет - можно ли ослаблять DoD. Ну планку задрали, написали, например, юнит тесты (неудачный пример). А по факту не тянут. И вот все собрались и команды с продактом решили выкинуть их из дод.
Arman
https://en.m.wikipedia.org/wiki/Cynefin_framework
Pavel
Нужно посмотреть, в чем була причина того, что элемент добавили в DoD, какую проблему он должен решать, а потом решить, решает ли на практике
Pavel
Ну и обсудить, почему этот элемент вызывает проблемы в имплементации у команды
Sergey
Ну и обсудить, почему этот элемент вызывает проблемы в имплементации у команды
Ну а если девелопмент тим и продакт решили, что хрен с ним. Надо ли в это лезть Скрам-мастеру?
« Rev
@agile_ru   508
Fwd »