将来、一人のプロジェクトからチームプロジェクトに移行する。準備中に今何をすべきか、何を待つことができますか？

詳しく説明すると、1人のプロジェクト（チームのソース管理、ドキュメント、ビルドなど）を実行している間に配置する必要があると考える人々と、2人目が来るまで何をする必要がないかを知ることに興味があります。プロジェクトに。

このシナリオを経験したことがある人なら誰でも、彼らの洞察に感謝します。

私が学んだこと。（別の順序を試してみました。間違っていました。これが物事が関連する順序です。）

1. すべてをソースコード管理に入れます。誰もがアクセスできるものを使用して、今すぐ始めましょう。例外なく。遅延なし。言い訳しない。

2. 個人の「作業」または「開発」環境から完全に分離したQA /テスト領域を作成します。少なくとも個別のユーザーID。理想的には、別個のVM上。
   完全に分離します。現在の作業環境と重複する可能性はありません。

3. 独自の作業環境で単体テストを超えるテストを停止します。「自分で」行うコードと単体テスト。別のVMで行う他のすべてのテスト（統合、パフォーマンスなど）。自分としてテストしないでください。常に別のQAユーザーとしてテストしてください。理想的には、別個のVM上。

   「私のために働く」は、チームメンバーに言わなければならない悪いことです。ひどい。あなたは彼らが間違っていることを理解する必要があります。一日に何度も。

4. すべてを書き留めてください。プレーンテキストマークアップツール（RSTまたはMarkdownなど）を使用して、バージョン管理リポジトリ内のすべてのドキュメントがプレーンテキストになるようにします。ツールは、HTMLページ（RSTのDocutilsなど）、PDF、または最適と思われるものを作成できます。独自のドキュメント形式（MS-Wordなど）を使用しないでください。一部のソースコード管理システムではうまく機能しない場合があります。

5. 最初に書き留める必要があるのは、次のことです。

   • 実用的な開発環境を作成する方法。疑わしい場合は、仮想マシンを作成し、その仮想マシンで操作全体を実行します。手順が実際に機能し、ドキュメントが明確であることを確認してください。実際のコマンドラインで入力された実際の行の種類。

   • 単体テストスイートの実行方法。再び。指示が機能し、思考を必要としないようにしてください。「これを入力：」「次のことを確認：」種類のもの。あなたのチームメンバーが愚かであるということではありません。それをすべて書き留めない限り、あなたが仮定していることを覚えていないということです。

   • 統合テストスイートの実行方法。

   アーキテクチャまたは設計原則を説明するのに多くの時間を無駄にしないでください。最初に誰かを立ち上げて実行する必要があります。後で説明できます。

6. 次に文書化するのは、ユーザーストーリーです。そして、それらのストーリーをサポートするテストケース。そして、それらのユーザーストーリーをサポートするテストケースに必要なデータフィクスチャ。

   これを共有します。ソースコード管理下に置かれます。

7. 最終的に、他の4つのビューを文書化できます。

   • 論理ビューは文書化するのに役立ちます。写真はここで受け入れられます。これは急速に進化する傾向があるため、レガシー情報の取得に時間を費やさないでください。チームメンバーと協力する方法を考えてください。

   • 多くの場合、プロセスビューが役立ちます。これがアプリケーション全体の重要性に依存します。

   • 開発ビュー（モジュール、ライブラリ、フレームワークなど）は、多くの場合非公式に説明されます。写真が役立つかもしれませんが、これを十分に完成させて誰かがドキュメントを拾い上げて頭や尻尾を作ることが難しいことは有名です。古くからある非常に公的なプロジェクトでさえ、単に無視されるライブラリ文書を持っています。（多くのスタックオーバーフローの質問に進みます。）

     非公式であることが許容されることに加えて、これは急速に変化する傾向があります。

   • 展開情報。サーバー。IPアドレス。データベース資格情報。そのすべてが書き留められなければなりません。最終的に。

ツールと方法論

共同作業を成功させ、生産性を高めるには何が必要ですか？

