Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to XP lives, XP dies, XP lives again !!
Similar to XP lives, XP dies, XP lives again !! (20)
More from Masanori Kado
More from Masanori Kado (20)
Recently uploaded
Recently uploaded (9)
XP lives, XP dies, XP lives again !!
- 2. XP lives (past) 2 1999/10 2004/11 2007/11 翻訳もあるよ
- 4. XP dies ... 4 and Scrum lives
- 5. Scrum lives ... 5 https://www.scrum.org/About/Origins By 2006, we had 30,000 CSMs. By early 2009, there were more than 60,000 CSMs.
- 6. ... and gets dying 6 https://www.scrum.org/About/Origins （2009年8月に辞任勧告） in August 2009 when the Scrum Alliance board of directors unanimously asked for my resignation （自分で作った組織に追い出される）
- 9. 達人デイヴの激怒事件 ‣ 👤<10年プログラム書いてないよw ‣ 👤<俺なんか20年書いてないよwww ‣ <なめとんのか💢 9 http://www.infoq.com/jp/news/2014/11/pragmatic-dave-agility 2人の"アジャイルコンサル"の会話 基調講演の予定を変更「Agile is Dead」
- 23. 23 Mad Max: Fury Road 一方的に「与える」モデル💀
- 24. Welcome to the Wasteland (again) 24 Mad Max: Fury Road
- 25. Mad Max: Fury Road 25 XP lives again !!
- 27. 私からのご提案 ‣0. プリクエル🎬 ‣1. 人間性を重視したときめき💖 ‣2. 適応型計画づくりとその技術🌿 ‣3. もっとエクストリーム🚀 27 これから「"俺も"XPを導入したい」と思う皆様へ
- 29. プログラミングチョットデキル（本当の意味で） ‣公開できるものは少ない……。 ‣Re:VIEW • https://github.com/kmuto/review • 組版ツール。XPE2ndもぜんぶコレ。 ‣卒業制作っぽいやつ • https://github.com/jointry/jointry • Scratchモドキのペアプロツール。 ‣プログラミングの本 29 http://www.slideshare.net/kenshimuto/review-36769754
- 30. 20分経過 30
- 31. 0. プリクエル🎬 31
- 42. 42
- 43. 何度も協力して知識を増やす 43
- 46. トヨタウェイと（だいたい）同じ 46 http://www.toyota.co.jp/jpn/sustainability/report/archive/html2012/employees/
- 47. 30分経過 47
- 52. 我々はモノではない 52 Mad Max: Fury Road
- 55. モノではない何か 55
- 57. 57
- 59. 新しいソーシャルチェンジ 59
- 67. 40分経過 67
- 72. “ ”72 Does it spark joy? （それはときめく💖か？） こんまり先生いわく
- 73. 73 なんか聞いたことがある！
- 74. 74 ⇒ ときめき💖の道
- 79. もはやどうでもいい！
- 80. ここまでのまとめ ‣人間性が大切 ‣人をモノ扱いする認定とかいらない ‣まずはHRT（with『Team Geek』） ‣ペアプログラミングをやってみよう ‣ときめく💖プラクティスを選択しよう 80
- 82. XPが目指している（いた？）もの 82 Kent Beck, "Extreme Programming Explained"
- 84. できることを増やすプラクティス ‣ソフトウェアの設計： •1. テスト（自動テスト） •2. 継続的インテグレーション •3. リファクタリング ‣他の分野にもあるはず！ •けど、何かはわからない……。 84 http://bliki-ja.github.io/SpreadingIncrementalism/
- 90. 技術的負債の四象限 90 島本和彦『燃えよペン』 井上雄彦『SLAM DUNK』 横山光輝『三国志』 無鉄砲 慎重 意図的 不注意 http://bliki-ja.github.io/TechnicalDebtQuadrant/ 高橋陽一『キャプテン翼』
- 92. 「経験」してから設計する ‣最終責任時点 •意思決定は遅いほうがチャンスは大きい（by ポッペンディーク） •とはいえ、いつが「最終」なのか不明 😓 ‣セットベース開発 •複数の案を実装してみる •→ そこから選ぶ😄 •「熟考」だけよりいいものができる（可能性が高い） ‣可逆性を確保する •できるだけあとでやり直せるようにする（→次ページ） 92
- 94. できることを増やすプラクティス ‣Development servers ‣Code review ‣Internal usage ‣Staged rollout ‣Dynamic Configuration ‣Correlation ‣IRC ‣Right hand side units ‣Shadow production ‣Frequent pushes ‣Data-informed decision ‣Advance countries ‣Soft launches ‣Double write/bulk migrate/double read 94https://www.facebook.com/notes/kent-beck/taming-complexity-with-reversibility/1000330413333156 （あとで読んでね）
- 96. Facebookの事例 96 D. G. Feitelson, E. Frachtenberg, and K. L. Beck,“Development and deployment at facebook,” IEEE Internet Comput., vol. 17, no. 4, pp. 8–17, 2013. たぶんKB
- 97. Facebookの事例 ‣永久に開発（継続的デプロイ） •実際のデプロイは週1回。内部リリースは1日2回。 ‣「A/Bテスト」で実験 •「経験」してから選択する •「まだ要求開発や仕様書で消耗してるの？」 ‣6週間の新人研修 •書いたコードをすぐにリリースする訓練 ‣エンジニアには責任と覚悟が欠かせない 97 D. G. Feitelson, E. Frachtenberg, and K. L. Beck,“Development and deployment at facebook,” IEEE Internet Comput., vol. 17, no. 4, pp. 8–17, 2013.
- 98. Facebookの事例 98 D. G. Feitelson, E. Frachtenberg, and K. L. Beck,“Development and deployment at facebook,” IEEE Internet Comput., vol. 17, no. 4, pp. 8–17, 2013. ますます活性化
- 99. その他の事例（2つ） 99
- 100. 100
- 105. Re:VIEWの事例 ‣普通のFLOSS開発（自動テスト + TravisCI） ‣課題駆動開発（リアルに困ったものを実装する）※熟考 + 経験 •自分の仕事（組版や出版事業）に使っているので切実 •「あったら誰かが使いそう」みたいな機能はあんまり入らない ‣書籍データが別にあるので後方互換性が超大切 •安易に新機能入れたら対応が大変😢 （増刷のつらみ……） ‣コミケ駆動開発（2、6、10月リリース）が特徴的 ‣開発者会議を不定期に実施 •チケットの落ち穂拾いと利用者（ 開発者）のヒアリング ‣ムトゥ神（@kmuto）のスライドおすすめ 105 http://www.slideshare.net/kenshimuto/
- 110. 3. もっとエクストリーム🚀 110
- 113. プロジェクト 113
- 114. ⇒プロダクト ‣もはや（実質的に）終わりはない •プロジェクト：有期性の業務（PMBOK） •短期決戦の戦略思考（戸部、野中他『失敗の本質』） ‣すくなくとも両者を区別しよう •Project Manager / Product Manager ‣チームにプロダクトをつけよう •プラクティス「チームの継続」「責任の引き受け」 •Uncle Bob Martin『Clean Coder』も参照（宣伝……） 114
- 115. ペアプログラミング 115
- 117. 117 Hohman, Moses M., and Andrew C. Slocum. "Mob Programming and the Transition to XP." proc. First XP Universe Conference. 2001.
- 119. 懸念点 119 翻訳はしばし待て!! For many organizations, mob programming is too extreme; a WIP limit of one is probably not suitable for everyone.
- 120. ストーリー 120
- 121. ⇒ 仮説（指標も一緒に） 121
- 123. その他いろいろ 123
- 124. インクリメンタルな設計 ⇒ ‣ リバーシブルな設計 •Facebookの話みたいな感じ ‣ ランタイムな設計 •動かしながら設計を変えていく •（それSmalltalkでできるよ） 124
- 125. テストファースト ⇒ ‣ 仮説テストファースト •仮説を検証するために何ができるか •結果が出るまでに時間がかかるのが難点 ‣ 探索的テストファースト •テスターと協業 •フィードバックループの深化 125
- 126. 本物の顧客参加 ⇒ ‣ 本物の顧客開発 •建物の外に出て、顧客を見つけ出す ‣ 本物のユーザー参加 •早い段階から実際に使ってもらおう 126
- 127. チームの縮小 ⇒ ‣ マイクロチーム（cf. マイクロサービス） •Bounded Contextごとにチーム文化を生成 •それぞれが自律している（ex. Spotifyのチーム） ‣ ひとりのチーム •フルスタックエンジニア（死語？ •スタンドプレーから生じる∼みたいな ‣ マシンのチーム •チャットで話しかけたらボットだった!! •データ駆動で意思決定を支援（cf.「アイアンマン」のジャービス） 127
- 128. [NEW] プロボノ（ボランティア + 公共性） ‣弁護士や医師などの活動 ‣社会に役立つソフトウェア開発 •ex. Code for Japan ‣社会的な意味での 「ソーシャルチェンジ」 128
- 129. 他にも考えてみてください！ 129
- 130. 全体のまとめ ‣おじさんたちの青春（XP lives） ‣もはやアジャイルは死んだ（Agile/XP dies） ‣XPなら自分たちでやれる（XP lives again） ‣人間性の回復 •HRT、ペアプロ、ときめき、ゆとり ‣適応性の維持 •できることを増やす、経験重要、続けることが正義 ‣もっとエクストリームにするたゆまぬK.U.F.U. 130
- 131. おわりに 131
- 135. 135
- 136. おしまい ＆ 質疑応答 136 XPに限らず、 お話しましょう :-) @kdmsnr kado.masanori@waicrew.com