はじめに
いきなり質問ですいません。
「アジャイルの反対」ってなんでしょう？
・・・
・・・
・・・
もし、「ゆっくり」とか「ウォーターフォール」みたいな単語が頭に浮かんだ方はこの記事で学べることが多くあるかもしれません。
質問の答えは最後に記載しています。
参考文献
アジャイルソフトウェア開発宣言
アジャイル宣言の背後にある原則
スクラムガイド
スクラム入門
Scrum Boot Camp
認定スクラムマスター研修
アジャイル
スクラムの前にアジャイルに触れておく。
アジャイルとは
アジャイルとは、より良い解決方法を探している状態である。
"状態"なので、よくある「アジャイル開発をやろう！」というのはおかしくて、振り返ってみて「あれはアジャイルだったなー」ってなるものだ。"Don't just do agile, be agile."という名言があるくらい。だから、極端な事を言うと、より良い方法を探してたどり着いた結果がウォーターフォールだったとしても、それはアジャイルなのである。
"agile"を辞書で調べると"迅速な"とか"俊敏な"とかがでてくるため、「アジャイルとは顧客の要望の変化に迅速にこたえるための考え方だ」などと誤解されることが多いが、それは単なるアジャイルの1つの側面にすぎない。
アジャイル自体の歴史は1950年代までさかのぼるが、いわゆる現代の我々が言葉にする"アジャイル"は、2001年に作成されたアジャイルマニフェスト（アジャイルソフトウェア開発宣言、アジャイル宣言の背後にある原則）だ。アジャイルとして決まっていることは実はこれだけ。下に概要をまとめる。
アジャイルソフトウェア開発宣言
左よりも右に価値を置く。（決して左が要らないとは言っていない。）
プロセスやツール ＜ 個人と対話
包括的なドキュメント ＜ 動くソフトウェア
契約交渉 ＜ 顧客との対話
計画に従う ＜ 変化への対応
アジャイル宣言の背後にある原則（抜粋）
要求の変更は歓迎します。
数週間から3か月という短い間隔でリリースします。
ビジネス側の人間と開発側の人間は毎日一緒に働かなければなりません。
face-to-faceのコミュニケーションを重視します。
動くソフトウェアこそが進捗の最も重要な尺度です。
一定の開発ペースを維持できるようにしなければなりません。
シンプルさ（無駄なく作る）が本質です。
自己組織的なチームである必要があります。
もっと効率的な方法をみつけるために定期的に振り返りそれに基づいて自分たちのやり方を調整します。
スクラム
スクラムとは
スクラムとは、経験主義にもとづき反復的かつ漸進的にプロセスを進め、現状を見える化するフレームワークである。
ソフトウェア開発以外でもスクラムは活用できる。
3本柱
スクラムの3本柱は透明性と検査と適応である。
最初は抽象的で理解しにくい部分かもしれないが、この3本柱を意識しながらスクラムを実践することが、スクラムの本質を理解して成功させるために必要なことである。ただ、なんとなく決められたイベントをこなして、なんとなく作成物を作るだけではスクラムの高い効果を得ることは難しい。
透明性
スクラムチームの現状や問題点を見える化すること。
検査
見える化により問題点を見つけること。
適応
スクラムチームに問題があった場合に、改善策を考えて対処すること。
5つの価値基準（確約、勇気、集中、公開、尊敬）
個人はスクラムチームのゴールの達成を確約しなければならない。
スクラムチームのメンバーは正しいことをする勇気を持ち、困難な問題に取り組まなければいけない。
全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない。
スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を公開することに合意しなければいけない。
スクラムチームのメンバーは、お互いを能力のある独立した個人として尊敬しなければいけない。
なんだか小学校のクラスルールみたいですが、全てを実現するって意外と難しいものです。
この5つの価値基準のどれかでも満たしていないケースを発見したら、発見した人は妨害リストにそれを追加するべきである。
スクラムチーム
スクラムチームは自己組織化されており、機能横断的である。
スクラムチームはプロダクトオーナー、スクラムマスター、開発チームの3つのロールをそれぞれ有する複数のメンバから構成される。
プロダクトオーナーとスクラムマスターのロールの兼任は禁止されているが、それ以外は禁止されていない。
自己組織化
スクラムチームが誰かに管理されておらず、自分たちで自分たちを管理している状態。
例えば開発チームの場合、進捗管理、課題管理、改善、スプリントバックログの選択などを自分たちで適切に行っていればそれは自己組織化されていると言える。
機能横断的
スクラムチーム外に頼らずにゴールを達成できる状態。
例えば開発チームの場合、プロダクトを開発するための全て（設計、コーディング、試験、環境構築、ドキュメント作成など）が開発チーム内でのスキルセットのみで解決されていれば、それは機能横断的なチームであると言える。
ロール
プロダクトオーナー(PO)
ミッション
プロダクトのROIを最大化すること。
POは開発チームへの作業依頼権限とスプリントの中止権限を持つ唯一の存在である。
主にやること
- プロダクトバックログアイテム(PBI)の管理
- リリース計画策定
- 市場調査
- ステークホルダとの対話
- 開発チームとの対話
- 予算管理
- スプリントレビューで"DONEの定義"にしたがって受け入れ判断をする
注意点
POを複数人で実施することも可能だが、その場合は代表者を1人決めておく必要がある。
スクラムマスター（SM）
ミッション
スクラムチームにスクラムの理論を理解してもらい、それを正しく実践するように促すこと。
"促す"とは具体的には、スクラムチームの誰かがスクラムのプロセスとして正しくないことをした際に「それで大丈夫だろうか、問題ないだろうか」と問題提議するなどである。(なんか、学校の先生みたい)
SMはサーバントリーダー（メンバーが成果をあげるために支援や奉仕を行うリーダー）である。また、外部からの不要な干渉を避けるためにスクラムチームを守る義務がある。そのため、社内のステークホルダーや顧客（SIerであれば）に楯突かなければならない場面もある。
主にやること
- 妨害リストの管理
- 妨害の除去
- POのサポート
- 開発チームのサポート
注意点
チームが自己組織化するために、SMはメンバーに直接的な指示（タスク割り当てなど）や管理（進捗管理など）をしてはいけない。従来のプロジェクトマネージャ（PM）にSMを重ねてしまう人が多いが、それは絶対にやってはいけないことだ。
スクラムにはPMは存在しない。ただし、それはPMがやっていた仕事そのものがなくなったわけでない。POとSMと開発の3つのロールに分担されているのである。
開発チームができるだけ開発業務に専念できるように、妨害の除去として、開発以外の雑用をやることも多い。
本来、スクラムチームが成熟してくるとSMはやることがなくなってくるはずである。
その場合は、ロールの兼任をするのも一つの方法だ。（本当にそんな日がやってくればの話だが。。。）
開発チーム
ミッション
インクリメント（成果物）を完成させること
主にやること
- 開発
- プロダクトバックログの追加
- 妨害リストの追加
注意点
開発チームは自己組織化されており、外部から仕事の進め方やタスクを指示されるようなことがあってはならない。
1つの開発チームは3~9人で構成されなければならない。
それより少ないと機能横断的でなくなる可能性が高くなるためNG。多すぎると調整が大変になってしまうためNG。多すぎる場合は別のスクラムチームをもう1つ作るべき。
開発チーム内で年齢や役職、会社の違いがあったとしても全員フラットな関係でなければならない。
開発チームに専門能力（JenkinsとかUIの芸術部分でありがちだよね？）の高いメンバーがいて、その分野ではその人に頼りがちだけど、そこで問題が起きたとしてもそれはそのメンバーだけの責任でなく開発メンバー全員の責任であることに注意する。
作成物
作成物は透明性と検査と適応の機会を提供する。
全ての作成物は全員に見える化されている必要がある。
プロダクトバックログ
プロダクトバックログとは、今後のプロダクトに必要なもの（新規機能追加、既存機能修正など）が優先度順に並べられた一覧である。
プロダクトバックログの構成要素それぞれをプロダクトバックログアイテム（PBI）と呼ぶ。
優先順位は顧客要求、市場調査結果、リスク対応、機能要件、非機能要件、依存関係などを考慮して最終的にPOが決定する。
POがプロダクトバックログの内容と優先順に責任を持つが、PBIの追加はスクラムチーム全員が行える。
これらのことから、プロダクトバックログはDEVとPOを繋ぐ接点とも言えます。
優先度が高いもの（1、2スプリント先くらいまで）ほどタスクレベルに分割可能なくらい詳細で、低いものほどアバウトなものにする。
優先度が低いものまで無理に詳細に記載すべきでない。なぜならば、作るかどうかも分からないものまで頑張って詳細化しても、結局必要なかったとかで無駄になる可能性があるからである。また、これはジャストアイディアを気軽に提案できるメリットもある。
ビジネス要求、市場、技術などの変化、新しいアイディアなどによりプロダクトバックログは常に変化する。
したがって、サービスが存在する限りプロダクトバックログは永遠に完成しない。
プロダクトバックログの書き方は自由だが、ユーザーストーリー形式とDONEの定義とストーリーポイントを書くフォーマットが一般的。
ユーザーストーリー形式
「〜として、〜したい。それは、〜だからだ。」を書きます。
これは、INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testableの頭文字をとったもの)を満たす必要があります。
Independent（独立している）
PBIはそれぞれが独立しているべきです。
内容が複数のプロダクトバックログに重複していたり密結合ではいけません。
Negotiable（交渉可能である）
PBIは結果は明確に決められているが、それの実現方法はDEVがPOと交渉して決めることができるべきです。
例えば、ソート機能が欲しいというプロダクトバックログがあったして、どのソートアルゴリズムを使用するかの決定はDEVが考えることができます。
Valuable（価値がある）
PBIはユーザやビジネスにとって価値があるべきです。
Estimable（見積もり可能である）
PBIはそれぞれが見積もり可能であるべきです。
内容が曖昧だったりそもそも仕様が確定していなければ見積もることはできません。
Small（適度に小さいべきである）
PBIは適度に小さい単位で用意されているべきである。
もしPBIが大きすぎると、それはIndependentやEstimableの問題を含んでいる可能性もあります。また、ストーリーポイントも大きな値となってしまい適切なベロシティを知ることが難しくなってしまいます。
Testable（テスト可能である）
PBIはテスト可能であるべきである。
テスト可能な単位でなければスプリントレビューでのデモを行うことも難しくなります。
DONEの定義
プロダクトバックログの完了定義である。
POのスプリントレビューでの受け入れ判断基準に使われたり、開発チームがインクリメントを作成する際のゴールになる。
機能要件だけでなく非機能要件、カバレッジ、必要であればドキュメントなどの完成も定義しておく。
スプリントバックログ
プロダクトバックログアイテムをタスクレベルに分割したものである。
スプリントバックログの構成要素をスプリントバックログアイテム（SBI）と呼ぶ。
スプリントプランニング第二部で開発チームにより作成される。
スプリント期間中での修正、追加、削除も可能である。
スプリントバックログの管理を行えるのは開発チームだけである。
規模や工数はバラバラで問題ないが、1つのスプリントバックログアイテムの見積もりは1日以下の大きさに分割すること。
スプリントバックログアイテムは"未着手"、"着手中"、"完了"などのいずれかのステータスがラベル付けされており、そのステータスが可視化されている必要がある。
JIRAでも付箋とホワイトボードによるアナログ方式でもどちらでも問題ない。
スプリントバックログの担当は開発チームが自分たちで決める。
自己組織化されているので、誰かに割り当てられるものではなく自ら挙手する。
設計、コーディング、テストコードの作成だけでなく、結合テストなどの実施、CI環境改良、ノウハウを残すなどもスプリントバックログとして分割するべきである。
妨害リスト
スクラムチームがスクラムを正しく実践する上で妨害になっていることを優先度順にリスト化したものである。
"妨害"とあるが、これはスクラムチーム外によるものだけでなく、スクラムチーム内によるものも対象である。
どのロールの人でも追加できるが、妨害リストの管理の責任者はSMである。
いつでも追加可能だが、特にデイリースクラムやスプリントレトロスペクティブで課題（妨害）の共有が行われやすい。
スプリント
スプリントの期間
スクラムではスプリントと呼ばれる1ヶ月以内の固定した開発期間を何度も繰り返す。1週間、2週間、1ヶ月のいずれかが一般的。
スプリント期間は固定である。つまり、第一スプリントは2週間、第二スプリントは1週間などと異なってはいけない。
たとえスプリント期間内に完了しなかったプロダクトバックログアイテムがあったとしても、スプリントを延長してはいけない。残ったものは次のスプリント以降に繰り越す。
特に開始曜日の決まりはない。月曜始まり金曜終わりは気分を入れ替えやすいし、火曜日始まりは金曜日や月曜日を有休にして連休取得しやすい。
スプリントの構成要素
スプリントは「スプリントプランニング」、「デイリースクラム」、「開発作業」、「プロダクトバックログリファインメント」、「スプリントレビュー」、「スプリントレトロスペクティブ」で構成される。
それぞれの詳細は後述。
スプリントの中止
緊急事態によりスプリントを続けることができなくなった、続ける必要がなくなった場合にスプリントは中止される。
スプリントの中止実行権限を持つのはPOだけである。
スプリントの中止はよっぽどのことが無い限り、行われるべきでない。開発チームのモチベーションを著しく落としてしまうからだ。中止された場合は、開発チームは会社のフロントで嘆きの儀式を行おう。
スプリント0
自己紹介、スクラム理論の勉強会（認識合わせ必須）、当面のプロダクトバックログの作成と共有、必要技術スキルの勉強会、開発環境構築などを行うスプリント開始前の準備期間のこと。必要期間はチームにより異なる。
リリーススプリント
インクリメントの統合テストや通常スプリントで残ったタスクを実施してリリースを行うための特別なスプリント。
原則、このスプリントは存在しません。
スプリント毎にリリース可能なものを作成するので、リリーススプリントが無いことが理想だが、そうでない場合に用意される。
リリーススプリントはPOがリリース準備が整ったと判断するまで続く。
イベント
イベントは規則性を生み、開発チームでイベント以外のミーティングができるだけ行われないようにする。
全てのイベントはタイムボックス化されている（何分とか、何時間までとかが決まっている）。もし、タイムボックスを超えてしまった場合、議論をそこで打ち切る必要はないが、タイムボックスを越してしまったという事実は妨害リストに追加したり、スプリントレトロスペクティブで話し合う必要がある。
イベントにより透明性の獲得と検査と適応が実施される。
スプリントプランニング
- いつ？⇒スプリントの最初
- 誰が？⇒全てのロールが参加する。ただし、第二部はPOは連絡がつく状態であれば参加しなくてもよい。
- 目的は？⇒「何」を「どのように」作るかを決定すること。
- どれくらい？⇒最大4時間（1スプリント2週間の場合）。
スプリントプランニングは第一部と第二部で構成される。
第一部
第一部では、ベロシティをもとに今回のスプリントで対応できそうな範囲でプロダクトバックログを開発チームが選択する。（POが選択してはいけない）
プロダクトバックログはリファインメントによってすでに見積もりがされている状態のはずだが、リファインメント後に新規追加されたプロダクトバックログアイテム（つまり見積もりがまだされていないもの）が含まれている場合は、この場でリファインメントを実施する。
第二部
第二部では、開発チームは選択したプロダクトバックログアイテムをスプリントバックログに分割し、タスクレベルに落とす。これにより、POとSMにどのようにプロダクトバックログアイテムを消化できるかを伝えられる状態になる。
分割したスプリントバックログに時間数を見積もり、その総計が1スプリントでのチームが開発できる時間をオーバーした場合は優先度の低いプロダクトバックログから外していく。逆に余裕がある場合なプロダクトバックログを追加する。
POの予想より多すぎたり少なすぎたりする場合は、開発チームとPOは話し合う。
開発チームは選択したプロダクトバックログアイテムを完了することに全力を注がなければならないが、完了することを約束するわけでない。なぜならば、見積もり時にはわからなかった技術的に困難な事象が発生することはよくあるからである。無謀な長期の残業は行わない。
1スプリントあたりのチームの開発時間数
これはスクラムで定義されているものではない。あくまで一例の計算方法。
下の公式の「オーバーヘッドを引いた割合」の存在理由は、開発チームはロボットではないため、イベント時間以外でも実際には開発しない時間があるからである。例えば、採用面接、直接開発には関係しない技術に関する議論、研修、タバコやコーヒーなどのリフレッシュ休憩時間、雑談などである。おおよそそのようなオーバーヘッドに割かれる割合は30%ほどである。
開発チームの人数×(1日の勤務時間数×スプリントの日数-イベントの時間数)×オーバーヘッドを引いた割合
例えば、開発チームが5人、1スプリント2週間、1日の勤務時間が8時間の場合は以下。
5人×(8時間×10日-15.5時間)×0.7=225.75時間
また、上記の計算式とは完全一致しないが、こちらの記事のキャパシティ計算が大変素晴らしいです。
デイリースクラム
- いつ？⇒毎日同じ時間（一般的には朝）
- どこで？⇒どこでもいいがいつも同じ場所
- 誰が？⇒開発メンバー。SMは必要に応じて参加する。POは見学（発言は基本的にNG）してもよい。
- 目的は？⇒開発チームの検査
- どれくらい？⇒最大15分
開発チームは各々が、昨日やったこと、今日やること、あれば課題（妨害）の共有を行う。
また、スプリントバックログのバーンダウンチャートなどを活用して、進捗確認を行う。
この時、SMが進捗管理をするのではなく開発メンバーが自分たちで進捗管理を行う（自己組織化）。
課題は共有に留めること！！
よくありがちなのは、課題の共有だけに留まらず、デイリースクラム内で解決方法まで議論してしまって、15分のタイムボックスを破ってしまうことだ。
課題の解決に関する議論はデイリースクラム後に関係者だけが話し合って、必要であればその結果を他のメンバーに共有するようにする。
毎日同じ時間と同じ場所で開催するのは、「いつだっけ？」、「どこだっけ？」という無駄をなくすため。
座りながらやると時間オーバーしがちだから、全員立ちながら行う。
SMはチームが未熟な場合、デイリースクラムを先導しても良いが、チームが成熟してきたら、一歩後ろから見守ったり、あえて参加せずに座りながら自分の作業をしているフリをして聞き耳を立てる程度でよいだろう。（進捗状況や妨害の確認のためにリスニングしておくのは必要。）
管理職の見学は避けたい。なぜならば、共有でなく管理職への報告になりがちで自己組織化が損なわれやすいのと、課題共有がしにくい雰囲気になりやすいからである。
もし管理職にエスカレーションするべき課題があるならば、デイリースクラム後に報告すること。
プロダクトバックログリファインメント
- いつ？⇒スプリント期間中であればいつでも良い。
- 誰が？⇒全てのロール
- 目的は？⇒プロダクトバックログの透明性の獲得
- どれくらい？⇒最大1日(8h)
POはプロダクトバックログの説明（前回からの変更分、追加分、削除分、詳細決定部分、順序変更部分など）を行う。
リファインメントの対象は、次のスプリントあるいはさらにその次のスプリントで開発対象となりそうなくらいの範囲となる。優先度低いプロダクトバックログの説明までは行う必要はない。本当に実施するかも不透明だし変更も発生しやすいため。
開発チームはプロダクトバックログへの意見（追加アイディアや順序変更や質問など）、新しいプロダクトバックログアイテムの見積もり、必要であれば再見積もりを行う。
プランニングポーカー
プロダクトバックログの見積もりには"プランニングポーカー"と呼ばれる手法が一般的に使われる。
プランニングポーカーは、開発チーム全員がフィボナッチ数列（0, 0.5, 1, 2, 3, 5, 8, 13,...∞）の値が書かれたカードを持ち、プロダクトバックログアイテムごとに「いっせーのせ！」でカード（見積もり）を提示する。
この見積もりは単位のない"相対見積もり"である。例えば基準にしやすい機能（しばしばログイン機能が用いられるが）を"2"として、それと比較した難しさを相対見積もりとして決定する。
当然ながら、人によってポーカーの出す値は異なる。基本的には、一番大きい値をだした人と小さい値をだした人を中心になぜその値をだしたのかを議論する。ここでたとえ外れた値を出したひとを嘲笑するようなことはしてはいけない。もしかしたらその人しか気づかなかった隠れた要素があったのかもしれないし、まだチームにはいったばかりよくわかっていないニューカマーかもしれない。
値があまりにも分散している場合は、議論したあと、再度カードを使って見積もりし直す。
この議論により、ある特定の人しか気づかなかった情報がチームに共有され、共通理解を得られる可能性がある。
一つ一つの見積もりにはそこまで大きな時間をかけてはいけない。少なくとも全員が同じ値になるまでプランニングポーカーをやり続けるのは愚行である。
見積もりの値が似たような値で均等に分散したとき（例えば5が3人で8が3人の場合）は、悲観的に考えて大きい値（ここでは8）をストーリポイントとして計算したほうがよい。
見積もりってなんか殺伐としがちだけど、カードを使うとなぜかみんなにこにこしながら話し合える。
スプリントレビュー
- いつ？⇒スプリントの終わり
- 誰が？⇒全てのロールとPOが招待した重要な関係者（ステークホルダーなど）
- 目的は？⇒インクリメントの検査とプロダクトバックログの適応
- どれくらい？⇒最大2時間（スプリント2週間の場合）
開発チームはインクリメントのデモを実施して、質問に答える。
また、完了できなかったプロダクトバックログがあれば説明する。
開発チームはデモをやることと受け入れに通ることばかり考えがちだが、大切なのはスプリントレビューを通して、よりよいプロダクトを得るための手がかりを見つけることである。
デモはそのための手段であって目的ではないことに注意しよう。
また、デモの説明スライドは作るべきでない。そこに労力が割かれがちだからだ。
POはDONEの定義に従い、インクリメントが受け入れ可能かを判断する。
スプリントレビューを通して参加者は議論し、有益な意見があれば、必要に応じてプロダクトバックログに適応していく。
スプリントレトロスペクティブ
- いつ？⇒スプリントレビュー後かつ次のスプリントが開始される前
- 誰が？⇒SMと開発チーム。POは参加してもよいが必須でない。
- 目的は？⇒スクラムチームの検査と適応
- どれくらい？⇒最大1.5時間（1スプリント2週間の場合）
スプリントで人・プロセス・ツールの観点から問題がなかったか、もっと成果を出すためにできることがないかを議論し、次回のスプリント以降の改善策を考える。
手法として、KPT（Keep, Problem, Tryを出し合うこと）がよく使われる。
このイベントが省かれる話を時々聞くが、本当にスクラムを理解していればそんなことは起こりえないはずだ。
イベント参加表
各イベントに各ロールが参加すべきかどうかを表にまとめました。
その他重要項目
ベロシティ
ベロシティとは、そのスプリントで開発したプロダクトバックログのストーリーポイントの合計である。
スクラムチームはベロシティを高めて安定させることを目指す。（高めることよりも安定させることの方がより重要）
ベロシティを過信し過ぎてはいけない。
なぜならば、そもそもストーリーポイントがいい加減な値だからだ。ストーリーポイントは綿密に議論してだした値でないし、フィボナッチ数列の値しかだせないし、開発者は技術的な不安点があるからとりあえず大きな値をしばしば出しがちである。さらに、スプリントの日数は祝日、メンバの休暇などでスプリント毎に異なるものである。
したがって、ベロシティはそこまで信頼できる値ではない。
ではなぜベロシティやストーリーポイントが必要なのだろうか？
それは、POがおおまかなリリース計画を立てるためである。
POの独断による推測よりも、実際に開発を行う開発チームの推測の方が、たとえそれがそこまで信頼できない数字だとしても、はるかに信頼できる。
特に開発チームが成熟してきてベロシティが安定してくればそこそこ信頼できるようになる。
ストーリーポイントが必要な理由は、ベロシティを計算するため以外に、その過程に大きな意味があるからである。それはプランニングポーカーで得られるチーム内での情報共有と共通理解を得ることだ。
しかしながら、数値として表現されるため、未熟なチームはベロシティの値の大きさを必要以上に気にしてしまうがちである。
加えてさらに危険なことに、スクラムを理解していない管理職はこのような数字が大好きなので、ベロシティでチームの業績評価をするなんていうバカげたことをやりかねない。「あっちのチームの方がベロシティ高いから、君たちのチームはもう少し頑張らないとだめだね。」とか。
そうなってしまうと、チームはベロシティに細工をしてしまい、チームは崩壊するだろう。そうならないようにSMはチームや管理職を教育する必要がある。
バーンダウンチャート
リリースバーンダウンチャート
横軸が時間で、縦軸が現在残ってるプロダクトバックログのストーリーポイントの合計である。
認定スクラムマスター研修でも取り上げられていたが、はっきり言ってこれを使うべきでない。
ナンセンスなうえに危険だからだ。
プロダクトバックログは期間関係なしに追加されるし、このチャートの縦軸が0になるようことは期待されていない。
しかし、しばしばウォーターフォールの感覚に慣れてしまった人はプロジェクト期間中に全部終わらせなければと誤解しがちだし、スクラムを理解してない管理職がこれを見て余計な妨害を加えてくる可能性がある。
スプリントバーンダウンチャート
横軸が時間で、縦軸がスプリントバックログのタスクの総見積もり時間である。
スプリントバーンダウンチャートにより、検査を行い、スプリントの進捗の透明性をあげられる。
スプリント期間中にスプリントバックログが追加されることもあるため、縦軸の値が上がることもあるが、最終的には0になるようにする。
開発チームはこのスプリントバーンダウンチャートを利用して、自己組織的にスプリントでの進捗を管理する。
鶏と豚
外野が野次を言うべきでないという比喩。
鶏と豚が経営する店で、ある日鶏が、”ハムエッグ”を新規メニューとして出そうと提案する。
しかし、豚は「俺は自分の身を削るのに、お前は卵を提供するだけで身を削らないじゃないか、公平じゃない！」と反対する話。
POはプロダクトバックログの豚、開発チームはスプリント作業の豚、SMはスクラムプロセスの豚、それ以外は鶏である。
各豚の責任分野ではその豚が一番偉い。
イベント毎に参加できるロールが限定されているのはこれが大きな理由である。
メンバの追加
メンバ追加するから次のスプリントからは開発ペースあげてよと言われても、簡単に「分かりました。」と言ってはいけない。
なぜならば、新規メンバは往々にして最初の期間は育成（プロダクトの理解、スクラムの理解、技術の理解など）が必要で、逆に最初の方はベロシティは落ちる傾向にあるからである。
メンバの追加で短期的に生産性をあげることは難しい。
一般的に、新規メンバ追加による生産性向上には3ヶ月〜6ヶ月かかると言われている。
これはスクラムに限らない話だと思う。
テスト専門チームを許さない
スクラムではテスト専門チームの存在を許していない。
なぜならば、例えば、スプリント終了後にテスト専門チームがバグを見つけたとしても、開発チームは既に次以降のスプリントの開発作業をやっているため、すぐには対応できないからだ。
そもそも、スプリントの中で徹底的にバグを発見して潰すべきなのである。
また、テスト専門チームがいることによって、心理的に彼らに頼ってしまい、自己組織化のマインドが薄れてしまう危険性もある。
開発チームって何人用意すれば充分？
プロジェクト開始前に、開発チームは何人集めればよいのだろうかと悩むだろう。
なぜならば、スクラムではどんな機能を作るかは決まっていないのでウォーターフォールのように期間と人月から人数を算出することはできないからである。
したがって、現実的には、社内のリソース事情や予算事情などにより決定されるだろう。
開発チームは3～9人までなら何人でもよいが、5人くらいが一番やりやすいので、初めてのスクラムだから5人集めようという考え方もある。
やりかけで終わったプロダクトバックログアイテムのベロシティ計上
スプリント期間中に途中までしかできなかったプロダクトバックログアイテムが存在する場合、そのプロダクトバックログアイテムのストーリーポイントをベロシティとしてどのように計上するかと悩むかもしれない。
例えば、そのプロダクトバックログアイテムのストーリーポイントが8だとして、それの半分くらいしかできなかった場合に、4ポイントを今回のスプリントのベロシティに計上するか、それとも全く計上しないかである。
答えとしては、計上するべきではない。（認定SMの研修でも質問しました。）
なぜならば、ベロシティは完了したものしかカウントしないからだ。ちなみに、そのやりかけのプロダクトバックログの再見積もりはやってもやらなくてもいいだろう。どうせやりかけなんて信用できないから。
最後に
スクラムをきちんと導入するのは難しいです。スクラムの理論をきちんと理解することが難しいからです。最初は、カタカナの専門用語多すぎて面食らうと思います。加えて、表面的なイベントだけを実践するのではなく、イベントの裏にある「三本柱」を意識できるようになることも必要です。また、スクラムチームのみならずステークホルダー、SIであれば顧客にも、スクラムを正しく理解してもらう必要があります。
スクラムは「銀の弾丸」ではないにも関わらず、なぜか欠点や失敗談ばかりの揚げ足取りをしたがる人が多いです。ソフトウェア開発に限らず新しいものが出てくる時って必ずこういう人いますよね。こういうところで疲弊してスクラムを辞めてしまうチームもあるでしょう。
どんなものにも一長一短があります。大事なのは、常に現状の問題点を改善しようとする社風が会社や組織にあるかだと思います。
最初の質問の答えは、私であれば「現状維持」、「問題放置」などと答えます。