スクラムを実践していた私がXPの現場に来て感じたこと

Slide 1

Slide 1 text

スクラムを実践していた私が  XPの現場に来て感じたこと  2021/09/18 XP祭り 2021 #xpjug Jun Nakajima

Slide 2

Slide 2 text

自己紹介  なかじま（@jnuank_）  ● 前職でスクラムを実践  ● UZABASEにJoinしてからXPを実践してます  ● モブプロ/ペアプロ/DDD/TDD/アジャイル好き  ○ 主にDDD-Comunity-JPで活動してます  ● 前職から日々の開発のカイゼンを率先してやってた  ● 社内でKAIZEN BOZU / OSHO と呼ばれることがあります  2

Slide 3

Slide 3 text

発表しようと思ったきっかけ  3 スクラムとXPって何がどう違うんですか？ 3年前の私

Slide 4

Slide 4 text

スクラムとXPの  違いがわからなかった 

Slide 5

Slide 5 text

XPとスクラムが目指すものは一緒  ● XPもスクラムも、アジャイルソフトウェア開発宣言に書いてある状態になることを目指している  ● スクラムとXP、どちらが優れているのかではなくて、ただアプローチが違うだけ  5

Slide 6

Slide 6 text

スクラムはフレームワーク 

Slide 7

Slide 7 text

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである  7 『スクラムガイド』 P.4 スクラムの定義 

Slide 8

Slide 8 text

XPは？ 

Slide 9

Slide 9 text

エクストリームプログラミング（XP）はソーシャルチェンジである  9 『エクストリームプログラミング』p.1 

Slide 10

Slide 10 text

XPとは、効果のない技術的／社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。  XPとは、自分が今日やるべきことを十分に理解することである。XPとは、明日をよりよくしようとすることである。  XPとは、チームのゴールに貢献した自分を評価することである。  XPとは、ソフトウェア開発で人間としての欲求を満たすことである。    10 『エクストリームプログラミング』p.6 

Slide 11

Slide 11 text

よくわからなかった  XPをやる前の私

Slide 12

Slide 12 text

実際に現場で経験した感想 

Slide 13

Slide 13 text

XPはエンジニアの生活習慣  と呼べるのではないか？ 

Slide 14

Slide 14 text

1.　3つのプロジェクトの話  14 2.　XPは生活習慣、スクラムはフレームワーク  今日お伝えしたいこと  3.　まとめ 

Slide 15

Slide 15 text

1.　3つのプロジェクトの話  15 2.　XPは生活習慣、スクラムはフレームワーク  今日お伝えしたいこと  3.　まとめ 

Slide 16

Slide 16 text

3つのプロジェクトの話 

Slide 17

Slide 17 text

17 自分がアジャイルを学んでいる過程  2017年 2018年 2019年 2020年 2021年 XP祭り参加スクラム、XPなにもわからん念願のスクラム開発 XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる

Slide 18

Slide 18 text

18 自分がアジャイルを学んでいる過程  2017年 2018年 2019年 2020年 2021年 XP祭り参加スクラム、XPなにもわからん念願のスクラム開発 XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる

Slide 19

Slide 19 text

アジャイル以前 

Slide 20

Slide 20 text

1つ目：ウォーターフォール開発  ● 巨大なレガシーシステムのマイグレーションプロジェクトに参加  ● 100人規模のウォーターフォール開発  ● 年単位掛かるプロジェクトで、設計フェーズだけで6ヶ月以上掛かる計画  20

Slide 21

Slide 21 text

21 当初の計画  要件定義設計開発計画 xxヶ月 xxヶ月テストリリ丨ス xxヶ月 xxヶ月 xxヶ月 xxヶ月よく見るフェーズ区切りの計画 

Slide 22

Slide 22 text

22 実際はこうだった  フェーズで区切れず情報入り乱れ戦場になった  要件定義設計開発 6ヶ月 3ヶ月… 計画 PJ中止 xxヶ月 xxヶ月設計やり直し要件変更要件追加テスト

Slide 23

Slide 23 text

プロジェクト炎上→解散 

Slide 24

Slide 24 text

この時学んだこと  ● 計画、設計、実装…とフェーズ区切りするやり方は、計画通りに物事が進むことが前提  ● だけど計画通りには進まない  ● せっかく設計書を大量に書いても、コード書かずにPJ中止になった  ● しっかり書いても無駄なのではないか  24

Slide 25

Slide 25 text

アジャイル開発を知る  ● もっと良い開発方法はないか調べて、アジャイル開発とメジャーだったスクラムを知る  ● 毎週開発をしてリリースし、ユーザーのフィードバックを貰うやり方はとても良さそうに感じた  25

