аутсорс?

Частично в штате, частично аутсорс

Но созвоны организовать не проблема

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

Наверное, это решается жирой и настройкой доски по фильтру из нескольких проектов

Ну про инструменты универсальные рецепты особо подобрать не получится.

Я в такой ситуации (одна команда, поток коротких проектов) в jira сделал кастомное поле client и по нему фильтровал, если была необходимость.

А вообще старался сохранять фокус команды на одном "проекте" хотя бы в течение спринта, оптимально двух-трех.

@NanoBjorn и Pavel Добро пожаловать в секту!

Внезапно, у нас техподдержка на OTRS, разработка на Redmine, всего хватает 😄

Отрс- да, вполне себе. А редмайн для разработки - внезапно) надо почитать рассказы

Отрс- да, вполне себе. А редмайн для разработки - внезапно) надо почитать рассказы

Ну мы с редмайном на Бэклоге Продукта вполне себе жили.

Визуализации не хватало. Ушли на ютрек

А долго жили?

Много лет.

Тогда еще не было восьми команд. Попробуйте не использовать один и тот же инструмент для управления Бэклогом Продукта и Спринт Бэклогами. И будет любой инструмент подходить. Чем проще, тем меньше гемору.

У нас в командах доски со стикерами.

Ну хз, честно говоря. Около пары лет работал тесно с редмайном в качестве саппорта и вот совсем не вижу ему применения в качестве «заменителя» Джиры

У нас в командах доски со стикерами.

А метрики на основе чего считаете?

@NanoBjorn и Pavel Добро пожаловать в секту!

Да я уже давно был))

А метрики на основе чего считаете?

Какие, например?

Да я уже давно был))

С возвращением тогда :)

С возвращением тогда :)

Так я и не уходил))

Но мало писал

Не прокатило ;)

Какие, например?

Как там.. Velocity, например

Если есть только бэклог в редмайне и физические доски для спринта

Как там.. Velocity, например

А зачем? Это нужно только команде доя планирования Спринта. Ну и считается легко. Обычно в Спринт приходит не больше пяти элементов бэклога. Пять цифр сложить :)

Элементов - имеется в виду стоптала/тасков?

Элементов - имеется в виду стоптала/тасков?

Имеется ввиду элементов Бэклога, попавших в Спринт

Есть компании где вообще не оценивают элементы бэклога. Тогда нельзя померить велосити ;)

А есть где в размерах маек оценивают. L,M,XL,2XL. Как велосити померять?

А есть где в размерах маек оценивают. L,M,XL,2XL. Как велосити померять?

Статистическими вычислениями)

Ага. Как в мультике 38 попугаев. В них тоже кстати оценивают :)

Сергей, статистически :)

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

Просто просите команду проголосовать "есть ли еще место в спринте".

Ну мы с редмайном на Бэклоге Продукта вполне себе жили.

Мы прикрутили плагин Agile от RedmineUP, хватает вполне

Просто просите команду проголосовать "есть ли еще место в спринте".

Как ни смешно, но метод гораздо более точен. Видел работу этого метода. Команда объяснить не может, но знает, что 44 задачи в спринт лезет, а вот эта сорок пятая - лишняя. И они правы.

"Сложение оценок отдельных задач дает менее точную оценку, чем оценка совокупности" Гипоеза. Но почему то мне нравится.

Потому что когда вы сравниваете три задачи между собой и 1>2>3, то совсем не факт, что 1+2=3 :)

Но цифры имеют магическое влияние.

К счастью в норме на коротких спринтах разница не успевает оказать существенное влияние.

Ну и вариативность в обе стороны работает, так что 1+2 может быть и рано трём, и больше трёх и меньше трёх.

Да и вообще, даже если у команды есть, условно, 25 сп велосити, это совершенно не значит, что они смогут сделать хотя бы один элемент в 8 сп, или 5 элементов в 5 сп.

Так что сторипоинты, численные, это такое... для комфорта и отчетов :)

Ты все же за #noestimates? 😁

Да

Никогда не скрывал :)

Я за cycle time :)

Помню, была дискуссия)

Возможно, я неправильно делаю. Я просто привык серьезно относиться к экспериментальным данным. И результатам эксперимента я доверяю несколько больше, чем "здравому смыслу". Сказывается академическое образование советской школы. И вот экспериментальные данные 1985 года:

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

Это не я говорю, это до меня было.

В 85-ом я еще ПО не разрабатывал. Так что все вопросы к тем парням.

Потому что когда вы сравниваете три задачи между собой и 1>2>3, то совсем не факт, что 1+2=3 :)

Интереснее вот так: ————————- Брэдли Эфрон (Bradley Efron), специалист по статистике из Стэнфордского университета, предложил комплекты игральных костей, обладающих парадоксальными свойствами [Секей Г. Парадоксы в теории вероятностей и математической статистике. М.:Мир, 1990.]. (Психолог В. А. Петровский удачно назвал эти комплекты "бойцовским клубом игральных кубиков".) Все кубики любого такого набора одинаковы и "честны" в отношении своей геометрической формы, веса и т. д. Единственная разница между ними - в числах, нанесенных на их грани. Числа подобраны так, что на верхней грани первого кубика при бросках чаще выпадает большее число, чем на втором; на втором чаще выпадает большее число, чем на третьем, и т. д., но последний кубик чаще показывает большее число, чем первый (!). Благодаря этому первый систематически выигрывает у второго, второй - у третьего и т. д., но последний кубик - казалось бы, аутсайдер! - систематически выигрывает у первого - казалось бы, безусловного фаворита.

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

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

И даже как с этим бороться :)

а что за книга?

Внутренний буфер, синдром студента, вот это вот все.

Выпрямление сроков)

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

Ну, знаю. Даже знаю, что это следствие попытки компенсации общей причины вариации. Так же знаю значения этой самой вариации.

Выпрямление сроков)

Нет. Это "Попытка компенсации общей причины вариации."

Эксперимент "воронка и мишень".

а что за книга?

Это фото 48 страницы книги "Peapleware"/

Нет. Это "Попытка компенсации общей причины вариации."

Я про предыдущие сообщения Павла, до TOC

Ну, знаю. Даже знаю, что это следствие попытки компенсации общей причины вариации. Так же знаю значения этой самой вариации.

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

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

Но зачем?:)

Но зачем?:)

Как сказал один программист: "Потому что смогли!!!"

Ну я знаю одного человека, который тоже смог. Но зачем?:)

В каком контексте «правильно»?

Не занижать

Обычно это значения из шкалы фибоначчи, где наименьшее значение показывает наиболее простой элемент бэклога.

Он как то привязан к времени?

Есть команды, которые пытаются приравнивать сторипоинты к часам работы. Например, 1сп = 4 часа работы. Это ведь не очень корректно?

Это хороший вопрос

Он как то привязан к времени?

Зависит от вас, но обычно нет, и не стоит.

Т.е. никто не запрещает привязывать sp ко времени, но лучше этого не делать.

http://tim.com.ua/2010/10/how-to-estimate-in-story-points/

В целом при relative sizing размер=неопределенность, но это больше про интерпретацию оценок командой.

Что такое шкала фибоначчи применительно для дааного случая?

1,2,3,5.8,13.20.40

Не вполне настоящая фибоначчи после 13, но оценки выше 13 в принципе не нужны :)