私は小さな会社で働いています。私が雇われる前の会社のソフトウェア開発部門は、独学で働きすぎた1人の男で構成されていました。数年前から会社のソフトウェアを書いてきたので、正式な会社全体のソフトウェア開発プラクティスの確立を任されました。現在、ガイドラインはありませんが、

コードを記述してテストし、.zipファイルに入れてクライアントに送信します。TDDおよびバージョン管理のボーナスポイント。

私の上司は、私たちが物事を成し遂げるために使用する一般的なプロセス、プロトコル、ツール、およびガイドラインを定義するソフトウェア開発者のハンドブックを書くことを望んでいます。言い換えれば、彼は「これが私たちがここでやること」という本を望んでおり、新しい従業員が私たちのやり方に慣れやすくなり、上司が彼の手下が何をしていてどのようにやっているかを理解しやすくしますそれ。

私が見ているように、私は基礎を築いています、それは正しく行われる必要があります。そのようなハンドブックのトピックをどのように選択しますか？サンプルトピックを提供できますか？

サイドノート：重要なのは、主にMicrosoft .NETショップです。また、XPやスクラムなどのアジャイルプラクティスを検討していますが、それらを社内で機能させるために大幅に変更する必要がある場合があります。

私はそれを次のようなセクションに分けます

• 現在のスタッフ-名前とタイトル（理想的には写真付き）
• アプリケーション、それらへのログイン、知っておくべきデータ、送信した許可リクエスト
• 企業サイトおよびビジネスに関連する主要な外部サイトへのブックマーク
• 会社が通信、メール、会議室予約、共有画面に使用するアプリケーション
• 領収書の支出、旅行の予約など、会社に関連する活動の手順
• 開発者マシンのセットアップ。新しい開発者マシンをセットアップするプロセスを詳細に説明してください。通常、これには1日しかかからないことが予想されますが、実際には3〜5日かかることがよくあります。
• 開発プロセス、作業の追跡、割り当て、更新の方法、使用されるツール。
• テストする方法、テストする対象、テストするタイミング、テストする場所。
• ファイルの命名規則や言語固有の標準を含むコーディング標準。
• バグの処理方法、文書化の場所、バグの修正方法。
• 展開プロセス、生産プッシュのために知っておくべき重要なことは何ですか。
• 文書化の方法、文書化の対象、文書化のタイミング。
• コード、データ、標準、ドキュメント、リンク、およびその他の資産の場所など、ものが「ある」場所。

また、モジュール化することで、あなたや他の人が個別にピースを更新できるようになります。たとえば、従業員の名前と役職は、人々が行き交うにつれて頻繁に変わります。

セクションごとに、「初心者」の観点から一生懸命書きます。最も重要なのは、初心者にとって本当に理にかなっていることを確認することです。あなたの上司は明らかにされていない、彼は対象読者ではないとしてこれを確認するために適切な人。彼はそれを望んでいます。コンテンツが彼によってテストされないようにしてください。また、「初心者」には、初心者として「1週間」しかありません... 1つの視点しかありません。そのため、新しい従業員ごとにドキュメントを改善することが推奨されます。実際、最初の週にもそれらを割り当てることは非常に良いタスクです。つまり、「初心者マニュアルを更新する」です。

アジャイル/スクラムの場合：

アジャイルとスクラムを行うことの最も難しい部分は、「本当に」それを行うことです。

読むために、私はhttp://agilemanifesto.org/から始めて、そこから行きます。

また、よく知られているhttp://www.halfarsedagilemanifesto.org/を読むこともできます。http： //www.halfarsedagilemanifesto.org/は、機能するためにすべての側面を実際に受け入れなければならないという事実に重みを加えています。組織のアジャイルを大幅に変更する必要がある場合、正しいプロセスを使用せずに人々が利益を望んでいる可能性があります。この事実自体は、半迷惑を避けるために提示されるべきです。

文書化する前に、いくつかのプラクティスを紹介する必要があるようです。

a）ソース管理-ソースをどのように保存し、リビジョン管理を行うか

b）リリース管理と追跡-ビルドの方法、リリースの番号付け、現在のリリース候補と以前のリリースの比較

c）問題管理-リリースのバグをどのように追跡しますか。

これらは非常に基本的なものですが、実装には多くの時間がかかります（場合によっては費用がかかります）。

開発者のハンドブックに含めるトピック：

• 部門内の役割/役職とそれに対応する責任
• 開発者のマシンソフトウェア要件（つまり、必要な開発環境）
• ソースコードリポジトリにアクセスする場所と方法
• 使用されている開発ツール（IDEなど）
• コーディングスタイル/標準
• ドキュメントの標準
• テストプロセス
• ビルドプロセス
• 展開プロセス
• サポートおよび問題管理プロセス
• このハンドブックの最新バージョンの入手先

このハンドブックには、開発に固有の項目のみを含めるようにし、会社全体の情報（従業員ハンドブックに含めるべきではない）を含めるようにしてください。

ソース管理の使用

• 使用しているソース管理ツール。
• IDEの一般的なコマンド/ツールの構文。
• 分岐/マージ戦略。
• コミットの単位は何ですか？ファイルをチェックアウトする/コミットしないにはどれくらいの時間がかかりますか？
• コミット/チェックインはどのレベルの「完了」を意味しますか？コンパイルしますか？単体テストに合格しましたか？審査？
• コミット/チェックインのメモに含まれることが期待されるもの。
• ロールバック手順。