Slide 26

Slide 26 text

26 自分がアジャイルを学んでいる過程  2017年 2018年 2019年 2020年 2021年 XP祭り参加スクラム、XPなにもわからん念願のスクラム開発 XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる

Slide 27

Slide 27 text

ウォーターフォール → スクラム 

Slide 28

Slide 28 text

2つ目：スクラム開発  28 私たちのチームプロダクトオーナー別チームA 子会社別チームB 親会社ユーザー

Slide 29

Slide 29 text

プロジェクト開始時  29 プロダクトオーナーリーダーメンバーこの△△システムの開発をやって欲しい

Slide 30

Slide 30 text

プロジェクト開始時  30 リーダーメンバー今スプリントは要件定義のドキュメント作成しましょう！

Slide 31

Slide 31 text

1スプリント後  31 リーダーメンバー要件定義が終わらなかったので、次のスプリントもやりましょう

Slide 32

Slide 32 text

3スプリント後…  32 リーダーメンバー要件定義が終わったので、次のスプリントでは設計書を作りましょう

Slide 33

Slide 33 text

ここまでやって、違和感 

Slide 34

Slide 34 text

34 私たちがやろうとしていたこと  要件定義設計開発テスト 3スプリント 2スプリント 6スプリント 2スプリントリリ丨ス 1スプリント ※ここでの1スプリント＝1週間計画 1スプリント

Slide 35

Slide 35 text

これって、  ウォーターフォールっぽい 

Slide 36

Slide 36 text

当時思っていたこと  36 ドキュメントばかり作ってたら遅くなるし、そんなに書きたくない当時の私

Slide 37

Slide 37 text

カイゼンをしてみた 

Slide 38

Slide 38 text

ドキュメントを減らすアプローチ  ● ユーザーストーリーマッピングで図で要件の合意を取る  ● API仕様書を手書きだったのをコードから生成する  ● PRを待つ時間の削減と知見共有のためにモブプロ・ペアプロを始める  38

Slide 39

Slide 39 text

結果 

Slide 40

Slide 40 text

40 各フェーズが効率的になった  テストリリ丨ス計画要件定義設計開発カイゼンしたよ、やったね！ 

Slide 41

Slide 41 text

当時の私はアジャイルになれたと思っていた  ● 当時の私はアジャイルになれたと思っていた  ● 各フェーズが短くなった  ● 必要十分以上のドキュメントも作られなくなった  ● 言うことなし！　最高！！  41

Slide 42

Slide 42 text

リリース後  42 ユーザーリーダーメンバーこの○○機能って何であるの？別に要らないんだけど

Slide 43

Slide 43 text

無駄な機能を作ってたことが  リリース後に発覚 

Slide 44

Slide 44 text

当時思っていたこと  44 事前にデザインのレビューや機能確認したはずなのに当時の私なんでこんなことになるんだろう…？

Slide 45

Slide 45 text

45 あらためて、私たちがやったこと  テストリリ丨ス計画要件定義設計開発

Slide 46

Slide 46 text

46 あらためて、私たちがやったこと  テストリリ丨ス計画要件定義設計開発

Slide 47

Slide 47 text

1回しかリリースを  していない 

Slide 48

Slide 48 text

開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。  48 『スクラムガイド』p.6 

Slide 49

Slide 49 text

利用可能なインクリメント＝  動くソフトウェア 

Slide 50

Slide 50 text

50 理想はこうだったのでは  要件定義 1 スプリント ※ここでの1スプリント＝1週間設計コーディングテストリリ丨ス計画要件定義 1 スプリント設計コーディングテストリリ丨ス計画要件定義 1 スプリント設計コーディングテストリリ丨ス計画

Slide 51

Slide 51 text

どうしてできなかった 

Slide 52

Slide 52 text

なぜ1回しかリリースしてなかったのか  ● 当時の私たちはリリース＝プロジェクトのゴールと捉えていた  ● 毎スプリントのインクリメント  ○ ドキュメント、(リリースしてない)コード  ○ 動くソフトウェアをリリースすると  ならなかった  52

Slide 53

Slide 53 text

この時学んだこと  ● 開発者もユーザーも、実際に動くソフトウェアを触ってみないと気づかないことが多い  ● 頻繁にリリースをして、ユーザーからのフィードバックを得たいと思った  53

Slide 54

Slide 54 text

54 自分がアジャイルを学んでいる過程  2017年 2018年 2019年 2020年 2021年 XP祭り参加スクラム、XPなにもわからん念願のスクラム開発 XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる

Slide 55

