第1回アジャイル読書会資料_第1章

アジャイルサムライ
第1章のポイントのまとめ

Transcript

1. 2018/04/19 アジャイルサムライ読書会 第1回 第１章 ざっくりわかるアジャイル開発 2018/4/20 1
2. 第1章 発表者プロフィール • 食品小売業で、鮮魚売り場担当 → システム管理者 という謎のキャリアパスを持つ • Webサイト制作・発注システムのタブレット化・自動発注 自社開発POS・基幹メインフレームのオープン化等の 企画・管理・導入・運用に従事した後 独立 • 現在、業務用マンガ制作 スタークリエイツ代表 2018/4/20 2 梅沢 太一 うめざわ たいち
3. 第1章の目次 第1章 ざっくりわかるアジャイル開発 1.1：価値のある成果を毎週届ける 1.2：アジャイルな計画づくりがうまくいく理由 1.3：「完了」とは完了のことだ 1.4：3つの真実 2018/4/20 3
4. 第1章でわかること • アジャイルな計画な立て方 • プロジェクトがうまく行っている度合いを図る方 法 • 3つの真実を受け入れることの効能 2018/4/20 4
5. なんのためのアジャイル？ ◆ アジャイル開発の原則 2018/4/20 5 価値ある成果を毎週必ず届ける 顧客が求めているもの：実際に使えるソフトウェア 顧客満足を最優先に、 価値のあるソフトウェアを早く継続的に提供する。
6. 1.1 価値ある成果を毎週届ける① ソフトウェアを届けるということを お客さん側の視点に立って考えてみる 2018/4/20 6 ・実施計画書？ ・大量の製品文書？ ・作業報告書を納品してくれるチーム？ テスト済で動くソフトウェアを定期的に届けること 本当に大事なこと
7. 1.1 価値ある成果を毎週届ける② 1. 大きな問題は小さくする 2. 本当に大事なことに集中して、それ以外のことは 忘れる 3. ちゃんと動くソフトウェアを届ける 4. フィードバックを求める 5. 必要とあらば進路を変える 6. 成果責任を果たす 2018/4/20 7
8. 1.1.1. 大きな問題は小さくする 「毎週届ける」 2018/4/20 8 1 週間で何もかもを終わらせるなんてムリ！ 大きくて厄介な問題→小さくシンプルに
9. 1.1.2. 本当に大事なことに集中して、それ以外のことは忘れる ドキュメント等のソフトウェア以外の成果物 →お客さんにとってほとんど価値がない 2018/4/20 9 お客さんにとって価値のある ドキュメントのみに絞る
10. 1.1.3. ちゃんと動くソフトウェアを届ける テストの頻度を上げる →日々のテストの習慣化 2018/4/20 10
11. 1.1.4. フィードバックを求める お客さんからのフィードバックを 定期的に求める 2018/4/20 11
12. 1.1.5.必要とあらば進路を変える ◆プロジェクトあるある 今週はきわめて重要だったこと → 翌週にはどうでもよくなる（とか顧客が言い出す） 2018/4/20 12 計画を乱すような現実に遭遇したら、計画を変える × 現実を変える
13. 1.1.6. 成果責任を果たす ◆成果責任（Accountability） 2018/4/20 13 価値ある成果を毎週届けることをお客さんにコミットメント して、彼らの資金の使いみちを示すこと ・仕事の質に責任を持つ ・スケジュールを守る ・お客さんの期待をマネジメントする ・身銭を切るような覚悟でお客さんの資金を扱う
14. 1.1.6. 期待をマネジメントすることについて • 明示的な期待 • 暗黙的な期待→厄介 2018/4/20 14 ◆「ご近所さん」をさがせ問題 （PINBOKで言うところのステークホルダーマネジメント） 各ステークホルダーの期待（状況等によって変わることもある）を 定期的にオープンにし合意する場を設けながら、マネジメン トしていく
15. 2018/4/20 15
16. 1.2 アジャイルな計画づくりがうまくいく理由① 2018/4/20 16 • マスターストーリーリスト？ • ユーザーストーリー？ • イテレーション？ • ベロシティ？
17. 1.2 アジャイルな計画づくりがうまくいく理由② 2018/4/20 17 マスターストーリーリスト プロジェクトのToDoリスト ユーザーストーリー 個別のToDo （開発対象となるソフトウェアで顧客が実現したい と思う機能・非機能） 記述レベルは、概要がわかれば十分 イテレーション 「完了」までの期間 1週間 ～ 2週間 ベロシティ 1回のイテレーションで完了させられるストーリー の量 スコープ プロジェクトで実施すべき内容と範囲を定義したも の 柔軟にしておく
18. 1.2 アジャイルな計画づくりがうまくいく理由③ 2018/4/20 18 １. マスターストーリーリストの 項目に顧客が優先順位をつける
19. 1.2 アジャイルな計画づくりがうまくいく理由④ 2018/4/20 19 2. 開発チームが見積り をつくる
20. 1.2 アジャイルな計画づくりがうまくいく理由⑤ 2018/4/20 20 3. 同じ期間で区切る （=イテレーション（1-2週間）） テスト済ソフトウェアを納品
21. 1.2 アジャイルな計画づくりがうまくいく理由⑥ 2018/4/20 21 4. 開発チームはベロシティを実測 自分たちのこなせる仕事量を把握 できる。
22. 1.2 アジャイルな計画づくりがうまくいく理由⑦ 非現実的な計画から 実際に動くソフトウェアに着地することは 奇跡でも起きないとムリ （だいたいリリースが延期される） 2018/4/20 22
23. 1.2 アジャイルな計画づくりがうまくいく理由⑧ • アジャイルなら、こんな奇跡は必要なくなる • 当初から顧客には隠し立てをせず、誠実に仕事を 進める • 開発者は顧客に事実をありのままに伝える。顧客 は現在の状況について十分な情報を得たうえで、 スコープ、予算、期日の判断を下す 2018/4/20 23
24. 1.3 「完了」とは完了のこと • 「あらゆる作業」には、分析、設計、コーディング、テス ト、UX デザイン—すべてが含まれる • お客さんから「じゃあリリースしてください」と言われた ら、すぐにリリースできる 2018/4/20 24
25. アジャイル開発の原則 動くソフトウェアこそが 進捗の最も重要な尺度 2018/4/20 25
26. 1.4 3つの真実 1. プロジェクトの開始時点に すべての要求を集めること はできない 2. 集めたところで、要求はど れも必ずといっていいほど 変わる 3. やるべきことはいつだって、 与えられた時間と資金より も多い 2018/4/20 26
27. 1.4 3つの真実① • 要求とは発見されるものであり、すべて出揃うま で前に進めないというものではない 2018/4/20 27 1. プロジェクトの開始時点に すべての要求を集めることはできない
28. 1.4 3つの真実② • 変化は起きるものだと心得よう。起きた変化を受 け入れる 2018/4/20 28 2. 集めたところで、要求はどれも 必ずといっていいほど変わる
29. 1.4 3つの真実③ • 与えられた時間とリソースを超えるToDo リストを 前にしてもプレッシャーを感じなくなる • 取り組む価値のあるプロジェクトなら、そうなっ ているのが普通 2018/4/20 29 3. やるべきことはいつだって、 与えられた時間と資金よりも多い
30. アジャイルの実践に 唯一の正解はない 2018/4/20 30
31. アジャイルの実践に唯一の正解はない 2018/4/20 31 スクラム アジャイルプロジェクトの運営の手法 エクストリーム ・プログラミング ソフトウェア開発のプラクティスを規 律正しく実践する手法 リーン （トヨタ生産方式） 能率を上げることをとことん追い求め る手法 +独自のアジャイル手法
32. 第1章でわかること（まとめ） アジャイルな計画な立て方 • ベロシティを実測する • 事実に基づいた計画を顧客と共有する • スコープは見直す プロジェクトがうまく行っ ている度合いを図る方法 • 動くソフトウェアが継続的に納品され ているかどうか 3つの真実を受け入れる ことの効能 • 変化は前提条件 • プロジェクトにありがちな、 不安やストレスから解放 2018/4/20 32 第1章の内容はここまで