スクラムの基礎知識に関しての備忘録
2017/02/24
なにこれ？
Schooで「はじめてのスクラムマスター」という講座があったので、
そちらの講座での学習した内容の備忘録。
前置き
スクラムの生みの親、Jeff Sutherland と Ken Schwaberによるスクラムガイドがある。
現在も更新されているので、スクラムに関わる機会がある方はかならず読むこと。
スクラムの定義
スクラムとは
スクラムとは 開発プロセスではなく問題に対応する為のフレームワーク であり、
価値の高いプロダクトやサービスを、
生産性高く、クリエイティブに届ける為のフレームワーク です。
スクラムの定義
スクラムとは、以下の様なものである。
- 軽量
- 理解が容易
- 習得は困難
スクラムを採用するべき開発プロセスモデル
採用すべき対象としては、
今まで経験した内容で開発全体が安定しているものではなく、
今まで経験した事がなく、 試行・検査・適応 していくしかないものに対して有効。
複雑で変化があるようなものに対して最適 だと言われている。
スクラムの理論と柱
スクラムの理論としては、 実際に経験していく事によって判断を繰り返し行う事になるので、
結果として知識が蓄積されて行き、リスクの予測ができるようになっていく。
抑えるべき要点
- 実際の経験 - A
- 即知に基づく判断 - B
- 知識 - C
- 予測可能性の最適化 - D
- リスクマネジメント - E
具体的な理論
経験に基づいて（A）、
わかったことに対して対処していき（B/C）、
リスクに対応できるように行く（D/E）
守るべき柱
スクラムを行う上で、大切な柱は以下の3点。
- 透明性*
- コンセンサスをとって認識齟齬を起こさないようにする。
- 物事に対して共通認識を持つ。
- 達成すべきゴールを一致させる。
- 検査
- 適応
スクラムのスプリント
タイムボックスと呼ぶ 開発の反復を行う期間を固定することがとても大事。
ウォーターフォールはそのまま流れ作業を行う。
一度決めたタイムボックスを仮に2週間で決めた場合は、 タイムボックス毎にフィードバックが出るのでメリットとして、
ユーザや発注者に対しての期待値をコントロールできる。
開発にリズムができるので利害関係者に対して、
次のスプリントに結果が確認できるという結果が提供できる。
この事により、横槍が入りづらくなるメリットがある。
スクラムのイベント
- 検査
- 適用
何かを行って開発を進めていくにあたって、
状況を確認する為のチェックポイントを作る。
うまくいっている所は引き続きやっていく。 何か問題が発生している場合は改善する。
それを行う為の仕組みとして、
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- レトロスペクティブ（振り返り）
タイムボックスで回した作業にて成果物が出来る。
1.スプリントプランニング（スプリント計画会議）
期間が決められたプロジェクトにあたる為、計画を行う。
- 何を作るのか
- それによって今の価値のあるプロダクトがどう変わるのか？
スプリントの期間は固定すること。
- 期間を区切る事で、期待値をコントロールできる。
- クライアント / ユーザ 次の二週間後にフィードバックがかえってくる。という信頼感につなげる事が可能
また、スプリントで行うタスクの見積もりは開発チームが見積る。
見積もりの手法はいくつかあるが、プランニングポーカーなどが多い。
※これはスクラムガイドには記載されていない
2.デイリースクラム
参加するロール
- 毎日、会議を行う（朝会とも言う）
- 開発チーム内で毎日行う作業。
期間を固定する。
スプリントのゴールに対して
- 昨日、何をしたのか。
- 今日、何をするのか
デイリースクラム自体もタイムボックスに入っているので、15分で終わらせる。
開発は難しいので、2週間という計画を立ててもその通りになるとは限らないが、 軌道修正・調整の為にデイリースクラムを行う。
朝じゃなくてもいいが、毎日同じ時間に同じ場所で同じメンバーで行うのが良い。
3. スプリントレビュー
どういった機能を作るのか？という所に対して、
ちゃんと機能を満たしているかどうかについて共有する。
4. レトロスペクティブ（ふりかえり）
- 良かった事を共有して継続する
- 悪かった事は改善点を考えて共有する
期間を固定する。
スクラムチーム
以下のロールの人員が集まって、スクラムチームと呼ぶ。
ロール
大前提として、下記のロールには上下関係はなく全員が同じ立場である
よくある注意点としては、プロダクトオーナー・スクラムマスターが従来のマネージャーやリーダーが行うケースが行う場合が多い傾向があるので、過去の立場関係に引っ張られる事がある。可能であれば、別の方が行ったほうが良い。
スクラムマスター（SM）- 1名
- 全体を俯瞰して、スクラムが逸脱していないか・横槍が入らないかを確認・調整する
- スクラムとはどういうやり方なのかを説明して理解してもらう
プロダクトオーナー（PO）- 1名
- プロダクトバックログで何をどの優先度で作るのか？という事を決定する
- 開発チームが成果を出して、プロダクトをリリースするまでの責務を追う
開発チーム（DevTerm） - 6±3名
- スプリントの中で実際に開発を行う
- スプリントのプランニングにも関わり、実際に作業の見積もりを行う。
スクラムチームの特徴として
自己組織化チーム であり、
機能横断的チーム である。
自己組織化チームとは
スクラムチームに関しては
- やり方の問題を解決したり
- うまくいくように立ち向かっていく事に関しては、外部の支援なしで行う自立したチーム
機能横断的チームとは
開発に必要な全ての事が行えるチーム でいる事。
- データベースの専門家がいない為、データベースの機能が実装ができません。
- チーム内では実装できないので、他から専門家を借りてくる。
というケースはNG。
いろんなスキルセットのメンバーが色々な知恵を出して保管し合って、
チームの中だけで完結して物事を達成していくチーム である事。
ただし個々が、スペシャリストである必要はない。 大事なのはチームで保管し合う事。
チームの人員について
開発チームはできるだけ、 6±3名が良い。
理由
- 3人未満だと、相互作用がおきづらい
- 9人を超えると自己組織的に動きづらい。*
- 理由としては同じマインドじゃない方がいたり、MTGの予定をあわせるのが難しくなったりする為。
- 人数が超える場合は、2つのチームに分ける等をしたほうが良い。