то есть если задача (как выяснилось) офигенно длинная и не деливирится

Если остались незавершенные задачи, значит спринт провален. Оценки были не верны. Нужно посчитать эффективность. К тому же, у нас на сторипойнты завязан бюджет.

вот зе фак

стопэ

все не так =)

Спринт провален!!!111

Ну наконец-то надо орать!

мы сломали систему и идти в бар

> Если остались незавершенные задачи, значит спринт провален. Спринт провален, если не достигли цели спринта

Ну я утрирую) Сори

Ну наконец-то надо орать!

орать надо с мемесов

Да тема все-таки скрама это цель

> Нужно посчитать эффективность. Эффективность чего? кого?

Есть набор метрик, которые заложены в процессы компании.

> Оценки были не верны. или нет

Есть набор метрик, которые заложены в процессы компании.

ммм, какие метрики?

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

Щас там индивидуальные KPI еще всплывут

и если срок срывается, то деньги не поступают - всех бьют палкой по голове

так?

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

тогда зачем вам скрам?

Это не цель, это мазахим

я вот пытаюсь выяснить, конечную цель у человека, который помощь просит, что бы постараться помочь :)

Это не цель, это мазахим

ну не ругайся, может им так нравится)

Хорошо, проситите. это приченение себе боли

http://blog.agilistic.nl/the-rise-of-zombie-scrum/

Нет, проблем с деньгами и оплатами тут нет. Вопрос в плоскости "как правильней с точки зрения Scrum" Пример метрик. Качество выпускаемых релизов. Банально, кол-во багов. Кто, когда и где нешел, на какой стадии, с какой стороны поступил репорт и.т.д. И вот переносы из спринта в спринт размазывают картинку.

Баги не определяют качество

http://blog.agilistic.nl/the-rise-of-zombie-scrum/

годно

Эта парадигму давно сломали, например в машинопроизводстве

Эта парадигму давно сломали, например в машинопроизводстве

Ты про lean всякий?

Да не про lean, мы все почему-то думаем. что если меньше багов, то качественнее софт - НЕТ

это иллюзия

возьмите мак бук

и последите за неделю активного использование сколько раз он сглючил

сколько раз завис ваш браузер

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

Я не говорил, что баги определяют кач-во. Это один из факторов определяющих его.

единственный фактор там - это "компьютер не включился, "машина не завелась"

остальное все это пользовательских персепшн

ий*

вот пример вам простой - кто-нибудь меряет как часто пользователь жмет F5 на вашем сайте7

открываются удивительные новые данные, как только ткнуть пальцем вот в такие вещи

зато все упорно считают метрики bug / feature throughput ;)

В веб-приложении меряли. Там фулскрин у юзеров. Если обновляют, значит что-то пошло не так и от этого момента разбираются логи.

👍

Вопрос в плоскости "как правильней с точки зрения Scrum" Тут Дима вроде выше писал про DoD, с точки зрения Scrum - как команда решила

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

Чтобы понимать, куда мы движемся.

эммм?

у вас продукт? или заказная разработка?

> Вопрос в плоскости "как правильней с точки зрения Scrum" с т.зр. скрама правильнее как я написал то есть закрываем спринт отправляем недоделанное в бэклог на следющим планинге решаем, что делать при этом: скрам не говорит, как оценивать и тд поэтому тут есть варианты: - Оценку в SP не менять, переоценивать только сабтаски в часах (если такое вообще у вас применяется) - Оценку в SP не менять, ничего не менять, просто при планировании помнить о том, что работы меньше (Это тоже абсолютно норм, велосити нужна для долгосрочного планирования, а отдельно каждый спринт – на совести команды и на ее ощущениях) - Оценку в SP менять, стори поинты сгорят, велосити чуток уменьшиться, но тоже будет давать достаточно честный результат

Кстати а что говорит скрам про смену домена, вон там как раз выше вопрос - аля поменялся заказчик

Кстати а что говорит скрам про смену домена, вон там как раз выше вопрос - аля поменялся заказчик

я что-то пропустил видимо поясни

1 sp != 1 sp

оно и так верно для любого спринта, но если заказчик например изменился, то со сл. спринат надо сбросить среднюю velocity ?

ээ

SP заказчик задает, что ли?)

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

SP это относительная единица измерения, которую вырабатывает команда

и значит 1SP ~= 1SP

а иначе в чем их суть

Ну ~= ;)

@dmitriyabr спасибо) мы пришли к тому, что если что-то не успелось, то проводим декомпозицию задачи и создаем сабтаск на незавершенку в новый спринт.

Ну ~= ;)

ну ~= значит на долгосрочной перспективе =

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

и с новым такая оценка может не прокатить

правильно понял вопрос?

;)

Ну конечно, velocity это гвоздями прибитая метрика к тому продукту, который разрабатывался

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

Математика говорит об обратном

Там forecast каждый раз корректируется

мне вот это почему то старую преедачу по зомбоящику напомнило. "угадай мелодию называется" - определим велосити и сторипоинты с 3х нот :)

так он и корректируется

только за счет этого velocity "выезжает", а с точки зрения нахождения команды на 3-м спринте, предсказать сколько сделаем на 23 - безнадежно проигрывает методу статистическего прогноза

тот-то в разы точнее, и то тоже корректируется

только за счет этого velocity "выезжает", а с точки зрения нахождения команды на 3-м спринте, предсказать сколько сделаем на 23 - безнадежно проигрывает методу статистическего прогноза

ладно я переборщил с долгой перспективой, да

Ну да, просто вот это вот "а давайте проект посчитаем"