エクストリームプログラミング―基本に立ち戻れ―

28.9K Views

June 24, 22

ub_techbase

スライド概要

https://uzabase-tech.connpass.com/event/249180/

Masanori Kado

@kdmsnr

スライド一覧

またはPlayer版

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

ダウンロード

ダウンロード(pdf - 17.92MB)

関連スライド

各ページのテキスト

エクストリームプログラミング ―基本に立ち戻れ― 2022年6月24日 techbase-vol1 エクストリームプログラミングで見える開発風景ワイクル株式会社角征典（かどまさのり） @kdmsnr [email protected]

自己紹介 ‣ ‣ 角征典（@kdmsnr） • 「XP白本」の翻訳 • 技術書の翻訳・執筆ワイクル株式会社代表取締 • ‣ アジャイル開発／リーンスタートアップの導入支援東京工業大学環境・社会理工学院特任講師 • エンジニアのためのデザイン思考 2

XPに関するこれまでの講演 https://www.docswell.com/user/kdmsnr https://www.youtube.com/watch?v=YRFWWS_2Epo 3

基本に立ち戻れ 4

エクストリームプログラミング（XP）はソーシャルチェンジである See Also: https://xtech.nikkei.com/it/article/NEWS/20060906/247316/ 5

https://xtech.nikkei.com/it/article/NEWS/20060906/247316/

XPの前日譚（1984-） http://wiki.c2.com/?WardAndKent 6

http://wiki.c2.com/?WardAndKent

XPの前日譚（1984-） Wardが私の情報源。私は彼が自然にやっていたことを説明しているだけ。 http://wiki.c2.com/?WardAndKent 6

http://wiki.c2.com/?WardAndKent

XPの前日譚（1984-） Kentの最大の功績は我々が発見したものを極限まで高めてくれたこと。 Wardが私の情報源。私は彼が自然にやっていたことを説明しているだけ。 http://wiki.c2.com/?WardAndKent 6

http://wiki.c2.com/?WardAndKent

Wardとの対話による自己研鑽 https://en.wikipedia.org/wiki/Ward_Cunningham 7

https://en.wikipedia.org/wiki/Ward_Cunningham

10.

Wardとの対話による自己研鑽 • 本を読むのが遅く、学校ではそれほど優秀ではありませんでした。でも、先生の話を予測しながら聞くのは好きでした。 • 今でも人の話を聞いたり、コンピュータに耳を傾けたりすることが好きです。 https://en.wikipedia.org/wiki/Ward_Cunningham • プログラミングしているときの自分の気持ちを話すことにも抵抗はありません。 • Kentも同じでした。だから、2人でただ一緒に座って、問題を解いていました。 7

https://en.wikipedia.org/wiki/Ward_Cunningham

11.

コミュニケーションフィードバック 8

12.

あなたの会社に対話できる相手はいますか？🗣 9

13.

対話する相手重要私の師匠：高橋征義（@takahashim） https://www.youtube.com/watch?v=7Yeir75CoPc 10

https://www.youtube.com/watch?v=7Yeir75CoPc

14.

XPの誕生 11

15.

C3プロジェクト（1996）エクストリームプログラミングの正式な誕生 https://bliki-ja.github.io/C3/ Martin Fowler アナリスト Kent Beck 技術コンサルタント Ron Je ries XPコーチ（フルタイム） https://en.wikipedia.org/wiki/Martin_Fowler_(software_engineer) https://en.wikipedia.org/wiki/Kent_Beck https:// ic.kr/p/72ij3L ff fl 12

16.

C3参加のきっかけは LISTSERV https://youtu.be/4fkUyQHToGI?t=1623 (2021) 13

https://youtu.be/4fkUyQHToGI?t=1623

17.

XPは人間中心の規律（1998） Beck, K. (1998, March). Extreme programming: A humanistic discipline of software development. In International Conference on Fundamental Approaches to Software Engineering (pp. 1-6). Springer, Berlin, Heidelberg. 14

18.

ソフトウェア開発は人間のプロセス人間は恐怖を感じる恐怖は経験によって払拭される Aggressive（積極性）が必要 15

19.

勇気 16

20.

Kent Beckの書いたXPの本 1999 2000 2004 第1版と第2版はまったく違う本である。第1版では、技術的な限界をプログラマに再発見するように促した。第2版では、トレードオフのなかで責任を持って仕事をするようにすべての人に呼びかけた。 https://twitter.com/KentBeck/status/1488901187990556672 17

https://twitter.com/KentBeck/status/1488901187990556672

21.