Slide 55 text

スクラム → XP 

Slide 56

Slide 56 text

3つ目：XPチーム  56 　エンジニアを2チームに分けて開発 1イテレーションごとにメンバーシャッフルする

Slide 57

Slide 57 text

驚いたこと 

Slide 58

Slide 58 text

58 要件定義 1 イテレーション ※ここでの1スプリント(イテレーション)＝1週間設計コーディングテスト計画 1 イテレーション 1 イテレーションリリース要件定義設計コーディングテスト計画リリース要件定義設計コーディングテスト計画リリース XPチームのサイクル 

Slide 59

Slide 59 text

イテレーションごとに  リリースができている 

Slide 60

Slide 60 text

同時に全てができている  ● テストを書くと同時にAPIパス・メソッド名やパラメータなどの設計と実装をする  ● WebE2Eテストを書く時に要件が曖昧で書けない場合、他のエンジニアやPdMと話して要件を確認する  ● 1つのストーリーが終わったらパイプラインを動かしてすぐリリースしている  60

Slide 61

Slide 61 text

XPのプラクティス  61 『Clean Agile』p.47 

Slide 62

Slide 62 text

XPのプラクティスを  全部実践している 

Slide 63

Slide 63 text

実践している例  ● 就業時間中、ずっとペアプロをする  ○ 1時間経ったらペアチェンジする  ● TDDの徹底、受け入れテスト、継続インテグレーション  ● リファクタリングはタスクとして作らず、常に行なう  ● チーム全体  ○ 月イチでチームシャッフルして継続性を高める  63

Slide 64

Slide 64 text

これがみんな自然にできている 

Slide 65

Slide 65 text

自然にできている一例  65 ○○画面で不正な文字列を入力できるようになってる私メンバーたち

Slide 66

Slide 66 text

自然にできている一例  66 私メンバーたちでは直しますかまずはバグを再現するテストを書いてからバグ修正しましょう

Slide 67

Slide 67 text

自然にできている一例  67 私メンバーたちですねー了解ー

Slide 68

Slide 68 text

TDDをやることが当たり前  になっている 

Slide 69

Slide 69 text

TDDをやることが当たり前になっている  ● バグを直すときでも、TDDを選択する  ● そこに対してチームの誰もが異論を挟まない  ● TDDをやることが当たり前だと思っている  69

Slide 70

Slide 70 text

なぜXPがみんな自然にできるのか  ● 純粋にXPについて知見があるメンバーが多い  ○ 加えてXP・アジャイルのスキルを他に伝えられる人も多い  ○ ちょっとXPのプラクティスから外れても、誰かが疑義を投げかけて修正ができている  70

Slide 71

Slide 71 text

なぜXPがみんな自然にできるのか  ● メンバーがコミュニケーションを嫌がらない  ○ 2〜3分考えてわからなければ、聞きに行く文化  ○ 聞いたり教え合ったりする中でXPに対する知見を各メンバーが深めていっている  71

Slide 72

Slide 72 text

1.　3つのプロジェクトの話  72 2.　XPは生活習慣、スクラムはフレームワーク  今日お伝えしたいこと  3.　まとめ 

Slide 73

Slide 73 text

スクラムはフレームワーク 

Slide 74

Slide 74 text

74 (再掲)2つ目のスクラムチームのサイクル  テストリリ丨ス計画要件定義設計開発

Slide 75

Slide 75 text

毎スプリントリリースをするには  ● 動くソフトウェアを毎スプリント、リリースできていないことが1 つ問題だとわかった  ● 上記を実現するためには、どんなプラクティスが必要か  75

Slide 76

Slide 76 text

毎スプリントリリースをするには  ● 特に関連の強いプラクティス  ○ 受け入れテスト、テスト駆動開発、シンプルな設計、リファクタリング、継続インテグレーション  ● これらについてスクラム自体には特に記述はない  76

Slide 77

Slide 77 text

スクラムはプロジェクトをマネジメントするためのフレームワークだ。  プロジェクトをマネジメントする方法は語っているが、エンジニアリングの話はほとんどない  77 『スクラム現場ガイド』p.39 

Slide 78

Slide 78 text

スクラムは、動くソフトウェアを顧客に届けるのを助けるフレームワークにすぎない。どんな問題でも解いてしまう魔法の粉ではないよ。問題を見つけやすくして、人びとを問題解決に集中させる。それが、スクラムの素晴らしいところだ。  78 『スクラム現場ガイド』p.352 

Slide 79

Slide 79 text

