ソフトウェアプロセス(3)
少し調べる
Rational Unified Process（以後RUP）を少し調べた。
- RUPはウォーターフォールモデルの後継であり、大型開発に向いていること。
- ウォーターフォールモデルでは対応しづらかった仕様変更に対して、Iterative Development（反復型開発）とUse Case Driven（ユースケース駆動）という二つの考え方を軸に、対応しやすくしていること。
- eXtream ProgrammingはどちらかといえばAnti Rational Unified Process系勢力であること。
- RUP自体はでかすぎてよくわからんこと。
という辺りは理解した。
ベトナム人SEの彼もよく勉強はしているが、本の受け売りで本質が理解出来ていないのか、単に経験が不足しているのか、他の開発モデルに対する知識が足らないのかはわからないが、彼にCUVELの開発プロセスを定義させるのが難しいということも、RUPを1時間程度勉強した私が彼の意見の盲点をつけたという事で、まあ理解出来た。
日本語記事で一番まとまっているのは、IT情報マネジメントさんでしょう。
http://www.atmarkit.co.jp/im/carc/serial/process02/process02_1.html
おまけでAgile Unified Process（英語）。
http://en.wikipedia.org/wiki/Agile_Unified_Process
で、どうしようかという話
ベトナム人SEの彼が構築出来ないなら構築出来ないって事だから、構築は出来ないんじゃないのという結論。
私の時期尚早という考え方に変わりはないし、一年目は10人未満の案件が多いだろうからスタンドプレーで十分。
スタンドプレーにせざるを得ないのは私が多忙であることが予想されるためであり、私が多忙でありながらプロセスを固めるとしたら、ベトナム人SEの誰かが屋台骨を作らなければならないが、少なくとも彼には無理。
よって、当初予定通りに進める事になりそう。
1年目小規模案件、2年目中規模案件、3年目大規模案件のプロセスを、それぞれアジャイルベース、(アジャイル + RUP) / 2、RUPという感じでまとめていければいいんじゃないかな。
オフショア独特のやり方も組み込まなければならないし、ベトナム人エンジニア向きのプロセスというのもあるはずだからな。
