XP祭り2015 基調講演「XP lives, XP dies, XP lives again!!」参加レポート #xpjug

スライド

www.slideshare.net

自己紹介

  • 角 征典

翻訳本

  • 6月に翻訳本を書いた
  • おっさんたちが「実はXP好きなんだよね」という感想が多かった
    • 若手に読んでもらえない
  • 若い人へどう迎合しようか
  • 翻訳が読みやすくなっている

  • 1999年に第1版、2004年に第2版を出版(この頃まではXPは生きていた)

  • 2007年Agile Developmentが発刊(実はXP導入の話)
  • XPは2008年ぐらいに死んだのでは?
  • 当時もツールや環境が無かったわけではなかった

XP dies...and Scrum lives

  • スクラムガイド
  • XPのわかりにくかった部分をフレームワーク化してくれた
  • 認定スクラムの数が30000人(2006年)→60000人(2009年)
  • 元々は認定スクラムは参加賞だったのに、次第にお金儲けのためになっていった
  • 「金儲けでないほうが良い」と主張したら、自分で作った組織を追い出されることに

ヘロヘロScrum

  • スクラムが一般化されたことで、技術的な側面が見られなくて、スクラムが死んでいった

達人デイヴの激怒事件

Agileで大事なこと

  • プラクティスではなくエビデンスベースのGROWSが大事
  • おかしなアジャイルが増えている

エイヴ様からのご提案

  1. アジャイルを広めて、定義し直そう
  2. みんなに届けられる賞品を作る
  3. 難しく見えるような工夫をしよう
    • カタカナ用語、新しい
  4. 開発者に売りつけよう
  5. 企業に売りつけよう
  6. IT業界以外にも

    • Leanとか言って
  7. こんな例はおかしい

    • 一方的に「与える」モデルになっているから
    • 自分達で作り上げていくのがAgileなのに
  8. XP lives again

XP2ndのいいところ

  • やり方が書いてない
  • 教え方が分からない
    • この本を読んでもすぐに導入できない

プリクエル(前の話。歴史)

  • XPは何を伝えたかったんだと思う?参照

アジャイルマニフェストの歴史

Conversational(対話)
  • Agileという言葉よりもこの言葉のほうが適任ではないか
  • DDDのような会話、インタビュー、Leanのように仮設検証が重要だが、それが失われているのではないか?

  • XPの15章で述べている

  • 「マーチン・ファウラーは翻訳機なので、マーチン・ファウラーの言葉を見よう」
  • マーチン・ファウラーはまとめ職人
Agile開発で重要なこと

人間性を重視したときめき

テイラー

  • 科学的管理法を導入した人

科学的管理法

  • 労働者の生産性を測定し…
    • 労働者の生産性をあげよう
  • チャップリンのモダンタイムスが代表的
  • 怠けたりミスするので、後工程でチェックすべき

  • 我々はモノでない

  • モノの証明(認定)は良くない
    • 金儲けをしているだけだ
    • XPは認定を作らない

モノではない何か

  • 機械学習で人間以外が作業をする時代
  • 自分達ならではのことを考える時代

ラッセル

  • 数学者や物理学者はおじいちゃんになると哲学者になる
  • 進歩のために必要な個人の創造性と存続のために必要な
    • まとめると「XPはソーシャルチェンジである」

新しいソーシャルチェンジ

  • よくわからない
  • 『Team Geek』を読んでもらう

HRT

  • 謙虚
  • 尊敬
    • XPの価値の一つ
  • 信頼
  • 自己啓発っぽい
  • けどGoogleではこれを守られている
  • QiitaやKaizen PlatformでもHRTの文化を導入している

ペアプログラミング

  • まずは演習
  • チームの最小単位はペア
    • ペアで体験してもらう
  • 楽しいを経験してもらう
  • フィードバック、コミュニケーション
    • XPの価値の二つ

シンプリシティ

  • XPの価値の一つ

こんまり流片付け術

  • 物を捨てること

    • 残すものを選ぶ
      • それはときめくのか?を重要にする
        • これは教えることができない
    • 以前までは断捨離術
      • 生活が荒んでいく
    • パターンランゲージと一緒の考え方
      • このデザインはときめくのか?
  • 時を越えたプログラミングの道→ときめきの道

プラクティス==パターン

  • XPもときめき
  • ときめくプラクティスを選ぶ
  • これからはときめき駆動開発(TDD)

  • エクストリームの純度(第21章より)はどうでもいい

    • ときめいていればOK

適応型計画づくり

XPが目指しているもの

