Agile2009初日

• 本日聞いてきたお話。

Face culture or face failure

• CVFチャートを使った企業文化の分析と改善。
• CVFは1980年代に流行ったものらしい。
• 4つのドメイン
  • Control(統制)
  • Compete(競争)
  • Create(創造)
  • Collaborate(協調)
• そして、相反する要素がある。
  • Control ⇔ Create
  • Collaborate ⇔ Compete
• ウォーターフォールはControlに重きをおいてる。
  • ただし100%ということはない。創造も協調も競争もない企業はありえない。
• Agileは４つの要素に分散。
• このControlに比重を置いた文化をどうやってAgileに持っていくか、というお話。
• まず己を知る、ということか。

New Approaches to Risk Management

• フィーチャは優先順位付けが必要。
• ただし、フィーチャが実現できなかったときのリスクを考えることも重要。
• そしてリスクを管理するには「割り振り(Allocation)」で考えること。
• 投資におけるポートフォリオ設計に通じるものがある。

Build and Test in the Cloud – CI and Cloud Provisioning for Agile Teams

• 最近はCloud+Agileというお題で仕事をしているので、どんぴしゃりというテーマだと思った。
• 期待した俺が阿呆だった。
• 中身はCollabNetの宣伝。
• たまにこういう発表が入るのがAgile2009にケチつけたい部分。

Integration Tests Are A Scam

• SCAM=インチキ
• 発表したのはJB Rainsberger。
• そう。JUnit Recipeの人。

JUnit Recipes: Practical Methods for Programmer Testing

• インチキというのは「偽りの安心感を生み出す」ということ。
• つまり、JBは「結合テストを網羅的に実施しても、それは偽りの安心感しか生み出さない。だから結合テストはインチキだ。」と主張している。
• なぜか？
• それは結合テストは時に(というか、ほぼ常に)必要なテスト件数が発散するから。
• 必死になって網羅的なテストを組んだとしても、それでどれほどの網羅率になるのかは明らかではない。
• そして実行時間はどんどん増える。
• テストの実行時間が増えるということは、問題検知が遅れる、ということ。
• それだけバグの摘出と対策は難しくなる。

• だったら、Unit Testの延長で「Collaboration Test」と「Contract Test」をやればいいじゃん、というのがJBの主張。
• もちろん、インターフェースをきっちりとくくり出すなどの工夫は必要。
• これだとテスト件数はクラス・メソッドの数に比例するだけ。組み合わせみたいに級数的には増えない。

• 賛否両論あるだろうけど、自分はJBの主張に同意したい。
• ただし、たまに(?)みかける巨大クラスや巨大メソッドには適用できない。
• あと、JBは要件を確認するためのテスト(UATなど)は否定していないし、やるべきだと言っている。そこは勘違いしないでほしい。