チームメイトにいくつかの基本的なルールに従うように説得する方法
チームメイトに問題があります。要するに、私たちはコンテストのプロジェクトで働いている3人の学生です。プロジェクトは2つの独立したアプリケーションで構成されています。1つはWindows（私が開発するもの）用であり、もう1つはAndroid（私の開発者はそれを開発する責任があります）用です。コードベースが交差することはなく、アプリは通信します。サードパーティのツールを介して。
問題は次のとおりです。私は昨年大企業でインターンシップを行ったときにチームで働いた経験があり、コードにいくつかのコーディング標準を適用しようとしています。コードのプッシュ、アイデアの記述、プロトコルの文書化などに使用できるgitリポジトリ/ wiki /コラボレーションソフトウェアもセットアップしましたが、これらのツールを使用しているのは私だけのようです。
高品質のコードを記述し、すべてのステップを文書化することは、長期的には私たちに利益をもたらすことを彼らに伝えようとしましたが、彼らはその利点を理解していないようです。また、私はいくつかの統合テストを追加することを考えていましたが、私が見ることができるものから、彼らが彼らの生活を楽にするために現在のツールを使用しない限り、私は彼らに統合テストの有用性を納得させることができないと思います。
ピアのコードのほとんどはコンピュータに常駐しており、共通のコードベースを共有していません。また、私が知ったように、USBスティックを介してコードを満たし、共有することで、それらのコードを統合しました。
私の質問は次のとおりです。私はこの問題にあまりにも厳しいですか？不条理なルールを強制しますか？これは小さなプロジェクトであり、要件は非常に明確です（アプリケーションで何をすべきかを指定したドキュメントを作成しました）。3人の熟練した開発者が3〜4日でこれを行うことができるため、書き込み品質の複雑さが増すことはありません。現在のメソッドが機能する限り、コードを記述します。
コードをドキュメント化したり、gitを使用したりするメリットを彼らに示す方法はありますか？
私の質問は次のとおりです。私はこの問題にあまりにも厳しいですか？
馬を水に導くことはできますが、彼に飲ませることはできません。
あなたが「厳しすぎる」かどうかを言うのは難しいですが、チームメイトがあなたが望んでいるすべてのインフラストラクチャを採用することを期待することは非現実的かもしれません。そして、本当に、チームがうまく連携している場合、wikiを使用して3人の間でコミュニケーションをとることはおそらくやり過ぎです。
期待を縮小し、知らないツールを使い始めることなく、いくつかの目標を達成する方法を探します。彼らがgitの使い方を知らなければ、いずれにせよgitから多くの利益を得ることはおそらくないでしょう。ただし、ハードドライブの障害やその他の大災害が発生した場合に備えて、すべてのコードが確実にバックアップされるようにしたいので、プロジェクトフォルダをGoogleドライブ、Dropbox、または同様のオンラインファイル共有サービスに定期的にコピーするよう依頼してください。同じことを確認してください。
私の態度は、もしあなたがこれらのことを小さなプロジェクトで行うことを学ぶことができれば、大きなプロジェクトがやって来たときにあなたは準備されるということです。
彼らがこのプロジェクトで優れた開発慣行に従っている場合、彼らは将来の雇用主に紹介するためのコードを持ち、従業員として彼らを貴重にする経験をします。
それらを説得するためにさらに資料が必要な場合は、 Pragmatic Programmer または Code Complete を参照します。
一方で、たるみをカットすることを検討してください。プロジェクトが概念実証であり、コンテストの直後にビニングされている場合は、好きなように任せることを検討する必要があります。彼らは、良い習慣の精神的なオーバーヘッドなしに、最初からコードを書くだけで苦労しているかもしれません。
ご説明いただいたルールは基本的なものではありません。
IMOの最も簡単なタスクは、チームメイトにいくつかのコーディング標準を使用するよう説得することです。そして、これを達成する簡単な方法は、一度適切にフォーマットされた後、スタイルが不十分な同じコードスニペットを表示し、コードを読んでもらい、それが何をするのかを理解し、自分で判断させることです。
Gitリポジトリを使用することになると、これは初心者にとって苦痛になる可能性があります。 Android=プロジェクトで3人のチームで作業していたとき、最初はバージョン管理システムに多くの問題がありました。そのため、チームメイトにも問題が発生すると予想されます。
経験豊富な開発者がプロジェクトを完了するのに3〜4日かかるとおっしゃっていました（チームには2〜3倍の時間がかかると思います）。これは非常に短い期間であるため、新しいツールを使用することは長期的には役立つという議論は単に機能しません。
あなたができることは、それらのツールがどのように使用されるかを示すために短くて簡単なデモを作ることです。最初に最も基本的な機能をカバーし、隣に座って、ツールの使用を支援します。 gitの構成、wikiページ構造の作成など、すべてのタスクを実行する準備をしてください。
編集：コメントに答えて、明確なタスク、見積もり、期限を設定し、費やした時間を追跡することは、gitや同様のツールを使用するよりも重要だと思います。後でアプリケーションで作業する予定がある場合は、すでに何が行われているか、および各機能がどれだけの時間かかったかを追跡することが非常に重要です。したがって、タスク管理から始めて、使用したいツールに進むことをお勧めします。
私は実際に、Joel Spolskyの自身の考えが気に入っています。彼が Getting Things Done Done When You'd Only a Grunt で説明したとおりです。要約する：
- やるだけ-makefileを書いて、毎日のビルドサーバーを作成するなど.
- 誰もソース管理データベースやバグデータベースを使用していませんか？自分で使い始めてください。誰かがあなたの仕事に対してバグを報告した場合は、それらを追跡できるように、バグデータベースを使用してバグを報告するよう丁寧に依頼してください。そうしないと、頭の中でまっすぐにして固定することができません。重要なプロジェクトでは、ソース管理でしか解決できない状況が発生します。自分でコードのソース管理を使用し、そのような状況が発生した日を救うために英雄的に急降下します。これが数回起こると、彼らは確信するようになります
- ポケットオブエクセレンスを作成する-仕様、スケジュールなど、自分で正しいことを行います。これは作業プロジェクトのように見えないため、あなたのメッセージを信じている新しいチームメンバーを雇うことができないので、あなたはこのアドバイスをずっと受けることができるように見えます
- 貴重になる-チームでの影響力を強化するための優れた貢献者であることを示します。そうでなければ、結果よりもプロセスとツールを重視する人物として知られるリスクを負います
ドキュメンテーション、Wiki、バージョン管理ソフトウェア、方法論などは、時間をかけて学んだ経験と教訓です。複数のプロジェクトの作業、おそらく複数のチームでの作業。そして、それは通常、すでに雇用されているか、彼らの業界を真剣に受け止めている人々に固執します。彼らは学生であるため、彼らの興味はおそらく、将来起こることを除いて制限されています。 :)
しかし、あなたの質問に答えるために：
あなたが彼らとチームを組んでいるなら、あなたは彼らの利益に役立つ方法であなたが重要だと思うことを適用する必要があるでしょう。例：usbを共有すると、コードが大幅に破損することについて文句を言うべきですか？次に、バージョン管理ツールとして（gitではなく）SVNを使用する単純な（複雑ではない）方法を彼らに提供します。
アルノーからのコメントにも同意します。
これらのツールを使用していたときに、これらすべてのツールの利点を確認しました。それが、それらのツールの価値を理解し、その使用法を理解する理由です。チームメイトが現在行っている方法に付加価値が表示されない場合、彼らはそれを適用しません。そして悲しいことに、これはあらゆるレベルの経験を持つ人々で構成されたチームにも当てはまります。
アプローチには問題があります：
あなたのアプローチは対称的ではありません。他のチームメンバーは変更する必要がありますが、あなたは彼らの良い習慣を学んでいません。このような状況でルールを適用することは困難です。より良いアプローチは、チームのすべてのメンバーから適切なルールと実践を収集し、結果のドキュメントを全員が読むことです。
学習は困難です。他の人々のルールは、プログラマが期待している論理構造を持っていないため、意味がありません。意味のないルールを強制することは、有益な活動ではありません。
- 誰もがさまざまなことを学びました。さまざまな背景のプログラマーがさまざまなことを学んだのは当然です。それらの長所は異なり、コードの書き方も異なります。彼らが使用するツールは異なります。一連のルール/ツール/スタイルを適用することは、開発者が長年の学習に費やしてきた強さを制限が失われているため、悪夢になるでしょう。
- 変更には時間がかかります。実施しているルールを発明した人は、ルールを順守するのにかなり簡単な時間を持っていますが、他のすべての人は苦しんでおり、新しいルールの学習に時間を費やしています。これが、チームの全員がルールを変更できる必要がある理由の1つです。
- ツール/コーディング規約の選択またはチーム全体のスタイル難しいアクティビティです。それは時間の経過とともにゆっくりとしか実行できず、何が機能し、何が機能していないかをテストします。チームに2週間かけて50のルールに従って開始することはできません。