Конкретно я вижу лишь ошибочность использования Lead Time как показателя качества оценки задач
А в чем вы видите смысл оценки задач? Для какой цели вы используете?
так как при таком подходе становятся бессмысленными понятия продуктивности/пропускной способности отдельного человека
Вот до момента "отдельного человека" я с вами соглашусь.
И отмечу, что продуктивность отдельного человека вам нужна только в случае если решили вы его уволить, и надо хоть что-то вам на него накопать.
В остальных случаях продуктивность отдельного человека не так важна с точки зрения общего end-to-end процесса команды, а так же отдельная продуктивность команды не так важна если она является сервисной и не в узком звене end-to-end процесса, как продуктивность всей системы в целом (что будет эквивалентно продуктивности узкого звена)
стори-поинты теряют свои аддитивные свойства, т.к. при наличии нескольких задач в ToDo и их последовательном выполнении Lead Time предпоследней = Reaction Time последней.
Story Points в общем-то и не обладают хорошими аддитивными свойствами, если
Они описывают свою зависимость от времени — время связано с распределениями логарифмического вида, тут нет нормальных распределений, чтобы сводить к аддитивности
Они имеют широкие распределения и в рамках своих границ вносят имеют большой разброс в шкале
Так что в итоге вы правы в том, что SP нельзя складывать!
И в общем в них особо смысла нет, если они не используются как названия категорий групп для анализа статистики.
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
И да, я все же настаиваю, что для спринтов не нужны SP. У спринтов есть цель. А цель это по сути и есть CWI, иначе говоря задача вокруг которой собирается вся команда и решает ее.
Если же у вас много разных задач которые вы набираете в спринт, и чтобы не перебрать используете для этого SP, то у вас точно не спринты, а итерации. И, конечно, больше шансов к дистабилизации чем в настоящем Scrum.
Возник вопрос по поводу расчета Lead Time и использование его как показателя качества оценки задач.
Предполагаю, что вы говорите о корреляции.
Разве при оценке задач мы учитываем промежуток времени с момента как задача перешла в ToDo до момента как она перешла в Developing?
Нет, Lead Time рассчитывается от момента принятия решения о том, что задачу берем в работу, до момента ее поставки клиенту или заказчику.
Если у вас настроен процесс так, что с момента попадания задачи в "To Do" и заказчик и команда разработки считают, что эта задача взята в работу — то именно тут и проходит линия Commitment (принятия обязательства). Не всегда это так настроено.
В Scrum обязательство на выполнение наступает с момента старта спринта, например.
В моем понимании, когда мы ставим оценку, мы сознательно отбрасываем этот промежуток и он определяется в основном важностью/приоритетом задачи, а не ее сложностью.
Честно сказать, я не понял сути этого изложения и не понимаю связи в этом предложении между важностью/приоритетом и сложностью. В статье про приоритеты ничего не было.
Если вы имели ввиду, что время от момента того как задача попадает в "To Do" до момента начала непосредственно работ "Developing"/"In Progress", у нас это время называется "Reaction Time". И "Reaction Time" входит в "Lead Time".
Кроме этого в "Lead Time" входит все время ожиданий в буферных состояниях от начала работ до завершения, например такие как "Ready to Review", "Ready to Test", "Ready to Deploy", как и Action состояния "Developing", "Review", "Testing", ...
Это, действительно все нужно учесть в Lead Time, потому что Lead Time — это именно время ожидания исполнения обязательства, которое на себя взяла команда по решению задачи.
С этим может быть связана еще и проблема "отложенного" ожидания. Когда заказчик задачи поставив ее, думает, о том, что команда уже над ней работает, а команда даже и не думала начинать. Такие ситуации приводят к конфликтам.
Пример Явного обязательства, который не приведет к таким проблемам
Пример явного обязательства, и заказчик и команда исполнителей понимают, что с изменением статуса на "To Do", фиксируется момент когда команда берет на себя гарантии реализации задачи (со всеми рисками)
И вот пример не явного обязательства, в этой ситуации конфликтов не избежать
Пример не явного обязательства, заказчик поставив задачу на команду думает о том, что команда уже работает над задачей, хотя команда фактически не подтвердила взятие обязательств на себя, и никак этот момент не был зафиксирован. Команда не гарантирует поставку.
Ведь, если мы работаем по спринтам, то это логичино, что таска на 1sp висит до последнего дня спринта, а потом выполняется за пару часов. При этом ее Lead Time = весь спринт. Тоже самое валидно и при работе без спринтов, если есть буферное время между ToDo и Developing.
Если вы работаете по спринтам, "Lead Time" может сильно отличатся от спринта. Допустим, во время спринта вы поняли что можете поставить быстрее функционал — это раз.
Допустим, вы не успели за спринт задачу и переносите ее на другой — это два
Только в случае если у вас всегда спринты завершаются поставкой инкримента и по завершению спринта вы отдаете результат клиенту или заказчику, то "Lead Time" будет равен спринту. Что довольно редкое явление к сожалению.
Интересно было бы посмотреть на Ваши графики после вычитания (ToDo - Developing)-периода из Lead Time.
Для команд у которых "Reaction Time" не большой разница будет не сильной. Актуально кстати, для коротких циклов планирования или для ситуаций с настроенным процессом без планирования.
А какой смысл смотреть на "Lead Time", который раскрывает проблему ожидания клиентом своей задачи считать без "Reaction Time"? Ведь именно от "Lead Time" он будет расчитывать все свои планы и договоренности с вами. И время без учета "Reaction Time" нужно только команде разработки, чтобы потешить себя. С точки зрения построения процесса в общем, это бессмысленно.
@anzв общем вы верно уловили конву. Только добавлю, что в статье говорится и о проблеме того, что в работу не всегда берутся задачи которые хорошо проработаны, а значит определенный риск переноситься на команду разработки — что собственно вы и подсветили во втором абзаце вашего сообщения.
И чем больше набранных рисков уходит на Downstream тем больше шансов того, что какие-то из них сработают.
Собственно и весь процесс Upstream нужно тюнить под то, чтобы как можно меньше рисков уходило в Downstream.
Я думаю подробнее расписать свой опыт настройки процесса в следующей статье, где хочется раскрыть более подробнее проблему с рисками и процессом Upstream
Отмечу что, когда мы говорим про Lead Time, хорошо все таки рассматривать в качестве исследуемых элементов работы элементы уровня "Customer Work Item". Если вы приводите метрики для задач которые являются результатом декомпозиции CWI, и измерение Lead Time по ним, действительно начинается от согласования с заказчиками на их реализацию, то ваша картина очень похожа больше на сервис поддержки, или выборку по багам. Там возможны такие показатели.
>Возможно не получается нормальное распределение из-за того, что люди склонны перестраховываться или давать другим людям запас времени на задачу.
Нормальное распределение не получается потому, что это время. Оно не умеет ходить назад. И если задаться анализом временных рядов, то работать будете всегда с логарифмическими распределениями в положительную сторону.
А вот распределение пропускной способности, вполне может подчиняться нормальному распределению.
Да, все верно, нам все равно нужно собрать информацию которая позволит ответить на вопрос.
Считаю, что изменение формы вопроса, позволяет начать сбор это информации проще. Как отметил в статье, при закрытом вопросе легче воспринимается и логика рассуждения и поиска дополнительной информации. Это полезно тогда когда еще очень мало информации, в самом начале.
Однако, если у вас уже есть наработанный аппарат по прогнозированию, например вы собрали модель своего процесса и используя Монте-Карло определяете сроки, то вам уже не так важно будет как поставлен вопрос о сроках.
Может быть Service Level Agreement — соглашение об уровне сервиса, где может быть указано и время необходимое для решения задач?
Соглашение вырабатываемое на основе исследований системы где выявляется возможности и определяются значение не свойственные этой системе, а дальше вырабатывается SLA — которое является опорой для возможных улучшений системы. Когда говорят о системе, говорят о сервисе построенного для решения каких-то задач.
А в чем вы видите смысл оценки задач? Для какой цели вы используете?
Вот до момента "отдельного человека" я с вами соглашусь.
И отмечу, что продуктивность отдельного человека вам нужна только в случае если решили вы его уволить, и надо хоть что-то вам на него накопать.
В остальных случаях продуктивность отдельного человека не так важна с точки зрения общего end-to-end процесса команды, а так же отдельная продуктивность команды не так важна если она является сервисной и не в узком звене end-to-end процесса, как продуктивность всей системы в целом (что будет эквивалентно продуктивности узкого звена)
Story Points в общем-то и не обладают хорошими аддитивными свойствами, если
Они описывают свою зависимость от времени — время связано с распределениями логарифмического вида, тут нет нормальных распределений, чтобы сводить к аддитивности
Они имеют широкие распределения и в рамках своих границ вносят имеют большой разброс в шкале
Так что в итоге вы правы в том, что SP нельзя складывать!
И в общем в них особо смысла нет, если они не используются как названия категорий групп для анализа статистики.
И да, я все же настаиваю, что для спринтов не нужны SP. У спринтов есть цель. А цель это по сути и есть CWI, иначе говоря задача вокруг которой собирается вся команда и решает ее.
Если же у вас много разных задач которые вы набираете в спринт, и чтобы не перебрать используете для этого SP, то у вас точно не спринты, а итерации. И, конечно, больше шансов к дистабилизации чем в настоящем Scrum.
Предполагаю, что вы говорите о корреляции.
Нет, Lead Time рассчитывается от момента принятия решения о том, что задачу берем в работу, до момента ее поставки клиенту или заказчику.
Если у вас настроен процесс так, что с момента попадания задачи в "To Do" и заказчик и команда разработки считают, что эта задача взята в работу — то именно тут и проходит линия Commitment (принятия обязательства). Не всегда это так настроено.
В Scrum обязательство на выполнение наступает с момента старта спринта, например.
Честно сказать, я не понял сути этого изложения и не понимаю связи в этом предложении между важностью/приоритетом и сложностью. В статье про приоритеты ничего не было.
Если вы имели ввиду, что время от момента того как задача попадает в "To Do" до момента начала непосредственно работ "Developing"/"In Progress", у нас это время называется "Reaction Time". И "Reaction Time" входит в "Lead Time".
Кроме этого в "Lead Time" входит все время ожиданий в буферных состояниях от начала работ до завершения, например такие как "Ready to Review", "Ready to Test", "Ready to Deploy", как и Action состояния "Developing", "Review", "Testing", ...
Это, действительно все нужно учесть в Lead Time, потому что Lead Time — это именно время ожидания исполнения обязательства, которое на себя взяла команда по решению задачи.
С этим может быть связана еще и проблема "отложенного" ожидания. Когда заказчик задачи поставив ее, думает, о том, что команда уже над ней работает, а команда даже и не думала начинать. Такие ситуации приводят к конфликтам.
Пример Явного обязательства, который не приведет к таким проблемам
И вот пример не явного обязательства, в этой ситуации конфликтов не избежать
Если вы работаете по спринтам, "Lead Time" может сильно отличатся от спринта. Допустим, во время спринта вы поняли что можете поставить быстрее функционал — это раз.
Допустим, вы не успели за спринт задачу и переносите ее на другой — это два
Только в случае если у вас всегда спринты завершаются поставкой инкримента и по завершению спринта вы отдаете результат клиенту или заказчику, то "Lead Time" будет равен спринту. Что довольно редкое явление к сожалению.
Для команд у которых "Reaction Time" не большой разница будет не сильной. Актуально кстати, для коротких циклов планирования или для ситуаций с настроенным процессом без планирования.
А какой смысл смотреть на "Lead Time", который раскрывает проблему ожидания клиентом своей задачи считать без "Reaction Time"? Ведь именно от "Lead Time" он будет расчитывать все свои планы и договоренности с вами. И время без учета "Reaction Time" нужно только команде разработки, чтобы потешить себя. С точки зрения построения процесса в общем, это бессмысленно.
@anzв общем вы верно уловили конву. Только добавлю, что в статье говорится и о проблеме того, что в работу не всегда берутся задачи которые хорошо проработаны, а значит определенный риск переноситься на команду разработки — что собственно вы и подсветили во втором абзаце вашего сообщения.
И чем больше набранных рисков уходит на Downstream тем больше шансов того, что какие-то из них сработают.
Собственно и весь процесс Upstream нужно тюнить под то, чтобы как можно меньше рисков уходило в Downstream.
Я думаю подробнее расписать свой опыт настройки процесса в следующей статье, где хочется раскрыть более подробнее проблему с рисками и процессом Upstream
@mad_nazgulесть уже курсы связанные с этим, правда не все публичные.
Спасибо за обратную связь.
Пример с разбором я планирую сделать в следующей статье, или в статье через одну.
Это отличный рецепт и практика, особенно там, где действительно нужны сроки, и возможны такие соглашения.
Как отметил
Отмечу что, когда мы говорим про Lead Time, хорошо все таки рассматривать в качестве исследуемых элементов работы элементы уровня "Customer Work Item". Если вы приводите метрики для задач которые являются результатом декомпозиции CWI, и измерение Lead Time по ним, действительно начинается от согласования с заказчиками на их реализацию, то ваша картина очень похожа больше на сервис поддержки, или выборку по багам. Там возможны такие показатели.
>Возможно не получается нормальное распределение из-за того, что люди склонны перестраховываться или давать другим людям запас времени на задачу.
Нормальное распределение не получается потому, что это время. Оно не умеет ходить назад. И если задаться анализом временных рядов, то работать будете всегда с логарифмическими распределениями в положительную сторону.
А вот распределение пропускной способности, вполне может подчиняться нормальному распределению.
Да, все верно, нам все равно нужно собрать информацию которая позволит ответить на вопрос.
Считаю, что изменение формы вопроса, позволяет начать сбор это информации проще. Как отметил в статье, при закрытом вопросе легче воспринимается и логика рассуждения и поиска дополнительной информации. Это полезно тогда когда еще очень мало информации, в самом начале.
Однако, если у вас уже есть наработанный аппарат по прогнозированию, например вы собрали модель своего процесса и используя Монте-Карло определяете сроки, то вам уже не так важно будет как поставлен вопрос о сроках.
Вам спасибо за обратную связь
>По крайней мере для задач, которые вы никогда раньше не делали, и не имеете четкого представления об их сложности.
Для задач о которых мы мало что знаем, вероятность будет низкая, действительно.
Однако если имеем ответ когда это надо, нам будет проще искать инфомрацию для ответа на этот вопрос.
Может быть Service Level Agreement — соглашение об уровне сервиса, где может быть указано и время необходимое для решения задач?
Соглашение вырабатываемое на основе исследований системы где выявляется возможности и определяются значение не свойственные этой системе, а дальше вырабатывается SLA — которое является опорой для возможных улучшений системы.
Когда говорят о системе, говорят о сервисе построенного для решения каких-то задач.