アジャイル・スクラムの基本一覧

# はじめに
アジャイル開発手法、特にスクラム開発手法について、インプット資料を整理します。

# 必須資料
## アジャイルへの理解
目的：”アジャイル”とは、価値観＋プラクティスの集合であることを理解する。
補足：まさひろが記載した資料なので、手前味噌ですいません。
資料：[ウォーターフォールに慣れた人のためのアジャイル入門](http://qiita.com/MasahiroSato/items/cf7b640ab3e26e27a3db)

## アジャイル・スクラムの概要
目的：スクラム開発手法で重要な、ロール、イベント、成果物を理解する。
補足：Scrum Allianceという組織が出しているスクラムガイドが原著。
資料：[スクラムガイド](http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf)

## アジャイル・スクラムのイメージ
目的：スクラム開発手法において、リリースまでに誰が何をするのかをストーリー（小説）で理解する。
方法：下記の本、第７部ケーススタディ（文量は50頁程度）を読む。あるゲーム会社のアジャイルチームの働き方が小説になっている。
資料：[『アジャイルな見積もりと計画づくり』](https://www.amazon.co.jp/dp/B00IR1HYGW/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)

## ユーザーストーリー（＋エピック）の理解
目的：アジャイル開発手法において、要求を定義する手法であるユーザーストーリーとエピックを理解する。
資料：[ユーザーストーリー駆動開発で行こう。](https://www.slideshare.net/papanda/ss-41638116)

## ビジネス側とエンジニア側の相互理解
目的：”計画”や”見積もり”において、ビジネス側とエンジニア側が相互理解するための前提事項を理解する。
注意：相互理解の重要性と問いているだけで、fs文化である”コミット”、”ANDを取る”と相反するわけではない。
資料：[エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう？（あるいはいったい何がないのだろう？）](https://speakerdeck.com/ykmc09/enziniagana-qi-woshou-reteinaitositara-sokonihaitutaihe-gaarufalsedarou-aruihaitutaihe-ganaifalsedarou)

# タイミングに応じて確認する書籍

## アジャイル・スクラムの実践で迷った時に
目的：スクラム開発手法を現場に適応した際、具体的にどうすべきかをストーリーと漫画で理解する。
補足：２～３時間で読める本なので、一読した後にリファレンスにするとよい。
書籍リンク：[『SCRUM BOOT CAMP THE BOOK』](https://www.amazon.co.jp/dp/B00DIM6BMI/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)

## ユーザーストーリーの見積もりを始める前に
目的：ユーザーストーリーの規模見積もり、優先順位付け、リリース計画づくりについて、理解する。
補足：全部読むと５～６時間必要なので、リファレンスにするとよい。
書籍リンク：[『アジャイルな見積もりと計画づくり』](https://www.amazon.co.jp/dp/B00IR1HYGW/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)
　※上記、”アジャイル・スクラムのイメージ”と同じ書籍。

## ユーザーストーリーの優先度付に迷った時に
目的：ユーザーストーリーの優先度付、リリース単位を決めるための技法であるユーザーストーリーマッピングを理解する。
補足：特にプロダクトオーナーに重要。
書籍リンク：[『ユーザーストーリーマッピング』](https://www.amazon.co.jp/%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AA%E3%83%BC%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0-Jeff-Patton/dp/4873117321/ref=pd_sim_14_5?_encoding=UTF8&psc=1&refRID=PXNM4DR7ZKM8T57PGKTE)

## テスト（ビジネス側もエンジニア側も）を計画する前に
目的：アジャイルにおける”テスト”の粒度を理解する。
補足：自動化すべきテスト、自動化が向いていないテストの四象限が、概念として重要。
書籍リンク：[『実践アジャイルテスト テスターとアジャイルチームのための実践ガイド』](https://www.amazon.co.jp/%E5%AE%9F%E8%B7%B5%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%86%E3%82%B9%E3%83%88-%E3%83%86%E3%82%B9%E3%82%BF%E3%83%BC%E3%81%A8%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%83%81%E3%83%BC%E3%83%A0%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-Architects-Archive%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA%E3%81%AE%E5%AE%9F%E8%B7%B5-Gregory/dp/4798119970)

## リリース計画までの大きな流れを設計する前に
目的：複数のアジャイルチームでリリースまでの計画を立案する例を理解する。
補足：各アジャイル手法（スクラムやXP）の説明も記載しているので、歴史から学びたい人は前半を読む。そうでない人は、後半だけでOK。
書籍リンク：[『アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス』](https://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E9%96%8B%E7%99%BA%E3%81%AE%E6%9C%AC%E8%B3%AA%E3%81%A8%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%AB%E3%82%A2%E3%83%83%E3%83%97-%E5%A4%89%E5%8C%96%E3%81%AB%E5%BC%B7%E3%81%84%E5%A4%A7%E8%A6%8F%E6%A8%A1%E9%96%8B%E7%99%BA%E3%82%92%E6%88%90%E5%8A%9F%E3%81%95%E3%81%9B%E3%82%8B14%E3%81%AE%E3%83%99%E3%82%B9%E3%83%88%E3%83%97%E3%83%A9%E3%82%AF%E3%83%86%E3%82%A3%E3%82%B9-Architects-Archive-%E3%83%87%E3%82%A3%E3%83%BC%E3%83%B3%E3%83%BB%E3%83%AC%E3%83%95%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%A6%E3%82%A7%E3%83%AB/dp/4798120405/ref=pd_sim_14_7?_encoding=UTF8&psc=1&refRID=71TJZ6053PNREMK95005)

## アジャイルでアーキテクトな人に
目的：アジャイルが細かく計画を積み上げるからといっアーキテクチャがないがしろにされることを防ぐ。
資料：[アーキテクチャとアジャイルプロジェクトをまともに進めるための両輪について](https://www.slideshare.net/yusuke/devlove-42910895)
資料：[アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか](https://www.infoq.com/jp/articles/kenji-modeling-agile)


## 経営レベルとプロダクトレベルの橋渡しを設計する（大規模アジャイル）
目的：大規模に要求を管理する手法であるSAFe,LESS,Nexusから、有用な考え方を学ぶ。
資料：[SAFe (Scaled Agile Framework) 入門 (第3回)　プロダクト開発フロー](https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroSAFe/IntroSAFePart3Feb2015.html)
資料：[SAFe (Scaled Agile Framework) 入門 (第4回)　SAFeの概要とポートフォリオレベル](https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroSAFe/IntroSAFePart4May2015.html)
資料：[LeSS(Large Scale Scrum)のご紹介](http://takubon.hatenablog.com/entry/2015/09/15/144119)
資料：[Nexus（大規模スクラム開発）の概要](http://enterprisegeeks.hatenablog.com/entry/2016/07/11/081117)

## テスト自動化
書籍リンク：[『システムテスト自動化 標準ガイド』](https://www.amazon.co.jp/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%86%E3%82%B9%E3%83%88%E8%87%AA%E5%8B%95%E5%8C%96-%E6%A8%99%E6%BA%96%E3%82%AC%E3%82%A4%E3%83%89-CodeZine-BOOKS-Fewster/dp/4798139211/ref=pd_sim_14_13?_encoding=UTF8&psc=1&refRID=GXWGQBH3TTJP5JGRECWR)