ソフトウェアの設計

反論

  • 小さい規模ならいいけど、大規模プロジェクトではアーキテクチャもちゃんと考えるべき

設計=スタミナ仮設

  • 悪い設計は機能追加の速度が落ちていく
  • 良い設計は機能追加の速度は上がっていく(最初の2週間ぐらいは悪い設計の方が早く作れるけど)
  • 技術的負債に陥る

技術的負債の四象

  • 無鉄砲、慎重
  • 意図的、不注意
  • 森崎くんは無鉄砲かつ不注意
  • あえて…寝る!無鉄砲かつ意図的
  • まだあわてるような時間じゃないは慎重かつ意図的
  • 孔明の罠は慎重かつ不注意
    • ここを一番気をつけるべき

第14章「いつやるか?」「あとで」

  • 熟考よりも経験が重要

経験してから設計する

  • 最終責任時点(Leanより)
    • とはいえ、いつが「最終」なのか
    • この考えは使いたくない
  • セットベース開発
    • 複数の案を実装してみる
    • 実際にはmasterブランチだけで開発しているような人も
    • 10個ぐらいブランチを作っても良いじゃん

可逆性を確保せよ

  • やっぱ止めたをできるようにする
  • How Facebook Worksという基調講演参照(まだ動画が上がってないけど)

Facebookの事例

  • Facebookの論文より
  • 永久に開発(継続的デプロイ)
  • A/Bテストで実験
    • Facebookでは要求開発をしていない
  • 6週間の新人研修
    • 書いたコードをすぐにリリースする訓練
    • エンジニアには責任と覚悟を持たせるため

その他の事例

Rails
Re:VIEW
  • 出版のためのツール
  • 普通のFLOSS開発
  • 課題駆動開発
    • 熟考+経験
    • 「あったら誰かが使いそう」みたいな機能はあんまり入らない
  • 後方互換性が超大切
  • コミケ駆動開発(2,6,10月)が特徴的
    • 技術同人誌系で良く使ってもらっているから、納入の時に間に合うように

余談

もっとエクストリーム

自分達でプラクティスを作るしかない

プロジェクト単位→プロダクト単位へ

  • ソフトウェアの寿命はない
    • プロジェクトのように終わりを決めてしまうのは良くない
  • Project ManagerとProduct Managerを区別しよう
  • チームにプロダクトをつけよう
    • プロダクトに人員を充てるのではない

モブプログラミングをしよう

Story

  • 仮設を作ろう
  • リリース後、仮説を検証しよう
  • プログラマがコードを書かなくても検証可能なことがある

その他

インクリメントな設計

テストファースト

本物の顧客参加

チームの縮小

  • マイクロチーム
  • 一人のチーム
    • フルスタックエンジニアではなく、ワンオペエンジニアという言葉で
  • マシンのチーム

プロボノ

  • 弁護士や意思などの活動
  • 社会に役立つソフトウェア開発
  • 社会的な意味での「ソーシャルチェンジ」

まとめ

  • おじさんたちの青春(XP lives)
  • もはやアジャイルは死んだ
  • XPなら自分達でやれる
  • 人間性の回復
  • 適応性の維持
  • もっとエクストリームにするための更なる工夫

おわりに

ラズベリージャムの法則

  • 広げれば広げるほど、意識や情報が薄くなっていく

いちごジャムの法則

  • つぶがあれば、どこまでも薄くはならない
  • Agileの場合は人間性や適用性

自分の道を歩き出す勇気を

  • XPの価値の最後の一つ

質疑応答

  • Q.ときめき駆動開発と言っていたが、お客さんに対しても?
    • A.従来、「お客さんに価値を」と言っているがよくわからないので、ときめきを伝えている
  • Q.とはいっても、ときめきを評価しろと上司に言われたりすると思うが
    • A.会話して応えを導き出してみれば良いのでは?(私は会社員ではないので逃げちゃう)
    • 上司がときめくことを含めるとか
    • 同じ方向にときめくものを探す
    • 対決軸に行かないことが大事
    • そういうときはValueを使ってみるのも手

感想

  • ときめき駆動開発っていいな
  • 「開発手法」と聞くと技術的な話に思えちゃうけど、やっぱり人間の気持ちって大事
  • 形式的に教えられないことは広まりづらくなるよね…(しみじみ)
  • 私のこのレポートは補足程度にして、そんなものよりも本編のスライドをチーム内の他の人にもぜひ見てもらいたいと思いました
    • そしてAgileの誤解に気付いてもらいたいです