スクラムはあくまで問題検知のフレームワーク  ● スクラム自体は、問題を素早く検知するためのフレームワークである  ● スプリントごとに動くソフトウェアをリリースするなど、技術的な問題にはテクニカルプラクティスが必要になってくる  79

Slide 80

Slide 80 text

XPはエンジニアの生活習慣 

Slide 81

Slide 81 text

(再掲)XPのプラクティス  81 『Clean Agile』p.47  

Slide 82

Slide 82 text

プラクティスとは   

Slide 83

Slide 83 text

プラクティスは日常的な取り組みである。  83 『エクストリームプログラミング』p.11 

Slide 84

Slide 84 text

プラクティス＝日常的な取り組み   

Slide 85

Slide 85 text

日常的な取り組み＝習慣   

Slide 86

Slide 86 text

XPは日常的な取り組み＝習慣  を集めたもの 

Slide 87

Slide 87 text

習慣とは、自動的に行なうまで何度も繰りかえす行動のことである  87 『ジェームズ・クリアー式複利で伸びる 1つの習慣』 p.59 

Slide 88

Slide 88 text

XPのプラクティスが  自動的になるまで何度も繰りかえす 

Slide 89

Slide 89 text

自然になるまでプラクティスを繰り返してた  ● バグを直すときでもTDDを当たり前のように実践した  ● 普段の開発でTDDを徹底して、何度も繰り返したからこそ、バグを直すときに自然とその行動が取れた  89

Slide 90

Slide 90 text

プラクティスを  ただ繰りかえせばいいのか 

Slide 91

Slide 91 text

価値を明確にすることが重要だ。価値がなければ、プラクティスはすぐに機械的な作業になってしまう。活動そのものが目的となり、本来の目的や方向性が失われてしまう。    91 『エクストリームプログラミング』p.12 

Slide 92

Slide 92 text

XPの価値 

Slide 93

Slide 93 text

XPの価値  ● コミュニケーション  ● シンプリシティ  ● フィードバック  ● 勇気  ● リスペクト  93

Slide 94

Slide 94 text

価値が失われたプラクティス  ● ペアプログラミングで、文字通りペアになるだけ  ● 一人がコードを書いているのを、もう一人が横でじっと眺めている  ○ 会話をしない  ○ ドライバーを交代しない  94

Slide 95

Slide 95 text

価値が失われたプラクティス  ● ペアプログラミングで、文字通りペアになるだけ  ● 一人がコードを書いているのを、もう一人が横でじっと眺めている  ○ 会話をしない  ○ ドライバーを交代しない  ● 最終的に形骸化してやらなくなる  95

Slide 96

Slide 96 text

プラクティスの背後にある価値  を意識することが大事である 

Slide 97

Slide 97 text

XPはよりアジャイルになる為の生活習慣  ● XPのプラクティスは日常的に取り組むもの  ● 繰り返し実践することで習慣形成されて、自然とできるようになっていく  ○ それがXPの価値を体現し続けることに繋がる  ● XPの価値を意識せずに、ただ機械的にやり続けても、それはXPとは言えないし、習慣が身につかなくなる  97

Slide 98

Slide 98 text

1.　3つのプロジェクトの話  98 2.　XPは生活習慣、スクラムはフレームワーク  今日お伝えしたいこと  3.　まとめ 

Slide 99

Slide 99 text

行動の背後にある価値を意識する 

Slide 100

Slide 100 text

100 『アジャイルソフトウェア開発宣言』 

Slide 101

Slide 101 text

スクラムもXPも目指すべき価値は一緒  ● アジャイルソフトウェア開発宣言に書かれている価値を体現するために、スクラムはフレームワーク、XPは良い生活習慣、を実践し続けるアプローチを取っている  ● 1つ1つのやり方も大事だが、それに固執せずに、  何の価値を目指すべきかを意識して、日々実践し続けることがどちらも大事です  101

Slide 102

Slide 102 text

参考文献  ● Kent Beck, Cynthia Andres(著), 角征典(訳) (2015) 『エクストリーム・プログラミング』オーム社   ● Mitch Lacey (著), 安井力, 近藤寛喜, 原田騎郎(訳) (2016) 『スクラム現場ガイド』マイナビ出版   ● Robert C. Martin(著), 角征典, 角谷信太郎(訳) (2020)『Clean Agile 基本に立ち戻れ』ドワンゴ   ● ジェームズ・クリアー (著), 牛原眞弓 (訳) (2019)『ジェームズ・クリアー式複利で伸びる1つの習慣』   ● Ken Schwaber & Jeff Sutherland『スクラムガイド』     ● 『アジャイルソフトウェア開発宣言』       102

Slide 103

Slide 103 text

Thank you! 103