チームメイトに基本的なルールに従うよう説得する方法

チームメイトに問題があります。簡単に言えば、私たちはコンテストのプロジェクトで働く3人の学生です。このプロジェクトは、2つの個別のアプリケーションで構成されています。1つはWindows用（もう1つは開発中）、もう1つはAndroid用（私の同僚が開発に責任を負います）です。コードベースが交差することはなく、アプリはサードパーティのツールを介して通信します。

問題は次のとおりです。昨年大企業でインターンシップを行ったときにチームで働いた経験があり、コードのコーディング標準を強制しようとしています。また、コードをプッシュしたり、アイデアを書いたり、プロトコルを文書化したりするために使用できるgitリポジトリ/ wiki /コラボレーションソフトウェアも設定しましたが、これらのツールを使用しているのは私だけであるようです。

質の高いコードを書いて、すべてのステップを文書化することは長期的には私たちに利益をもたらすと彼らに伝えようとしましたが、彼らはそれの利点を理解していないようです。また、いくつかの統合テストを追加することを考えていましたが、私が見ることができることから、彼らが生活を楽にするために現在のツールを使用しない限り、統合テストの有用性を説得することはできないと思います。

ピアのコードのほとんどは自分のコンピューター上にあり、共通のコードベースを共有していません。私が知ったように、彼らはusbスティックを介してコードを会議および共有することで、それらの部分を統合しました。

私の質問は次のとおりです。いくつかの不条理なルールを施行しますか？これは小さなプロジェクトであり、要件は非常に明確であることに注意してください（アプリケーションの動作を指定するドキュメントを作成しました）。3人の熟練した開発者が3〜4日でこれを行うことができます。現在のメソッドが機能する限り、コードを作成します。

gitなどを使用してコードをドキュメント化することの利点を示す方法はありますか？

私の質問は次のとおりです。

馬を水に導くことはできますが、彼に飲ませることはできません。

あなたが「過酷」であるかどうかを言うのは難しいですが、チームメイトがあなたが望んでいるすべてのインフラストラクチャを採用することを期待するのは非現実的かもしれません。本当に、チームがうまく連携している場合、Wikiを使用して3人のユーザー間でやり取りするのはおそらくやり過ぎです。

期待を縮小し、知らないツールの使用を開始せずに目標の一部を達成する方法を探します。彼らがgitの使い方を知らない場合、彼らはおそらくそれから多くの利益を得ることはおそらくないでしょう。ただし、ハードドライブの障害やその他の大惨事が発生した場合にすべてのコードがバックアップされるようにする必要があるため、プロジェクトフォルダーをGoogleドライブ、Dropbox、または同様のオンラインファイル共有サービスに定期的にコピーするよう依頼してください。同じことを確認してください。

私の態度は、これらのことを小さなプロジェクトで行うことができれば、大きなプロジェクトがやって来たときに準備ができるということです。

このプロジェクトで優れた開発慣行に従うと、将来の雇用主に紹介するコードを持ち、従業員として価値のある経験を積むことができます。

それらを納得させるためにもっと資料が必要な場合は、プラグマティックプログラマー、またはCode Completeを参照します。

その一方で、それらにいくつかのたるみをカットすることを検討してください。プロジェクトがコンセプトの証明であり、競争の直後にビニングされている場合は、好きなように実行させることを検討する必要があります。彼らは、良い習慣の精神的なオーバーヘッドなしで、最初にコードを書くだけで苦労しているかもしれません。

あなたが説明したルールは基本的なものではないのではないかと思います。

IMOの最も簡単なタスクは、チームメイトにいくつかのコーディング標準を使用するよう説得することです。そして、これを実現する簡単な方法は、一度フォーマットを整えてからスタイルを整えて同じコードスニペットを見せ、コードを読んでもらい、それが何をするのかを理解させ、自分で判断させることです。

gitリポジトリを使用することで、これは初心者にとっては苦痛になる可能性があります。Androidプロジェクトで3人のチームで働いていたとき、最初はバージョン管理システムに多くの問題がありました。ですから、チームメイトにも問題があると思います。

経験豊かな開発者がプロ​​ジェクトを完了するのに3〜4日かかるとおっしゃっていました（チームの時間が2〜3倍かかると思います）。これは非常に短い期間であるため、新しいツールを使用することが長期的には役立つという主張は、単に機能しません。

できることは、これらのツールがどのように使用されるかを示すために、短くて簡単なデモを作成することです。最初に最も基本的な機能を説明し、その横に座って、ツールの使用を支援します。gitの構成、wikiページ構造の作成などのすべてのタスクを実行する準備をします。