第1版は敬意を欠いていた（2015） The 1st ed.is very programmer centric. It was snotty, disrespectful toward other people. 第1版は非常にプログラマ中心だった。傲慢で他の人たちへの敬意を欠いていた。 https://youtu.be/cGuTmOUdFbo?t=1602 18

https://youtu.be/cGuTmOUdFbo?t=1602

22.

リスペクト 19

23.

【宣伝】第2版とクリーンアジャイル 2020年代はこの2冊で十分ですよ！（わかってくださいよ*） *『ブレードランナー』（1982）の引用です（念の為） 20

24.

基本に立ち戻れ 21

25.

エクストリーム✨ 22

26.

コリン・ターンブルの研究 Kent Beck, Cynthia Andres『エクストリームプログラミング』オーム社 ※『山の民』のほうは真偽が怪しいらしい 23

27.

極限まで高める映画『スパイナル・タップ』予告編 24 https://www.youtube.com/watch?v=A-FducsaVww

https://www.youtube.com/watch?v=A-FducsaVww

28.

ソフトウェアで大切なこと ‣コードを書くこと • 当たり前（！） ‣テストすること • コードが完成したかどうかを教えてくれる。 ‣話を聞くこと • 何のためのコードを書くのか？ ‣設計すること • コードとテストだけではいずれ行き詰まる。賢くやる必要がある。 http://wiki.c2.com/?ExtremeProgramming 25

http://wiki.c2.com/?ExtremeProgramming

29.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！） • 何のためのコードを書くのか？ ‣テストすること ‣設計すること • コードが完成したかどうかを教えてくれる。 • コードとテストだけではいずれ行き詰まる。賢くやる必要がある。これがソフトウェアのすべて。違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 26

http://wiki.c2.com/?ExtremeProgramming

30.

http://wiki.c2.com/?ExtremeProgramming

31.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くことコミュニ • 何のためのコードを書くのか？ケーション • 当たり前（！） ‣テストすること ‣設計すること • コードが完成したかどうかを教えてくれる。 • コードとテストだけではいずれ行き詰まる。賢くやる必要がある。これがソフトウェアのすべて。違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 27

http://wiki.c2.com/?ExtremeProgramming

32.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くことコミュニ • 何のためのコードを書くのか？ケーション • 当たり前（！） ‣テストすること ‣設計すること • コードが完成したかどうかを教えフィードてくれる。バック • コードとテストだけではいずれ行き詰まる。賢くやる必要がある。これがソフトウェアのすべて。違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 27

http://wiki.c2.com/?ExtremeProgramming

33.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること ‣設計すること • コードが完成したかどうかを教えフィードてくれる。バックコミュニ • 何のためのコードを書くのか？ケーション • コードとテストだけではいずれ行き詰まる。賢くやる必要がある。これがソフトウェアのすべて。違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 27

http://wiki.c2.com/?ExtremeProgramming

34.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること ‣設計すること • コードが完成したかどうかを教えフィードてくれる。バックコミュニ • 何のためのコードを書くのか？ケーション • コードとテストだけではいずれ行シンプリシティき詰まる。賢くやる必要がある。これがソフトウェアのすべて。違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 27

http://wiki.c2.com/?ExtremeProgramming

35.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること ‣設計すること • コードが完成したかどうかを教えフィードてくれる。バックコミュニ • 何のためのコードを書くのか？ケーション • コードとテストだけではいずれ行シンプリシティき詰まる。賢くやる必要がある。これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 27

http://wiki.c2.com/?ExtremeProgramming

36.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) コミュニ • 何のためのコードを書くのか？ケーション ‣テストすること設計すること ‣ 価値（Values） • コードが完成したかどうかを教え • コードとテストだけではいずれ行シンプリフィードてくれる。バックシティき詰まる。賢くやる必要がある。これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 27

http://wiki.c2.com/?ExtremeProgramming

37.

XPプラクティスの「サークルオブライフ」ビジネスに関することチームに関すること技術に関することチーム全体継続的インテグレーションテスト駆動共同所有開発（TDD）受け入れテスト協力的プログラミングメタファーリファクタリングシンプルな設計計画ゲーム持続可能なペース小さなリリース Bob Martin『Clean Agile』図1.8 サークルオブライフ ※プラクティスは他にも考えられる 28

38.

39.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること ‣設計すること • コードが完成したかどうかを教えフィードてくれる。バックコミュニ • 何のためのコードを書くのか？ケーション • コードとテストだけではいずれ行シンプリシティき詰まる。賢くやる必要がある。これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 29

http://wiki.c2.com/?ExtremeProgramming

40.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすることコミュニ • 何のためのコードを書くのか？ケーション ‣設計すること • コードが完成したかどうかを教えフィードてくれる。バック受け入れテスト • コードとテストだけではいずれ行シンプリシティき詰まる。賢くやる必要がある。これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 29