• プロジェクトのパーツ/コンポーネントの特定：異なるパーツ（データベース、データアクセスレイヤー、Webサイト、サービス、API、テストプロジェクト、ビルドスクリプトなど）と環境（開発、ステージング、プロダクション）を明確に区別し、それらに名前を付けます一貫して口頭および書面によるコミュニケーションに影響を与えます（ドキュメント、プロジェクト名、...）
• ソースコード管理システムを使用します（まだ行っていない場合に備えて）。プロジェクトとセットアップで分岐を使用する方法を考えてください。
• ビルドの自動化 -ソースリポジトリから環境をできるだけ簡単にセットアップできます。
• 少なくともより複雑なプロジェクトの場合、テストプロジェクトは大規模プロジェクトでは必須です。
• 使用ステージング環境（s）は、プロジェクトを使用する準備ができています。また、自動ステージング設定用のサンプルデータを作成および管理します。
• 開発の優先順位付けと計画に役立つバグ追跡システムを使用します。また、過去のバグとその解決方法のメモリとしても機能します。
• プロジェクトの各部分を文書化します。個人的には：概要-アーキテクチャ-依存関係-構成-一般的な問題（ここから）。ドキュメントが古くなってしまわないようにするために、ドキュメントを簡潔にし、ドキュメントを日常の活動の一部にすることをお勧めします。

管理/チームワーク

...または対人レベルのその他のもの

• 他の開発者への期待を定義します。合理的で、誰もあなたと同じような関与と情熱を持ち込むことはないでしょう-少なくとも最初からそうではありません。期待するものとそうでないものを伝え、自分と他の人の責任を明確にします。誰もがエンジニア、アーキテクト、開発者、dba、sysadminではありませんが、それがあなたが探しているものであるなら、適切な人を選ぶか、あなたは失望するでしょう。
• 最初に、タスクを正確に定義し、結果を確認して議論します。徐々に、より少ないマイクロ管理を開始します。考えは信頼を築き、責任を増すことです。
• プロジェクトを計画し、プロジェクトと来年のチームの目標を設定します。書き留めて、後で確認します。これにより、視点が得られます。これらの目標はや（彼らは目標である限り、他の人に伝えてもしなくてもよいあなたは、ない他人を達成する必要があるが）、それは単にあなた自身のチェックリストすることができます。
• するために、1日を取る最初の月を準備し、計画（または2/3ヶ月）あなたの新しい開発の。よく準備された人々と仕事をするとき、それは非常にやる気になります。誰も彼/彼女の時間が無駄にされているという印象を得るべきではありません。
• 手放しなさい。それはあなたの赤ちゃんです、それは他の誰かのものにもなるはずです。少なくともプロジェクトのいくつかの部分で、他の人があなたよりも優れた専門家になることを許可します。これは実際にあなたが成功したことを意味します。
• 聞いてください -あなたが彼女を雇ったなら、彼女は何か言いたいことがあります。学ぶ準備をしてください。
• あなたの知識と経験を共有する準備をしてください（したがって、時間-我慢してください）。
• 間違いが発生します。それがどのように扱われ、誰もが何について何を学んでいるかです。
• 時間をかけて学習し、実験する

本の参照

私が実際に読んだ一般的に言及された本のいくつかをリストします。より詳細な説明や、それについて正確に尋ねるSOの質問のいくつかをチェックしてください。これまたはこの質問。

これらの本は、チーム、組織、およびプログラミングプロジェクトに関して本当に読む価値があります。

• ピープルウェア
• 神話上の男の月
• ソフトウェア推定、ブラックアートの謎解き

方法論Xの実装方法に関する実用的なガイドはありません（ソフトウェアの推定を除き、この本は適切な推定プロセスの選択に役立ちます）。もちろん、Code Completeのようなプログラミング自体に焦点を当てた本も非常に充実しています。

経験から話をしますが、誰もが違うことを心に留めておいてください。これらは普遍的なものではありません。

一つのことは、個人的にそれを手放すことです。このプロジェクトは、18か月間一緒に住んでいたものです。当然、すべての変更を自分のやりたいようにしたいと思うでしょう。同僚が間違いを犯し、学ぶためのバッファを提供します。役に立つ部屋を作りましょう。そして、すぐには起こらないかもしれないことを覚えておいてください。また、コードの一部で、改善または作成に成功したと感じることができ、短期間で成功したように感じる何かがあれば素晴らしいでしょう。忍耐と寛容はここで良いペイオフ率を持っています。細かく管理しようとしないでください。批判したい場合は、「あなたは間違っています」と言って、あなたがメリットを持っていることを確認し、それを証明できます、それは「宗教的な」戦いではありません。

