Это не значит, что все красные тесты не ошибки. Есть красные тесты которые ошибки.
Но вообще имеет смысл мерять количество багов, которые ушло в прод. Если тесты пропускают в прод не меньше ошибок чем люди тестеры и люди тестеры меньше стоят, то люди выигрывают.
Единственное, тут вопрос в качестве тестов и в легкости их разработки — это может серьезно повлиять на результат.
Можно попробовать поставить задачу по другому — есть ли какие-то варианты, когда тесты будут выгодны?
Например для начала писать тесты только для того, что легко тестировать.
Есть ли какие-то области кода, которые приност наибольшее количество багов или типы багов, которые чаще возникают? Тогда их можно покрыть небольшим количеством тестов. Пусть это будут интеграционные тесты, но если их запускать все время, они найдут ошибки такого типа раньше.
У вас есть анализ причин этого? Юниты по идее должны следовать ментальной модели предметного специалиста. Человеку неудобно оперировать большими кусками информации и он делит ее на более мелкие. Если это не так, то либо предметная область либо технология не позволяет. Что именно в случае геймдева?
Я вот тесты рассматриваю прежде всего как документацию, на соответствие которой систему можно автоматически проверить. Но объективно число выявленных на этапах прогона тестов ошибок минимально (красные тесты при TDD и ко — не ошибки по факту).
Она должна объяснять все проведенные эксперименты и наблюдения с мозгом (типа тыкаешь электродом в определенное место и человеку или крысе становится хорошо, стукаешь по другому и человек теряет определенный вид памяти). Также она должна предсказывать эксперименты, которые противоречат теории о том, что мозг принимает решения сам.
Тут нет никакого вопроса к вам только упоминание. Это вопрос к funca — рассказать где он видел «маркетинг скрам» и привести по возможности цитату, подтверждающую его тезис
Demetrikl подумал, что идет речь про ваш собственный маркетинг.
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
Речь была не о том, что куда конкретно пишут. А том, что при специализации задачи/элементы backlog получаются персонализированными.
Зависит. Вы используете конкретный термин "элемент беклог", если он не означает отделное действие по фиче, а всю фичу в целом, то он не персонализированный.
Например, если вы в список дел записываете "Заказать новый холодильник", то он не специализирован для ваших органов. А если вы записываете "Глазам — посмотреть налево, пальцам — набрать на клавиатуре "холодильник с большой морозилкой"" то каждый пункт специализирован.
Тут надо еще понять, какие навыки у другой команды. Вася и Петя могут получить ошибку из рук Валеры, который сначала ее воспроизведет, а потом проверит фикс.
Если Валера занят, Вася может проверить фикс Пети или написать скрипт, который поможет Маше.
У Пети может быть альтернативный подход — он скажет, что он не тестер а программер, поэтому тестировать за Васей не будет. А если не хватает тестеров, то пусть нанимают, а он лучше почитает про новый фреймфорк.
Это получается испорченный телефон: пользователи жалуются на баги в обработке формы. Мы ставим цель «улучшить интерфейс», а в результате перекрашиваем в более контрастный и увеличиваем кнопки, чтобы на мобильнике было удобнее пользоваться.
Это значит что либо цель спринта неправильная либо задача.
Еще возможно, если исполнители ссами не могут понять эту рассогласованность, то скрам — не для них.
Аналогия с пиджаком очень далёкая и непонятная — где там цель и инкремент спринта? (и где вы слышали, чтобы пуговицы производились прямо в ателье одежды?)
Эта краткая формулировка — «цель спринта» не должна подменять собой конкретные запланированные задачи/пользовательские истории
А мне кажется должна. Команда должна вместе достигнуть цель спринта и думать о задачах именно в этом контексте. Т.е. специалист по пуговицам должен думать о пиждаке в целом и делать такие пуговицы, которые хорошо будут смотреться на пиджаке а не лучшие пуговицы взятые отдельно.
Команда также может согласовать какие-то изменения прямо в контексте спринта. То есть думать не только о своей задачи а о том имеет ли она смысл для команды.
During the Sprint:
No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and,
Scope may be clarified and re-negotiated between the Product Owner and
Если задача запланирована на Sprint, значит она ведёт к Sprint Goal. «Правильные вопросы»: «Что ты сделал для достижения цели спринта? Что планируешь делать для достижения цели спринта?» — не имеют смысла.
В SCRUM guide не написано что задачи должны быть в backlog — см также мое сообщение задачи могут выделяться формально (например статус или задача внутри айтема) или неформально но это не значит, что задачи сами по себе обязаны являться элементом PBI. Напрмер в процессе с выделеными тестерами "Тестирование" может являться просто статусом PBI так что у тестеров нет отдельного беклога.
Это не значит, что все красные тесты не ошибки. Есть красные тесты которые ошибки.
Но вообще имеет смысл мерять количество багов, которые ушло в прод. Если тесты пропускают в прод не меньше ошибок чем люди тестеры и люди тестеры меньше стоят, то люди выигрывают.
Единственное, тут вопрос в качестве тестов и в легкости их разработки — это может серьезно повлиять на результат.
Например для начала писать тесты только для того, что легко тестировать.
Есть ли какие-то области кода, которые приност наибольшее количество багов или типы багов, которые чаще возникают? Тогда их можно покрыть небольшим количеством тестов. Пусть это будут интеграционные тесты, но если их запускать все время, они найдут ошибки такого типа раньше.
Что значит не ошибки — а что?
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
Вообще высяснение состава и очередности задач это по-моему весьма важно и тут легко ошибиться.
"XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work."
Вообще чаем из чашки при помощи компьютера я предлагаю поить тех, у кого руки не действуют, например. Какого-нибудь Стивена Хоккинга, мир его праху.
Можно пруф, как мне кажется, к большинству ртов присобачена какая-нибудь головогрудь или кольчатое тело :)
Зависит. Вы используете конкретный термин "элемент беклог", если он не означает отделное действие по фиче, а всю фичу в целом, то он не персонализированный.
Например, если вы в список дел записываете "Заказать новый холодильник", то он не специализирован для ваших органов. А если вы записываете "Глазам — посмотреть налево, пальцам — набрать на клавиатуре "холодильник с большой морозилкой"" то каждый пункт специализирован.
У других членов команды. Если только Вася знает Питон, это не значит, что Вася знает только Питон.
Если Валера занят, Вася может проверить фикс Пети или написать скрипт, который поможет Маше.
У Пети может быть альтернативный подход — он скажет, что он не тестер а программер, поэтому тестировать за Васей не будет. А если не хватает тестеров, то пусть нанимают, а он лучше почитает про новый фреймфорк.
Это значит что либо цель спринта неправильная либо задача.
Еще возможно, если исполнители ссами не могут понять эту рассогласованность, то скрам — не для них.
Разумеется все аналогии врут.
А мне кажется должна. Команда должна вместе достигнуть цель спринта и думать о задачах именно в этом контексте. Т.е. специалист по пуговицам должен думать о пиждаке в целом и делать такие пуговицы, которые хорошо будут смотреться на пиджаке а не лучшие пуговицы взятые отдельно.
Команда также может согласовать какие-то изменения прямо в контексте спринта. То есть думать не только о своей задачи а о том имеет ли она смысл для команды.
Почему?
В SCRUM guide не написано что задачи должны быть в backlog — см также мое сообщение задачи могут выделяться формально (например статус или задача внутри айтема) или неформально но это не значит, что задачи сами по себе обязаны являться элементом PBI. Напрмер в процессе с выделеными тестерами "Тестирование" может являться просто статусом PBI так что у тестеров нет отдельного беклога.