スライド
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が大事
- おかしなアジャイルが増えている
エイヴ様からのご提案
- アジャイルを広めて、定義し直そう
- みんなに届けられる賞品を作る
- 難しく見えるような工夫をしよう
- カタカナ用語、新しい
- 開発者に売りつけよう
- アジャイルを使ってないんなんて馬鹿だよね
- 企業に売りつけよう
IT業界以外にも
- Leanとか言って
こんな例はおかしい
- 一方的に「与える」モデルになっているから
- 自分達で作り上げていくのがAgileなのに
- XP lives again
XP2ndのいいところ
- やり方が書いてない
- 教え方が分からない
- この本を読んでもすぐに導入できない
プリクエル(前の話。歴史)
- XPは何を伝えたかったんだと思う?参照
アジャイルマニフェストの歴史
「アジャイル」はイギリス人(マーティン・ファウラー)が決めたから
- マイクビードルは本人が「自分が名前を付けた」と言っていた(会場の意見)
- みんな言っているみたいですね。サイトではこのように書いてありました
- マイクビードルは本人が「自分が名前を付けた」と言っていた(会場の意見)
- アメリカ人が「アジャイル」と発音できるかが一番の不安点だった
Conversational(対話)
- Agileという言葉よりもこの言葉のほうが適任ではないか
DDDのような会話、インタビュー、Leanのように仮設検証が重要だが、それが失われているのではないか?
XPの15章で述べている
- 「マーチン・ファウラーは翻訳機なので、マーチン・ファウラーの言葉を見よう」
- マーチン・ファウラーはまとめ職人
Agile開発で重要なこと
人間性を重視したときめき
テイラー
- 科学的管理法を導入した人
科学的管理法
- 労働者の生産性を測定し…
- 労働者の生産性をあげよう
- チャップリンのモダンタイムスが代表的
怠けたりミスするので、後工程でチェックすべき
我々はモノでない
- モノの証明(認定)は良くない
- 金儲けをしているだけだ
- XPは認定を作らない
モノではない何か
- 機械学習で人間以外が作業をする時代
- 自分達ならではのことを考える時代
ラッセル
- 数学者や物理学者はおじいちゃんになると哲学者になる
- 進歩のために必要な個人の創造性と存続のために必要な
- まとめると「XPはソーシャルチェンジである」
新しいソーシャルチェンジ
- よくわからない
- 『Team Geek』を読んでもらう
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月)が特徴的
- 技術同人誌系で良く使ってもらっているから、納入の時に間に合うように
余談
- オブジェクト指向でDDDは辛い
- 型システムこそDDD
もっとエクストリーム
自分達でプラクティスを作るしかない
プロジェクト単位→プロダクト単位へ
- ソフトウェアの寿命はない
- プロジェクトのように終わりを決めてしまうのは良くない
- Project ManagerとProduct Managerを区別しよう
- チームにプロダクトをつけよう
- プロダクトに人員を充てるのではない
モブプログラミングをしよう
Story
- 仮設を作ろう
- リリース後、仮説を検証しよう
- プログラマがコードを書かなくても検証可能なことがある
その他
インクリメントな設計
- リバーシブルな設計
- ランタイムな設計
テストファースト
本物の顧客参加
チームの縮小
- マイクロチーム
- 一人のチーム
- フルスタックエンジニアではなく、ワンオペエンジニアという言葉で
- マシンのチーム
プロボノ
- 弁護士や意思などの活動
- 社会に役立つソフトウェア開発
- 社会的な意味での「ソーシャルチェンジ」
まとめ
- おじさんたちの青春(XP lives)
- もはやアジャイルは死んだ
- XPなら自分達でやれる
- 人間性の回復
- 適応性の維持
- もっとエクストリームにするための更なる工夫
おわりに
ラズベリージャムの法則
- 広げれば広げるほど、意識や情報が薄くなっていく
いちごジャムの法則
- つぶがあれば、どこまでも薄くはならない
- Agileの場合は人間性や適用性
自分の道を歩き出す勇気を
- XPの価値の最後の一つ
質疑応答
- Q.ときめき駆動開発と言っていたが、お客さんに対しても?
- A.従来、「お客さんに価値を」と言っているがよくわからないので、ときめきを伝えている
- Q.とはいっても、ときめきを評価しろと上司に言われたりすると思うが
- A.会話して応えを導き出してみれば良いのでは?(私は会社員ではないので逃げちゃう)
- 上司がときめくことを含めるとか
- 同じ方向にときめくものを探す
- 対決軸に行かないことが大事
- そういうときはValueを使ってみるのも手
感想
- ときめき駆動開発っていいな
- 「開発手法」と聞くと技術的な話に思えちゃうけど、やっぱり人間の気持ちって大事
- 形式的に教えられないことは広まりづらくなるよね…(しみじみ)
- 私のこのレポートは補足程度にして、そんなものよりも本編のスライドをチーム内の他の人にもぜひ見てもらいたいと思いました
- そしてAgileの誤解に気付いてもらいたいです