もう1つの重要な問題は、適切な人を見つけることです。理想的には、自分よりも賢い人を見つける方が良いです。それは主観的で相対的なものですが、あなたが持っていない知識やスキルを持っていると感じたら、それは最高です。相互にやりがいのあるコラボレーションになります。

2つの方法があります-同僚は引きずります、そして、あなたは彼または彼女がしたことをやり直すことになります、またはあなたの2人のスキルは単に足し算するのではなく、増加します、そしてあなたは本当に一緒に働くことに感謝します。

「クリーン、高速、再利用可能なコード」のトピックについて-インタビューで、小さなマイクロカーネル/サービスマネージャーやジョブエグゼキューターの作成を依頼することをお勧めします。プラグ可能なコンポーネントがどのように指定され設定されているかをご覧ください。終了する必要はありません、それは重要な考えです。そして、あなたはそれを行う方法をよく知っている人々がすぐにお金を必要とすることを学ぶでしょう;-)幸運を！

私の考え：内部プロジェクトのアーキテクチャを文書化することから始めましょう...知らない人のために。どの仮定が設定されているか、いつ/どこで一般的な慣行から逸脱したか、およびその理由を説明してください。

ビルドの自動化：素晴らしいアイデアです。開発マシンに構成の自動化を追加できますか。最も簡単なのは、より多くビルドすることです（テスト展開がより多く/高速になります）。

別のアイデア（それは私を何度も助けてくれました）：新しい開発者に、コードベースのさまざまな領域でいくつかのクリーンアップ小規模タスクを実行するよう依頼します。そうすれば、レイアウトツールなどに慣れるでしょう。後で混乱を招く可能性のある不明瞭な領域（例：どこかでシェルスクリプトの2行にemmm pythonを使用し、プロジェクトがJavaに基づいている場合、開発者＃3が必要とするように、これら2行をJavaで書き換えるように依頼します働くためにあまり知らない）

私は、手作業を必要とするすべての自動化に焦点を当てるので、経験の浅い人が台無しにすることができます。上記の短いコメントに基づいて、次のものが含まれます。

• バージョン管理をインストールし、手動バックアップを自動バックアップに置き換えます。
• 可能な限り自動展開を設定します（最低限、手動で行うのではなく、FTP経由で展開するスクリプトを作成します。

これらを実行できない場合、これらのタスクを永久に実行するためにチェーンされるか、新しい男（またはその一部）が遅かれ早かれ何かを台無しにします。

他の重要なタスクは、@ dimitrisが述べたように、ドキュメントです。@S。Lottはこれにさらに詳細を追加したので、繰り返すのではなく+1するだけです:-)

以下は、個人的な経験に一部基づいた考えです。

• プロジェクトを文書化します。設計仕様、図、マニュアル、およびコメントは、新入社員がスピードを上げるのに役立ちます。複雑なシステムを口頭でのみ説明すると、遅くてイライラすることがあります。ドキュメントは、一人のプロジェクトではしばしば無視されます。あなたのものが例外であることを確認してください。

• 最初は、新しい従業員に「アプリケーション層」の作業またはバグ修正を与えながら、徐々にコードに慣れるようにしながら、API /コアレベルのコードに専念します。一般的に、より簡単でありながら有意義な、やりがいのあるタスクから始めます。

• コミュニケーションは重要です。新入社員の質問、コメント、アイデアに対応する。アイデアが良くないと思う理由を説明してください。新鮮な目で驚くほど改善の余地を見つけることができます。あなたの新しい従業員がまともな人であれば、彼はあなたのコードをピアレビューし、最終的にアーキテクチャの決定に参加できます。話し合い、アイデアを互いに打ち合わせます。それはあなたのプロジェクトに同僚がいることの最大の利点の一つです。

• 新しいチームメンバーがどのような仕事をしているのかがわかったら、責任を明確に定義します。文書化の慣行とコーディング規約を確立して、物事をスムーズに保ちます。

• リビジョン管理システムを使用します。論理ソースファイルのレイアウトを維持し、規律を構築します。

