アジャイル開発フレームワークの一つである「Scrum」を勉強した際に、ありがたかったサイトのリンク集です。
#Scrumの原典「ScrumGuide」
####リンク先
Download the official Scrum Guide
https://www.scrumguides.org/download.html
####コメント
フレームワーク「Scrum」の開発者Ken･SchwaberとJeff･Sutherlandによって書かれたガイドブック。Scrumの原典ともいえますから、Scrumを学ぶ上では必読です。
比較的Scrumで定義される事項が少ないこともあり、18ページ（2017年11月 日本語版)とコンパクトにまとまっています。読み終えるのに時間はかかりません。
フレームワークのテクニカルな部分だけでもなく、考え方や価値観も強く打ち出しています。
抽象的な言葉遣いが難点ともいえるので、次の記事も役に立ちました。
スクラムガイドをきちんと読もう
https://qiita.com/bringer1092/items/a459cc9e9e2bc2b25deb
#Scrumの俯瞰図
####リンク先
スクラムの概要を1分で理解できるイラスト【2018版】
https://www.ryuzee.com/contents/blog/7124
####コメント
Scrumの俯瞰図として、現時点で最高のものだと思います。とくに初心者には。
私は、Scrumにプロジェクト管理担当やマネジャーがいない、ということを、この俯瞰図で悟りました。
改変せずに引用元を併記するれば自由に使っていい、という点もすばらしい。
#Scurmの方向性を一言でいうと
####リンク先
5分で分かる、「スクラム」の基本まとめ
https://www.atmarkit.co.jp/ait/articles/1208/07/news128.html
####コメント
「ScrumGuide」で咀嚼が難しい内容に図解を入れて、よりわかりやすくまとめてくれています。
とくにScrumを「伝統的なリーダーが行ってきたことを、できる限りチーム自身が行うこと」とまとめてくれているのは、ウォーターフォール開発を経験してきた人にはありがたいものではないでしょうか。
このサイトを読んでからもう一度「ScrumGuide」に立ち戻ると、より理解が深まると思います。
#IPA版 "ScrumGuide"
####リンク先
「アジャイル領域へのスキル変革の指針 アジャイル開発の進め方」
https://www.ipa.go.jp/files/000065606.pdf
####コメント
IPA(独立行政法人 情報処理推進機構)が作成したScrum解説書。IPA版の"ScrumGuide"といえる内容です。特にScrumのおける開発チームの構成や必要なスキルをこれまでIPAが培ってきたIT人材の知見をベースに解説しており、非常に充実しています。
IPAが策定している「ITスキル標準(ITSS)」にアジャイル領域を追加する際に作成されたドキュメントになります。
https://www.ipa.go.jp/about/press/20180409.html
https://www.ipa.go.jp/jinzai/itss/itssplus.html#section1-4
開発チームの人材やスキルに関心がある人は一読するとよいと思います。
#立場によって変わる「プロダクトバックログ」の意味
####リンク先
魅力的なプロダクトバックログで開発を楽しく！
https://kray.jp/blog/attractive-product-backlog/
####コメント
よりよい(リンク先の表現では「魅力的な」)プロダクトバックログを、プロダクトオーナーと開発チームの双方の視点から説明していることが新鮮でした。
当たり前ですが、立場によってその意味が変わるという観点は、Scrum開発を実際に行う上で忘れないでおこうと思います。
#スプリント期間中の臨場感
####リンク先
わたしたちがスクラムのスプリント期間を 1 週間にし、タスクを 1 時間以下の単位に分割するのはなぜか
http://appresso.hatenablog.com/entry/2016/12/03/104407
####コメント
スプリントの解説としても充実していますが、Scrum開発の創意工夫の臨場感がすばらしい。
スクラムマスターの思考を追体験できます。
#ベロシティとは
####リンク先
ベロシティに対する誤解
https://www.ryuzee.com/contents/blog/4802
####コメント
最初、語感からまったく想像できなかったベロシティを誤解なく説明してくれています。
ベロシティと工数は重なる部分もありますが、重ならないところにこそScrumらしさがあります。
#タスクボード
####リンク先
スクラム開発-タスクボード公開
https://qiita.com/R_TK_8170/items/86e2ff3e890763413af4
####コメント
進化したタスクボードの紹介。タスクボード自体は「ScrumGuide」で定義されていないものですが、創意工夫の一例として新鮮でした。
#プログラミング手法
####リンク先
ペアプロ懐疑派だった僕が、実務でペアプロ導入して180度考えが変わった話
https://qiita.com/YudaiTsukamoto/items/06b426f4dbee268d5035
エンジニアのスキルを伸ばす“テスト駆動開発”を学んでみよう
https://thinkit.co.jp/story/2014/07/30/5097
####コメント
「ペアプログラミング」「テスト駆動開発」は、アジャイル開発手法の一つ「XP(エクストリームプログラミング)」の中で語られるプログラミング手法ですが、Scrumとの親和性が高いのでScrumの中で活用されていることも多いらしいです。
(以下参照)
海外の開発者はどのような開発手法を使っている？(アジャイル、スクラム、ペアプログラミング、かんばん開発手法等)
http://everything-you-do-is-practice.blogspot.com/2017/11/blog-post_27.html
#まとめ
「ScrumGuide」でScrumを「理解が容易」で「習得は困難」と定義しています。
習得のためには、教科書的な理解を超えた経験や情報は欠かせないもので上記リンク先はありがたいものでした。感謝。