мы об этом и поговорим?)

Ну их полно по сети, думаю тут проще разобрать.

Q. 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 to decide acceptable perfromance 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

И мой ответ В

Вопрос, кстати, со звездочкой. В нем все ответы правильные :)

B - наиболее правильный :)

Кстати Лапшин пишет, что С

по фасилитации можно посмотреть вебинары и выступления Светланы Мухиной, мне хорошо зашли, Кейнера само собой проштудировать 😄

The Scrum Guide says “During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.” So, the right option is C – change the DoD at the Retrospective.

по фасилитации можно посмотреть вебинары и выступления Светланы Мухиной, мне хорошо зашли, Кейнера само собой проштудировать 😄

Кейнера начал читать.

И он тоже прав. Мое мнение, что B лучше, потому что указывает, что весть о проблеме с производительностью (т.е. feedback по продукту) должен принести PO

А в C про это не указано :)

И как в Дод производительность вбить, не совсем понятно. Да еще и для всей системы ...

это какая попытка уже?)

Вторая

Q. 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 to decide acceptable perfromance 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

А тут какой ответ?

И как в Дод производительность вбить, не совсем понятно. Да еще и для всей системы ...

Вбить, как влияние на performance, или добавить прохождение системой performance testing с заданным бенчмарком

Вбить, как влияние на performance, или добавить прохождение системой performance testing с заданным бенчмарком

На каждой фиче тестить производительность?

Подход команда должна обсудить и выработать :)

Подход команда должна обсудить и выработать :)

я cd ответил

На каждой фиче тестить производительность?

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

я cd ответил

Там разве не один вариант?

два

А где там D?

Подожди, ты наверное не на тот вопрос цитату поставил :)

Я про предыдущий :)

CD

Q. A team practices pair programming. Jason is one team member about who everyone has come to you to complain about him. Anyone who pairs with him gets caught in design and architecture decision discussion.. As a scrum master what will your do(choose two) a)Raise a concern to HR and get Jason removed from the team b)Take Jason aside and express your concern over this behavior. Tell him to act as team player and comply to team decision c)You suggest to open it up with full team now so that is does not further worsen. You propose to help initiate this discussion but not being the one to start it. d)You observe this in Retrospective whether discussion on design and architecture is initiated, if not then check how comfortable is everyone with the way it is handled in project

Ага, я этот имел ввиду

A неправильный, B непродуктивный

What are the main purposes of Product Backlog Refinement at scale? Select two. A) Identifying dependencies across the teams B) Decomposing large Product Backlog items into smaller ones C) Clarifying unclear Product Backlog Items D) Adding new items into the Product Backlog E) Forecasting which team will deliver which Product Backlog items

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

BC

Почему не А?

Хз, если честно, это вопрос из серии "к какой религии в scaling вы относитесь" и я не помню правильный ответ в Nexus

В SAFe зависимости определяются в режиме реального времени, как на PI Planning, так и во время PI Execution

В Nexus натурально не помню

Может и AC

Однозначно я уверен только в C :)

И в том, что D и E неверны

Refine the Product Backlog: The Product Backlog needs to be decomposed so that dependencies are identified and removed or minimized. Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified.

Сергей, тут вопрос про контекст scaling

Вот и пойми их

Это из Нексус гайда

АВ выходит

Я знаю, что LeSS настаивает на том, чтобы cross-team dependencies были минимизированны, в идеале - убраны. В SAFe пофигу, считается, что зависимости есть и должны обрабатываться (хотя на практике стараются минимизировать). В Nexus я реально не помню, просто потому, что не сталкивался в nexus с обработкой межкомандных зависимостей

Refinement of the Product Backlog at scale serves a dual purpose. It helps the Scrum Teams forecast which team will deliver which Product Backlog items, and it identifies dependencies across those teams. This transparency allows the teams to monitor and minimize dependencies. Refinement of Product Backlog Items by the Nexus continues until the Product Backlog Items are sufficiently independent to be worked on by a single Scrum Team without excessive conflict. The number, frequency, duration and attendance of Refinement is based on the dependencies and uncertainty inherent in the Product Backlog. Product Backlog items pass through different levels of decomposition from very large and vague requests to actionable work that a single Scrum Team could deliver inside a Sprint. Refinement is continuous throughout the Sprint as necessary and appropriate. Product Backlog refinement will continue within each Scrum Team in order for the Product Backlog items to be ready for selection in a Nexus Sprint Planning event.

Нежданчик

Да, неожиданно :)

Он вообще кривой какой-то этот Нексус

но почему refinement?

Риторический вопрос, хотя возможно кто-то знает

АЕ выходит правильно

В Лесс АВСЕ я бы ответил

Не, без Е

Ну тогда смысл refinement в scaling отличается от смысла refinement вне scaling :)

Я понял. В нексусе уже на Пибиар выбирают кто делать будет

В лесс максималтно оттягивают до планирования

Оно и логично. Зачем на PBR это выбирать... Ладно, видимо для ответа на этот вопрос надо изучить NExus Более глубоко :)

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

В защиту нексуса могу сказать, что это самый простой в имплементации фреймворк для scaling :)

Q. You’re a product lead with a good track record and the organization has asked you to take the lead of a new product. The product will have 6 teams working on it but they are all new to Scrum. You’re starting to form a Product Backlog. How would you minimize dependencies between Scrum Teams? (A): You identify the dependencies and re-order the Product Backlog for them. (B): You work with the Development Teams on how to best parse the work.

B

Угу

Без команды A все равно не получится :)

How much time should be spent carrying out Product Backlog Refinement? A. As much as the Product Owner and Development Team agree is necessary to create enough ready Product Backlog Items B. Up to 10% of the capacity of the Development Team C. As much as the Product Owner deems necessary to create enough ready Product Backlog Items D. Up to 10% of the capacity of the Development Team in a typical Sprint, but as much as 90% in early Sprints

Хитрый вопрос

Хитрый, да

А

Я бы ответил А

А В так и хочется выбрать :)

Почему?

Я могу сказать, что на практике будет D :) Но все зависит от договоренностей между командой и PO

Ну В очень похож на рекомендации Скрам гайда.

На первый взгляд

Но В это всего лишь рекомендация

У меня есть набор метрик, по которым я понимаю, все ли в порядке с командой. Одна из них - backlog granularity, это на сколько спринтов вперед PBI оценены в диапазоне 1-5. Если больше, чем на 2, скорее всего в refinement переинвестируют.

Q. A new Developer joins the Development Team taking the total number to 10 people. As a Scrum Master, What should you do? A. Instruct the Development Team to split into 2 teams with 5 Developers in each B. Instruct the Development Team to split into 2 teams, they should decide the appropriate sizes C. Raise the increased team size as a potential impediment and help the Development Team decide what to do about it D. Do nothing, the Development Team must fix its own issues

С

У меня есть набор метрик, по которым я понимаю, все ли в порядке с командой. Одна из них - backlog granularity, это на сколько спринтов вперед PBI оценены в диапазоне 1-5. Если больше, чем на 2, скорее всего в refinement переинвестируют.

А есть ограничения на оценку для Sprint Ready??

А есть ограничения на оценку для Sprint Ready??

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