アジャイル初心者です。現場で知らない用語が飛び交っていてその度ググるのが大変なのでまとめました。
主に『アジャイルサムライ』と『スクラム実践入門』を参考にしています。本から得た情報なので、実際には使われない用語とかも含んでいる恐れがあります。
今後もチマチマ追記していこうと思います。
あるといいなリスト
必須ではないが、実装できたらいいなというストーリーのリスト。顧客が途中で予定にないストーリーを差し込むか迷っているときは、あるといいなリストにとりあえず入れておく。余裕があれば実装する。
イテレーション
開発サイクルの単位。スクラム開発ではスプリントと呼ぶ。1 - 4週間で設定されることが多い。
プロダクトバックログから拾ってきたストーリー（設計、実装、テストまで）をこの中で完了させていく。
イテレーションの最初にプランニング、最後に振り返りをそれぞれ行う。
イテレーション計画ミーティング
次回のイテレーションの計画を立てるミーティング。スクラムではスプリントプランニング。
イテレーション・ゼロ
プロジェクトの最初のイテレーション、もしくはプロジェクトを始める前のイテレーション。実際の準備作業を行うイテレーション。スクラムではスプリントゼロと呼ぶ。
ツールのセットアップ、リポジトリの用意、開発環境と本番環境の準備、ビルドやテストの自動化環境の構築など。
インクリメント
スクラム用語。いつでもリリース可能な状態のプロダクト。
インセプションデッキ
プロジェクトの開始時にプロジェクトの方向性を決めるために使用するツール。『アジャイルサムライ』では10の課題から構成された例が挙げられている。やってみた結果は、壁に貼り出していつでも見られるようにしておく。
我われはなぜここにいるのか？
これから始まろうとしているプロジェクトはなんのためにあるのか、我われチームは何を解決するのか、という質問に対する簡潔な答えを用意する。この時点で顧客の業務の現場なども把握しておく。
エレベーターピッチを作る
エレベーターピッチとは、たまたまエレベーターに同乗したベンチャーキャピタルの関係者に対して、自分の事業をエレベーターに乗っているたった30秒間で説明しても資金提供を得られるような、簡潔に事業の魅力を伝えるプレゼンのこと。
余計な内容は盛り込まず、端的にプロダクトの本質を表すプレゼン内容を考える。
パッケージデザインを作る
文字通り、プロダクトのパッケージデザインをつくる。プロダクトのフィーチャをユーザー目線で考え、それをキャッチコピーに落とし込み、パッケージの絵を自分で描いてみる。
やらないことリストを作る
なんとなくやったほうがいいっぽいと考えられていることを、「やること」「やらないこと」「あとで決める」の3項目に仕分けする。今回のプロジェクトでなにをやるべきなのかが明確になる。いまやるべきなのかやらないべきなのかが決められないものは「あとで決める」に入れて、あとでどうするか決める。
「ご近所さん」を探せ
チーム外のプロジェクト関係者に会って信頼関係を築いておく。ライター、運用、インフラ、セキュリティ、などの、チームメンバーではないが関係する人たちに会って、コーヒーとドーナツを奢ったりするらしい。
解決策を描く
プロジェクトが解決するべき問題の解決策を図に描く。具体的には、プロジェクトで使用するツールやアーキテクチャを図にして検討する。そしてチームのみんなで合意形成をする。多分サーバー構成とか使用するミドルウェアとかをここで考える。
夜も眠れなくなるような問題は何だろう？
プロジェクトに関して、夜も眠れなくなる問題は何かを考える。具体的には、カネの問題や、スケジュールの問題や、チームメンバーの問題など。要するにリスクを考えておくということである。途中で炎上しそうな問題を先にこのタイミングで出して潰しておく。
期間を見極める
大雑把なスケジュールの予測を立てる。スケジュールには、受け入れテストから運営トレーニング期間なども全て含めておく。
正確なスケジュールを決めるためには、イテレーションを回してみて実際のベロシティを計る必要がある。
何を諦めるのかはっきりさせる
プロジェクトには時間、予算、品質、スコープ（やるべきことの範囲）などの要件が複数あるが、それらの優先度を決める必要がある。
具体的には、トレードオフ・スライダーというものを使用する。（トレードオフ・スライダーの具体例）
実際には、時間は伸ばすべきではないし、予算が増えることは期待できないし、品質を犠牲にするのは論外。ゆえに、プロジェクトが炎上しそうなときはスコープを動かす。つまり、やるべきことを減らしたり調整したりする。
何がどれだけ必要なのか
ここまででプロジェクトのことは大体わかってきている。ここでやるべきなのは、
- チームのメンバーにどういう人が何人必要なのか
- 何に対して時間がどれだけ必要なのか
- 資金が何に対してどれだけ必要なのか
上記を見積もること。そしてこれらを顧客に説明すること。
また、顧客に対して、顧客がチームの一員、つまり「プロダクトオーナー」、「オンサイト顧客」であることを説明する。つまり顧客にもしっかりプロジェクトに参加してもらうことを要求する。
エクストリームプログラミング
アジャイル開発手法の一種。ペアプログラミングで実装したりするらしい。
エピック
完了まで数週間以上かかりそうなストーリーはエピックと呼ぶ。実際に作業に取り掛かるときは複数のストーリーに分割する。
オンサイト顧客
エクストリームプログラミングでは、チームの一員としての顧客のことをオンサイト顧客と呼ぶ。オンサイト(On-site)とは、その場にいる、という意味。
開発チーム
チームから、顧客（プロダクトオーナー）とコーチ（スクラムマスター）専任者を除いたメンバー。手を動かす人たち。
カンバン
タスクの現在の進行状況を「見える化」して、生産性を高める手法。最近のTODOアプリとかプロジェクト管理ツールではこれを採用しているのが多い。「TODO」「進行中」「DONE」の様なステートがあって、タスクがいまどんな状態かを把握できるようにする。
完了
アジャイルでは完了の定義が決まっている。完了とは、テストまで終わったちゃんと動くソフトウェアがある、という状態を意味する。完了済みということは、その機能はいつでもリリース可能だということ。
コーチ
アジャイルの考え方をチームメンバーに浸透させる役割の人。メンバーがアジャイルに慣れているならコーチはいなくても可。
三角測量
ストーリーポイントの見積もり技法。大中小の基準となるストーリーを選び出し、それらとの比較によってストーリーポイントを見積もる。
自己組織化
チームのメンバーが自律的に目標や計画を立てて、能動的に学習と成長をし続けている状態のこと。アジャイルではチームの決まりきった理想像は存在しないため、チームの理想像はチーム自身で作り上げていく必要がある。
ジャストインタイム分析
ユーザーストーリーを実装するタイミングで、そのストーリーを詳細に分析する。機能の仕様の詳細を決める。
実際にストーリーを実装をするイテレーションの一つ前のイテレーションで分析を行う。
ジャストインタイム分析の利点は、
- 最新の情報に基づいて分析できる
- プロジェクトの進行中に行うことで、分析がうまくなっている
- 手戻りを防ぐことができる
とされている。
ショーケース
実装が終わった機能を顧客にデモで見せてフィードバックをもらうこと。
スクラム
アジャイル開発手法の一種。ラグビーのスクラムから来ている。エクストリーム・プログラミングとは用語系が少し異なる。
「複雑で変化の激しい問題に対応する」というところに力点がある。
スクラムイベント
下記のイベントのこと。
- スプリント
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
スクラムマスター
スクラムではコーチとマネージャを合わせたようなスクラムマスターという役割がある。チーム内のコミュニケーションが円滑になるために頑張る。
ストーリー収集ワークショップ
顧客と話してユーザーストーリーを聞き出し、フィーチャをなるべく広く集めること。
図を沢山描くことがポイントらしい。
ストーリーボード
カンバン方式風のボード。現在のイテレーションで実装するストーリーを縦に並べて、横軸のステータス（「TODO」、「作業中」、「レビュー中」、「完了」など）を動かしていく。
スプリント
イテレーションのことをスクラムではスプリントと呼ぶ。
スプリントゴール
そのスプリントで達成したい内容。
スプリントゼロ
スクラム用語。エクストリームプログラミングで言うイテレーション・ゼロ。インセプションデッキの作成もここで行う。
スプリントバックログ
スクラム用語。そのスプリント内で達成すべきタスクの一覧と、そのステータスを可視化したもの。カンバン方式風の表が用いられる。
スプリントプランニング
スプリント開始時に行う。このスプリントで何ができるのか、どうやって達成するか、を確認するミーティング。
スプリントが一ヶ月であれば最大8時間、一週間であれば1〜2時間くらい行うらしい。
スプリントレトロスペクティブ
スクラム用語。スプリントレビューの後に行うミーティング。スプリントの開発プロセスでどんな問題があったか確認し改善策を考える。スクラムマスターの責任の範疇。KPTなどを使う。
スプリントが1ヶ月であれば3時間、1週間であれば30分〜1時間が目安らしい。開発チームとスクラムマスターで開催するが、プロダクトオーナーも参加したほうが良いとされる。
スプリントレビュー
スクラム用語。スプリントの最終日に、スプリントで何が実現できて何ができなかったのか確認して改善策を考えるミーティング。スプリントレトロスペクティブが開発プロセスについて問題点を考えるのに対し、スプリントレビューはプロダクトの問題点を考える。プロダクトオーナーの責任の範疇。
スプリントが1ヶ月であれば4時間、1週間であれば1時間程度が目安らしい。動くソフトウェアのデモも行う。なので、ステークホルダーも参加するのが望ましい。
タイムボックス
時間のこと。タイムボックスと呼ぶのは、時間の区切りを意識したいかららしい。こちらの記事が参考になる。
チーム
チームがやること
非アジャイルな開発では、担当領域をまたいでチームが作られることはない。例えば、マネージメントについてはマネージャーが、デザインについてはデザイナーが、開発についてはプログラマーが、テストについてはテスターが、それぞれ専門的に担当する。プログラマーがマネージメントをしたり、デザイナーがテストをしたりはしない。
これに対してアジャイルのチームは、マネージメントもデザインも開発もテストも、一つのチームでやる。縦割りではなく、チームが一丸となって設計からテストまでを完了させる。
同じ空間で働くのが理想
アジャイルのチームはリモートよりも同じ空間で仕事をするのが理想とされる。チームの意思疎通がしやすいから。遠隔地にいても、テレビ会議のシステムを使ってコミュニケーションを多めにとる必要がある。
顧客もチームの一員
顧客もチームの一員で、顧客の役割も用意されている。具体的には、チームに対してフィードバックを与えるという役割を担うのが顧客。
エクストリームプログラミングではチームの一員としての顧客をオンサイト顧客と呼ぶ。スクラムではプロダクトオーナーと呼ぶ。
デイリースクラム
スクラム用語。朝回とか夕会とか呼ばれている、毎日行うミーティング。デイリースタンドアップに似ているが、デイリースクラムの場合は15分を目安にするらしい。報告の内容も、昨日やったことと今日やること（今日やったことと明日やること）に加え、今困っていることも正直に言ったり、スプリントゴールが達成できそうかどうかも確認する。
時間内に終わらなければ参加者を絞って二次会をする。
デイリースタンドアップ
朝回とか夕会とか呼ばれている、毎日行うミーティング。手短に5 - 10分で終わらせるため、立ったままでやる。自分が昨日やったことと今日やること（今日やったことと明日やること）や、共有すべき重要な情報を共有する。
バーンアップチャート
バーンダウンチャートとは逆に、ストーリーを完了したら縦軸に終わった作業を積んでいく。右肩上がりのチャートになる。
バーンダウンチャート
チームがどのくらいの速度でストーリーを実装しているかを目で見てわかるようにした図。縦軸に残っている作業の総量、横軸に時間をとる。イテレーションごとに、完了したストーリーの数を記録していく。時間が経過するほど、残りの作業がどんどん減っていく様子がわかる。つまり、右肩下がりのチャートになる。
日毎に記録していくバーンダウンチャートもある。
フィーチャ
プロダクトの機能をユーザー目線で記述したもの。
フィーチャセット
プロジェクトの中核をなすフィーチャのまとまり。
不確実性コーン
プロジェクトが事前の見積もり通りには進行しないことを言い表した言葉。『ソフトウェア見積り 人月の暗黙知を解き明かす（スティーブ・マコネル著）』に由来する語。
プランニングポーカー
ストーリーポイントの見積もり技法。あるストーリーに対してチームメンバーの各々がポイントを見積もってみる。ポイントの差異があれば話し合いをして、正しいポイントを見積もる。
多数派の意見が優先されるべきではなく、少数派であっても異なる意見があった場合に話し合いをして、正しいポイント見積もりを行えるようにする。
（ミニ）ふりかえり
今回のイテレーションをふりかえり、次回のイテレーションで改善できる余地を探す。
良かったこと探し（特に他人の良かったことを褒める）をまずやって、そのあと改善点探しをする。
人格攻撃をしてはいけない。みんな各々できる限り頑張ったという前提で話す。
プロジェクトインセプション
プロジェクトを開始する際にプロジェクトの方向付けをすること。インセプションデッキを使う。
プロジェクトコミュニティ
チームだけでなく、より広範囲にプロジェクトに関わる関係者全員を含めてプロジェクトコミュニティと呼ぶ。
プロダクトオーナー
スクラムではチームの一員としての顧客のことをプロダクトオーナーと呼ぶ。プロダクトについての決定権を持っていることが大事。それがない場合は決定権を持っているステークホルダーとの調整が必要になり大変である。
プロダクトバックログ
プロジェクトの中で実現したいことの一覧表。この中から選んでイテレーションの中に積んでいく。マスターストーリーリストとも呼ぶらしい。
1-6ヶ月の期間で完了させられるストーリーがリストアップされている。
ペルソナ
開発中のシステムの、具体的な利用者像。
ベロシティ
1回のイテレーションでチームが完了させることのできるストーリー（ポイント）の量。要するにチームの開発速度のこと。
ベロシティは最初からわかっているわけではないので、イテレーションを回しながら計測していく。計測したベロシティを元にだんだん正確な計画をたてることができるようになるという寸法。
ペーパープロトタイプ
UIのプロトタイプを紙に描いたもの。手軽に描けるから沢山描いてみるのがいいらしい。
ポイント（ストーリーポイント）
アジャイルでは工数を相対的に見積もる。ウォーターフォール的な開発では工数を「１人月」とか「１人日」とかで見積もるが、アジャイルではポイントという単位を用いる。
ポイントは、複数のストーリーを比較して相対的に見積もる。AというストーリーとBというストーリーを比較した場合に、Aの方がBに比べて3倍工数がかかりそうであれば、Aにかかる工数は3ポイントであり、Bにかかる工数は1ポイント。
ポイントが相対的な単位となっている理由は、人間は絶対数の見積もりよりも相対的な見積もりのほうがうまくできる、という研究結果に基づいているらしい。（どこの何という研究なのか知りたいところ）
ポイントには小数点や半端な数は使用せず、1、3、5という数字や、フィボナッチ数を使う事が多い。その理由は、小数点を含んだ数や半端な数はポイント見積もりがあたかも精密な見積もりであるかのように錯覚させてしまうから。
マシュマロ・チャレンジ
チームの仲間意識醸成のために行うゲーム。マシュマロ・チャレンジについて詳しく説明してあるページを参照。
ユニットテスト
アジャイルではユニットテストは自動化する。新しい実装をするときは、テストを先に書く。そのあとに、テストをパスする実装を書く。
ユーザーストーリー（ストーリー）
顧客がプロジェクトに期待している機能、フィーチャのこと。これらはポストイットみたいな小さな紙に端的に（キーワードだけを）書いて利用する。技術用語や専門用語を使うのではなく、顧客目線で内容を書く。
例:
「AuthControllerとAuthModelを作成し、authテーブルを作成する」→「ログイン機能を追加する」
また、ユーザーストーリーはある程度の機能の一まとまりとして書く。
例：
「ログイン画面を作る」「ユーザーをDB管理できるようにする」「認証トークン等を保存するテーブルを作る」→「ユーザーログイン機能を作る」
ユーザーストーリーには他にも下記の特徴がある。
- 機能的に互いに独立している（他の機能に依存していない）
- 価値がある
- 交渉の余地がある（内容を調整可能な幅が持たせてあること）
- テストできる
- 小さい（イテレーションの範囲に収まる）
- 見積もれる
ユーザーストーリーを書き出したからといってすぐにそれに着手するのではなく、プロダクトバックログに積んでおいて、良きタイミングで着手する。
単にストーリーとも言う。
理想日
工数の見積もりをストーリーポイントで行う方法以外に、理想日という単位を用いる方法もある。理想日とは、1日8時間みっちり作業時間を確保できた場合の作業量のこと。
リファインメント
スプリントプランニングの準備を行う。前の日までに行う。具体的には、プロダクトバックログを整理する。
リファクタリング
コードの良くない実装をイケてるコードに改善して技術的負債を返済していくこと。変数名やメソッド名が悪いとか、重複コードが多いとか、読みにくいとか、そういうコードを書き換える。これによって保守性が高まる。
本来リファクタリングは随時行われるべきなのだが、エンジニアの心に禍根を残す恐れや、動いているコードを触りたくない顧客の意向から、技術的負債が溜まっていく一方であることも多い。そういう現場では、既存のダメなコードを土台として歪なコードが次々と追加されてゆくので、そびえ立つクソの山が構築されてゆく。
リリース
プロダクトバックログから実装可能なストーリーを拾い上げたサブセットのこと。MMF(Minimal Marketable Featrue Set)と呼ばれることもあるらしい。訳すると、最小単位の市場価値のある機能のまとまり。
リリーススプリント
リリースのための作業を行うスプリント。テストが終わってない場合はテストをやったり、ドキュメントが足りない場合はドキュメントを作ったりする。準備が整ったらリリースをする。基本的に機能の追加などはしない。
スプリント内に実装からテストまで終えていつでもリリースできる状態にしておけるのが理想だが、そうもいかない場合はリリーススプリントを作る。
リリースボード
チームがストーリーをどれだけ完了させているかを可視化したボード。壁に貼り出していつでも見られるようにしておく。
リーン
アジャイル開発手法の一種。トヨタの生産方式（カンバンとか）に影響を受けているらしい。
リーンキャンバス
プロダクトの具体的なイメージを固めるために使うツール。「リーンキャンバス」でGoogle画像検索をすると大体どういうものかわかる。
KPT
ケプトもしくはケーピーティーと読む。良かったこと（Keep）、困ったこと（Problem）、改善策（Try）の三種類の項目を挙げていく。それについて話し合う。
WIP
Work In Progress（仕掛り、進行中の作業）のこと。カンバン方式では、WIPに置けるタスクの数に上限を設ける（同時進行できるタスクの数に上限を設けるということ）。
