Можно делать как - задачи на SP, а на второй части планирования технические таски в часах. Очень удобно.

ну я к тому что бесполезная штука

только путает и дает ровно ничего

ну то есть инвестор спрашивает через сколько будет говорим 2 стори поинта если разраб не с похмела

Денис, повторюсь, если инвестор спрашивает "когда" - говорите через сколько спринтов.

sp - не мера времени.

ну то есть инвестор спрашивает через сколько будет говорим 2 стори поинта если разраб не с похмела

Да не спланируете вы. Могут и требования поменяться и зависимости вылезти ... может разраб заболеть.

ну то есть инвестор спрашивает через сколько будет говорим 2 стори поинта если разраб не с похмела

использование SP в отрыве от итеративного подхода бессмысленно. Вы не сможете SP конвертировать в часы. Вернее сможете, но это будет неверная информация. Поэтому, как и говорят выше коллеги, апеллировать надо к итерациям, а не "часам/дням/етс"

@AUGmoscow

в смысле спросить у них?)

в смысле спросить у них?)

угу

ну как же не могу у меня если я знаю количество рабочих часов в спринте и количество законченных поинтов за прошедший спринт

а что ни у кого таких проблем нету? все пряи работают над внутреними проектами и могут одновременно и рисовать и кодить?)

а что ни у кого таких проблем нету? все пряи работают над внутреними проектами и могут одновременно и рисовать и кодить?)

просто вопрос про джиру же

просто вопрос про джиру же

скорее как в условиях джиры ведется и планируется проект

Мне скучно про жиру читать, я лучше полу-троллинг от Дениса почитаю :)

ну как же не могу у меня если я знаю количество рабочих часов в спринте и количество законченных поинтов за прошедший спринт

Так у вас над Юзер стори работают в идеале несколько человек, а не один. Плюс velocity не будет статичен. Как вы потом объясните почему у вас в этом спринте команда работала 60 часов, а не 80, например?)

Ну как жеж забудишь такие эпичные грабли, на которые буквально каждая первая команда наступает :)

Погодой, пробками, чемпионатом и "Вася в отпуск ушел".

Так у вас над Юзер стори работают в идеале несколько человек, а не один. Плюс velocity не будет статичен. Как вы потом объясните почему у вас в этом спринте команда работала 60 часов, а не 80, например?)

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

В таком случае могу только пожелать удачи с этим!) Я такое никогда не пробовал. Будет здорово если поделитесь опытом с остальными в этом чатике по прошествии какого-то времени.

В таком случае могу только пожелать удачи с этим!) Я такое никогда не пробовал. Будет здорово если поделитесь опытом с остальными в этом чатике по прошествии какого-то времени.

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

Что-то без огонька сегодня. Наверняка "опытные процессники" смогут дать точную дату релиза и выполнить обещание, но на практике я такого не встречал никогда. Чаще бывает так что под давлением большого и страшного босса дают нереалистичную дату, а затем заставляют впахивать всех остальных да и себя тоже ) Вот такое я видел много раз. Возникает даже такое подозрение что деражть своих сотруников виноватыми это такой стиль управления.

Что-то без огонька сегодня. Наверняка "опытные процессники" смогут дать точную дату релиза и выполнить обещание, но на практике я такого не встречал никогда. Чаще бывает так что под давлением большого и страшного босса дают нереалистичную дату, а затем заставляют впахивать всех остальных да и себя тоже ) Вот такое я видел много раз. Возникает даже такое подозрение что деражть своих сотруников виноватыми это такой стиль управления.

нельзя дать реалистичную дату?

Кому?

ну тому кто спрашивает

Можно

нельзя дать реалистичную дату?

чем выше уровень неопределенности, тем ниже вероятность точной даты. Даже на конвейере, где люди повторяют из раза в раз одну и ту же механическую работу, могут случиться неполадки, больничные, ЧП. Что уж говорить про интеллектуальный труд с высокой степенью неопределенности.

ну так вот тут говорят что в стори поинтах только

Я бы сказал что скорее можно дать реалистичный диапазон

но не конкретную дату

ну так вот тут говорят что в стори поинтах только

