NP
что значит "задача"? вот как только станет понятно внутри команды - что подразумевает этот термин
Size: a a a
2020 February 13
NP
тогда и вопросы все сами отпадут
IS
Вот и вопрос эти оценки должны быть с учетом тестирования или нет
Ответ тут - вся работа в спринте должна быть учтена. Если вам удобно включать в задачу - включайте. Если нет, то делайте отдельную задачу на тестирование.
А если не учитывать, то сложно планировать.
А если не учитывать, то сложно планировать.
IZ
Nikita Poselyanov
или это значит исследовать + поменять + тесты + релиз + деплой + пост прод сапорт?
это значит внести изменения в код, замёржить + протестировать. остальное автоматизировано
NP
ну значит у Вас уже всё включено :)
NP
или вы о каком то другом тестировании?
IZ
Ответ тут - вся работа в спринте должна быть учтена. Если вам удобно включать в задачу - включайте. Если нет, то делайте отдельную задачу на тестирование.
А если не учитывать, то сложно планировать.
А если не учитывать, то сложно планировать.
мне важно понять практику у кого как на самом деле
NP
мне важно понять практику у кого как на самом деле
Практически, везде всё может быть разное, где то девелопер - это наборщик кода, где то чувак который знает Crystal Code \ Java Manifesto + XP + DevOps и всё остальное и тогда он вполне может вертеть задачей и мочь её оценить под разными углами.
IS
мне важно понять практику у кого как на самом деле
мы включаем :)
IZ
Nikita Poselyanov
ну значит у Вас уже всё включено :)
Никита, давай ещё разок:
1. вариант. Оцениваем только затраты разработчика на внесение изменений в код (допустим будет 1 sp)
2. вариант. Оцениваем затраты разработчика на внесение изменений в код + труд тестировщика (здесь допустим 2sp)
мне сейчас не очень ценно слышать «как должно быть». Мне ценно понять как у вас на практике и почему
1. вариант. Оцениваем только затраты разработчика на внесение изменений в код (допустим будет 1 sp)
2. вариант. Оцениваем затраты разработчика на внесение изменений в код + труд тестировщика (здесь допустим 2sp)
мне сейчас не очень ценно слышать «как должно быть». Мне ценно понять как у вас на практике и почему
IZ
мы включаем :)
вот за этот ответ спасибо)
NP
Никита, давай ещё разок:
1. вариант. Оцениваем только затраты разработчика на внесение изменений в код (допустим будет 1 sp)
2. вариант. Оцениваем затраты разработчика на внесение изменений в код + труд тестировщика (здесь допустим 2sp)
мне сейчас не очень ценно слышать «как должно быть». Мне ценно понять как у вас на практике и почему
1. вариант. Оцениваем только затраты разработчика на внесение изменений в код (допустим будет 1 sp)
2. вариант. Оцениваем затраты разработчика на внесение изменений в код + труд тестировщика (здесь допустим 2sp)
мне сейчас не очень ценно слышать «как должно быть». Мне ценно понять как у вас на практике и почему
Раз уж мы на ты, то я тебе ответа на вопрос делаем или нет не дам, по простой причине - у команд с которыми я работаю ОЧЕНЬ контекстно и ты об этом контексте понятия не имеешь. Ввиду того, что я стараюсь не давать советов которые могли бы "ломать процесс", я даю рекомендации осмыслить.
NP
Я надеюсь понятно описал, что ценно для меня
DN
Никита, давай ещё разок:
1. вариант. Оцениваем только затраты разработчика на внесение изменений в код (допустим будет 1 sp)
2. вариант. Оцениваем затраты разработчика на внесение изменений в код + труд тестировщика (здесь допустим 2sp)
мне сейчас не очень ценно слышать «как должно быть». Мне ценно понять как у вас на практике и почему
1. вариант. Оцениваем только затраты разработчика на внесение изменений в код (допустим будет 1 sp)
2. вариант. Оцениваем затраты разработчика на внесение изменений в код + труд тестировщика (здесь допустим 2sp)
мне сейчас не очень ценно слышать «как должно быть». Мне ценно понять как у вас на практике и почему
На сколько я помню, в идеале включать все!
Формирование требований+дизайн+разработка+тестирование+зазор на баги+регрессия+деплой на маркет
Формирование требований+дизайн+разработка+тестирование+зазор на баги+регрессия+деплой на маркет
IZ
Nikita Poselyanov
Раз уж мы на ты, то я тебе ответа на вопрос делаем или нет не дам, по простой причине - у команд с которыми я работаю ОЧЕНЬ контекстно и ты об этом контексте понятия не имеешь. Ввиду того, что я стараюсь не давать советов которые могли бы "ломать процесс", я даю рекомендации осмыслить.
ок спасибо
IZ
На сколько я помню, в идеале включать все!
Формирование требований+дизайн+разработка+тестирование+зазор на баги+регрессия+деплой на маркет
Формирование требований+дизайн+разработка+тестирование+зазор на баги+регрессия+деплой на маркет
вы так делаете?
DN
вы так делаете?
Да, но кроме требований+дизайн
IZ
спасибо. понял) Похоже всё-таки тестирование лучше учитывать чем нет)
DN
Они у нас в отдельном спринте, так как нам надо проходить ревью у заказчика
IZ
не очень понял, но видимо это ваша специфика. В целом спасибо всем за обратную связь 👍