twitterのTLで派生開発カンファレンス2010のハッシュタグが盛り上がってるのを見て、久しぶりにXDDPのことを思い出した。
このブログでも、だいぶ昔に少しだけ触れているのだが、その後
「派生開発」を成功させるプロセス改善の技術と極意 |
|
 |
清水 吉男
技術評論社 2007-10-27 おすすめ平均 |
この本を買って読んだのか、立ち読みで流したのか覚えていないのだけど、「ちょっと面倒かなぁ」と思ったことだけは覚えている。
- 変更要求仕様をまずは確定できないといけない
- 当然ではあるけど、お客も何がしたいか分かってない時があるのでそこを詰めるだけでも時間がかかる。空気を読んで先回りして仕様を作ってしまう下請けが重宝されたりするが。
- 対応期限3日以内などの超短期の場合にどこまでプロセスを回せるか
など、当時やっていたプロジェクトではそのまま適用させるには難しい感じがあった。元のプロジェクトの進め方に無理があるのは分かっていたのだけれど。
あれから別のプロジェクトを担当して今はちょうど派生開発のようなフェーズ、一度作った機能の品質向上を目的とした一部作り替えの作業を行おうとしているので、
- 作り替える個所と作り替えなくても良いところの切り分け
- 新しく作った部分が、作り替えていない個所にどのような影響を与えそうか
- 前回作ったときに見落とした、仕様的に競合している個所、仕様バグは無いか
というのを設計段階できちんと意識を持ってからソースコードの改修作業に入りたい。これは少しXDDPのエッセンスくらいは適用できるんじゃないか。
...と、XDDPについてググってみると、それだけでいくつか有用な資料が出てくる。
- XDDP によるソフト派生開発の QCD 向上活動
- 無知見プロジェクトに対する XDDP の適用
- テストの質を上げるための要求仕様書
- Togetter - まとめ「まとめ「派生開発カンファレンス2010」」
- XDDPと言う派生開発: プログラマの思索
あとXDDPの場合は"USDM"、"PFD"のような固有用語が出てくるのが少し戸惑うところだろうか。
どういう手順でどういう成果物を作って、その作った成果物が何か別のプロセスのインプットとなるかどうかというのを先に定義しておくということなのかな。成果物も色々と細かく作る必要がある点は賛否ありそう。
ソースコードを修正する前に十分な設計と改修個所のレビューをやってからソースコードを弄るのは確かに有用だと思う。よく、ソース修正に着手してから、あのケースの場合の考慮が漏れてた、この関数も修正しないとと予定より作業ボリュームが膨らんでしまうことが発生するので。ただ改修個所の洗い出しと設計にどれくらいの工数がかかるかの見積もりは難しいかもな...。
