C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: 開発管理形態

分類:[設計/仕様]　

お世話になっております。

入社以来8年間、ひたすら・・・

というわけではないですが、専らコーディングをメインに仕事をしてまいりました。

今回新しいプロジェクトのソース管理することになったのですが、自分が今まで経験した手法(と呼べるものかどうか)

と言いますと、ファイルサーバを設けてモジュールごとにフォルダをわけ、更にバージョンごとに管理したり、

上記にVisualSourceSafeをかませたり、最近ではリポジトリサーバを構築して管理したりと、その程度なのですが、

改めて自分が管理するとなると、管理形態にはどのような種類があり、規模によって適した手法が何なのか、

全く知識がないことに顔面蒼白状態になっております。

ネットで色々と探してはみたのですが、有力な情報が得られず、そもそも管理形態に様々な手法があるのかどうかすら、

その観点が間違っているのかなと怪しくなってきております。
(ポリシーの問題？)

色々な開発を経験された方で、管理形態にはこういったものがあるなど、サイトのご紹介でも構いませんので、

どうかアドバイス頂けると幸いです。

※現時点では
リポジトリサーバを構築し、
Root
|-Origenal
|-各種オリジナルソース
|-Release
|-Ver1.0.0.1
|-Ver2.x.x.x
|-・・・
|-Brunch
|-ベンダーごとの各種カスタマイズ版
|-Document

くらいしか思いつかないのですが、御教授頂ければ幸いです。

「管理」「形態」という文言にどういう意味合いを持たせて使っているのか
よくわからないけど、結局のところ何がしたくて、何が訊きたいの？
それがわからないとコメントのしようがないんで。

ソースコードの履歴管理＋リリース履歴管理、でよいのであれば
なんであれソースコード管理ツール(SCM)が１つあれば十分。
VisualSourceSafe でもいいし、俺なら Mercurial 使うだろうし。
ブランチ（カスタマイズ版作成）も SCM 使えば維持管理できる。
って、そういう話ではない？

■No30751 (774RR さん) に返信
> 「管理」「形態」という文言にどういう意味合いを持たせて使っているのか
> よくわからないけど、結局のところ何がしたくて、何が訊きたいの？
> それがわからないとコメントのしようがないんで。
>
> ソースコードの履歴管理＋リリース履歴管理、でよいのであれば
> なんであれソースコード管理ツール(SCM)が１つあれば十分。
> VisualSourceSafe でもいいし、俺なら Mercurial 使うだろうし。
> ブランチ（カスタマイズ版作成）も SCM 使えば維持管理できる。
> って、そういう話ではない？

御返答ありがとうございます。

すいません、いかんせん自分でもよく見えていないので「結局のところ何がしたくて」が上手く伝えられないままの質問になってしまいました。

頂いた解答もお聞きしたかった項目のひとつです。

もう少しまとめられるようになってからまた機会があればお伺いしたいと思います。

うーん。要するに SCM の運用のノウハウ話が聞きたいっつーことでいいのか？

SCM にも限界がある、とか
・commit されていない履歴は残らないぞ

ソースファイル以外の要因でバイナリが変わりうるとか
・コンパイラ・リンカにパッチがあたってしまうとソースコードが同じであっても同一バイナリにならない
・コンパイラ・リンカもバイナリーSCMの対象にしとくべきかも？とか
・いやそれならば開発環境丸々一式、マシン＋OS 全部セットで保存しておかなきゃ意味がなさそうとか。
・ならば VMware/VirtualPC 上に開発環境作っとけ！とか・・・ (そこまでいくと行き過ぎかも)

再コンパイルの時間が無駄なので、コンパイル済みバイナリは保存しておくといいとか
・バイナリファイルの社外リリース時には、必ず version リソースが変更されていることを確認し
　SCM にてタグを打ち、なおかつその対外リリース対象バイナリファイル (EXE/DLL) だけでなく
　中間ファイル (MAP/OBJ) も別ディレクトリに保存しておく (SCM 対象外ディレクトリのほうがいい)
・MAP が残っていれば客先でエラーが発生したとき DrWatson のログからの検証がはかどる