編集：コメントへの返信では、明確なタスク、見積もり、期限を設定し、費やした時間を追跡することは、gitや同様のツールを使用するよりも重要だと思います。後でアプリケーションで作業する予定がある場合は、すでに行われていることと各機能にかかった時間を追跡することが非常に重要です。したがって、タスク管理から始めて、使用するツールに進むことをお勧めします。

ジョエル・スポルスキーが自分の考えを気に入っているのは、彼があなたがただのうなり声であるときに物事を成し遂げることで彼がレイアウトしたように。要約する：

1. ちょうどそれをしてください -メイクファイルを書いて、毎日のビルドサーバーなどを作成してください
2. 誰もソース管理データベースやバグデータベースを使用していませんか？自分で使用を開始してください。誰かがあなたの作業に対してバグを報告した場合、バグデータベースを使用してバグを報告するよう丁寧に依頼し、バグを追跡できるようにしてください。そうしないと、頭の中にまっすぐに置いて修正することができなくなります。どんな些細なプロジェクトでも、ソース管理でしか解決できない状況があります。コードに対してソース管理を自分で使用し、そのような状況が発生した日を救うために勇敢に急襲します。これが数回起こると、彼らは確信します
3. ポケットオブエクセレンスを作成する -スペック設定、スケジューリングなど、自分のために正しいことを実行しますあなたのメッセージを信じる新しいチームメンバー
4. かけがえのないものになる -チームでの影響力を強化するために、あなたが偉大な貢献者であることを示してください。そうでなければ、結果よりもプロセスとツールを大切にする人として知られるようになるリスクがあります

ドキュメント、Wiki、バージョン管理ソフトウェア、方法論などは、時間をかけて学んだ経験と教訓です。いくつかのプロジェクトで、おそらくいくつかのチームで働いています。そして、それは通常、すでに雇用されている人や、業界を真剣に受け止めている人に固執しています。彼らは学生ですので、彼らの興味はおそらく将来起こるものに限定されます。:)

しかし、あなたの質問に答えてみるには：

あなたが彼らとチームを組んでいるなら、あなたは彼らの利益に利益をもたらす方法であなたが重要だと思うことを適用する必要があるでしょう。例として：usb共有時にコードが大量に破損することについて不満を言うべきでしょうか？次に、バージョン管理ツールとして（gitではなく）SVNを使用する簡単な（複雑でない）方法を提供します。

arnaudからのコメントにも同意します。

これらのツールを使用して作業しているときに、これらすべてのツールの利点を理解しました。それが、ツールの価値を理解し、その使用方法を理解する理由です。チームの仲間が現在のやり方で付加価値を見ない場合、彼らはそれを適用しません。悲しいことに、これはあらゆるレベルの経験を持つ人々で構成されるチームにとっても重要です。

このアプローチには問題があります：

1. あなたのアプローチは対称的ではありません。他のチームメンバーは変更する必要がありますが、あなたは彼らの良い習慣を学んでいません。このような状況でルールを実施することは困難です。より良いアプローチは、チームのすべてのメンバーから適切なルールと実践を収集し、全員が結果のドキュメントを読むことです。

2. 学習は難しいです。他の人のルールは、あなたのプログラマーが期待している論理構造を持っていないため、意味をなさないだけです。意味をなさないルールを強制することは、有用なアクティビティではありません。

3. 誰もがさまざまなことを学びました。さまざまなバックグラウンドのプログラマーがさまざまなことを学んだのは当然です。それらの強みは異なり、コードを記述するスタイルも異なります。彼らが使用するツールは異なります。1つのルール/ツール/スタイルのセットを強制することは悪夢になります。これは、開発者が長年の学習に費やしてきた力が制限によって失われるためです。
4. 変更には時間がかかります。あなたが実施しているルールを発明した人はルールに従うのが非常に簡単ですが、他の誰もが苦しみ、新しいルールを学ぶことに時間を費やしています。これが、チームの全員がルールを変更できるようにする必要がある理由の1つです。
5. チーム全体でツール/コーディング規約またはスタイルを選択するのは難しい作業です。時間の経過とともにゆっくりとしか実行できず、機能するものと機能しないものをテストします。チームに50のルールに従うために2週間を与えることは機能しません。

私は大学でこの問題を発見しました。多くの人々は、単に異なる（そしてより専門的なアプローチの）働き方を学ぼうとはしないでしょう。

ただし、システムを導入している場合は、システムの使用方法を説明してから、多くの人がシステムを試してみてください。また、リポジトリは使用済みのツールが非常に少なく、人々は通常、dropboxのようなものを使用するだけだと思います。