Пробная выжимка из чата ctodailychat на тему Scrum, Agile и др.
- Есть две задачи, одна легкая, но объёмная; вторая просто неизвестность. как оценить, пусть в любых единицах
- На сколько спринтов возможно планировать без «эффекта бульдозера»?
- Что делать с вечно переезжающими задачами?
- Понятие и распределение «старых» и «новых» задач в спринте
- Распределение задач по тегам в спринте (сегментация)
- Планирует ли кто в таком режиме: «в этот спринт берем фича1..фичаN, баг1…багN», без оценки каждой задачи в днях часах, сторипоинтах, попугаях?
- Проблемы в процессах
Есть две задачи, одна легкая, но объёмная; вторая просто неизвестность. как оценить, пусть в любых единицах
- берётся список задач, которые команда делала за последние пару месяцев, каждый член команды предлагает свои 5-7 штук разной сложности по его мнению (то есть от самой простой до огромной и сложной)
- Команда садится, смотрит в случайно отсортированный список и начинается первая стадия: предложивший читает задачу, рассказывает, что надо было сделать, какие были риски и проблемы и что он в итоге сделал, говорит свою словестную оценку сложности от "оч простая" до "супер сложная"
- задача кладётся в начало, конец или середину в зависимости от оценки
- повторяем 2-3 для всего списка
- опять идём по списку и хотим поддержать следующий инвариат: задача выше не сложнее задачи ниже для любых i, j, это может быть длительной дискуссией
- к этому моменту имеем отсортированный список задач и какой-то консенсус по сложности каждой на уровне команды
- первой задаче даём 0.5 или 1
- идем сверху вниз и говорим, увеличилась ли сложность задачи относительно предыдущей или осталась та же самая, чиселки увеличиваем по известной шкале (фибоначчи, степени двойки, что угодно экспоненциально растущее) 8.1 не надо бояться поменять порядок во время оценки, такое бывает
к концу имеем отсортированный по сложности список задач, где есть промежутки с числами можно ещё написать для каждого блока словестное описание критериев к задаче, чтобы она подходила под этот блок, но это уже высший пилотаж))) и собственно оцениваем новую задачу в соответствии с этими эталонами, на покере обсуждаем, на что задача больше похожа и почему я её положил в тот или иной бакит с числом X, почему там 5, а не 13 и тп
когда все хз, что делать с задачей и как много там работы, то кажется, что можно написать отдельную слинкованную задачу на исследование, оценить её (обычно это какое-то небольшое число) и исходя из этого исследования взять новую в спринт, мы так делаем, но у нас спринты недельные
По поводу горизонта планирования: на сколько угодно спринтов вперед, просто нужно понимать, что это не точно. Потому что потребности бизнеса могут быть скорректированы за этот год. >>
Если смотреть на треугоьник ограничений, то за спринт фиксирован бюджет, и время. А команда на планировании должна выбрать те задачи (из уже проработанных), которые принесут максимальную пользу продукту
С багами в аджайлах можно подругому бороться: например есть дежурный, который раскапывает всякую хрень по багам, он берет баг и тратит на него не больше часа. Если не смог решить (записывает все что раскопал в задачу и возвращает в поток), в другой день дежурный может потратить на эту задачу в 2 раза больше времени, потом еще в 2 раза и тп. цель такая: не зарыться в задачу и записывать все что раскопали >>
есть еще прикольная тема с тех спринтами: каждый 6й (любая другая цифра) технический, в рамках которого делаются задачи по улучшению надежности, рефакторингу кода, багофиксам, техническим ресечам. В идеале, есть еще метрика качества и если она ниже минимума, в этот спринт должны взять баги, которые люди хотят >>
качество еще не забывайте включать в треугольник. Часто для достижения "выше рынка" приходится сильно процессы менять. В том числе и горизонт планирования обеспечивать
мы просто пофиксили процесс, сделали итеративным с фиксами по планам и архитектуре в среднесроке. из ажайла остались планерки :) Решили не патчить бажный процесс, а просто заюзать то, что работает
Полагаю, что единственный верный способ узнать ответы на подобные вопросы — пойти гуглить на английском и читать по 3 перпендикулярных друг другу источника или мнения. Не существует лучших для всех практик, почитайте успехи и фейлы, подумайте, что можно попробовать применить и дальше адаптируйте. >>
Ant M - DEBUG!!!
юзать нормальные методологии планирования и подходы. Проблема не в инструментах, проблема в системе.
Бульдозер: это как раз переезжающие задачи. Их планируют после какой-нибудь важной даты/релиза, и к (например) новому году понимаем, что на январь запланировано задач втрое больше возможностей (от темной темы для ios до редизайна карточки предложения в программе лояльности) >>
среднесрок обычно отдельно планируется, если пред. анализ делать (можно прям через RnD тикеты), то можно получать лучшую оценку LoE. Обсуждений в этом случае недостаточно, нужен полноценный анализ. С продуктовой линии тоже нужны ориентиры, под которые подстраивать тех. часть >>
если у вас задача ездит по бэклогу третий месяц, то возможно эта задача вам не очень нужна >>
Понять вы это сможете, если честно сядете и верхнеуровнево посмотрите на бэклог, выделите там направления развития, шаги этих направлений (майлстоуны, цели), сгруппируете задачи по этим направлениям (можно повесить их на один эпик) и шагам (это похоже на юзер стори) >>
было что-то подобное, что сейчас обсуждается про бульдозер, кмк вылечилось слегка раздутием эстимейтов, чтобы заполнять спринт с точки зрения клиента. количество выполненной работы принципиально не изменилось (считай, начали правильнее считать ревью, митинги, груминги), зато ощущение между "чуть не успели" и "сделали чуть дополнительно" (по факту столько же, как и раньше когда не успевали) - команде и клиенту сильно больше нравится второй вариант. >>
Но все же, да, есть ощущение, что похороним нужные задачи >>
не хороните, структурируйте. Одну модель Вам Глеб показал, я бы еще допонительно посоветовал сделать синтез связанного функционала и положить его описание в общее место, потом бреинштормить и понять, как оно в ваш продукт вписывается, кто юзер, покупатель и т.д. Не разбрасывайтесь информацией, делайте аналитику по проблемному полю и вашим кастомерам. Это часть создания отличных продуктов и отличной команды >>
возвращаясь к баранам в самом верху, у меня был кейс, когда команда не справлялась со своим спринтом не потому что много задач брали в спринт, а потому что другие команды и саппорт их заваливал своими задачами. Они думали так: "задач у меня в спринте не много, наверно сейчас сделаю очень срочную таску саппорту, а потом возьмусь за спринт" и не успевали. В итоге решили двумя договоренностями:
- изменили воркфлоу в жире так, чтобы нельзя было таску вернуть назад (кроме как из тестирования в реворк) + разрешили из любой точки переход с резолюцией won't do в done
- договорились что одновременно на человеке не может быть больше 2х задач, одна из спринта, другая не из спринта. >>
формулировать Definition of Done, если есть, то внедрять оценку и снижать объём работ до момента, когда спринт реально будет закрыт. >>
это короткая выжимка из большого кол-ва статей по теме)))
не надо бояться недонаполнить спринт, если вы случайно сделали так, что спринт реально был закрыт раньше на день-два-три, то это успех и надо зафиксировать его, ещё пару раз закрыв такие спринты. Воизбежание снижения эффективности рабочего времени предлагается завести список задач "когда-нибудь обязательно надо сделать" (техдолг) и закрывать их в случае, если спринт был закрыт раньше >>
И на самом деле, удовольствие и профит от закрытия спринта команда получит гораздо больше, чем бизнес потеряет от того, что не забил этот спринт под завязку >>
каких старых и новых? Все задачи одинаково новые, даже незакрытые переехавшие. Расставьте строгие приоритеты выполнения (т.е. последовательность), сформулируйте цели спринта, разделите задачи на группы по сформулированным целям, приоритеты скорее всего будут кореллировать с этими целями. >>
Это называется Sprint Goals и про это написано в скрам гайде >>
У меня была практика, вроде бы в итоге успешная, где мы поступили следующим образом: у нас было три статуса у тикета: New, Open, Backlog и виртуальный Sprint Backlog (на самом деле Backlog + фильтр по заполненности поля со спринтом) >>
Open и Backlog считались классическим скрамовым бэклогом >>
Флоу у ПО был следующий: в New попадала любая задача, добавленная в очередь, в Open висели задачи, на которые po посмотрел и наполнял их контекстом, в Backlog попадало то, что уже готово для того, чтобы брать и делать >>
кстати, я часто видел проблемы в процессах просто из-за того, что скрам гайд или аджаил манифест неправильно прочитали или прочитали сквозь пальцы
но когда возникают вопросы по процессам — почти всегда есть формулировка на англ, по которой гуглится статья-ответ или близкий кейс
важно регулярно формулировать и задавать себе эти вопросы, например, на ретро, которым пренебрегают, кажется, почти всегда >>
Планирует ли кто в таком режиме: «в этот спринт берем фича1..фичаN, баг1…багN», без оценки каждой задачи в днях часах, сторипоинтах, попугаях? >>
Александр Арбузов
а это имеет смысл? спринт фиксированный?
Dmitry Badanin
Спринт фиксированный.
Gleb Novikov
если вы набираете спринт, успеваете его, то почему бы так не делать?
Max Syabro
Это получается тот же канбан с разделением по две недели
Gleb Novikov
оценки никакого отношения к скраму не имеют, кстати
Александр Арбузов
такое имеет хоть какой-то смысл только если коллектив настолько сработался, что все примерно знают капасити/велосити команды и могут без эстимирования
Gleb Novikov
ванильный скрам без оценок)
Ant M
а почему нельзя оценки получить?
Dmitry Badanin
Эстимирование это же часто пальцем в небо. То есть если чел говорит, что сделает за 2 дня, то он часто делает так, чтобы растянуть на 2 дня - не быстрее.
Dmitry Badanin
Бизнес конечно хочет метрик и оценок. В команде оценка часто дается пипец как неточно. Собираем статистику по исполнителям, но часто задачи сильно разные и набрать взвешенную оценку по каждому типу задачи не получается.
Gleb Novikov
эстимирование абсолютное да
Александр Арбузов
у меня лично есть стойкое ощущение, что чем дольше я работаю в рамках проекта с одной и той же командой - у меня все лучше будет ощущение как быстро и успешно мы справимся с набором задач
Gleb Novikov
но оценка стори поинтами как раз запрещает оценивать часами / днями
Ant M
если никак не решать проблему агента-принципала, то да, но обычно эффективный бизнес (и команды) ее умеют решать
Dmitry Badanin
Когда то практиковали так: берем простую всем понятную задачу, оцениваем ее в условных единицах, все остальные оцениваем по ней. Потом Planning Poker + оценка из ряда фибоначи. Не скажу, что было круто, но по крайней мере почти не было ситуаций когда пообещали, но не сделали. Ряд фибоначи помогал закладывать риски: ты не можешь оценить задачу в 4 условных единицы, только 3 или 5.
Gleb Novikov
ну так это классический подход, да, и тут нет абсолютных оценок, они относительные (относительно вашей базовой задачи)
Gleb Novikov
Но я сторонник чуть более сложного подхода — там не про одну базовую задачу, а про список нескольких эталонов на каждое число