ログは膨大になるのでタグ・ブランチ類の命名規則は大事とか
・後からタグ見たときに素性がすぐわかる規則をうまく考えろ！

SCM の変更履歴の記入方法のちょっとしたコツを周知徹底しとくとか
・Mercurial の場合 commit ログの１行目は特に重要
・変更差分を commit ログに書いちゃう馬鹿は戦力外通告（変更理由/根拠を書け！）

リポジトリがクラッシュしちゃうと目も当てられないのでリポジトリサーバのバックアップは大事だとか

まあいろいろあるよなー、ということで。

掲示板のスペースでは漠然とした質問には答えにくいんで、スポット絞ったほうがいいよ。
そうすりゃ俺以外からもたくさん返信つくと思うし。

774RRさんありがとうございます。

はい、もちろんSCMのノウハウも知りたいひとつの項目でした。

もとい、プロジェクトとはどう管理していくものなのか、について何か管理していく上での手法のようなものはないのかな？

と漠然に思っておりました。

と申しますのも、クリティカルパスなんかを使ってる人を実際みたことはなく、

期限が詰まってくると、期限を延ばすか、「頑張れ！」で終わってしまっていたので、

決まったスパンの中で進捗状況が危ういと判断された場合、その危うさを数値的に示す手法や、

危うさに応じた対処手法というものが存在しないのかな？

というところに大きく気をとられております。

とりあえずは本屋で「プロジェクト管理」について書かれている書物をあさるところから初めてみたいと思います。

Mercurialには触れたことがないので、こちらも実際に触ってみたいと思います。

ご紹介ならびにご意見ありがとうございました。
ｍ(＿＿)ｍ

クリティカルパス、ね
要するに「ソース管理」ではなく「プロジェクト管理」ね
プログラマーの仕事ではなくて、マネージャの仕事をする上での心構えというかなんというか、ね。

とりあえずこの辺だけ。

俺んちも使ってないよ＞クリティカルパス
少なくともソフトウェア開発においてはあまり意味無いから。

プログラム開発っつーか、設計+実装っていうか、要するにあるソフトが動くまで、って
Ａ．基礎設計を、慎重かつ細心の注意を払って考える時間
Ｂ．基礎設計がきっちりできた上で、各種仕様を実装して回る時間
Ｃ．実装されたプログラムを検証する時間
なわけだけど、Ａ中は「動くもの」はまったくできてないわけで、そういう意味で進捗０なわけよ
この段階で「クリティカルパス」とか言われても開発実情にそぐわないんでさ。
最初に選んだ設計方針を途中で撤回してやり直して・・・それって進捗０なの？違うだろ！

Ｂの部分は進捗ってのがある程度計測できるから「管理」も意味がありそうだけど、
Ｃは結局どれだけ時間取れるか、どれだけ念入りにもれなく行うか・行えるか
な部分があるので、やはりここも「進捗」とかそういう話とはあまり相容れない部分があって。
実装変更→全部試験やりなおし！なんてのもごく普通にありえる話であって
それって進捗してるの？進捗０なの？どっち！

Ａをすっ飛ばしちゃうとか、Ｂの段階で「進捗が危うい」と判断されるとか、
そういうプロジェクトって最初からデスマーチ確定、つーことになると思うのだが・・・
管理以前の問題だろう。

難しいよね＞プロジェクトの管理

■No30771 (774RR さん) に返信
> ・いやそれならば開発環境丸々一式、マシン＋OS 全部セットで保存しておかなきゃ意味がなさそうとか。
> ・ならば VMware/VirtualPC 上に開発環境作っとけ！とか・・・ (そこまでいくと行き過ぎかも)

Visual Studio 2010 の Team Lab がそんなことをやってますね。

C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[4]: 開発管理形態

過去ログには書き込み不可