Score %0 (0 correct0 incorrect140 unanswered)
Q1。 團隊可能會遇到對「技術」使用者故事的需求。 誰決定這些的優先順序？
- 產品負責人在營運部門的協助下
- 技術主管在產品負責人的幫助下
- 產品負責人在技術主管的協助下
- 技術主管在營運部門的幫助下
Q2。 Scrum Master 在日常站會中扮演什麼角色？
- 祝賀團隊的出色工作。
- 站在開發人員圈子之外並傾聽障礙。
- Scrum Master 不應參加－該會議僅適用於開發人員。
- 詢問每位開發人員自上次每日站會以來他們做了什麼。
Q3。 Sprint 計畫不應考慮哪些因素？
- 團隊的速度
- 產品待辦事項中的故事數量
- 準備好的故事
- 團隊能力
Q4。 一名團隊成員表現出嚴重的個人痛苦跡象：在工作中哭泣、對同事發脾氣以及在電話中激烈交談。 身為團隊引導者，你該做什麼？
- 在 Sprint 發佈時報告此情況。
- 盡快通知採購訂單。 （舊答案：將您的觀察告知團隊成員的經理，並向經理尋求協助。）
- 指出原因並協同解決方案。
- 要求 PO 延長 sprint。
Q5。 哪一句話描述了規模化敏捷框架中的工作流程？
- 這是一個「推送」系統。
- 上方為“推”，底部為“拉”。
- 這是一個「拉」系統。
- 它既不是「推」也不是「拉」。
Q6。 產品負責人在決定衝刺待辦事項中的工作優先順序上扮演什麼角色？
- 無－Scrum Master 應優先考慮衝刺待辦事項中的工作。
- PO 應優先考慮衝刺待辦事項中的項目。
- 開發人員優先考慮工作，除非他們無法完成工作，在這種情況下，PO 應優先考慮剩餘的工作。
- 無－開發人員應優先考慮衝刺待辦事項中的工作。
Q7。 規模化敏捷框架主張，如果只衡量一件事，那麼該衡量什麼？
- 品質
- 交付的可預測性
- 延誤成本
- 投資報酬率
Q8。 為什麼您應該先申請加權最短職位？
- 最大化投資回報
- 決定積壓的經濟排序
- 可視化隊列長度
- 履行品質承諾
參考 `Weighted Shortest Job First (WSJF) 是一種優先模型，用於對作業（例如功能、功能和史詩）進行排序，以產生最大的經濟效益。 在基於流程的系統中，優先順序不斷更新，以提供最佳的經濟成果。 工作排序，而不是個人工作的投資回報，可以產生最佳結果。 為此，WSJF 用於透過計算相對 CoD 和作業大小（持續時間的代理）來確定積壓的優先順序。
Q9。 您已根據風險和價值對待待辦事項中的功能進行了分類。 開發團隊應該先開發哪些功能？
- 低價值高風險
- 高價值和高風險
- 高價值、低風險
- 低價值、低風險
參考`建議做高商業價值、高風險的專案第一的。 雖然這似乎有悖常理，但這項工作完成得越早，團隊就能越早採取行動緩解問題和未知因素，從而生產出更高品質的產品。 如果發生故障，它會提前發生並且相對便宜。
Q10。 在規模化敏捷框架中，推動者的角色是什麼？
- 他們幫助擴展建築跑道。
- 他們將願景與使命連結起來，以便組織能夠取得成功。
- 他們支持團隊建立。
- 他們消除了品質障礙。
Q11。 哪一項結果不是衝刺評審的預期結果？
- 團隊展示其已完成的工作。
- 團隊反思如何提升績效。
- 待辦事項中的項目可能會重新排列優先順序。
- 利害關係人詢問有關已完成和即將完成的積壓項目的問題。
Q12。 什麼不是用來分割使用者故事的技術？
- 按業務線劃分
- 分割複合使用者故事
- 依替代路徑分割
- 按介面分割
Q13。 誰決定團隊要做什麼？
- Scrum Master
- 一個自組織團隊
- 產品負責人
- 產品經理
Q14。 哪個選擇不是 Scrum 值？
- 重點
- 誠信
- 勇氣
- 承諾
Q15。 如果產品負責人在迭代結束時不接受故事，會發生什麼事？
- 團隊在速度計算中不會獲得故事點的積分。
- 故事應該被分割以反映作品的完成情況 d.
- 應調整驗收標準以反映已完成的工作。
- 該故事應向利害關係人展示以徵求他們的回饋。
Q16。 關於產品待辦事項列表，哪一項表述不正確？
- 這是落後於計劃的工作項目的清單。
- 項目依優先順序保留。
- 團隊中的任何人都可以為其提議一個專案。
- 它包括所有要完成的工作。
Q17。 專案有一些團隊希望減輕的主要風險。 監控這項工作進展的最佳方法是什麼？
- 基於風險的尖峰
- 風險調整後的積壓訂單
- 風險速度圖
- 風險燃盡圖
Q18。 工程副總裁希望開始頒發「衝刺團隊成員」獎，以表彰每個小組中的最佳表現者。 您應該給這位副總裁什麼建議？
- 除非最近的員工回饋顯示人們覺得自己不受重視，否則這沒有任何幫助。
- 只要在每個衝刺中識別不同的人，這就是一個好主意。
- 這是一個好主意，因為獎勵可以激勵人們盡力而為。
- 這沒有任何幫助，因為它會破壞實現高績效所必需的團隊團結。
Q19。 團隊的任務板和看板有什麼不同？
- 看板有明確的規則來限制 WIP。
- 看板顯示積壓的工作。
- 看板不使用完成定義。
- 看板顯示工作項目的狀態。
參考 明確規則適用於 scrum 團隊的任務板：任務無法加入 scrum在衝刺中登機。
Q20。 團隊抱怨說「最近事情一直在惡化」。 你該怎麼辦？
- 要求團隊經理進行角色分配，以便團隊能跟上。
- 舉辦研討會，以確定所有需要完成的事情，並看看誰可以為每項事情提供幫助。
- 請參閱團隊的 RACI（負責、負責、諮詢、通知）任務。
- 與技術主管和產品負責人會面，試著確定可以做什麼。
Q21。 在大規模 Scrum 中，Scrum Master 與團隊的建議比例是多少？
- 一位 Scrum Master 最多可以支援五個團隊。
- 大型團隊應該有兩位 Scrum Master。
- 每個團隊應該有一個 Scrum Master。
- 一個 Scrum Master 可以支援一到三個團隊。
Q22。 在 Cynefin 框架中，「最佳實踐」在哪裡最適合？
- 複雜政權中的 [ ]
- 複雜體系中的 [ ]
- 在混亂政權中
- 在明顯的製度中
Q23。 經理通知您，另一個團隊的開發人員正在執行任務，她希望將該開發人員安排在您的團隊中進行幾次衝刺。 你該怎麼辦？
- 向經理解釋這會對團隊造成乾擾，並要求找到另一項任務。
- 向團隊解釋情況並要求他們順其自然。
- 向您的經理解釋情況並要求他們解決。
- 當臨時開發人員出現時，指派他們編寫文件。
Q24。 產品負責人向您抱怨團隊工作不夠努力，他們需要將速度提高至少 50%。 您不應該採取哪些行動？
- 分享 PO 的回饋並挑戰團隊提高速度。
- 請 PO 向團隊解釋業務背景。
- 解釋技術債對 PO 的影響以及投入一定能力來減少技術債的好處。
- 舉辦價值流圖研討會以識別和減少浪費。
Q25。 跨職能團隊密切合作開發新產品創意的實踐名稱是什麼？
- 黑客馬拉松
- 大規模 Scrum
- 創新與規劃
- 萬能焦點
Q26。 團隊經理想要參加 Sprint 回顧會。 你該怎麼辦？
- 同意經理的請求並通知團隊。
- 建議經理只參加其他所有回顧會議。
- 為經理提議一個不同的論壇來與團隊會面。
- 詢問團隊是否同意經理參加。
Q27。 誰對 Scrum 團隊的績效負責？
- 團隊
- Scrum Master
- 產品負責人
- 工程經理
這是 Scrum Master 的職責之一！ Scrum Master 負責確保 Scrum 團隊能依照 Scrum 價值觀盡可能有效運作。 這意味著他們讓團隊保持正軌，規劃和領導會議，並解決團隊可能面臨的任何障礙。 參考
Q28。 關於小規模、頻繁發佈軟體的說法哪一項是正確的？
- 回滾的幾率很高。
- 它通常需要高度自動化。
- 行政成本很高。
- 向後相容性可能會受到損害。
Q29。 澄清和擴展使用者故事的活動叫什麼？
- 故事點估算
- 完成的定義
- 使用者故事擴展
- 待辦事項細化
Q30。 開發團隊首選哪種策略？
- 優化大多數已完成的工作。
- 最大化產出並最大化結果。
- 最大化結果，同時最小化輸出。
- 優化資源利用。
“……你的工作是最小化產出，最大化結果和影響。” ——傑夫巴頓`
Q31。 關於使用者故事中的演員，哪一項敘述是正確的？
- 參與者不必在解決方案中具有指定的角色。
- 每個演員必須有多個角色。
- 參與者可以是系統本身。
- 系統不能是演員。
[參考](https://tcagley.wordpress.com/2015/03/31/the-difference- Between-a-persona-and-an-actor/) 參與者可以是個人、團體或系統。
Q32。 關於敏捷的哪一種說法是正確的？
- 敏捷需要高度的前期規劃。
- 一旦需求得到同意，團隊就可以完成工作。
- 敏捷需要高度的紀律。
- 沒有合約時敏捷效果最好。
Q33。 哪一項有關燃盡圖和燃耗圖的敘述是不正確的？
- 燃盡圖顯示尚待完成的工作。
- 燃耗圖顯示已完成的工作。
- 燃盡圖比燃盡圖更有用。
- 敏捷專案管理工具可以自動產生這些。
Q35。 當團隊需要做出決定時，最好的行動方案是什麼？
- 試著達成共識。
- 進行投票，多數決定。
- 找出最有知識的人並請他們做出決定。
- 讓團隊中最資深的成員決定。
Q36。 哪些行為是團隊輔導老師不該做的？
- 擁抱僕人式領導。
- 估計故事點。
- 慶祝成功。
- 消除障礙
Q37。 團隊需要進行研究、設計或原型製作。 這種類型的故事叫什麼？
- 探索性尖峰
- 待辦事項細化
- 功能分解
- 研發
Q38。 關於技術債的哪一種說法是正確的？
- 技術債是 bug 的別稱
- 由產品負責人自行決定分配工作以減少技術債。
- 應不惜一切代價避免增加技術債。
- 技術債是產品負責人欠開發人員的債務，如果他們加班很多才能完成衝刺。
Q39。 哪一項關於估計的敘述是不正確的？
- 絕對估計值比相對估計值更可靠。
- 相對估計比絕對估計更可靠。
- 在估算中，準確度比精確度更重要。
- 在估算中，付出的努力比所需的時間更重要。
Q40。 產品負責人不該參加哪些儀式？
- 每日站立會議
- Sprint 回顧
- 故事點估算
- 程式碼審查
Q41。 哪一項任務不是產品負責人的責任？
- 估計故事點
- 細化驗收標準
- 向開發人員提供有關使用者故事的回饋
- 向利害關係人展示工作
Q42。 在衝刺計畫期間「不」考慮哪個選項？
- 個符合「完成」定義的故事
- 團隊速度
- 符合就緒定義的故事
- 團隊能力
Q43。 您已經注意到一種模式，即 Sprint Backlog 上最有趣的故事會立即開始，而最不有趣的故事則會停滯或無法完成。 你該怎麼辦？
- 使用抽籤系統來分配每個故事。
- 與團隊分享您的觀察結果，並邀請他們承擔並解決問題。
- 在故事點估計期間，增加分配給最不有趣的故事的分數，以便團隊可以提高速度。
- 要求技術主管將每個故事分配給開發人員，以便他們都能有效率且負責任地完成。
Q44。 什麼敏捷實踐最能支持這項原則：「團隊定期反思如何變得更有效，然後相應地調整其行為」？
- 衝刺回顧
- Sprint 回顧
- 每日站立會議
- 衝刺演示
Q45。 角色通常是基於什麼？
- 發起人或團隊成員的個性和特質
- 開發者認為什麼是使用者友善的迪利
- 真實的人、原型使用者或多個使用者的組合
- 產品功能與用途的描述
Q47。 敏捷宣言顯示了什麼？
- 回應變化比遵循計劃更有價值。
- 預先記錄需求比最後記錄需求更有價值。
- 遵循計劃對於不超出預算至關重要。
- 應透過合約談判來解決爭議。
[參考] (https://www.agilealliance.org/agile101/the-agile-manifesto/) 完整宣言。
Q48。 工作協議的主要好處是什麼？
- 指定核心工作時間。
- 澄清了團隊中的報告關係。
- 它定義了團隊渴望實現的文化。
- 它匯集了每個人的信息。
Q49。 具有多個用於視覺化工作流程的資料列的資訊輻射器的名稱是什麼？
- 工作流程指示器
- 價值流圖
- 故事地圖
- 看板
Q50。 故事點的最佳定義是什麼？
- 它們是完成故事所需努力的相對衡量標準。
- 它們僅衡量開發時間，測試時間單獨考慮。
- 它們是故事價值的相對衡量標準。
- 它們是完成故事的時間度量。
Q51。 什麼是 Scrum of Scrum？
- 這是兩個或更多團隊合作協調工作的一種技術。
- 這是 Scrum Master 實踐社群的另一個名稱。
- 它是一個資訊輻射器，用於比較多個團隊的速度。
- 這是同一版本系列中團隊的系統演示。
Q52。 產品負責人在產品待辦事項扮演什麼角色？
- PO 必須確定待辦事項清單中功能的目標使用者。
- PO 負責估算總數的大小。
- PO 必須辨識影響積壓工作的依賴關係。
- PO 決定待辦事項包含哪些內容以及排除哪些內容。
Q53。 團隊為什麼要重構？
- 將開發人員分配到其他團隊，以消除性格衝突。
- 它改進了產品的功能，
- 它重新調整了產品在市場上的成功標準。
- 它改進了設計，從而提高了開發效率和可維護性。
Q54。 哪一個選擇不是通常與產品演示相關的好處？
- 了解新要求。
- 了解功能適用性。
- 了解功能可用性。
- 了解特徵估計。
Q55。 什麼是資訊輻射器？
- 團隊的 KPI 列表
- 逾期行動項目列表
- 任務板
- 關鍵效能資料的高度可見顯示
Q56。 根據敏捷宣言，您的最高優先事項是_。
- 最小化變更請求
- 滿足客戶
- 按時完成工作
- 實現所需的投資報酬率
Q57。 產品開發組織有時會使用原型使用者及其價值觀的描述，以便開發人員可以設計系統來滿足他們的需求和願望。 這些描述叫什麼？
- 演員
- 角色
- 代理
- 角色
Q58。 產品負責人專注於盡可能快速且廉價地在市場上測試新的系統概念。 第一代產品叫什麼名字？
- 預生產版本
- 焦點小組演示
- 第一代產品
- 最小可行產品
Q59。 產品負責人該向誰報告？
- 品質經理
- 產品經理
- Scrum Master
- 工程經理
Q60。 Sprint 0 中會發生什麼事？
- 團隊在該衝刺中沒有提供任何故事點。
- 團隊在生產發布前進行回歸測試。
- 團隊準備處理產品待辦事項清單。
- 現在是檢查和適應的時候了。
Q61。 完成的定義是什麼意思？
- 該故事符合 INVEST 標準。
- 團隊已完成 Sprint 中的所有工作。
- 故事已移交給 DevOps 團隊。
- 團隊已就故事完成的標準達成一致。
Q62。 描述您的產品時哪個元素最重要？
- 其成本
- 其授權條款與條件
- 它的好處
- 其特點
Q63。 哪個選項最能描述團隊協調員？
- 會議安排程序
- 記錄員
- 專案經理
- 敏捷教練
Q64。 什麼是 t 將故事分成更小部分的技術的名稱？
- 有絲分裂
- 故事切片
- 分解
- 分而治之
參考 什麼是故事切片？ 為了有效地建立功能並逐步交付用戶價值，需要將功能進一步分解為更小的用戶故事。 很多時候，團隊不斷地將使用者故事分成更小的價值部分，這樣他們就可以在衝刺中完成故事。 這稱為故事切片或分裂。
Q65。 一名團隊成員向您投訴另一名團隊成員。 你該怎麼辦？
- 向其他人提出投訴並嘗試解決問題。
- 讓他們與對方交談並嘗試解決問題。
- 將問題通知 HR 並要求他們處理。
- 邀請雙方參加會議並嘗試調解衝突。
Q66。 團隊發展的形成-風暴-規範、執行模式是什麼？
- 塔克曼模型
- 標準團隊模型
- 摩爾的團隊框架
- 西伯特模型
Q67。 您檢查衝刺期間完成的工作的儀式的名稱是什麼？
- Sprint 回顧
- Sprint 回顧
- 下一個 Sprint 計劃
- 速度確認
“衝刺回顧：反思之前的衝刺，討論哪些方面效果良好，哪些可以改進，以及如何改進以提高生產力。”
參考 Sprint Review：討論 sprint 期間完成的工作以及 sprint 目標是否實現已經遇見了。
Q68。 哪個選項最能描述敏捷發布系列 (ART)？
- 持續交付
- 由計劃內的團隊組成
- DevOps 卓越中心
- Scrum 中的 Scrum
Q69。 身為敏捷教練，您對團隊成員的個人目標和動機應該持什麼態度？
- 理解它們－試著將個人動機與團隊達成專案目標的進度結合。
- 培養他們－目標是人們想要工作的原因。
- 忽略它們－個人觀點與達成專案目標無關。
- 利用它們－利用個人目標來鼓勵團隊成員提高績效水準。
Q70。 哪個片語最能描述敏捷團隊？
- 由專案經理領導的獨立技能、自我指導的團隊。
- 一個跨職能、長期存在的團隊，沒有最後期限。
- 具有集體責任的跨職能、自組織團隊。
- 專注於單一專案的熟練臨時團隊。
Q71。 哪種技術無助於決定待辦事項的優先順序？
- 莫斯科牛
- 卡諾
- 華爾街日報
- 改善
參考 oznaczające japońską filozofię biznesową (sposób postępowania) ustawicznego powania, poprawiania procesu zarządzania izah nichhaahihaahimah shmzania imzah shzania iz 好的 他們 technik biznesu 「及時」。
Q72。 準備好的定義是什麼意思？
- 故事已經過測試，準備發布。
- 故事已準備好進入衝刺。
- 利害關係人已準備好討論他們對故事的要求。
- 團隊已完成衝刺 0，準備工作。
參考 `就緒的定義意味著故事必須立即可付諸實踐。 團隊必須能夠確定需要做什麼以及完成使用者故事所需的工作量。
Q74。 容量的定義是什麼？
- 它是團隊知識和技能的清單，用於規劃他們所做的工作。
- 團隊輔導員可以同時支援的團隊數量。
- 這意味著團隊確定他們是否可以參加下一個衝刺。
- 這是衝刺中允許的最大故事數。
Q75。 團隊抱怨他們向產品負責人發送了澄清請求，但這些請求沒有得到回應。 你應該採取什麼行動？
- 如果對故事有疑問，請告訴開發人員使用他們的最佳判斷，避免拖延，並在衝刺評審中討論該問題。
- 向產品負責人發送一條說明，說明完成工作的延遲將是他們的責任，而不是團隊的責任。
- 制定服務等級協定 (SLA)，為不同類型的請求定義特定的回應時間並要求由產品負責人簽名。
- 安排與產品負責人和其他團隊成員一起解決問題的會議。
Q77。 哪一種說法最能描述敏捷、精實和六西格瑪？
- 它們是交付顧客價值的策略。
- 它們是由豐田開創的。
- 它們是發現顧客需求的策略。
- 它們源自於統計過程控制。
Q78。 什麼是使用者故事？
- 描述演員想要做什麼來實現目標
- 原型使用 者的描述，以便開發人員可以使解決方案變得用戶友好
- 來自現場的有關使用者產品體驗的報告
- 需求的敏捷術語
Q79。 規劃撲克會議的預期成果是什麼？
- 對這些故事進行了討論，並為每個故事分配了一個故事點估計。
- 團隊向產品負責人提供了有關驗收標準的回饋。
- 團隊決定應在同一個衝刺中發展哪些故事。
- 團隊制定了初步計劃，哪些故事將在下個季度完成。
Q80。 速度的定義是什麼？
- 衝刺期間交付的故事點數
- 衝刺積壓中故事的平均等待時間
- 故事從產品待辦事項轉移到衝刺待辦事項的平均等待時間
- 開發者完成一個故事所花費的時間除以其相對價值
Q81。 對於成功的產品負責人來說，最重要的是要理解什麼？
- 產品的預算。
- 產品底層技術。
- 開發團隊的優勢與劣勢。
- 產品的業務環境。
參考 `Scrum 團隊有 3 個角色 - 產品負責人、Scrum Master 和開發人員。 所有 3 個角色都在各自的環境中產生價值； 然而，產品負責人可以從產品或業務環境中最大化價值。
Q82。 關於敏捷宣言的哪一項敘述是正確的？
- 它是透過眾包編寫的，作者未知。
- 它已被翻譯成數十種語言並在世界各地使用。
- 編寫於 2001 年，現已過時。
- 它首次作為 Jim Highsmith 博士論文的一部分發表。
Q83。 該團隊不會完成其 Sprint 承諾。 身為團隊協調員，你該做什麼？
- 要求 PO 延長 sprint。
- 盡快通知採購訂單。
- 在 Sprint 評審中報告此情況。
- 指出原因並協同解決方案。
參考，最後一段完美地告訴了敏捷開發人員在這種情況下會做什麼。
Q84。 當使用者故事進一步分解時，元素被稱為什麼？
- 技術任務
- 演員與動作
- 誰、什麼、為什麼
- 線程
Q85。 集體所有製是什麼意思？
- 團隊的每個成員都可以根據需要對程式碼的任何部分進行更改。
- 如果有人有錯，那麼整個團隊都有錯。
- 團隊平均分享產品所產生的利潤。
- 接受績效評估的是團隊，而不是個人。
Q86。 根據敏捷宣言，開發人員和業務人員應該多久合作一次？
- 視需要經常使用
- 每兩週一次
- 每天
- 每週
Q87。 在編寫程式碼之前先寫測試的做法叫什麼？
- 可測試性設計
- 測試驅動開發
- 單元測試
- 測試然後編碼
Q88。 「T 技能」團隊成員的術語是什麼？
- 跨職能
- 多才多藝
- 學徒開發者
- 泛化專家
Q89。 關於結對編程，哪項說法不正確？
- 它已經被抹黑了，因為它太貴了。
- 在結對程式設計中，兩位開發人員共用一台電腦並輪流操作鍵盤。
- 這是教導團隊新成員的好方法。
- 兩個開發人員協作產生的程式碼通常比他們單獨工作時的品質更高。
Q90。 具有固定型思維模式的人_ .
-
%OPTION% 具有更好的注意力和更長的注意力持續時間
-
%OPTION% 更加目標導向
-
%OPTION% 往往更有彈性
-
%OPTION% 更害怕失敗
Q91。 如何改善團隊成員之間的互動？
- 在團隊房間中移動人們的工作站以創造新的社交可能性。
- 詢問團隊是否願意一起做一些娛樂活動並主動提出組織。
- 告訴團隊您認為這是一個問題，並要求他們解決。
- 由於沒有人向您投訴，因此假設有限的互動對每個人都有效。
Q92。 每日站立會議的預期結果是什麼？
- 更新了所有工作的狀態
- 團隊就當天的計劃進行協調
- 障礙與優先事項列表
- 向產品負責人提交準備接受的故事報告
Q93。 分解故事、輸入分割資料並產生新輸出的技術的名稱是什麼？
- 輸入輸出處理
- ITIOO 故事格式
- 垂直薄切片
- 結構化編碼
ITIOO 不是一個東西，薄垂直切片指的是你優先考慮的工作，結構化程式碼與故事無關。
Q94。 形容「T 型」團隊成員的字眼是什麼？
- 跨職能
- 多才多藝
- 泛化專家
- 學徒開發者
跨職能和泛化專家似乎都是正確的，但我們更多地談論跨職能團隊，並且就團隊成員而言，我認為該術語更像是泛化專家 參考 這是指團隊： 參考 `當組織轉向敏捷工作方式時，他們面臨的挑戰之一是經常提到需要建立由「T 型」人組成的團隊。 這也可以被描述為跨功能。
Q95。 什麼是精益畫布？
- 用於將解決方案分解為史詩、特徵和故事
- 這是一個輕量級商業計劃模板，可以讓你的假設變得明確
- 它是一個規劃未來專案發布的工具
- 這是一種預測市場佔有率成長的技術。
參考 1頁商業計劃模板，可幫助您使用9 個基本要素將您的想法解構為其關鍵假設積木。
Q96。 該團隊不會完成其 Sprint 承諾。 身為團隊協調員，你該做什麼？
- 盡快通知採購訂單
- 指出原因並合作解決方案
- 在 Sprint 評審中報告這一點
- 要求 PO 延長 sprint
Sprint 無法延長。 Scrum 指南對此說得很清楚：你不能延長衝刺。 在衝刺結束時，如果有未完成的工作：“所有未完成的產品待辦事項清單項目都會重新估計並放回產品待辦事項清單中。” 參考 第 4 點：4）如果開發人員無法在 Sprint 結束時完成他們的工作，會發生什麼事？ 開發人員通知產品負責人。 如果出現問題，Scrum 團隊應該進行檢查和調整，以防止將來發生這種情況。 了解為什麼會發生這種情況至關重要。
Q97。 對於成為一名有效的團隊協調員來說，下列哪些特質最重要？
- 有自我意識
- 外向
- 具有 A 型人格（絕對不是這個 :P）
- 成為負責人
參考未經驗證的答案 - 協調員是幫助團隊確定共同目標，然後提供團隊流程以實現既定結果，同時保持中立。 熟練的引導者有意識地體現自我意識、自我管理和偏見管理，同時傳達開放性和熱情。
Q98。 什麼時候是更新團隊燃盡圖的最佳時間？
- Sprint 回顧之前的 [ ]
- 每日站會後
- 每日 Scrum 之前
- 季度計劃之前
Q99。 什麼是同理心地圖？
- 這是一種用於提高生產力的團隊建立技術。
- 它是組織用來獲取競爭情報的工具。
- 這是一種用於提高團隊士氣的回顧技術。
- 它是一種協作工具，用於更深入地了解客戶。
Q100。 哪些工作描述不是用使用者的語言寫的？
- 任務
- 史詩
- 故事
- 特徵
它說：不是用使用者的語言寫的。 故事，也稱為使用者故事，是可以交付的簡短請求在一次衝刺中。 它是從使用者的角度用簡單的語言編寫的。
應該是任務： 任務是故事的一個小節。 它有助於分解故事並概述它將如何完成。 任務往往更具技術性，因為它們是由開發團隊成員使用的。 參考
Q101。 團隊在衝刺結束時有一個不完整的故事，並希望為已完成的工作獲得部分功勞。 你該怎麼辦？
- 要求產品負責人接受該故事，並承諾團隊將在下一個衝刺中完成它
- 要求他們對故事進行切片以反映已完成的工作和待完成的工作
- 要求產品所有者修改驗收標準，以便可以接受和計數
- 解釋說，在敏捷中，工作軟體是進度的主要衡量標準。 然後幫忙...
Q102。 在規劃會議時，哪個行動最重要？
- 澄清預期結果
- 記筆記
- 邀請專案經理
- 確保每個人都發言
Q103。 您正在主持一次會議，但出乎意料的是，一位關鍵人物沒有參加。 你該怎麼辦？
- 召開會議並更新稍後無法參加的人員。
- 請未能出席的人員根據其空閒時間重新安排會議。
- 詢問所有會議參與者對於某人的缺席他們想做什麼
- 重新安排會議時間，以便所有必要的人員都可以參加
Q104。 什麼是開放空間？
- 團隊房間的設計理念
- 一個供團隊示範其工作的房間
- 程式碼主體中用於未來功能的佔位符
- 參與者創造和管理議程的會議形式
Q105。 哪個選擇不是重構的預期好處？
- 重構可以減少未來開發的工作量
- 重構用於修復錯誤
- 重構改進了系統的設計
- 重構提高了程式碼的可維護性
Q106。 在規模化敏捷框架中，連續的迭代被分組為一個 PI。 什麼是 PI？
- 專案增量
- 投資組合增量
- 產品增量
- 程式增量
參考 `計畫增量 (PI) 是一個時間盒，在此期間敏捷發布列車 (ART) 以可工作、經過測試的軟體和系統。 PI 通常持續 8 – 12 週。
Q107。 如何改善團隊成員之間的互動？
- 在團隊房間中移動人們的工作站以創造新的社交可能性
- 由於沒有人向您投訴，因此假設有限的互動對每個人都有效
- 詢問團隊是否願意一起做一些娛樂活動並主動提出組織該活動
- 告訴團隊您認為這是一個問題，並要求他們解決它
調動人員並重新設計辦公空間可以改善團隊成員之間的互動，這一點有據可查： 參考
Q108。 Planning Poker 通常使用哪種量表？
- 少於 1 小時、1 至 4 小時、4 至 8 小時、8 至 24 小時、超過 24 小時
- 2、4、6、8、10
- XS、S、M、L、XL
- 1、2、3、4、5、8、13、20
Q109。 您是 Scrum Master，剛剛主持了一次會議，您正在思考改進的方法。 你正在展示什麼技能？
- 有自我意識
- 外向
- 具有 A 型性格
- 成為負責人
Q110。 對於成功的產品負責人來說，了解哪些背景資訊最重要？
- 產品的預算。
- 產品底層技術。
- 開發團隊的優勢與劣勢。
- 產品的業務環境。
它與 Q81 相同，只是措詞略有不同。
Q111。 您正在組織一個分解使用者故事的會議，但意外的是，開發團隊成員無法參加。 你該怎麼辦？
- 召開會議並更新稍後無法參加的人員。
- 請未能出席的人員根據其空閒時間重新安排會議。
- 詢問所有會議參與者對於某人的缺席他們想做什麼
- 重新安排會議時間，以便所有必要的人員都可以參加
Q112。 身為 Scrum Master，您發現團隊成員透過即時訊息傳遞比透過直接轉換進行溝通更舒適。 如何鼓勵團隊成員之間的對話？
- 在團隊房間中移動人們的工作站以創造新的社交可能性。
- 由於沒有人向您投訴，因此假設有限的對話對每個人都有效。
- 告訴團隊您將此視為專業人士問題並要求他們解決。
- 詢問團隊是否可以想出增加直接對話的方法。
Q113。 每日 Scrum 會議的預期結果為何？
- 更新了所有工作的狀態
- 團隊就當天的計劃進行協調
- 障礙與優先事項列表
- 向產品負責人提交準備接受的故事報告
Q115。 什麼類型的環境最適合敏捷原則？
- 在靜態環境中效果很好。
- 它在動態環境中效果很好。
- 它在客戶環境中效果很好。
- 敏捷已被證明不適用於任何良好的環境。
參考`敏捷環境呼籲快速行動、討論、評估和考慮不同的方法。 它在動態環境中效果很好，在動態環境中，需求可能會改變或演變。
Q116。 跨職能團隊意味著什麼？
- 組織中的每個團隊都有特定的專長
- 每個團隊成員都有自己的專長
- 團隊中存在所有必要的技能
- 團隊可以有效溝通
Q117。 什麼是 PBI？
- 增量前的產品
- 項目計費信息
- 生產待辦事項增量
- 產品待辦事項項目
Q118。 下列哪一項 Scrum 活動致力於流程改善？
- 衝刺計劃
- 每日站會
- 衝刺回顧
- 衝刺回顧
Q119。 對於為期一個月的衝刺，衝刺回顧的時間範圍是**_**。
- 3 小時
- 6 小時
- 8 小時
- 1 小時
Q121。 下列關於看板控制圖的哪些表述是錯誤的？
- 淺藍色陰影區域是標準差。
- 綠點是問題本身。
- 當您追蹤的任務大小不同時，控製圖效果最佳。
- 藍線是滾動平均週期時間。
Q122。 EBM 在管理決策中考慮什麼？
- 生產力與道德問題
- 情境與道德問題
- 情況與財務問題
- 道德與倫理問題
Q123。 Stacey 的流程複雜性模型向我們表明，敏捷思維是最好的 **___**。
- 當複雜度較高時
- 當確定性較高時
- 無論複雜性或確定性
- 當確定性和複雜性較低時
Q124。 什麼是深度產品積壓？
- 詳細、恰當、緊急、優雅且優先
- 詳細、緊急、估計並確定優先順序
- 詳細、適當、散發、估計並確定優先順序
- 詳細、適當、緊急、估計和優先級
Q125。 哪個 Jira 功能提供了多個項目的概述？
- 易拉寶板
- 程式碼集成
- 任務自動化
- 報告
Q126。 下列哪一個元素不是 Scrum 的支柱？
- 適應
- 透明度
- 永續性
- 檢查
Q127。 產品負責人負責產品的哪些面向？
- 指導產品開發團隊
- 管理與擁有積壓訂單
- 所有選項均正確
- 產品本身
Q128。 在 Scrum 中，在每個衝刺結束時，都會有一次 _ 會議，團隊在會上接收並提供有關其流程和績效的回饋。
- 回顧
- 審查
- 反射
- 衝刺
Q129。 在使用者故事的 INVEST 縮寫中，「V」代表什麼？
- 有價值
- 可驗證
- 真實性
- 大量
Q130。 對於敏捷團隊成員來說，專注於成長和機會的心態是健康的。 如何展現成長心態？
- 將挑戰視為機遇
- 指出別人的失敗
- 領先時退出
- 僅在成功時慶祝
Q131。 關於敏捷宣言的哪一項敘述是正確的？
- 它是透過眾包編寫的，並且其作者未知
- 編寫於 2001 年，現已過時。
- 它是為了回應大量文件的軟體開發專案實踐而編寫的。
- 它首次作為 Jim Highsmith 博士論文的一部分發表。
參考 “(...)其他人同情需要一種替代文檔驅動的重量級軟體開發流程。” [第一段]
Q132。 由於您尚未收到銷售數據，衝刺目標的進展處於危險之中。 你該怎麼辦？
- 請務必在下次 Scrum 中提及該問題
- 與您的團隊分享問題，看看他們是否可以創建解決方案
- 解決問題，直到最後負責任的時刻解決它
- 檢查產品負責人的日程安排並預訂會議時間
Q133。 什麼時候是查看團隊燃盡圖的最佳時間？
- 每日站會後
- Sprint 回顧之前的 [x]
- 每日 Scrum 之前的 [ ]
- 季度計劃之前
Q134。 使用者故事中關於演員的哪一項敘述可能是正確的？
- 系統不能是演員
- 每個演員必須有多個角色
- 參與者可以是系統本身
- 參與者不必是解決方案中的指定角色
Q136。 團隊最有可能在哪裡發現潛在問題的最初跡象？
- 每日站會
- 衝刺演示
- 回顧
- 衝刺計劃
Q137。 與 Scrum 團隊合作時，誰主要負責確保專案交付價值？
- 產品擁有者
- 開發團隊
- Scrum 大師
- 品質保證
來源 「Scrum Master 是負責將所有內容黏合在一起並確保 Scrum 順利完成的角色。實際上，這意味著他們可以幫助產品擁有者定義價值，開發團隊交付價值，而Scrum 團隊則變得更好。"
Q138。 5.0 版的 Scaled Agile Framework 有多種設定。 哪一項不是配置之一？
- 完全安全
- 大型解法 SAFe
- SAFe 流行
- 基本 SAFe
Q139。 什麼是精益畫布？
- 這是一個規劃未來產品發表的工具
- 用於將解決方案分解為史詩、特徵和故事
- 這是一種預測市場佔有率成長的技術
- 這是一個輕量級商業計劃模板，可以讓您的假設變得明確
Q140。 身為 Scrum Master，您已經注意到一種模式：衝刺待辦事項中最有趣的故事會立即開始，而最不有趣的故事則會停滯或無法完成。 你該怎麼辦？
- 在故事點估計期間，增加分配給最不有趣的故事的分數，以便團隊可以提高速度。
- 與團隊分享您的觀察結果，並邀請他們承擔並解決問題。
- 要求團隊使用抽籤系統來分配每個故事
- 要求技術主管將每個故事分配給開發人員，以便他們都能有效率且負責任地完成。
