С

Да. Точно не сами

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

У нас ограничено 13

Я вообще интересное заметил про оценку в SP и velocity. Если команда умеет пользоваться сторипоинтами, то у нее велосити всегда будет в пределах 20-24, внезависимости от длинны спринта :)

Но у нас 21 уже не влезет. Хотя по сумме больше делают :)

И размера команда.

Надо посмотреть у себя.

А count будет в диапазоне 5-8 :)

Количество задач?

Да

Количество PBI

Сегодня прошлый Спринт считал, но не помню. Посмотрю.

Сергей, это не метрика эффектиности, есличе. Это наблюдение.

Я знаю. Меня попросили считать, но это бессмысленно без разделения на группы с разными стори поинтами. Да и с ними не играет имхо

Сергей, у меня это наблюдение стабильно для разных клиентов, разных команд и разных контекстов за 4 года

За большее время не могу померять, я не сохранил данные :)

Интересное наблюдение.

Ну и коучи, с которыми я работал, подтверждают, что у них где-то так же.

Навскидку похоже.

The Development Team must be no smaller than 3 and no larger than 9 members A. True B. False

Еще один вопрос с подвохом

почему must?:)

Тут и подвох :)

Ответ В

What happens in Daily Scrum? A. Development team plans work for next 24 hours B. Inspect work since last daily scrum C. Forecast upcoming sprint work

А или В?

B

А, нет, A

At it, the Development Team plans work for the next 24 hours.

Говорит нам Скрам Гайд

Вот и я к А. А как быть если завтра суббота? Вот если было не 24 h a next work day ...

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

Неувязочка :)

Я в этой части обращал внимание на inspecting the work, но если читать вопросы и ответы строго в рамках теста, то А :)

Q. Which of the following are correct: A. Technical debt must be added to the product backlog B. Technical debt may or may not be added to the product backlog C. Technical debt should never be added to the product backlog D. Separate PBIs should be created for technical debt E. Technical debt can be added as a task in relevant PBI F. Technical debt should always be added as a task in relevant PBI

Только B :)

Why not may?

must понял

Потому что разрешение технического долга может быть не только PBI :)

After several Sprints into a project, increment got release in the production and key stakeholders complains on performance issues. Even the PO agrees, he comes to Scrum Master. What should the scrum master do(choose one) A. Tell PO that dev team own DoD and it is their duty to decide acceptable performance standard B. Encourage the PO to bring this up to the team so that team can come up with improved DoD, with strong SLA requirements for performance issues C. Wait till retrospective , as this is the appropriate time for dev team to re-consider the DoD

Похож на недавний

Это он

Про прошлый, сразу говорю, я не уверен, что B - действительно единственно правильный.

В, я тоже так думаю.

Q. The Development Team does not have any testing specialists in the team. They should… A. Request for a specialist tester to join the team and queue testing for them to do when they arrive in a later Sprint B. Produce an Increment that will be tested by a dedicated test team after the Sprint to guarantee the quality C. Raise this as an impediment which may require the assistance of the Scrum Master to resolve D. Quality is the responsibility of the Development team and they should undertake testing themselves to the best of their abilities

D

Тут без вариантов :)

У меня уже третий спринт с командой "обсуждение вариантов" на эту тему :)

https://www.scaledagileframework.com/blog/assess-your-devops-health-with-the-safe-devops-radar/

Это так, поделиться инструментом

У нас слава бгу норм с этим. И компетенции тестировщиков есть и все тестируют при необходимости ручных тестов и сами тесты пишут.

У меня и так каша, положил на будущее

Ребят, давайте сливать вопросы ПСМ в личку

Ок. Не буду больше.

Ребят, давайте сливать вопросы ПСМ в личку

Гм. Когда только начиналось, все хотели публично. ОК

Гм. Когда только начиналось, все хотели публично. ОК

Тут получается, что мы вдвоем тольо смотрим :)

Вы превратили чат в 1-1 разбор вопросов, которые вообще-то запрещено в паблик сливать

Дык они в открытом доступе http://mlapshin.com/index.php/blog/scrum-questions/comment-page-4/#comments

Они из жизни все. Очень полезны

Но не бүду, договорились.

Вы превратили чат в 1-1 разбор вопросов, которые вообще-то запрещено в паблик сливать

Вопросы, я так понимаю, из паблика. И раньше в обсуждении участвовало больше людей. Но ок, не будем обсуждать вопросы.

Дмитрий - а что тогда можно?

Ну чтобы не нарушать?

Кстати, правила ... где нибудь описаны? Может их пришпилить сверху?

Столкнулся с веселой просьбой от бизнеса - описать каркас процесса для Tech Support. Кто-нибудь это уже делал? Можете посоветовать, на что внимание обратить?:)

Теч саппорт это что под этим поимается?

Это просто фантастика: в офис приехала команда поваров от одного из вендоров, готовит презентацию своей еды. Команда говорит по-польски, я их понимаю, но они не в курсе. На большом телевизоре висит JIRA Dashboard с результатами активного спринта (борда, берндаун, радиатор). Один из людей в комане спрашивает других сокомандников "что это у них за фигня на телевизоре". Другой объясняет "А, это scrum, и судя по отчету этот спринт они нормально не завершат" :)

Scrum реально вышел за пределы айти. И надо будет обсудить со знатоком, не думает ли он о смене работы :)

Прикольно :)

Теч саппорт это что под этим поимается?

Это реагировать на жалобы пользователей, объяснять им, как пользоваться продуктом, при необходимости верифицировать, воспроизводить и репортить баги

Продукт внутренний, т.е. пользователи - сотрудники компании.

У нас есть такой, но практически не связан с разработкой. Баги только пушат и все ... и это печально.

У нас внешний

Строй канбан систему

Для фикса багов у нас есть роль on-duty developer, который на спринт уходит из команды и работает с поддержкой

Строй канбан систему

Угу, там и так канбан-система. Очередь, приоритеты, WIP, вот это все.

Мне ее теперь описать в формальных терминах надо, что не так уж просто без образца + я не уверен, что все учел.

А что нужно тогда?

Scrum реально вышел за пределы айти. И надо будет обсудить со знатоком, не думает ли он о смене работы :)

https://youtu.be/ir5rj2yYH_8

В тему видео, если не видели. Две минуты.

Мне ее теперь описать в формальных терминах надо, что не так уж просто без образца + я не уверен, что все учел.

Описание процесса?

Т.е. есть три уровня саппорта: tier 1 обрабатывает все входящие, решает то, что является репортом из-за Misunderstanding или отсутствия прав. tier-2 получает эскалацию, если есть проблема с инфраструктурой: недоступен сервер, например, или проблемы с данынми по вендору/клиенту, etc - то, что находится вне компетенции tier-1, tier-3 получает эскалацию, если в системе конкретно обнаружен баг, или если система конкретно легла не на уровне инфраструктуры (database locked, информация не вводится/не читается)