アジャイルを学ぼう

メモ：

クリティカルチェーンでの考え方
ABP（Aggressive But Possible）：「がんばればなんとか実現できる」
HP（Highly Possible）：「概ね可能」
https://ssaits.jp/promapedia/glossary/abp-hp.html

Transcript

1. アジャイルを学ぼう
 2019-06-01 インフラ勉強会 @nainaistar(きり丸) 

2. アジェンダ 自己紹介及び資料の説明 5分 アジャイルのゴール 3分 アジャイルがなぜ生まれたか 15分 アジャイルとは 5分 アジャイルの幻想 5分 アジャイルとウォーターフォールの違い 27分
3. 自己紹介 HN：きり丸 ツイッター名：@nainaistar 経歴 二次受けSIer ウォーターフォール5年弱経験 社内SE アジャイル(スクラム)4カ月経験 資格
4. 当資料の対象人物 ・アジャイルを知らない人 ・アジャイルを知っているが、ウォーターフォールを知らない人 ・アジャイルを再勉強したい人 当資料の非対象人物 ・アジャイルを熟知している人
5. 当資料でわかること ・アジャイルの理解 ・アジャイルとウォーターフォールの違い 当資料でわからないこと ・具体的なアジャイルのフレームワーク実践方法 (次の登壇テーマはスクラムにしようと考えています。 )
6. アジャイルのゴール
7. アジャイルのゴール 価値のあるものを迅速に、 定期的にお客様に届けて、 お客様の満足度を高める。
8. アジャイルがなぜ生まれたか
9. なぜアジャイルが生まれたか プロジェクトで炎上した経験はありませんか。 もし炎上した経験があれば、轍を踏まないように、 ルールを追加するでしょう。 しかし、失敗の数だけ追加したいルールはあり、 理論上いくらでも膨らんでいきます。 そして、ルールが重くなることによって、 利益を得るまでのリードタイムが長くなったり、 そもそもルールが多すぎることによって別の失敗が発生してしまう可能性があります。
10. なぜアジャイルが生まれたか そのような中で、90年代ごろから開発者たちが 古いアイデアと新しいアイデアを組み合わせ始めました。 様々な組み合わせが出来上がる中で、 開発チームとビジネスの利害関係者間の密接な協力関係 、ビジネス価値の頻繁な提供 、自 己組織的なチーム、コードの作成、レビュー、リリース方法が大事であることがわかりました。 様々な組み合わせがフレームワークとなり、 スクラム、エクストリームプログラミング (XP)、機能駆動型開発（FDD）、 動的システム開発方式（ DSDM）などが登場し始めました。
11. なぜアジャイルが生まれたか そして、2001年。 とある17人が集まり、 フレームワークを使ったさまざまなアプローチの共通点を話し合って、 合意した結果、アジャイルソフトウェア開発宣言が生まれました。
13. なぜアジャイルが生まれたか アジャイルソフトウェア開発宣言が行った 2つの主なことは、 アジャイルソフトウェア開発の基礎を形成する価値ステートメントを提供すること、 アジャイルソフトウェア開発という用語自体を結び付けることでした。 https://agilemanifesto.org/iso/ja/manifesto.html
14. なぜアジャイルが生まれたか その後の数か月の間に、 アジャイル宣言の背後にある 12の原則を用いてアジャイル宣言のアイデアを拡張しました。 https://agilemanifesto.org/iso/ja/principles.html ※アジャイルの歴史とは関係ないですが、 川口 恭伸（カワグチ ヤスノブ）様の資料が 12の原則を反転させていて面白かったので、 一読しておくと皆様の役に立てると思います。 https://speakerdeck.com/kawaguti/what-is-agile
15. アジャイルとは
16. アジャイルとは 迅速かつ適応的にソフトウェア開発を行う 軽量な開発手法群の総称。 逆に、「重量ソフトウェア開発手法 」とは、 ウォーターフォール開発を選んだ時に起こりがちな手法。 (軽量な開発手法群 = アジャイル 重量な開発手法群 ≠ ウォーターフォール)
17. アジャイルのフレームワーク ・スクラム ・エクストリームプログラミング (XP) ・機能駆動型開発（FDD） ・動的システム開発方式（ DSDM） ・リーン 人にフォーカスしたフレームワーク (スクラム等)、 プロダクトにフォーカスしたフレームワーク (Lean等)の大きく2パターンに分けられます。 どれか一つだけを採用する。というわけではない。 Pivotal Lab、Yahoo Japanでは、「Lean XP」を採用している。
18. アジャイルの幻想
19. おことわり 当スライド以降、アジャイルそのものではなく、 スクラムの話が混ざります。 基本的な概念は、変わらないと思いますが、 実践するフレームワークによっては、 異なるかもしれない点があることをご了承ください。 また、グラフも出てきますが、 Spreadシートでの グラフ作成方法がよくわからず、雰囲気だけを伝えるようにしているため、 数値や桁数がおかしいことになっています。 その旨もご了承ください、または正しい値を知っていれば、コメントください。
20. アジャイルの幻想 アジャイルで開発すると、 生産性とか倍だし、開発期間も短くなるんでしょ？
21. アジャイルの幻想 ウォーターフォールだろうが、 アジャイルだろうが、 最終的に作る人が同じため、生産性は変わりません。 開発期間は短くなる傾向はありますが、 劇的な変化が見込めるわけではありません。
22. ウォーターフォールと比較して
23. そもそもウォーターフォールの メリットってなんだっけ？
24. ウォーターフォールは作業工程ごとに分割する。 分割した工程を一工程ずつ終わらせる計画を立て進捗管理をする。 原則として前工程が完了しないと次工程に進まない事で、 前工程の成果物の品質を確保し、前工程への 後戻りを最小限にする。 ウォーターフォールの利点は、工程の 進捗管理がしやすい。 そもそもウォーターフォールの メリットってなんだっけ？
25. ただし、前提が前工程が完璧であること。 後戻りしない前提なので、 後戻りした場合のスケジュール遅延を組み込むことができません。 そもそもウォーターフォールの メリットってなんだっけ？
26. 一個流しとロット流し (一個ずつやるか、 まとめてやるか)
27. 実は、ウォーターフォールのキーワード「 一工程ずつ終わらせる」という処理は、 効率がよさそうに見えて、効率が悪いです。 1つずつ終わらせた方が、作業が早く終わります。 アジャイルでは、1個ずつ終わらせます。 同時に仕掛かる機能を減らして、 迅速に出荷することが大事です。 参考動画 https://www.youtube.com/watch?v=uc7N3aPTCkY 一個流しとロット流し (1個ずつやるか、まとめてやるか)
28. スケジュールの立て方の違い
29. ウォーターフォールでは、 マスタースケジュール(プロジェクト全体のスケジュール )を立て、 更に各工程ごとの詳細のスケジュールを作成します。 アジャイルでは、1スプリントや2スプリントの直近1-4週間しかスケジュールを立てません。 リリースできる概算日を出すことはあるでしょうが、 基本的に全体スケジュールの概念はありません。 スケジュールの立て方の違い
30. 見積もり時間のぶれやすさ
31. 時間見積もりの違い
32. 見積もった時間に対して、 実際の時間はどうなりがちか 以下の作業が、見積もりに対して実際はどうなりがちか考えてみましょう。 ・単純作業(デプロイ作業等) ・知的作業(設計、コーディング等)
33. 単純作業の時間分布 (5分で終わる見積もりしたとき)
34. 単純作業の時間分布 (5分で終わる見積もりしたとき)
35. 知的作業の時間分布 (5分で終わる見積もりしたとき)
36. 知的作業の時間分布 (5分で終わる見積もりしたとき) ABP HP 2倍の時間かけて も、終わってないこ ともある
37. 知的作業の時間分布 (5分で終わる見積もりしたとき) ABP HP
38. パーキンソンの法則 第1法則
 　仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
