アジャイル開発、スクラムについてまとめてみた


:writing_hand_tone1:この記事を書こうと思ったのは、実務で初めてのアジャイル、スクラムを経験し
　改めてアジャイル開発について学びアウトプットしたいと思ったのがきっかけです。


そもそもアジャイルとスクラムって同じもの？という曖昧な認識でしたが・・
**アジャイル開発の手法（フレームワーク）としてスクラムがある**


:::note info
スクラム以外にもフレームワークは色々あるみたいで、
※それぞれを組み合わせて使われることもあるそう！
**フレームワーク例**
・Scrum
・Hybrid
・Scramban
・XP
・Kanban
・その他
:::

## アジャイルマニフェスト4つの価値

:::note info
**1.プロセスやツールよりも個々との対話のほうが大事**
 →上からゆわれたことをそのまま単純にやっていこうは×
　自分たちから主体的にプロジェクトをよくしていく
　これができるとパフォーマンスが50倍くらいあがるとゆわれている
:::

メリット：自発的にやるのでチームワーク、コミュニケーションが高まる
デメリット：チームに入り込み関与する能力が必要、チームワークが必須
　　　　　　チームワークを意識してくれない人が入ると難しい

:::note info
**2.包括的なドキュメントより動作するソフトウェア**
　→ドキュメントだけでは理解しにくい、実際に作ったものと違うため
　　やり直すということになると費用とコストが24倍くらいかかってしまう
:::

例：50%の進捗の場合
ウォーターフォール：0%完成
アジャイル：50%で納品→細かく部品を分けて動作するものを見せる

:::note info
**3.契約交渉よりも顧客とのコラボレーション**
　→一番最初に交わした契約内容で進めていっても、想定するものと違うことはよくある
　　顧客と一緒にものを作っていくことができると生産性が4倍くらいになる
:::

ウォーターフォール：顧客と関わるのは開始、途中（必要な場合）、終了時のみ
アジャイル：継続的に顧客と関わる（2,3週間に一度のスプリントレビュー）

:::note info
**4.計画に従順するよりも変更への対応**
　→ビジネスの変化、お客様の意向も変わることがあるため変化に対応したほうがお客様満足度があがる
:::

ウォーターフォール：変更のコストが高くなっていく
アジャイル：2週間くらいのスプリントで変化に対応していく


**開発チーム内でのアジャイルのメリット：**
リリースと時間を無駄にせずに高品質の製品を開発する
意思決定力、自己啓発も高まる

**管理者内のアジャイルのメリット：**
高品質の製品を作り上げる
時間と費用対効果、無駄な機能を作ってお金や時間を無駄にしない

## スクラム
:writing_hand_tone1:スクラムガイド

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf


**役割**
:family_mwgg:スクラムチーム
* スクラムマスター（プロジェクト進行役、コーチ）
　開発チームをサポートし、アジャイルプロセスが確実に実行されるようにする
　開発者からうまく今の不満を聞き出してあげる
* プロダクト・オーナー
　経済の状況やビジネスの変化によって、バックログの優先順位付けや監督を行う

:family_mmg:開発チーム
* エンジニア、デザイナー、プログラマー、QAなど（4~6人）
　T字型スキルが求められる
　※専門分野だけでなく、専門分野以外のスキルも求められる

　:thumbsup_tone3:：対面コミュニケーション、電話会議システム
　:thumbsup_tone3:：適切なチーム規模（小さすぎても大きすぎても×）

### 価値と理念
* 尊敬
    チーム全体が成果と失敗に対して責任を負う
* オープンマインド
    他人の意見を受け入れる、全員が関与する
* コミットメント
    チーム全体でスプリントの目標を達成する責任がある

## アジャイル開発
![スプリント プランニング (1).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/543815/680322f2-faaa-3e2e-1ca9-1f6c6d37cfb4.jpeg)
#### プロダクト・ビジョン
**WHO:** プロダクトオーナーがやるが、全員がビジョンに貢献できる
**FOR:** 関係者全員
**WHAT:** 最終目標と製品の価値
**WHEN:** バックログの前or更新時