Кто?

ну ты же и говорил

и вот опять

когда я такое говорил?) Я сразу сказал что это только один из возможных способов относительной оценки)

ну так вот тут говорят что в стори поинтах только

Дату в стори поинтах вряд ли получится дать )

есть еще T-shirts size, попугаи, etc

но обычно спрашивают: "Когда будет готово вот это"

никто же в тишотах не просит

но обычно спрашивают: "Когда будет готово вот это"

А ты в ответ - месяц плюс минус год!

тебе на следующей зп ничего не дали ты спрашиваешь когда и тебе ну там месяц плюс минус год

как-то так

Ответ который обычно даю я такой: "Команда может дать вам сейчас цифру с потолка, или же вы можете дать ей поработать несколько спринтов и тогда они смогут вернуться к вам с реалистичным диапазоном"

опять же, оч странный инвестор если его интересует дата выпуска конкретной юзер стори (юзер стори != фича "от и до"), а не фичи или куска проекта

то есть типо через месяц только сможем примерно оценить ?

если позиция этой задачи в бэклоге не будет меняться (что очень вряд ли), то да - можно будет спрогнозировать диапазон когда это случится с точностью до 1-2 спринтов

тебе на следующей зп ничего не дали ты спрашиваешь когда и тебе ну там месяц плюс минус год

Да загвоздка. Или обмануть и быть виноватым или без зп остаться. Такая страшная штука - работа в старомодных компаниях )

но обычно спрашивают: "Когда будет готово вот это"

А кто спрашивает?

но обычно спрашивают: "Когда будет готово вот это"

Рекомендую: https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351

Да отличная книга)

Тоже рекомендую

А кто спрашивает?

На это утверждение можно ответить у меня обычно не спрашивают)

#whois Всем привет! ⚜Наш проект называется КСУТО (комплексная система управления техобслуживанием), облачный сервис автоматизации управления техобслуживанием зданий, сооружений и оборудования. ⚜Я Инженер эксплуатации зданий и сооружений. ⚜Могу быть полезен с выходом на Великобританию, Вьетнам и Дальний Восток России. ⚜Сейчас проект нуждается в структуризации планирования, этим и интересно это сообщество - узнать побольше про agile и минимизировать процесс до критично важных шагов. ⚜Я с Сахалина, соучредитель проекта с Питера, а сейчас оба находимся в Москве. ⚜Группу нашел через поиск в телеге.

если позиция этой задачи в бэклоге не будет меняться (что очень вряд ли), то да - можно будет спрогнозировать диапазон когда это случится с точностью до 1-2 спринтов

я наверное не правильно выразился это не задача и не фича обычно спрашивают ну когда будет уже готова новая система оплаты (там например реинтегрировать со старой платежной системы на новую на сторой договор заканчивается и продлять не хотят)?

Ну если у вас эта задача лежит в бэклоге, допустим, 8 по счету и "весит" 5 SP. Перед ней семь сторей суммарный "весом" 40 поинтов. Вы знаете что velocity Вашей команды 22 стори поинта, т.к. в последних трех спринтах команда "закрыла" 18, 28 и 20. Значит можно говорить что скорее всего вы выполните эту задачу либо в спринте n+2, либо в спринте n+3 , если ее положение в бэклоге не изменится - отсюда даете и "вилку" инвестору. Важно понимать что это именно forecast, не commitment. Прогноз погоды тоже не всегда бывает точным.

Ну да.

А можно усложнить модель, добавить туда еще тренд роста бэклога после каждого спринта и вариативность эстимейтов

Коллеги, кто работает рвботает по scrum в jira. Есть вопрос. Есть user story с подзадачами внутри (дизайн, бэкендс, айос, андроид). Разные подзадачи делаются в разных спринтах. Мы в начале отрисовываем, а потом отдаем us с дизайном разрабам. Но непонятно как в jira отдельно завести подзадачу в спринт, приходится us полностью вставлять в спринт, но делается только одна подзадача. Можно ли как то решить эту проблему?)

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

Посоветуй плз пару-тройку ссылок почитать / посмотреть про agile? Очень много хлама в сети валяется..

