kglabo.blog

I will output what I thought.

スクラムの基礎知識に関しての備忘録

なにこれ?

Schooで「はじめてのスクラムマスター」という講座があったので、
そちらの講座での学習した内容の備忘録。

f:id:kgr0210:20190313003640p:plain

前置き

スクラムの生みの親、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つのチームに分ける等をしたほうが良い。