http://wiki.c2.com/?ExtremeProgramming

41.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること協力的プログラミング • コードが完成したかどうかを教えフィードてくれる。バック受け入れテストコミュニ • 何のためのコードを書くのか？ケーション ‣設計すること • コードとテストだけではいずれ行シンプリシティき詰まる。賢くやる必要がある。これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 29

http://wiki.c2.com/?ExtremeProgramming

42.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること協力的プログラミング • コードが完成したかどうかを教えフィードてくれる。バック受け入れテストコミュニ • 何のためのコードを書くのか？ケーション ‣設計すること • コードとテストだけではいずれ行シンプリシンプルシティき詰まる。賢くやる必要がある。な設計これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 29

http://wiki.c2.com/?ExtremeProgramming

43.

ソフトウェアで大切なこと ‣コードを書くこと ‣話を聞くこと • 当たり前（！）勇気(積極性) ‣テストすること協力的プログラミング • コードが完成したかどうかを教えフィードてくれる。バック TDD + リファクタリング受け入れテストコミュニ • 何のためのコードを書くのか？ケーション ‣設計すること • コードとテストだけではいずれ行シンプリシンプルシティき詰まる。賢くやる必要がある。な設計これがソフトウェアのすべて。リスペクト違うことを言う人は、何かを売りつけようとする人。 http://wiki.c2.com/?ExtremeProgramming 29

http://wiki.c2.com/?ExtremeProgramming

44.

受け入れテスト 30

45.

ストーリーを中心に置く記入記入＆決定ユーザーストーリープロダクトオーナーガイド開発者プロダクトマネージャー対話的ストーリー https://bliki-ja.github.io/ConversationalStories/ 31

https://bliki-ja.github.io/ConversationalStories/

46.

ストーリーから受け入れテストへ記入記入＆決定ユーザーストーリープロダクトオーナープロダクトマネージャーガイド開発者エッジケースとテスト条件を記入テスト自動化テスター対話的ストーリー https://bliki-ja.github.io/ConversationalStories/ 32

https://bliki-ja.github.io/ConversationalStories/

47.

協力的プログラミング 33

48.

ペアプログラミング ‣ Fred Brooks「大学院生時代(1953-56)にはじめてペアプログラミングをやってみた」 ‣ Richard P. Gabriel「MIT人工知能研究所時代（1972-73）一般的に実施されていた」 ‣ Larry Constantine「1980年代の"ダイナミックデュオ"という開発方法」 ‣ Jim Coplien「1995年、ベル研究所におけるペアによる開発（組織パターン）」出典：『Pair Programming Illuminated』Laurie Williams, Robert R. Kessler 昔からあるプログラミング方法だった『Clean Coder』Bob C. Martin 34

49.

エゴレスプログラミング ‣ Ward Cunningham：Kentと私が一緒に仕事をしていたとき、自分たちがやってきたことをふりかえり、そういう言葉（エゴレスプログラミング）を使っていたことがある。私たち2人は、どちらも大きなエゴを持っている。でも、一緒に仕事をしているときは、それを脇に置くようにしている。2人の間にはエゴがないんだ。でも、2人としては非常に大きなエゴがあったよ。 35

50.

シンプルな設計 36

51.

Kent Beckの設計のルール ‣テストをパスさせる • テスト可能なコードは「分離」されたコード ‣意図を明らかにする • リーダブルコード、ユビキタス言語 ‣重複を排除する • DRY ‣要素を最小限にする https://bliki-ja.github.io/BeckDesignRules/ 37

https://bliki-ja.github.io/BeckDesignRules/

52.

TDD + リファクタリング 38

53.

TDDのRGRサイクル (1) 失敗するテストを書く (3) コードをクリーンにする (2) テストをパスさせるコードを書く https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html 39

https://blog.cleancoder.com/uncle-bob/2014/12/17/TheCyclesOfTDD.html

54.

TDDの手順「変換の優先順位説」行き詰まらないための変換の順番 1. {} → Nil 5. 値 → リスト 2. Nil → 固定値 6. 選択 → 反復 3. 固定値 → 変数 7. 文 → 再帰 4. 無条件 → 選択 8. 値 → 変異値 * Bob C. Martin『Clean Craftsmanship』ch04 * https://blog.cleancoder.com/uncle-bob/2013/05/27/TheTransformationPriorityPremise.html 40

55.

TDDはプロの前提条件 TDDを実践していなければ、プロのソフトウェア開発者になれない。私は本気だ。というより、それが真実になりつつある。 Bob C. Martin『Clean Craftsmanship』 41

56.

基本に立ち戻れ 42

57.