PMI-ACP日本語 無料問題集「PMI Agile Certified Practitioner (PMI-ACP日本語版)」

（A）非機能要件としてセキュリティをリスクレジスタに追加し、定期的に確認します。

（B）計画と優先順位付けにセキュリティ要件の考慮が含まれていることを確認します。

（C）すべての会議の議題にセキュリティ上の懸念を含めます。

（D）セキュリティの専門家をチームに追加するように要求します。

（A）回顧

（B）毎日のスタンドアップミーティング

（C）スパイク

（D）改善会議

（A）高レベルのリリース計画はイテレーション0の一部であり、概念実証として機能します。

（B）進行中の作業 (WIP) と将来の開発を視覚化するためのカンバン ボードを作成します。

（C）ウォーキング スケルトンを指摘し、価値を提供する基本的な機能を強調します。

（D）チームのパフォーマンスと速度はプロジェクト開始後にのみ判断できます

（A）顧客がユーザーストーリーから得る価値をレビューしてバックログの優先順位を決定する

（B）次のイテレーションの振り返りで効率性について議論する

（C）プロセスバリューストリームをレビューして潜在的な改善点を特定する

（D）次のスプリントレビューでソリューションのパフォーマンスについて議論する

（A）チームメンバーを指導して、機能的専門性を向上させ、全体的な速度を向上させます。

（B）バックログをレビューして、優先順位が付けられ、洗練され、適切に処理されていることを確認します。

（C）チームプロセスが、承認されたスクラムプラクティスとどこでずれているかを特定します。

（D）問題または問題の特定を容易にし、チームがそれらを解決するのを助けます。

（A）チームを指導して、バックログ アクティビティを、見積もりと完了が容易な、細かく単純なタスクに分解します。

（B）チームの能力を評価し、能力使用率の 80% に基づいて反復のユーザー ストーリーを選択できるように支援します。

（C）タスクを時間通りに予算内で完了できるように、チームに人員を追加するオプションについて話し合います。

（D）チームの能力を評価し、能力使用率の 60% に基づいて反復のユーザー ストーリーを選択できるように支援します。

（A）チームが見積もりを維持するように促します。これにより、他の人が見逃している可能性のあるさまざまな制約や仮定が明らかになります。

（B）開発者に見積もりを維持するよう依頼し、チームが作業の理解度を透明化できるようにします。

（C）上級開発者の見積もりの​​みを考慮し、下級開発者にそこから学ばせることを提案します。

（D）最終的なストーリー ポイント数はチーム メンバー全員の平均となるため、見積もりを維持することにチームと合意します。

（A）チームメンバーの報告を聞く時間を確保するために会議を延長することをチームに通知します。

（B）チームメンバーが報告した問題に集中するため、チームの残りのメンバーを会議から退出させる

（C）チームを丁寧に止め、この特定の問題について話し合うために別の会議をスケジュールすることを提案します。

（D）チーム メンバーに、次の毎日の調整会議まで議論を待つように依頼します。チームは現在のステータスを確認する必要があります。

（A）バックログから目標達成に貢献するユーザーストーリーを読んで特定します。

（B）チームの速度を向上させるためのアイデアのリストを作成し、次のスプリントでより多くのストーリー ポイントを計画できるようにします。

（C）技術的な専門知識に基づいて、各ストーリーの労力見積もりを作成します。

（D）選択した各ユーザー ストーリーの考えられるリスクと、最終ユーザーに追加される価値を考慮します。

（E）目標を達成するために必要なタスクのリストと、それらを実行する順序を準備します。

（A）現在のスプリントで変更を実装し、現在の作業負荷や進行中のタスクへの潜在的な影響に関係なく、リソースを再割り当てし、フィードバックにすぐに対応できるようにスプリントの目標を調整します。

（B）次の製品リリースまでフィードバックを無視し、現在のスプリントのコミットメントのみに焦点を当てて、混乱を回避し、現在のワークフローを維持します。これにより、潜在的に価値のある変更が遅れることになりますが。

（C）戦略目標と現在の作業負荷への影響を考慮して、利害関係者のフィードバックに優先順位を付け、次のスプリント計画会議でこれらの優先順位についてチームと話し合い、次のステップを共同で決定します。

（D）チームに相談せずにすぐに製品バックログを更新し、現在のワークフローを中断する場合でも、最も重要なフィードバックができるだけ早く対処されるようにします。

（A）最も頻繁に完了する速度を表す 46 ストーリー ポイントのコミットメントを維持します。

（B）チームのパフォーマンスを向上させるために、コミットメントを 48 ストーリー ポイントに増やします。

（C）完了したストーリー ポイントのチームの平均速度と一致するように、44 ストーリー ポイントにコミットします。

（D）コミットメントを満たす可能性を高めるために、コミットメントを 40 ストーリー ポイントに減らします。

（A）各オプションの公平な評価者として機能し、開発チームと製品所有者に指示を提供します。

（B）開発チームにプロダクトオーナーの指示に従わせる

（C）開発チームとプロダクトオーナーの間でユーザーストーリーに関する会話を促進する

（D）プロダクトオーナーのアプローチに穴を開けるために、公然と異議を唱える

（A）技術設計チームから主題専門家 (SME) を招き、チームのコンサルタントとして活動してもらいます。

（B）最適な機能実装の決定を最上級のチームメンバーに委任します。

（C）スプリントレビュー中に、この競合を解決する方法について、チームを個別に、そしてチーム全体に指導します。

（D）技術設計の目的に最も適した技術実装を決定します。

（A）より予測的な製品開発アプローチへの移行を検討してください。

（B）チーム内の製品テストと品質保証スキルを向上させる

（C）ソフトウェア チームとの製品計画セッションをさらに促進します。

（D）ユーザーからのフィードバックを得るために製品のプロトタイプを開発します。

（A）プロジェクト開始時に考慮されていなかった、追加の作業時間とコストにつながる顕在化したリスクのリストを説明します。

（B）プロダクト オーナーによって要求されたスコープ変更の数と、チームが計画外のタスクに費やした時間数を説明します。

（C）初期見積りはプロジェクトの実現可能性を測定するのに役立ちますが、実際の見積りはチームが各スプリントでどれだけ学習するかによって決まることを説明します。

（D）プロジェクトの特徴的な側面を形成し、以前の経験と比較できない機能と要件について説明します。

（A）インタラクティブなコミュニケーション

（B）対人コミュニケーション

（C）プル通信

（D）プッシュ通信

（A）チームメンバーが密接に連携したコードを記述するように促します。

（B）プロジェクトの開始時に作成されたプロジェクト スケジュールに従います。

（C）チームメンバーが改善項目を選択できるようにし、その判断を信頼します。

（D）定期的に振り返りを行い、チームメンバーに具体的なアクションを約束してもらいます。

（A）この新しい改善のためのユーザーストーリーを作成し、次のスプリントで優先順位を付ける

（B）要件の増大として文書化する

（C）この新しい改善のためのユーザーストーリーを作成し、顧客による優先順位付けと検証のために製品バックログに入れます。

（D）UI を改善するための追加のストーリーポイントをチームに依頼する