#### プロダクトロードマップ
**WHO:** プロダクトオーナーだが、全員が貢献できる
**WHAT:** 製品の戦略目標、優先順位、計画を整理
**WHEN:** 製品開発タスクに優先順位をつける前、年2回など再確認する

#### アーキテクチャ作成
* アーキテクチャ図の作成
ツール等を用いて簡単な図を用意する

https://www.visual-paradigm.com/

#### ユーザーストーリー
* シンプルに顧客のために何が必要かを要件にする（製品要件を記述する方法ではない）

:::note warn
顧客が理解できるもの

ユーザーがログインできる
ユーザーが商品を閲覧できる
ユーザーが購入ボタンを押せる
:::

#### 見積手法
* プランニングポーカー（シンプルに気軽に、時間をかけず見積もる）

https://qiita.com/e99h2121/items/2bc505415e1ccfd2ff95


#### ストーリーポイント
https://ssaits.jp/promapedia/method/story-point.html#

**※スパイクとは？**
調査が必要なもの、どうなるかわからない
ストーリーポイントは13など多めに評価しているもの
タイトルの前に**SPIKE:** と表記すると分かりやすい

#### リリース・プランニング
**WHO:** プロダクトオーナー
**FORWHO:** 顧客
**WHAT:** 作業機能のリリースの高レベルの時間割を特定する
**WHEN:** 各リリースの開始
**WHY:** プロダクトビジョンを達成するための次のステップは何かを判断する

#### プロダクト・バッグログ
**WHO:** プロダクトオーナー、全員が貢献できる
**FORWHO:** 製品、開発チーム
**WHAT:** タスクレベルの詳細を一覧表示して優先順位をつける
**WHEN:** ロードマップを作成したと
**WHY:** ホワイトボード、JIRA等

https://do-scrum.com/pbl/


#### スプリントプランニング
**WHO:** 
　プロダクトオーナー（バックログアイテムと受け入れ基準の詳細を明確にする）
　スクラムマスター（ファシリテーター）
　開発チーム（スプリントに必要な作業と労力を定義する）
**WHAT:** 今後のスプリントのバックログを定義するために会議をもうける
**WHEN:** スプリントの開始、スプリントの週ごとに約1~2時間

https://do-scrum.com/planning/

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

**WHO:** 開発チーム
**WHAT:** 次の24時間の計画を作成する
**WHEN:** 毎日約15分間
**HOW:** 立って（会議が長引かないように）

:::note warn
**チームがスプリントの目標を達成するために正しいことをしているか？**
**1.** 昨日なにしたか
**2.** 今日何するか
**3.** 今の仕事で何か問題・障害があるか
進捗状況を確認したり、何か問題があれば手助けする
（15分以内に収まりきらなさそうであれば個別対応）
:::

##### 進行状況を追跡する方法

* スプリントバックログを更新
* バーンダウン/バーンアップチャート（Jira）を更新
* タスクボードを使用

https://note.com/mogmogmogb/n/n2b77dbe5b2df


#### スプリントレビュー
**手順**
* 完了と未完了の内容
* デモンストレーション
* 製品バックログを確認及び修正

https://do-scrum.com/review/

#### スプリント・レトロスペクティブ（反省会）
* 会議の目標を特定する
 　→　何がうまくいったか、いかなかったか
　　　何をどう変えたいか
　　　アクションアイテムは
* 話し合い、ブレインストーミング
* まとめとアクションプラン

https://codezine.jp/article/detail/13572

　　　　　　　　　　　　　
## アジャイルは自社開発がやりやすい
:::note info
自社開発では期限も伸ばしやすく柔軟に対応できる
:::
:::note info
ビジネスの変化や他の競合企業のサービスに応じてすぐに変更できる
:::
:::note alert
アウトソーシングすると仕様変更が難しい
:::
:::note alert
アウトソーシングをして他企業と一緒にアジャイル開発する場合は、アジャイルが何かを両者で理解しないと上手くいかない
:::