39. 振り返りの頻度の違い
40. 開発期間が短くなる理由 スクラムでは、1-2週間で振り返り(レトロスペクティブ)を行います。 ウォーターフォールでは、工程ごとの 1-2カ月、またはリリース後に振り返ります。 定期的な振り返りの場があることで、 不満があったら次の機会で吐き出そうとするため、 効果的な振り返りができやすくなります。
41. 作るものが決まっている プロジェクトでは比較できない点
42. 必要なものを必要なだけ作る
45. 要望に優先度をつけて少しずつ 価値のあるものを作っていく。 作ったものからフィードバックを得て、 本当に顧客が欲しかった要望を引き出す。 作る根拠のないものは、作らない。 必要なものを必要なだけ作る
46. ウォーターフォールは計画主義 アジャイルは適応的開発
48. ウォーターフォールでは、計画に従うことを重要視しています。 アジャイルでは、変化への対応を重要視しています。 ウォーターフォールでは、追加タスクを嫌います。 最初に想定していたタスク以外を実施しない、ということは、 ビジネスの観点(Buisiness Domein)のみでしかタスクを作成することができず、 プロダクトの観点(Solution Domain)からタスクを作成できません。 ウォーターフォールは計画主義(完璧主義) アジャイルは適応的開発
49. つまり、ビジネス側からの要請が無い限り、 ウォーターフォールでは、プロダクトの改善をする機会を得づらいです。 プロダクトの改善をする機会が無いということは、 エンハンス開発で増えた機能、バグ修正等でプロダクトは 複雑になって可読性がどんどん悪くなっていきます。 (技術的負債の増加) アジャイルでは、プロダクトの改善する時間を取るようにしています。 ウォーターフォールは計画主義(完璧主義) アジャイルは適応的開発
50. ウォーターフォールでは、リリースするたびに難易度が上がります。 アジャイルでは、リリースを繰り返しても、難易度が上がらないようにして、 定期的にリリースできるようにします。 ウォーターフォールは計画主義(完璧主義) アジャイルは適応的開発
51. まとめ
52. アジャイルのゴール 価値のあるものを迅速に、 定期的にお客様に届けて、 お客様の満足度を高める。
53. 参考資料及び 使用しなかったスライド
54. 参考資料 ・Agile Alliance https://www.agilealliance.org/ ・5分で分かるアジャイルムーブメントの歴史 拡大版 https://www.slideshare.net/fkino/brief-history-of-agile-movement ・アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技 https://www.amazon.co.jp/dp/4797347783
55. 参考資料 ・マイクロソフト牛尾様のブログ http://simplearchitect.hatenablog.com/entry/2017/10/16/081633 ・最初の機能が少なくて乏しいほど、最後の品質が高くなる。 https://sloanreview.mit.edu/article/productdevelopment-practices-that-work-how-internet-companies-build-softw are/
56. 使用しなかったスライド
57. 優先度
58. プロジェクト目標マネジメントのＱＣＤＳ（品質、 コスト、タイム、スコープ） 品質 ウォーターフォール アジャイル コスト タイム (納期) スコープ 低 高 低 高