Посоветуй плз пару-тройку ссылок почитать / посмотреть про agile? Очень много хлама в сети валяется..

Майк Кон

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

Можно считать создание дизайна частью подготовки истории к работе т.е. артефактом груминга (или как он сейчас называется?). Тогда задачу можно совсем не создавать :)

Можно считать создание дизайна частью подготовки истории к работе т.е. артефактом груминга (или как он сейчас называется?). Тогда задачу можно совсем не создавать :)

на аутсорсе так нельзя. всетаки время тратиться и тд и тп… отчетность…

Тогда просто внести отдельный таскать в спринт ) а потом на ретроспективе решите норм лм

Посоветуй плз пару-тройку ссылок почитать / посмотреть про agile? Очень много хлама в сети валяется..

Очень понравилась книга https://www.ozon.ru/context/detail/id/6961504/

Но без Массоннелла все равно не обойтись. Я его рассматриваю как справочник. Книга есть на русском. Одна из самых крутых по управлению проектами.

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

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

А как попытаться сделать проект к сроку неплохо написал Голдратт в "Критической цепи".

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

+1. Но time2market сильно растет. Увы. Я видел и модель, когда тестирование выносили за рамки спринта. Но заказчик ругался на сроки поставки... Время то почти удваивалось.

А если у нас просто проект (замена старой системы и в прод выходим когда можно старую отключить), то самая большая засада - пропущенные требования. И тут никакой SCRUM не поможет. Нужен спец прекрасно владеющий техникой верификации требований на полноту. А таких на рынке ОЧЕНЬ мало. Очень-очень.

А если у нас просто проект (замена старой системы и в прод выходим когда можно старую отключить), то самая большая засада - пропущенные требования. И тут никакой SCRUM не поможет. Нужен спец прекрасно владеющий техникой верификации требований на полноту. А таких на рынке ОЧЕНЬ мало. Очень-очень.

value-stream mapping, use cases, BPML...

value-stream mapping, use cases, BPML...

Все так. И еще куча нотаций. Но. Как их писать учат очень многие. А вот как верифиировать на полноту... Мне известны всего пара источников. При том, что прочел я очень до фига.

Все так. И еще куча нотаций. Но. Как их писать учат очень многие. А вот как верифиировать на полноту... Мне известны всего пара источников. При том, что прочел я очень до фига.

А в чем причина необходимости верификации на полноту?

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

а кто ответственый когда us в статусе OPEN?

А в чем причина необходимости верификации на полноту?

Их несколько. 1) пропустили требовиния (я видел ТЗ c пропуском 85%) - неверно сделали расчет сроков. Получили Денверский аэропорт.

Их несколько. 1) пропустили требовиния (я видел ТЗ c пропуском 85%) - неверно сделали расчет сроков. Получили Денверский аэропорт.

Ключевой вопрос - зачем делать проекты с попыткой вычислить скорки настолько заранее,

2) есть вариант хуже. Сильно хуже. Иногда из пропуска небольшого процента требований допускают архитектурные ошибки. И усе. Допилить нельзя. Слышал такой случай, что из-за пропуска всего одного требования выкинули уже написанную систему.

+ попытка выяснить ВСЕ требования на 100% до старта проекта гарантирует, что что-то будет пропущено, а что-то понять неверно

2) есть вариант хуже. Сильно хуже. Иногда из пропуска небольшого процента требований допускают архитектурные ошибки. И усе. Допилить нельзя. Слышал такой случай, что из-за пропуска всего одного требования выкинули уже написанную систему.

TDD\ATDD, microservices, cloud-ready architecture, set-based design...

Бонусом, например, идет strangler pattern, который позволяет поверх окаменевших отложений legasy добавлять новые модные и гибкие фичи быстро и без дорогой ошибки.

Ключевой вопрос - зачем делать проекты с попыткой вычислить скорки настолько заранее,

Если софт лишь малая часть проекта. Например: "Национальный центр управления в кризисных ситуациях МЧС России" Без софта эту штуку було несколько сложно сдать. А весь проект более 3 миллирдов долларов.

Вторым бонусом идет скорость поставки.