Agile2009二日目

Agile開発

初めてのお散歩

  • 本日聞いてきたお話。

基調講演: I Come to Bury Agile, Not to Praise It(PowerPoint資料)

  • シェークスピアを読んでないと理解できない題名。
  • 当然俺はなんのことかわからなかった。
  • 「Agileを葬る」といっても、もうAgileが終わりということではない。
  • 「Agileが普通になる」という宣言。

How the FBI learned to catch bad guys one iteration at a time

  • 政府系受託開発のお話。
  • 日本でいうSI屋さん。
  • お客はFBI。
  • FBIにおけるシステム開発の失敗事例は色々有名らしい。
  • そのFBIシステム部門がAgile開発を受け入れることで体質が変わりつつある、というお話。
  • 二週間の周回開発。
  • 計画ポーカー採用。
  • ペアプログラミング。
  • 継続的統合。
  • 一方で、CMMI Level-3は満たしている、と。
  • CMMIは膨大な文書類の提出を求めるものではない。
  • 追跡可能・再現可能な工程を規定できれば良い。
    • 要件ストーリを文書化。(Requirement)
    • 受入テスト実施とそれに対する承認。(Validation)
    • Subversionコミット時の記録(Verification)
  • 質疑応答時に契約形態を質問した。
  • 複数年度契約。
  • 道幅課金。
  • 日本でいう随意契約に近く、また完成するまで支払いは保証されるみたい。
  • Waterfallより早く完成し、失敗もしないからお客もハッピーなのだろう。

Covert Agile: Development at the Speed of…Government?

  • もう一つの政府系受託開発事例。
  • 顧客は空軍。
  • 対象はレーダー追跡局(RTS)
  • 世界中のあちこちにあるRTSのパラボラアンテナをいつ、どの方向に向けるかを計画するシステムらしい。
  • 元々は冷戦時代の代物で、ハードの老朽化が進行。
  • 国防に重要なシステムがMS-DOS 6.22+フロッピー+シリアル転送+ライトペンで動いていた、という事実。
  • ハードが壊れると、eBayで代替品を探していたらしい。
  • システム近代化プロジェクトはこれまで三回あったが、いずれも失敗。失敗総額2200万ドル。
  • システムを利用する現場の職員は「その現場一筋」で業務内容を熟知。
  • 一方で予算を管轄する上層部は、軍内部の定期的な人事異動のため、2年でいなくなってしまう。
  • 受託〜開発〜受入を二年以内で完了させる必要がある。
  • 失敗した場合、その原因が分析される前に責任者が交代するので、同じ轍を踏む可能性が高い。
  • 今回は「従来の半分の期間で完成させてみせる。ただし予算は従来の倍いただきます」という触れ込みで入札し、受託した。
  • 驚いたことに、契約は「ウォーターフォール」。
  • お客の予算管理部門には、ウォーターフォール的な計画書を提出し、途中の説明も全てその計画書に準じたものに。
  • お客の現場部門と開発者達はAgileで。
  • ストーリーベースでの周回開発。もともとの要件はバインダー5冊の膨大な文章＝把握するのも検証するのも困難。
  • まず、簡単な「大枠」のアプリを作り、それを現場の人たちに使ってもらう。
  • そこから徐々に各ストーリを実装。
  • 一方で、文書書き専門の職員を雇い、顧客上層部報告に必要な文書類を整備した。
  • Agile開発は15-20人。
  • 文書書きは20人体制。
  • 予定納期までにシステムは完成。
  • 顧客上層部はAgile開発だったことを全く知らない。

注記

上の政府系事例二つは実に対照的で興味深い。

  • 随意契約 vs 入札
  • 道幅課金(可変納期・可変予算) vs 固定納期・固定予算
  • 顧客上層部がAgileに理解 vs 顧客上層部は計画管理に興味を示さない(Waterfallで決めうち)
  • 少人数で軽い開発 vs オーバーヘッドの多い体制(文書書き職員が開発者より多い)
  • お客の文化・お客が求めるものに対して柔軟に対処できるのがAgileのすごいところ。

Agile in the Enterprise Corporation

  • HP、Qualcomm、BMC Softwareという大企業における「組織のAgile化」の話。
  • 開発の現場がAgile化するのは、この3社では「当然」の話。
  • 開発だけでなく、企画・販促・サポートなどの各組織や経営までもAgile化する必要がある。
  • 株式公開企業なら、なおさら。
  • 自社開発だろうが、外部に開発を委託していようが、Agile化しないと損するし、競合に市場をとられてしまう。
  • ウォーターフォールやRAP計画を活用する組織体制は「時間と金のムダ」
  • 計画管理や経過報告と、それによる軌道修正を経営・管理レベルで受け入れないと、Agile開発の旨みを活かせない。
  • 営業や顧客窓口の人達に早期リリースの製品を使ってもらわないと、やはりAgile開発の旨みを活かせない。

Agile Lightweight Project Management with Google Docs

  • 分散Agile開発環境におけるプロジェクト計画管理をGoogle Docのスプレッドシートでやってしまおう、というお話。
  • 無料。
  • 地域分散していても、みんな同じ文書にアクセスできる。
  • Backlogの管理はもともとスプレッドシート向け。
  • 計画ポーカーゲームもスプレッドシート上でやれる。Skypeで話しながらやると効果的。
  • Google Data APIで特定の数値を取り出し、集計したものを大型ディスプレイに表示し「見える化」を実現。
  • ちなみに「見える化」は英語でも「Mieruka」。

印象に残った言葉

  • Alister Cockburnによる基調講演: 「開発言語に関するスキルは5年で陳腐化する。だから私は5年毎にスキルアップしている。」
  • 同じくAlister: 「ソフトウェアの開発は工芸(Craft)」