モダン・ソフトウェアエンジニアリングのエッセンス

580 Views

July 21, 20

スライド概要

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

モダン・ソフトウェアエンジニアリング のエッセンス 2020年7月21日 ワイクル株式会社 角 征典(@kdmsnr)

3.

Martin Fowler says(2010) • 厳格すぎて、価値が限られる • Alistair Cockburnが、ソフトウェア開発では人が中心的な要 素であり、人は本質的に非線形的で予測不能なものであると 説明してくれた https://bliki-ja.github.io/Semat/ 3

4.

Martin Fowler says(2010) • 厳格すぎて、価値が限られる • Alistair Cockburnが、ソフトウェア開発では人が中心的な要 素であり、人は本質的に非線形的で予測不能なものであると 説明してくれた • 人が扱いやすい計算式で記述できる予測可能なエージェントに なれば可能性はあるかもしれない https://bliki-ja.github.io/Semat/ 4

5.

7.2 理論の使用 • 理論とは? • i) 現象を「記述」するもの • ii)現象を「予測」するもの • 「予測」するためには「記述」が必要であり、 「記述」するためには「言語」が必要である 5

6.

7.2 理論の使用 • 理論とは? • i) 現象を「記述」するもの • ii)現象を「予測」するもの • 「予測」するためには「記述」が必要であり、 「記述」するためには「言語」が必要である • 将来を予測したいが、まずはそのための言語が必要 6

7.

Essenceのアーキテクチャ 7

8.

Essenceのアーキテクチャ ① ② ③ 8

9.

①エッセンシャル化された手法 9

10.

ざっくりと「手法」とは何か • 「ソフトウェアを開発・維持するときに必要となるすべてのことに対して、 アドバイスを提供するもの」 • 「すべてのこと」はウォーターフォール手法が理解しやすい • うまくいかないことを除けば(!)そんなに悪くはない • 現実的には、アジャイルを含む反復的手法でやるべき • とはいえ、自己組織化が前提だと「すべてのこと」を見逃しやすい • 全体の見取り図を別途用意しておくとよい 10

11.

手法の問題は大きく2つある • 乱立による足の引っ張り合い(手法の戦争) • 似たようなことをやってるのに名前が違う • 部品(プラクティス)がモジュール化されていたら再利用可能なのに! • 手法の作者が決める絶対的なルールがある(手法の監獄) • 「👺 そんなものでは止めを刺せん」 • 書籍では触れていないが、認定資格制度の問題もありそう💦 11

12.

「ソフトウェアが世界を食べる」時代(2011) ソフトウェアの手法だけを語ってる場合じゃねえ!! 12

13.

食後の手法はこうありたい • 既製品を使うのではなく、状況にあわせて自分たちで手法を作りたい • ただし、ゼロから手法を作るのは大変すぎる💦 • 既存のプラクティスを「合成」すればいい(3.2「手法はプラクティスの合成) • それに、自分たちで手法を作っても誰も理解してくれない💦 • 「記述する言語」を統一して誰でも読めるようにすればいい • プロダクトのUMLに対するプロセスのEssenceという位置づけっぽい? (UMLと同じくらいの希望と絶望を持つといいと思う……) 13

14.

②エッセンシャル化された プラクティス 14

15.

プラクティスとは何か • 手法を構成する具体的な作業方法のこと • 手法と違って「こんなんなんぼあってもいいですからね 🥣」 • 3つの領域に影響を与える(アルファの状態を変化させる): • 顧客 • ソリューション(技術) • 活動(プロジェクト) 15

16.

プラクティスを記述する言語 16

17.

プラクティスを記述する言語 使うべき「もの」 (扱うのほうがよかった?) やるべき「こと」 必要な「能力」 17

18.

「ペアプログラミング」を記述してみた 18

19.

「ペアプログラミング」を記述してみた 使うべき「もの」 必要な「能力」 やるべき「こと」 19

20.

素直な感想 • これって、本当にわかりやすい……のか? 🤔 • UMLと同じくらいの希望と絶望を持つといいと思う(2回目) • もうちょっと説明を続けます 20

21.

やるべき「こと」がプラクティスの中心 やるべき「こと」 21

22.

「こと」の詳細をカードに記述する 22

23.

「こと」は「もの」の状態を変える 23

24.

用意された7種類のアルファ(もの) 24

25.

アルファはカード化されている 25

26.

アルファは複数の状態を持つ 26

27.

素直な感想 • プラクティスによって状態を変化させるのはわかりやすい • 状態などをカードにするのはいいアイデアだと思う!🎴 • 途中からEssenceの説明に踏み込んでしまってた……。 27

28.

③ Essence (カーネル + 言語) 28

29.

Essenceとは? 「手法の基盤」となるもの Essence カーネル 言語 29

30.

Essence言語 30

31.

Essenceカーネル ここがカーネル ・もの ・こと こいつらは具体的すぎるので ・能力 カーネルに入っていない (表現型だけ定義されている) 31

32.

カーネルの アルファ(もの) 32

33.

カーネルのアルファ(もの) 33

34.

アルファは複数の状態を持つ 34

35.

状態を進捗させるために考える💭 🗣「ステークホルダーを巻き込むためのミーティングを開催してみる?」 35

36.

「状態を追え」ゲーム 36

37.

「状態を追え」ゲーム 37

38.

状態の進捗の可視化 38

39.

(補足)日本語のアルファ状態カードつくりました https://github.com/kdmsnr/essence-alpha-state-cards-ja 39

40.

カーネルの アクティビティスペース(こと) 40

41.

アクティビティスペース(こと) 正確にはプラクティスのアクティビティ(こと)を入れる「ことの入れ物」 41

42.

プラクティスが足りないところがわかる 42

43.

(補足)カーネルでは足りないとき • カーネルにあるアルファ(もの)やアクティビティスペース(こ と)では不十分なことがある • プラクティスの作成時にカーネルを継承して拡張すればいい • e.g.[要求]を継承した[プロダクトバックログアイテム] • e.g.[作業を準備する]を継承した[チームのキックオフ] 43

44.

スクラムとEssence 44

45.

スクラムの全体像 45

46.

Essence言語にマッピング 46

47.

Essence言語で表現したもの 47

48.

素直な感想 • えっ、めっちゃわかりにくくなって……ない? 🤔 • UMLと同じくらいの希望と絶望を持つといいと思う(3回目) • もうちょっと説明を続けます 48

49.

カード化されたのは👍 49

50.

状態が明示的になったのは👍 50

51.

スクラムだけじゃ不十分なこともわかる👍 ([活動]領域だけじゃない気もするけど、不十分なのは同意) 51

52.

スクラムの58%は失敗してる😵 • Essenceのカードを使えば、どこで失敗しているかがわかる • 次の「状態」に進むためには何をすべきか? を考えられる https://pages.services/ss.ivarjacobson.com/essential-scrum 52

53.

(補足)Agile Essentials もある https://practicelibrary.ivarjacobson.com/ 53

54.

全体的な印象 • アジャイル開発の「楽しさ」は大幅ダウンしてる気がするね😞 • 「すでに流行ってる」そうだが、全然そんな気がしない...😞 • あれほど避けていた「手法の監獄」感が出てない!?😞 • UMLと同じくらいの希望と絶望を持つといいと思う(4回目)😞 • でも、開発がうまくいってないときに使うのはよさそう🙂 • 「手法の基盤」となる安定感はなんとなく感じられる🙂 • ヤコブソンが元気そうでよかったです🙂 54

55.

開発がうまくいってない方は是非どうぞ! 55