スクラムを学ぶ

# 1.はじめに
今回の記事は以下の公認スクラムマスターの研修を受けて、感じたことや理解したことを記載していますので、
間違ったことを記載があるかもしれません。
あくまでも、個人の意見と捉えて読んでいただけると幸いです。

※途中から結構だれてきて、グダグダです。。
 随時更新します

https://www.abi-agile.com/%e8%aa%8d%e5%ae%9a%e3%82%b9%e3%82%af%e3%83%a9%e3%83%a0%e3%83%9e%e3%82%b9%e3%82%bf%e3%83%bc/


## 2.スクラムとは

- そもそもスクラムってなに？
  - アジャイル開発なソフトウェア開発をを実践するための枠組みの一つ
     - 仕事を遂行するために人々の編成する方法であり、現在、スクラムマスターを採用している何千もの世界的な企業において普及しています。世界中の求人広告には、かなりの割合で「スクラム」という単語が含まれています。

- アジャイルとは？
  - ビジネスサイドと開発サイドの2人三脚
  - 要求・使用の変更を前提とする
  - 小さな単位で実装、テスト、リリースを繰り返す



### 参考文献
[アジャイルソフトウェア開発宣言](http://agilemanifesto.org/iso/ja/manifesto.html)
[アジャイル宣言の背後にある原則](http://agilemanifesto.org/iso/ja/principles.html)
[スクラムガイド](https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf#search=%27%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%82%AC%E3%82%A4%E3%83%89%27)
[スクラム入門](http://www.goodagile.com/scrumprimer/scrumprimer_jp.pdf#search=%27%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E5%85%A5%E9%96%80%27)
[Scrum Boot Camp](https://www.amazon.co.jp/SCRUM-BOOT-CAMP-BOOK-%E8%A5%BF%E6%9D%91%E7%9B%B4%E4%BA%BA-ebook/dp/B00DIM6BMI/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=)
[認定スクラムマスター研修](https://www.jp.agilergo.com/training)

### アジャイルソフトウェア開発宣言
左よりも右に価値を置く。（決して左が要らないとは言っていない。）

プロセスやツール　＜　個人と対話
包括的なドキュメント　＜　動くソフトウェア
契約交渉　＜　顧客との対話
計画に従う　＜　変化への対応


### アジャイル宣言の背後にある原則（抜粋）
要求の変更は歓迎します。
数週間から3か月という短い間隔でリリースします。
ビジネス側の人間と開発側の人間は毎日一緒に働かなければなりません。
face-to-faceのコミュニケーションを重視します。
動くソフトウェアこそが進捗の最も重要な尺度です。
一定の開発ペースを維持できるようにしなければなりません。
シンプルさ（無駄なく作る）が本質です。
自己組織的なチームである必要があります。
もっと効率的な方法をみつけるために定期的に振り返りそれに基づいて自分たちのやり方を調整します。


### 3本柱
スクラムの3本柱は**透明性**と**検査**と**適応**である。
最初は抽象的で理解しにくい部分かもしれないが、この3本柱を意識しながらスクラムを実践することが、スクラムの本質を理解して成功させるために必要なことである。ただ、なんとなく決められたイベントをこなして、なんとなく作成物を作るだけではスクラムの高い効果を得ることは難しい。

#### 透明性
スクラムチームの現状や問題点を見える化すること。

#### 検査
見える化により問題点を見つけること。

#### 適応
スクラムチームに問題があった場合に、改善策を考えて対処すること。

### 5つの価値基準（確約、勇気、集中、公開、尊敬）
個人はスクラムチームのゴールの達成を**確約**しなければならない。
スクラムチームのメンバーは正しいことをする**勇気**を持ち、困難な問題に取り組まなければいけない。
全員がスプリントの作業とスクラムチームのゴールに**集中**しなければいけない。
スクラムチームとステークホルダーは、仕事や課題と、その遂行の様子を**公開**することに合意しなければいけない。
スクラムチームのメンバーは、お互いを能力のある独立した個人として**尊敬**しなければいけない。

なんだか小学校のクラスルールみたいですが、全てを実現するって意外と難しいものです。
この5つの価値基準のどれかでも満たしていないケースを発見したら、発見した人は妨害リストにそれを追加するべきである。


### スクラムチーム
スクラムチームは自己組織化されており、機能横断的である。
スクラムチームはプロダクトオーナー、スクラムマスター、開発チームの3つのロールをそれぞれ有する複数のメンバから構成される。
プロダクトオーナーとスクラムマスターのロールの兼任は禁止されているが、それ以外は禁止されていない。

#### 自己組織化
スクラムチームが誰かに管理されておらず、自分たちで自分たちを管理している状態。
例えば開発チームの場合、進捗管理、課題管理、改善、スプリントバックログの選択などを自分たちで適切に行っていればそれは自己組織化されていると言える。

#### 機能横断的
スクラムチーム外に頼らずにゴールを達成できる状態。
例えば開発チームの場合、プロダクトを開発するための全て（設計、コーディング、試験、環境構築、ドキュメント作成など）が開発チーム内でのスキルセットのみで解決されていれば、それは機能横断的なチームであると言える。


## 3.役割

スクラムで作業を行う際には以下の役割が存在しており、それぞれに明確な役割があります。

- スクラムマスター
- プロダクトーオーナー
- 開発者

### 3.1.スクラムマスター

- スクラムマスター？
  - スクラムの仕組みに精通している人
     - チームがスクラムフレームワーク構造を使用して作業することを、支援することが出来る。
- 役割
 - 長期的にチームの力を継続して発揮させるのがメインの目的
     - ボードを最新の状態にする
 - インペディメント(障害)を排除する
 - プロセス改善
 - スケジュール管理＆プロジェクト進行を担っていはいない
 - 各タスクのスケジュール管理は各開発者にてコミット

##### 注意点
チームが自己組織化するために、SMはメンバーに直接的な指示（タスク割り当てなど）や管理（進捗管理など）をしてはいけない。従来のプロジェクトマネージャ（PM）にSMを重ねてしまう人が多いが、それは絶対にやってはいけないことだ。
スクラムにはPMは存在しない。ただし、それはPMがやっていた仕事そのものがなくなったわけでない。POとSMと開発の3つのロールに分担されているのである。

### 3.2.プロダクトオーナー

- プロダクトオーナー？
    - 製品責任者
    - スクラムチームの仕事に優先順位を付ける人

- 役割
 - POはプロダクトの完了に責任を追う
 - ファイナンスリスク
 - 優先順位づけ行う
 - 予算の管理を行う
 - 予算確保
 - 人材募集予算管理

##### 注意点
POを複数人で実施することも可能だが、その場合は代表者を1人決めておく必要がある。

### 3.３.開発者

- 開発者？
 - 実際に製品を作る人達


- 役割
 - Scrumに参加
 - 詳細計画作成
 - 納期のコミット
     - いつくらいにできるかどうかをコミットする
 - 技術リスクケア
      - どんな技術を採用するかも技術者が選択
 - 給与とパフォーマンスのレビュー
     - 技術者同士でレビューし、SMへ報告する
 - 人材リクエスト




## ４．イベント

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/626780/1c0b8bc0-5447-9387-3ab6-4fcd2933bad1.png)

### 4.1.スプリント

スプリントは、チームがプロダクトや、サービスを提供し、それがどれだけ効果的に完了したかについて、フィードバックを受け取る最短時間のサイクルです。これはよく理解されていません。プロダクトがすべての設計、評価、品質、資金調達、テスト、認定などのフェーズや、レビューを完了していない場合、スプリントを終了することはできません。


### 4.2.スプリント計画

スプリント計画は、開発チームがプロダクトオーナーに向けて、スプリントが品質基準を満たす可能性がどれだけあるかを伝えます。また、どのように仕事を進めていくか、初期計画を作成するための最短の会議です。

### 4.3.デイリースクラム

デイリースクラムは、最適なアウトプットを得るために1日の作業を再計画するための最短の会議です。

### 4.4.レビュー

スプリントレビューは、次のスプリント内に完了の定義を満たせるプロダクトバックログの量を統計的に説明し、それを達成するための初期計画を作る実用的で最短のイベントです。

### 4.5.振り返り(レトロスペクティブ)

スプリントレトロスペクティブは、心理的な安全性を高め、品質を低下させることなくチームのスピードと幸福を高めるために実用的で最短の会議です。






### 感想

良いと思った点

- 技術者とビジネスサイドが一体となって開発が行えること
  - 技術者目線で言うと、全技術者がビジネスや業務を理解し、解決策や要件を検討する場に参画できること。
ウォータフォールの場合は一部の人間のみが参画しており、分業制になるため、一つのビジネスに対しての一体感が生まれていない。
- ユーザーに価値を早く提供できる
  - 開発速度が早いため、ユーザーがその時に望んでいるものを提供できる
- 計画を変更できる
  - ウォータフォールと違い、スプリント単位で計画の変更が容易