アジャイルに行こう!

Agile Software Product Line を考える

»

Agilesplmonocro SPLASH2010 のバンケットのテーブルで、Software Product Line の研究で有名なPOSTECH(浦項工科大学)のKYO-CHUL KANG 教授とご一緒させて頂きました。

先生と話がはずみ、ぼくはアジャイルのコミュニティーにいて、という話をして、Agile と Software Product Line について、食後のブレインストーミングをさせていただいた。同じテーブルに、早稲田の鷲崎先生、デンソーの岩井さん、がこの議論に加わり、カミナプキン上に、そのコンセプトを書き出したのが、これです。

「まずは、Agile Product Line というものがあるとしたら、What is it ? であり、What is it for ? というところから考えなくてはならない」

という方針のもとに、

  • AgileもSoftware Product Line(SPL)も、Business Valueが目的(Goal)である。ただし、そのアプローチが違う。(3つの○。上位目的がBusiness Valueで、右がAgile、左がSPL)
  • 経済的観点から、SPLはAssetベース。AgileはFlowベース。SPLはB/S志向であり、AgileはP/L、さらにはキャッシュフローベース。
  • SPLはProduct Familyのドメイン知識をAssetとして蓄え、その再利用によって効果的な製品開発を行う。キーとなるソフトウェア品質は「再利用性」。
  • Agileはワンショットのプロジェクトにおいて、フローベースでROIを最適化する。1プロジェクト毎のコンテキスト重視。キーとなるソフトウェア品質は「変更可能性」。
  • 両者を融合するには、ワンショットのプロジェクトをAgileで、プロジェクト終了時に、得たknowledgeのアセット化により、SPLへフィードバックする。
  • これにより、企業ワイドで、再利用資産を使うことにより、さらなる製品のAgility(早期の市場投入)ができるようになる。

という概要を書き出しました。そして、

  • Agile Software Product Line とは、個々のプロジェクトをAgileで、そこから得たknowledgeを企業ワイドに資産として蓄えることで、特定のドメインについての製品開発全体において、顧客ニーズへのすばやい対応、対コスト効果の高い開発をはかる企業活動である。

と定義してはどうだろう。(おそらくもうすでにある概念だと思うが、あえてググらずに、そのテーブルの議論をまとめた)

さて、この領域に関心がある人はどれくらいいるだろうか?まだまだ、アジアから、新しい活動が出ないといけない、そう思っています。また、KANG先生は日本においての松本吉弘先生の80年代のSoftware Factoryがいかに衝撃的であったか、そして、それがSPLに与えた影響について話しておられました。このAgile Software Product Line ですが、新しいコンセプトとして、研究・実践して行きたい人は、何かやって行きましょう(とりあえずコメントください)。

Profkangdinner4small 議論に参加してもらった、鷲崎さん、岩井さん、ありがとうございました!

こういった議論は、突発的に起こるもので、その場で書き留めるには、やはり紙ナプキンとペン、というのが一番いいようです。ボールペンで書くと破れやすいのが注意ですね。写真は、ボールペンで書いた後で、蛍光ペンで少し装飾してモノクロにしました。

Comment(5)

コメント

関心あります (^^)/

このAgile Software Product Lineのコンセプトは、今まさに自分が実践に取り組まなければならない内容です。
この領域に興味のある方、意見をお持ちの方には是非お話を伺って議論を深めたいと思っています。
機会がありましたらよろしくお願いします。

yhas

こんにちは。第一感で思いついたことをざっと書いてみます。

・できれば足し算以上のものを求めたい。すぐに思いつくものはSPLのプラクティスをアジャイル視点で見直してみるとしたら、何か変わるのだろうか?ということ。もし変わるならそれは既にに面白そうだし、変わらないとしたら本質的に直行しているか、もっとextremeに考えるべき、という示唆が得られそう。
・『アジャイル開発の本質とスケールアップ』という書籍を思い出した。スケールの問題をどう扱うか。個人的には「大規模な組織ではどう運用するんですか?」という良くある問いよりも、アウトプットの水準を向上しつつ、いかに開発組織を小さくするかに興味あり。
・企業ワイドでフローを最適化すると考えると、JITとかSCMが思い浮かかぶところ(ソフトウェアJITは良く知りませんが)。大きく括りすぎると何でも同じ話になってしまう気がするので、SPL+agileのコンテキストで考えるのに適した話題って何だろう、と思う

Agileがフローに関する観点で、SPLがアセットに関する観点であることは直感的ではあるがすぐに腑に落ちた。
しかしここで扱う価値について、それはどういう単位でどういう表現であることが適切なのかが課題であると思っている。
最近はMMF(Minimum Marketable Feature)という単位が最有力だと思っている。
ただMMFはどう表現すれば適切で、その価値はどのように評価するべきかという根本的な課題が残っている。

非常に面白い! 丁度昨日今日読んでいた論文が、一本が agile な SPLE について、もう一本が製品リリース後に参照アーキテクチャの実際の適合性を見て徐々に将来に向けて効果的かつ現実的な形に整えていくという事例についてでした。
プロジェクトにフォーカスして知見を積んで製品系列開発の途中から SPL に移行するという試みは既になされています。そこでは「知見を積む」段階では XDDP が使われています。知見の反映という観点では、ここに書いておいでの agile SPLE の方が短いですね(agile だから当たり前か)。
いきなり全面的に SPLE を採用するのではなく、部分的に(製品系列の一部、製品の一部、一部のプロセス、etc.)採用することを SPLC 2010 では partial SPLE と呼ぶ人がいました。目論見としては、そこから(必要に応じて)スコープを拡げて行きます。
その、スコープを拡げるという考え方と、書いておられる agile での knowledge の SPL 化は、観点は異なるかも知れませんが、徐々に蓄積していく/されていくという点では同じに見えます。

一枚かませてください。

コメントを投稿する