レトロスペクティブとは
レトロスペクティブ（retrospective）とは、スクラム開発のスプリント終了時に行う振り返りミーティングのことです。アジャイル開発手法のひとつであるスクラム開発では、スプリントを繰り返して製品の品質を高めていきます。スプリントは1～2週間の期間内にタイムボックスを構築して仕様設計からリリースまで一通りの行程を迅速に行う開発方法です。
KPT法
KPT法とは、振り返りの手法のひとつです。「keep（成果がある継続事項）」「problem（解決が必要な課題）」「try（次に実施する事項）」の頭文字をとってKPT（ケーピーティー・ケプト）と呼ばれています。アジャイル開発においてよく活用されている手法で、個人の業務や、プロジェクトチームを集めて全体で振り返りを行うケースなどに幅広く利用可能です。 KPT法では、現在の課題を洗い出して、問題解決に向けて次に実施する事項まで決定します。話し合いの場で課題の改善方法を具体的に決め、その結果をメンバー全員で共有できることから、課題の早期発見と解決が期待できます。メンバー全員から意見を集めて議論を行う手法なのでコミュニケーションの円滑化につながり、有益な情報の共有も可能です。 KPT法は、「keep」「problem」「try」のそれぞれのセクションに全員で意見を出して、書き出していく方法です。「keep」には「できたこと」をまとめ、「problem」には「発生した問題とその原因・考え方」を洗い出して個人の考えも確認していきます。「try」では「problem」の内容をもとに「改善のためにチャレンジしたいこと」を具体的に決めることが大切です。KPT法で繰り返し振り返りを行うことにより、課題が解消してより効果的な改善策の実現につなげられます。
ベロシティ
ベロシティとはアジャイル・スクラムのチームが１スプリント内で作業できる平均的な作業量を表す指標です。 基本的にはストーリーポイント数（作業完了に必要な全体見積りを示す測定単位）で表現します。
ベロシティはなぜ必要か？
ベロシティを用いることで、チームがどれくらいの速さでバックログを処理できるかを予測することができます。 そのためベロシティは、開発完了見込みの時期予測や、次のスプリントでどれくらいの作業に対応できそうか検討する際の参考値として利用することができます。
またベロシティはそのチームが1スプリントに実施できた作業量の値であるため、ベロシティが安定してきたり、上昇傾向にあるケースはチームが成長しているという数値根拠にもなりえます。
スクラムの役割（ロール）の特徴
プロダクトオーナー
何を開発するか決める人 開発への投資に対する効果（ROI）を最大にすることに責任をもつ。チームに最も価値の高いソフトウェアを開発してもらうために、プロダクトに必要な機能を定義し、その機能を順位づけする。機能がプロダクトバックログというリストになっている。バックログへの追加、削除、順位づけは、プロダクトオーナーに最終的な責任がある。また、プロダクトオーナーには、開発チームに機能を説明して理解してもらう責任がある。もちろん、プロダクトのビジョンを示すことも大切な仕事である。
開発チーム
実際に開発作業に携わる人々 実際に開発を行うチームのことで、開発者たちを指す。従来型では、役割ごとに、タスクや役割が決まっているのが一般的である。スクラムでは、ビジネスアナリスト、プログラマー、テスター、アーキテ クト、デザイナーなどの明示的な区分けはない。個人の専門分野はあってよく、むしろ強みを持ち寄り、その垣根を超えて貢献しあう。機能横断的な様々な技能を持った人がプロダクトを中心に集まり、自律的に行動する。開発チームはバックログに入っている項目を完了状態にし、プロダクトの価値を高めていくことに責任を持つ。
スクラムマスター
全体を支援・マネジメントする人 スクラムマスターはスクラム全体をうまく回すことに責任を持つ、キーパーソンといえる。スクラムチーム全体が自律的に協働できるように、場作りをするファシリテーター的な役割を担う。ときにはコーチとなってメンバーの相談に乗ったり、開発チームが抱えている問題を取り除いたりする。
スクラムチーム全体をマネジメントするが、コントロール型の管理を行うのではなく、チームを支援す る役割を担う。サーバントリーダー（奉仕型のリーダー）といえ、開発チームを外部の割り込みから 守り、チームの障害を取り除くために外部との交渉を行う。
開発のやり方に関する決定はスクラムマスターではなく、開発チームが行う。スクラムマスターが細か い指示を出すのではなく、自分たちで決めながら動く自律したチームを作ることが、生産性をあげる 鍵となる。
ウォークスルー
ウォークスルーとは、会議室などで参加者が机上でシミュレーションする形で、欠陥を発見していくレビュー手法です。
ウォークスルーは、あらかじめ日程を決めて実施するものではなく、開発作業の開始直後や、作業が行き詰まったときなどに、レビュー対象物の作成者自身がプロジェクトメンバーに声をかけて自主的に実施します。正式な議事録はとらず、参加者が自由に内容を検討していくカジュアルな進行が特徴です。
FTA（故障の木解析）
FTAとは「Fault Tree Analysis」の略で、「故障の木解析」と呼ばれています。製品や工程の安全性や信頼性を保証するうえで、発生することが望ましくない「トップ事象：TE（Top Event）」を定め、その事象の発生要因となる下位事象を一次要因、二次要因と深掘りしながら、トップダウン形式で発生防止対策を決定する解析手法です。
エクストリームプログラミング
エクストリームプログラミングは、アジャイル開発における開発手法の１つです。略してXPとも呼ばれます。
アジャイル開発とは、最初に綿密な計画を立てず、臨機応変に進める開発方法のことです。設計・実装・テストを短期間で何度も繰り返しながら、顧客の意見や要望を都度取り入れて開発を進めます。設計・実装・テストの１サイクルをイテレーションと呼びます。
ただし、闇雲に開発を進めてもうまくいきません。そこで、アジャイル開発の指針となる手法があります。その代表格がスクラムです。エクストリームプログラミングはスクラムほどではありませんが、アジャイル開発手法として知られています。スクラムが勢いよく製品を作る手法であるのに対し、エクストリームプログラミングは継続的な成長に主眼を置いています。
テスト後に実装を行う「テスト駆動開発」
テスト駆動開発とは、プログラムの実装よりもテストコードを先に作成することです。それにより、求められる機能が洗い出され、シンプルな設計が実現します。
テストの通過を目標に開発を行えば、仕様変更などによる開発途中のブレを最小限に抑えられるでしょう。なお、テストはユニットテストと受け入れテストからなり、どちらのテストも自動化が望ましいです。
２人１組で行う「ペアプログラミング」
ペアプログラミングは、２人１組でプログラミングを行うことです。１人がコードを記述し、もう１人はそれを確認・補佐します。
記述しながら確認を行うと、細々とした問題をその場で解決できるメリットがあります。また、記述されたコードを把握している人物が２人いるので、その後の問題発生時にも迅速な対応が可能になるでしょう。
内部構造を整える「リファクタリング」
リファクタリングとは、完成したコードをわかりやすく書き換えることです。外部の動作を変えずに、内部構造だけを変更します。同じ動作をするコードでも、わかりやすいものに変換されるので、メンテナンス性の向上や不具合の発生頻度の低下が期待できます。
必要なコードだけを記述する「YAGNI」
YANGIは「You Aren't Going to Need It」の略で「今必要なことだけをする」という意味です。つまり、必要なコードのみを記述することを意味します。
モジュール結合度
結合度が弱い順に並べると下記のようになります。
1 データ結合
引数で単純なデータを渡すパターン
2 スタンプ結合
引数で構造体などのオブジェクトを渡すパターン
3 制御結合
引数の種類によって、メソッドの内の処理が変わるパターン
4 外部結合
単一のグローバルデータを参照しているパターン
5 共通結合
複数のグローバルデータを参照しているパターン
6 内容結合
他のオブジェクトの内部を参照しているパターン
アクティビティ図
アクティビティ図とはUML（統一モデリング言語）の一種で「システム実行の流れと条件分岐」を図解したものです。具体的には、ある作業の開始から終了までの機能を、実行される順序どおりに記述します。
システムの流れを記述するのがUMLですが、アクティビティ図では「実体の制御の流れ」について描写しています。実体の制御とは「どのような行動（アクティビティ）が発生するか」を指します。よってアクティビティ図はほかのUML図に比べ「どのような行動が発生するのか」を視覚的に理解しやすいです。
システム開発の目的は「クライアントの業務効率化」が多いので、アクティビティ図を作成しておけば、システム開発メンバーがクライアントの仕事内容を理解しやすくなります。その結果、クライアントが求めていた機能を備えたシステムを正確に実装することができます。
バーンダウンチャート
バーンダウンチャートとは、プロジェクトの進捗状況を可視化し分かりやすくしたグラフです。縦軸にタスク量、横軸に時間、残りのタスク量を線グラフで表します。
チャートは「実績線」「計画線」「理想線」の3つの線で表されます。3つの線の位置関係から、進捗状況や課題の有無などを読み解きます。
