XP祭り2021 で発表したスライドです
イベント https://xpjug.connpass.com/event/218516/
https://confengine.com/conferences/xp2021/proposal/15825/xp
スクラムを実践していた私が XPの現場に来て感じたこと 2021/09/18XP祭り 2021#xpjugJun Nakajima
View Slide
自己紹介 なかじま（@jnuank_） ● 前職でスクラムを実践 ● UZABASEにJoinしてからXPを実践してます ● モブプロ/ペアプロ/DDD/TDD/アジャイル好き ○ 主にDDD-Comunity-JPで活動してます ● 前職から日々の開発のカイゼンを率先してやってた ● 社内でKAIZEN BOZU / OSHO と呼ばれることがあります 2
発表しようと思ったきっかけ 3スクラムとXPって何がどう違うんですか？3年前の私
スクラムとXPの 違いがわからなかった
XPとスクラムが目指すものは一緒 ● XPもスクラムも、アジャイルソフトウェア開発宣言に書いてある状態になることを目指している ● スクラムとXP、どちらが優れているのかではなくて、ただアプローチが違うだけ 5
スクラムはフレームワーク
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである 7『スクラムガイド』 P.4 スクラムの定義
XPは？
エクストリームプログラミング（XP）はソーシャルチェンジである 9『エクストリームプログラミング』p.1
XPとは、効果のない技術的／社会的な古い習慣を捨て、効果のある新しい習慣を選ぶことである。 XPとは、自分が今日やるべきことを十分に理解することである。XPとは、明日をよりよくしようとすることである。 XPとは、チームのゴールに貢献した自分を評価することである。 XPとは、ソフトウェア開発で人間としての欲求を満たすことである。 10『エクストリームプログラミング』p.6
よくわからなかった XPをやる前の私
実際に現場で経験した感想
XPはエンジニアの生活習慣 と呼べるのではないか？
1. 3つのプロジェクトの話 142. XPは生活習慣、スクラムはフレームワーク 今日お伝えしたいこと 3. まとめ
1. 3つのプロジェクトの話 152. XPは生活習慣、スクラムはフレームワーク 今日お伝えしたいこと 3. まとめ
3つのプロジェクトの話
17自分がアジャイルを学んでいる過程 2017年 2018年 2019年 2020年 2021年XP祭り参加スクラム、XPなにもわからん念願のスクラム開発XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる
18自分がアジャイルを学んでいる過程 2017年 2018年 2019年 2020年 2021年XP祭り参加スクラム、XPなにもわからん念願のスクラム開発XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる
アジャイル以前
1つ目：ウォーターフォール開発 ● 巨大なレガシーシステムのマイグレーションプロジェクトに参加 ● 100人規模のウォーターフォール開発 ● 年単位掛かるプロジェクトで、設計フェーズだけで6ヶ月以上掛かる計画 20
21当初の計画 要件定義 設計 開発計画xxヶ月xxヶ月テストリリ丨スxxヶ月 xxヶ月 xxヶ月 xxヶ月よく見るフェーズ区切りの計画
22実際はこうだった フェーズで区切れず情報入り乱れ戦場になった 要件定義設計開発6ヶ月 3ヶ月…計画PJ中止xxヶ月xxヶ月設計やり直し要件変更要件追加テスト
プロジェクト炎上→解散
この時学んだこと ● 計画、設計、実装…とフェーズ区切りするやり方は、計画通りに物事が進むことが前提 ● だけど計画通りには進まない ● せっかく設計書を大量に書いても、コード書かずにPJ中止になった ● しっかり書いても無駄なのではないか 24
アジャイル開発を知る ● もっと良い開発方法はないか調べて、アジャイル開発とメジャーだったスクラムを知る ● 毎週開発をしてリリースし、ユーザーのフィードバックを貰うやり方はとても良さそうに感じた 25
26自分がアジャイルを学んでいる過程 2017年 2018年 2019年 2020年 2021年XP祭り参加スクラム、XPなにもわからん念願のスクラム開発XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる
ウォーターフォール → スクラム
2つ目：スクラム開発 28私たちのチームプロダクトオーナー別チームA子会社別チームB親会社ユーザー
プロジェクト開始時 29プロダクトオーナーリーダーメンバーこの△△システムの開発をやって欲しい
プロジェクト開始時 30リーダーメンバー今スプリントは要件定義のドキュメント作成しましょう！
1スプリント後 31リーダーメンバー要件定義が終わらなかったので、次のスプリントもやりましょう
3スプリント後… 32リーダーメンバー要件定義が終わったので、次のスプリントでは設計書を作りましょう
ここまでやって、違和感
34私たちがやろうとしていたこと 要件定義 設計 開発 テスト3スプリント 2スプリント 6スプリント 2スプリントリリ丨ス1スプリント※ここでの1スプリント＝1週間計画1スプリント
これって、 ウォーターフォールっぽい
当時思っていたこと 36ドキュメントばかり作ってたら遅くなるし、そんなに書きたくない当時の私
カイゼンをしてみた
ドキュメントを減らすアプローチ ● ユーザーストーリーマッピングで図で要件の合意を取る ● API仕様書を手書きだったのをコードから生成する ● PRを待つ時間の削減と知見共有のためにモブプロ・ペアプロを始める 38
結果
40各フェーズが効率的になった テストリリ丨ス計画要件定義設計 開発カイゼンしたよ、やったね！
当時の私はアジャイルになれたと思っていた ● 当時の私はアジャイルになれたと思っていた ● 各フェーズが短くなった ● 必要十分以上のドキュメントも作られなくなった ● 言うことなし！ 最高！！ 41
リリース後 42ユーザーリーダーメンバーこの○○機能って何であるの？別に要らないんだけど
無駄な機能を作ってたことが リリース後に発覚
当時思っていたこと 44事前にデザインのレビューや機能確認したはずなのに当時の私なんでこんなことになるんだろう…？
45あらためて、私たちがやったこと テストリリ丨ス計画要件定義設計 開発
46あらためて、私たちがやったこと テストリリ丨ス計画要件定義設計 開発
1回しかリリースを していない
開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。 48『スクラムガイド』p.6
利用可能なインクリメント＝ 動くソフトウェア
50理想はこうだったのでは 要件定義1 スプリント※ここでの1スプリント＝1週間設計コーディングテストリリ丨ス計画要件定義1 スプリント設計コーディングテストリリ丨ス計画要件定義1 スプリント設計コーディングテストリリ丨ス計画
どうしてできなかった
なぜ1回しかリリースしてなかったのか ● 当時の私たちはリリース＝プロジェクトのゴールと捉えていた ● 毎スプリントのインクリメント ○ ドキュメント、(リリースしてない)コード ○ 動くソフトウェアをリリースすると ならなかった 52
この時学んだこと ● 開発者もユーザーも、実際に動くソフトウェアを触ってみないと気づかないことが多い ● 頻繁にリリースをして、ユーザーからのフィードバックを得たいと思った 53
54自分がアジャイルを学んでいる過程 2017年 2018年 2019年 2020年 2021年XP祭り参加スクラム、XPなにもわからん念願のスクラム開発XPを経験してカルチャーショックを受けるアジャイル以前ウォーターフォール開発理解したという自信違和感はありつついろいろプラクティス試してみる
スクラム → XP
3つ目：XPチーム 56 エンジニアを2チームに分けて開発1イテレーションごとにメンバーシャッフルする
驚いたこと
58要件定義1 イテレーション※ここでの1スプリント(イテレーション)＝1週間設計コーディングテスト計画1 イテレーション1 イテレーションリリース要件定義設計コーディングテスト計画リリース要件定義設計コーディングテスト計画リリースXPチームのサイクル
イテレーションごとに リリースができている
同時に全てができている ● テストを書くと同時にAPIパス・メソッド名やパラメータなどの設計と実装をする ● WebE2Eテストを書く時に要件が曖昧で書けない場合、他のエンジニアやPdMと話して要件を確認する ● 1つのストーリーが終わったらパイプラインを動かしてすぐリリースしている 60
XPのプラクティス 61『Clean Agile』p.47
XPのプラクティスを 全部実践している
実践している例 ● 就業時間中、ずっとペアプロをする ○ 1時間経ったらペアチェンジする ● TDDの徹底、受け入れテスト、継続インテグレーション ● リファクタリングはタスクとして作らず、常に行なう ● チーム全体 ○ 月イチでチームシャッフルして継続性を高める 63
これがみんな自然にできている
自然にできている一例 65○○画面で不正な文字列を入力できるようになってる私 メンバーたち
自然にできている一例 66私 メンバーたちでは直しますかまずはバグを再現するテストを書いてからバグ修正しましょう
自然にできている一例 67私 メンバーたちですねー 了解ー
TDDをやることが当たり前 になっている
TDDをやることが当たり前になっている ● バグを直すときでも、TDDを選択する ● そこに対してチームの誰もが異論を挟まない ● TDDをやることが当たり前だと思っている 69
なぜXPがみんな自然にできるのか ● 純粋にXPについて知見があるメンバーが多い ○ 加えてXP・アジャイルのスキルを他に伝えられる人も多い ○ ちょっとXPのプラクティスから外れても、誰かが疑義を投げかけて修正ができている 70
なぜXPがみんな自然にできるのか ● メンバーがコミュニケーションを嫌がらない ○ 2〜3分考えてわからなければ、聞きに行く文化 ○ 聞いたり教え合ったりする中でXPに対する知見を各メンバーが深めていっている 71
1. 3つのプロジェクトの話 722. XPは生活習慣、スクラムはフレームワーク 今日お伝えしたいこと 3. まとめ
74(再掲)2つ目のスクラムチームのサイクル テストリリ丨ス計画要件定義設計 開発
毎スプリントリリースをするには ● 動くソフトウェアを毎スプリント、リリースできていないことが1つ問題だとわかった ● 上記を実現するためには、どんなプラクティスが必要か 75
毎スプリントリリースをするには ● 特に関連の強いプラクティス ○ 受け入れテスト、テスト駆動開発、シンプルな設計、リファクタリング、継続インテグレーション ● これらについてスクラム自体には特に記述はない 76
スクラムはプロジェクトをマネジメントするためのフレームワークだ。 プロジェクトをマネジメントする方法は語っているが、エンジニアリングの話はほとんどない 77『スクラム現場ガイド』p.39
スクラムは、動くソフトウェアを顧客に届けるのを助けるフレームワークにすぎない。どんな問題でも解いてしまう魔法の粉ではないよ。問題を見つけやすくして、人びとを問題解決に集中させる。それが、スクラムの素晴らしいところだ。 78『スクラム現場ガイド』p.352
スクラムはあくまで問題検知のフレームワーク ● スクラム自体は、問題を素早く検知するためのフレームワークである ● スプリントごとに動くソフトウェアをリリースするなど、技術的な問題にはテクニカルプラクティスが必要になってくる 79
XPはエンジニアの生活習慣
(再掲)XPのプラクティス 81『Clean Agile』p.47
プラクティスとは
プラクティスは日常的な取り組みである。 83『エクストリームプログラミング』p.11
プラクティス＝日常的な取り組み
日常的な取り組み＝習慣
XPは日常的な取り組み＝習慣 を集めたもの
習慣とは、自動的に行なうまで何度も繰りかえす行動のことである 87『ジェームズ・クリアー式 複利で伸びる 1つの習慣』 p.59
XPのプラクティスが 自動的になるまで何度も繰りかえす
自然になるまでプラクティスを繰り返してた ● バグを直すときでもTDDを当たり前のように実践した ● 普段の開発でTDDを徹底して、何度も繰り返したからこそ、バグを直すときに自然とその行動が取れた 89
プラクティスを ただ繰りかえせばいいのか
価値を明確にすることが重要だ。価値がなければ、プラクティスはすぐに機械的な作業になってしまう。活動そのものが目的となり、本来の目的や方向性が失われてしまう。 91『エクストリームプログラミング』p.12
XPの価値
XPの価値 ● コミュニケーション ● シンプリシティ ● フィードバック ● 勇気 ● リスペクト 93
価値が失われたプラクティス ● ペアプログラミングで、文字通りペアになるだけ ● 一人がコードを書いているのを、もう一人が横でじっと眺めている ○ 会話をしない ○ ドライバーを交代しない 94
価値が失われたプラクティス ● ペアプログラミングで、文字通りペアになるだけ ● 一人がコードを書いているのを、もう一人が横でじっと眺めている ○ 会話をしない ○ ドライバーを交代しない ● 最終的に形骸化してやらなくなる 95
プラクティスの背後にある価値 を意識することが大事である
XPはよりアジャイルになる為の生活習慣 ● XPのプラクティスは日常的に取り組むもの ● 繰り返し実践することで習慣形成されて、自然とできるようになっていく ○ それがXPの価値を体現し続けることに繋がる ● XPの価値を意識せずに、ただ機械的にやり続けても、それはXPとは言えないし、習慣が身につかなくなる 97
1. 3つのプロジェクトの話 982. XPは生活習慣、スクラムはフレームワーク 今日お伝えしたいこと 3. まとめ
行動の背後にある価値を意識する
100『アジャイルソフトウェア開発宣言』
スクラムもXPも目指すべき価値は一緒 ● アジャイルソフトウェア開発宣言に書かれている価値を体現するために、スクラムはフレームワーク、XPは良い生活習慣、を実践し続けるアプローチを取っている ● 1つ1つのやり方も大事だが、それに固執せずに、 何の価値を目指すべきかを意識して、日々実践し続けることがどちらも大事です 101
参考文献 ● Kent Beck, Cynthia Andres(著), 角 征典(訳) (2015) 『エクストリーム・プログラミング』オーム社 ● Mitch Lacey (著), 安井 力, 近藤 寛喜, 原田 騎郎(訳) (2016) 『スクラム現場ガイド』マイナビ出版 ● Robert C. Martin(著), 角 征典, 角谷信太郎(訳) (2020)『Clean Agile 基本に立ち戻れ』ドワンゴ ● ジェームズ・クリアー (著), 牛原眞弓 (訳) (2019)『ジェームズ・クリアー式 複利で伸びる1つの習慣』 ● Ken Schwaber & Jeff Sutherland『スクラムガイド』 ● 『アジャイルソフトウェア開発宣言』 102
Thank you!103
jnuank
icoxfog417
mindman
eikohashiba
informetis
weddingpark
maijun
satokifuruya
foodison_hr
ichkura1991
10xinc
recruithokkaidousubaru
mf_recruitment_pr
iamctodd
csswizardry
hannesfritz
dotmariusz
holman
62gerente
chriscoyier
reverentgeek
mongodb
swwweet
pauljervisheath
lara