インタビューに関しては-候補者のストレスに耐える能力を試してみたいと思わない限り、私は人工的なコーディングテストやトリックの質問の大ファンではありません。最も賢い問題解決者でさえ、このような状況でロックアップする可能性があります。あなたが探している資質は、とりわけ：誠実さ、専門能力、技術的知識/洞察、熱意と相互互換性です。職場の雰囲気は非常に重要です。気に入らないチームメイトを選ぶことはお勧めできません。質問を適切に配置し、非公式のディスカッションを行って、候補者の良い写真を撮ってください。幸運を！

技術

開発者として他の誰かを連れてきた場合、開始する前に実行しておくことをお勧めする3つの重要なことがあります。

1. ソース管理
2. 問題追跡
3. 継続的インテグレーション

これら3つが正常に動作している場合、新しいチームメンバーを雇用するときに発生する一般的な問題の約75％を排除できます。これらのテクノロジーのポイントは、あなたの頭の中でのみ起こっていることの多くを取り出し、チームメンバーがそれとやり取りできる場所にそれを引き出すことです。

ソース管理により、両方が同じものに取り組んでいることを確認できます。問題追跡は、何をする必要があるかを追跡するのに役立ち、彼らが何に取り組んで何を達成しているかを簡単に知ることができます。継続的な統合とテストは、繰り返し可能なビルドプロセスがあり、新しい改善がコードの他の部分を壊さないことを確認するのに役立ちます。

Pragmatic Programmerには、これに関するかなり良い本があります。ここにいくつかお勧めします。使用しているプログラミング言語や使用するバージョン管理に基づいて、同様のタイトルがあります。

http://www.pragprog.com/titles/tpp/the-pragmatic-programmer http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git http：//www.pragprog。 com / titles / auto / pragmatic-project-automation

パーソナル

多くの場合、あなたが直面する困難は物事の技術的な側面ではなく、手放すための学習にあります。特に他の誰かにプロジェクトの側面を制御するのは難しい場合があります。特に、自分ですべてを行い、すべての決定を下すことに慣れている場合はなおさらです。信頼できる基盤を築くことができるように、新しい人が最初に合理的な量の自由を持って働くことができる場所を見つけることができれば、あなたは自分自身の悲しみを救うでしょう。あなたが良い人を雇うなら、おそらくあなたが学ぶであろう主なことは、彼らの個々の決定のすべてがあなたがしたことと同じでなくても、他の人が良い仕事をすることを信頼する方法です。

新規採用者には、問題を早期に発見できるように、セーフガードを維持しながら問題に対処する方法で問題を解決する自由を与えたいと考えています。

私の意見では、これらの点が最も重要です。

1. コードの重要な部分を読んで、理解しやすいようにしてください。コメントまたは直感的な関数名と変数名を使用してください。
2. 新しい人がコードを簡単に送信できるようにします。
3. 簡単ではない場合は、開発環境のセットアップ方法に関する新しい開発者に必要なすべての手順を説明するREADMEファイルを作成します。または、この環境のセットアップを密接に支援します。
4. この新しいプロジェクトで作業するとき、新しい開発者に非常に明確に定義されたタスクを与えます。私の意見では、これらのタスクには新しいがシンプルな機能が含まれるべきです。私の意見では、クリーンアップタスクはあまり意味がありません。なぜなら、新しい開発者はコーディングスタイルとその習慣に慣れる必要があるからです。クリーンアップやリファクタリングは、コードを知っている人が行う必要がある仕事です。
5. コードを送信するためのプロセスを明確にします。（たとえば、コンパイルするものだけを送信します。）しかし、厳しすぎないでください。最初はイライラすることがあります。
6. コーディング規約を備えたドキュメントを用意してください。他のコーディング規約が何であるかを推測するのは本当にイライラすることがあります。
7. アプリが複雑な場合は、アーキテクチャを説明するドキュメントを用意してください。または、フローチャートなどを使用して、新しい人にアーキテクチャを説明します。新しい開発者がプロ​​ジェクトのリバースエンジニアリングに時間を浪費するのは望ましくありません。
8. 新しい開発者が自分で展開を行うことになっている場合は、順序付けられたチェックリストを用意して、展開に必要なすべての手順を説明してください。

最後になりましたが、バージョン管理システムを入手してください。Subversionは問題ありません。ただし、ユーザー固有のEclipseファイル（またはその他）を追加しないでください。彼らは時間を無駄にします。Stackoverflowに問題がある場合は、askしないでください。