PD-S開発・運用の方法論 · 開発の手法・方法論

スプリントレトロスペクティブ

Sprint Retrospective

すぷりんとれとろすぺくてぃぶ

スクラムで、スプリントの最後に行うふりかえりのイベント。スクラムチームが、そのスプリントでの人、相互作用、プロセス、ツールについて、うまくいったことと問題を検討し、品質と効果を高めるための改善策を決めて、次のスプリントで実行する。

共有:

他の資格での定義

スプリントの進め方そのものを振り返り、次のスプリントでの改善策を決める場。

Past Exams

過去問で 7 回出題（応用情報技術者試験 3・システムアーキテクト試験 2・基本情報技術者試験 1・高度試験午前Ⅰ 1）

出典: 独立行政法人情報処理推進機構（IPA）の過去問題。問題文は IPA のサイトの PDF で確認できます。「選択肢」は、問題文ではなく選択肢に出たものです。用語名で照合しているため、関係の薄い問題が含まれることがあります。

一定期間の活動を終えた節目に、チームでやり方を振り返り、良かった点や問題点を共有して次の期間の改善策を決める活動。アジャイル開発では反復ごとに行い、KPTなどの手法を使う。スクラムではスプリントレトロスペクティブとして行う。

2001年に軽量な開発手法の提唱者たちがまとめた、アジャイル開発の価値観を示す宣言。プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を価値とする。あわせて12の原則が示されている。

チームが外部から細かく指示されるのではなく、目標の達成に向けて作業の進め方や分担を自分たちで決めて進めること。アジャイルソフトウェア開発宣言の背後にある原則では、最良のアーキテクチャ、要求、設計は自己組織的なチームから生み出されるとされる。

複数のチームで1つのプロダクトを開発するために、スクラムを大規模に適用する枠組み。全チームが1つのプロダクトバックログと1人のプロダクトオーナーを共有し、スプリントをそろえて進める。役割や成果物の追加を最小限に抑え、スクラムの原則のまま規模を広げることを重視する。

複数のスクラムチームが並行して開発するとき、各チームの代表者が定期的に集まり、進捗、チーム間の依存関係、障害を共有して調整する仕組み。デイリースクラムをチームの上の階層で行う形で、大規模なアジャイル開発でチーム間の連携をとるのに使う。

スクラムで開発を担う、1人のプロダクトオーナー、1人のスクラムマスター、複数の開発者からなるチーム。階層や下位のチームを持たず、プロダクトの価値を生み出すのに必要なスキルをすべて備えた（機能横断的な）10人程度以下の小さな集団で、作業の進め方を自分たちで決める。