プロジェクトのソフトウェアプロセスをどのように作成しますか？

ここで他の質問で書いたように、現在取り組んでいるプロジェクトにはソフトウェアプロセスがありません。意味することに何の（ハードコピー要件や仕様を含む）のドキュメント、無ソースコントロール、無バグデータベース（たぶん）、「固定」されているバグや新しいコードは、同じ時間、および正式なテスターで追加されていない-私たちは失敗するだろうジョエルテストひどく、面白くないです。

昨日、私のマネージャーは、これらの欠点を修正し始める方法についての文書を書くように私に頼みました。ここで6か月間、私は単なるインターンです。私は学校に戻るために11月に感謝祭の周りを離れます。ただし、このプロジェクトを正しい方向に進めることはできると思いますが、どこから始めればよいのかわかりません。私は現在、CiteSeerとWikipediaを使用して、ソフトウェアプロセスを説明し、それらを実装するいくつかの論文を見つけようと試みていますが、アドバイス、個人的な経験、またはブログ、論文、wiki記事などへのリンクは大歓迎です。

アジャイルプログラミングを検討することをお勧めします。

バリアントはたくさんありますが、共通点がいくつかあります。

• 機能の定期的なレビューと再優先順位付け。
• 継続的な統合と自動化された単体テスト。
• ドキュメントを介したコミュニケーションに焦点を当てます（実際には、事前に書かれた巨大で柔軟性のない仕様を検討する際のWikiスタイルのドキュメントを意味します）。
• バーンダウンチャートと速度メトリックをもたらす柔軟な見積もり。
• サインオフ付きの200を超えるページ仕様でレビューされる通常のプロトタイプ。
• ソースの品質、または可能な限り近い品質。
• 定期的な利害関係者レビュー-顧客の理解の延長。
• ソフトウェアをできるだけ早く市場に出します（そしてお金を稼ぎます）。
• 可能な限り直接通信します。

開始するのに適した場所は、MSF AgileまたはScrumです。

状況を考えると、あなたは6か月で行方不明になり、チームは何のプロセスも開始しないので、導入する範囲を合理的に実装できる1つまたは2つのものに限定し、そこにいる間に定着させます。それが私なら、ソース管理ツールとバグ追跡システムを見てみます。

私がそこから始める理由は、これらのツールを導入することで、チームの現在のパフォーマンスのベースラインを確立し、再発する可能性のある問題を特定するのに役立つからです。プロセスの変更は素晴らしいものですが、これらは最初に導入すべき基本的な基本事項です。

Prince2をプロジェクト管理のプロセスに使用しており、非常にうまく機能しています。ただし、プロジェクト管理を実施していない会社にとっては、それは曲がりくねったように思えます。

TeamCityをCIサーバーとして使用して、このビデオで説明されている開発パイプラインを独自のニーズに合わせて調整しました。

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TCは、プルではなくリポジトリプッシュを行う、私が知っている唯一のCIシステムです。つまり、（理論的には）壊れたビルドはもうありません。

上記のいくつかの感情を反映するために、構造を持たないチームはアジャイル構造によりよく適合します。今すぐソース管理を入手して、変更をSVNに入れて、バグを探しているときに開発者の一部に差分を見せてください。改訂ログの追加を開始します。SVNの利点と使いやすさがわからない場合は、運命にあります。

MSBuild、CruiseControl.NET、FxCop、NUnit、NCover、Subversionを使用した.NETプログラミングの継続的統合に関するこれらの記事をご覧ください...

ソフトウェア開発の溝から