会ったことのない人たちとのプログラミング
私はAPコンピュータサイエンスのクラスからグループプロジェクトを割り当てられており、他の3人と協力する必要があります。私はこれまで彼らと話したことがありませんでした。彼らのスキルレベルはわかりません。私が持っているのは彼らのメールアドレスだけです。まとめると、割り当ては次のとおりです。
「チームとして、クラスに最低3つのモジュールを完了します...」
私は「チームキャプテン」になろうとしています。誰もお互いに連絡を取ろうとしなかったので、興味があります。どうすればいいですか。私は彼らに電子メールを送り、彼らがお互いに電子メールを送るよりも好むコミュニケーションの方法があるかどうか彼らに尋ねました、しかし我々が実際にプロジェクトを始めると、誰が何をしているのかを理解しなければなりません。
私は何をすべきか？会ったことのない3人を「担当」して主導するにはどうすればよいですか。
これが実際の割り当ての抜粋です。
したがって、週の初めにこのプロジェクトで各チームメンバーが担うさまざまな役割について話し合う必要があります。 Pronto（またはBlackboard IM）、電子メール、Wiki、Googleグループ、ブログ、またはその他の適切な方法で通信できます。グループメンバーが週末までにグループに参加しない場合は、インストラクターに知らせてください。追加のガイダンスが提供されます。
...
また、プロジェクトの最後にチーム評価が行われ、提案された成績とともに、このプロジェクトの完了に対する各チームメンバーの貢献度を評価します。
編集：多くの人が私が喫茶店などで会うことを提案しました。問題は、私たち全員が異なる状態にあることです。また、そのうちの1つがFacebook、Skype、Twitterの使用を許可されていないこともわかったので、yahooメッセンジャーとメールでメッセージを送る必要があります。
このプロジェクトのリーダーは、最初にステップアップして担当する人になります。
これは、ソフトウェア開発だけでなく、人生の大部分に当てはまります。他の誰もが頭のないニワトリのように走り回っているとき、物事を考えている人が前に進み、「これが私たちがやっていることであり、これが私たちが行っている方法ですそれを行うには。」通常、プロジェクトの残りのリーダーと見なされる人物です。これを行うことで、プロジェクトの最終的な成功または失敗の責任を負うことに注意してください。
このプロジェクトを主導したいですか？大きな影響を与えるためにすぐに始められるいくつかのことをここに示します。
- Trello のようなプロジェクト管理ツールを使用して、全員に招待状を送信し、プロジェクトの一部を人に割り当て始めます。
- バグデータベースを生成し、タスクとバグの追加を開始します-もう一度、割り当てを開始します。
- バージョン管理リポジトリをセットアップし、誰もが作業できる適切なコードの初期チャンクをチェックインします。他の形式のコード制御の処理を拒否します。
- バージョン管理システムとバグデータベースの使用方法を示すことにより、開発を進める人々を支援することを申し出ます。
- プロジェクトのステータスと前週の進捗状況を詳しく説明するメールを毎週送信します。
これらの手順はどれも特に難しい、または時間のかかるものではありませんが、将来的には大幅に時間を節約できます。さらに、それはあなたのチームが互いに話し合い、彼らがあなたを担当するのを見ることに慣れるようになります。
Jarrod Nettlesの回答は、私が提案しようとしていることの大部分を要約しているので、同様の状況での最近の経験で機能したもののいくつかを投入します。
メールではなく、声で話しかける方法を見つけることをお勧めします。同じ地域にいない場合は、すべてをSkypeで入手してください。あなたがその地域にいるなら、喫茶店か何かで彼らに会います。最初の会議で直接話すと、実際に意思決定を行い、その場で仕事を終わらせることができます。電子メールスレッドを使用すると、恥ずかしがり屋や、コンピューターにあまり慣れていない人でも、このプロセスを保留できます。
あなたの最初の会議では、私はあなたのグループがプロジェクトに取り掛かろうとすることについて知るようにしようとしますが、プロジェクトを無視しないでください！氷を割るのに10分から20分は、おそらく4人で十分です。
プロジェクトについて話すとき、私はあなたがプロジェクトに関係していると思うことを実行することをお勧めします。これがあなたの理解であることを明確にすることが重要であり、あなたが彼らに何をすべきかを正確に伝えるケースではありません。誰もが自分の考えやアイデアを持っている場合は、それをリングに投げ込むことができるはずです。また、最初のミーティングから離れて、グループとしてプロジェクトが何を必要としているのかを十分に理解しておく必要があります。
今後の（定期的な）会議では、プロジェクトのさまざまな部分をより詳細に検討し始めることができます。何を正確に実行する必要があるか、どのリソース、どのくらいの時間が必要になるか、誰が何を実行できるかを調べます。必要に応じて、ピースをさらに分割します。おそらく、いくつかのソフトな期限を設定してみてください。
オンラインで会ったことのないグループとの共同作業の経験があり、直接会うことはできませんが、一緒にプロジェクトを完了する必要がありますか。
予算不足、とんでもない締め切りを加えて、マーケティングによって川を下って売りに出されます。これは、現実世界のソフトウェア開発プロジェクトのおよそ65％のように聞こえます。
おそらく、一方的に責任を負ってタスクを割り当てるのではなく、人々が興味のある部分にボランティアを参加させることで、最善を尽くすでしょう。彼らはおそらく彼らがどのように責任を負うべきかについて考えてそこに座っています。または、彼らがどのようにしてすべてのグループ作業をやり過ぎて彼の成績に乗ることができるように気を配っている貧しいsodを手に入れることができますか？.
このような場合に最初に行うことは、 issue tracker を確立して、その使用方法を学ぶことです
あなたが説明するように開発を処理する方法のより基本的な紹介として、私のお気に入りのリファレンスは、Martin Fowlerの記事 オフショア開発でのアジャイルソフトウェアプロセスの使用 です。この記事では、分散型チームコミュニケーションの設定の基本と高度な概念について概説します。
Use Continuous Integration to Avoid Integration Headaches Have Each Site Send Ambassadors to the Other Sites Use Contact Visits to build trust Don't Underestimate the Culture Change Use wikis to contain common information Use Test Scripts to Help Understand the Requirements Use Regular Builds to Get Feedback on Functionality Use Regular Short Status Meetings Use Short Iterations Use an Iteration Planning Meeting that's Tailored for Remote Sites When Moving a Code Base, Bug Fixing Makes a Good Start Separate teams by functionality not activity Expect to need more documents. Get multiple communication modes working early
あなたのプロジェクトでは、そこで言及されているすべてのヒントやトリックを確実に実行することはできません（たとえば、大使も連絡先の訪問もない可能性が高いです）。しかし、とにかく勉強する価値があります。
- 上記のすべてを持っている多くのチームにとって、確かにやり過ぎです。それでも、このような包括的な checklist を用意することは非常に役立ちます。スキップされたアイテムもチェックされ、拒否の理由が明確に文書化されるため、重要なものを逃さないようにしています。
あなたはこれにどのくらいの時間をかけているのか、またはあなたが作業している言語を私たちに教えていません（私は単一のクラスは非常に小さいと思いますが、おそらくあなたの言語ではそれはかなり多いです）。
まず第一に、どんな費用でも実用的な製品を持っています。
プロジェクトの継続時間が2週間以下の場合は、あなただけが何かをしていて、手助けに非常に満足していると思います。全員の予定を立てるようにしてください。ただし、誰も何もしない場合でも、正常に機能する製品があることを確認してください。誰かが何かをしたとしても、その継続に頼るのではなく、いつでも誰かが中退できるように準備してください。
1週間を超える場合は、製品をマイルストーンとしてマークする必要がある曜日をスケジュールし、それをできるだけ遵守することを検討してください。キックできる何かがあることを確認し、欠陥を確認します。最悪の場合は、これがあなたの手に渡ります。作成するものごとに、どれだけ改善できるかがわかり、それがあなたのモチベーションになります。オン。あまり遠くまで計画しないでください。最終的に何ができるかを理解する必要がありますが、最も具体的な計画は短期的に維持する必要があります。
これらの2つは少し重なっていることに注意してください。これは意図的なものです。私の意見では、2週間は少し灰色の領域で、2回の反復を行うのは難しいですが、1回の反復でのみ作業するのは危険です。
私は最悪のケースを想定しています。あなたがプログラミングに非常に新しい人々と一緒に作業することになるでしょう。私の一般的なアドバイスは：
- すぐに実装したい機能のリストと、誰がそれらに取り組むかを保管してください。ジャロッドはトレロを提案しました、そして私はそれを完全にサポートします：もしあなたのチームメイトがあまり経験がなければ、それは大いに役立ちます。そこにバグを残しておくこともできます。
- 4人のチームでは、バージョン管理が必要です。他の人がそのやり方を知らない場合、貢献することをためらうかもしれませんが、それだけの価値はあります。
- 外部の依存関係は初心者を怖がらせる可能性があります。単体テストを作成する場合は、それらを壊すことについて心配する必要がないことを人々に伝えます。特に最初はビルドを壊すことについて心配するべきではないことを人々に伝えます。バグのあるコードをコミットする人よりも、コードをコミットしない人を修正することははるかに困難です。
- ここで提案されていることが本当に当てはまるかどうかを確認してください。 「継続的インテグレーション」は空想的な用語です。小さなプログラムの場合、「このプログラムが実行され、すべての機能を使用できる」ことを意味する場合があります。あなたもサイトを持っていますか？チームに分割することは役に立ちますか？
- YAGNI、百倍以上。本当に必要な場合は、自分で作成する機能について事前に書いてください。それを機能させてからリファクタリングしないと、機能させるために回避できません。
- リファクタリング。動作したら、修正に時間をかけます。チームメイトもコードを読まなければならないことを忘れないでください。醜い部分を修正し、単純なソリューションをより優れたソリューションに置き換えるのに1日を費やすのは無駄なことではありません。
- すべてのパーツに注意してください。変更ログをスキミングし、時々他の人のコードを読むことで、すべてがあなたが実施すべきと感じる品質基準に達していることを確認し、その人が脱落した場合に飛び込むのがそれほど難しくないことを確認できます。
- 指定されたものとは対照的に、最も重要なものに取り組むことを躊躇しないでください。誰かが予定より遅れている場合は、どこかにそれを書いてメモして、自分で行います。最初に彼らに尋ねますが、彼らが答えない場合、またはあなたが一度か二度尋ねて、それでも彼らがまだそれをしないように感じる場合は先に進んでください。
- 誇りに思うものを作ることに集中しましょう。課題から外れても。大きな機能をカットして、よりスムーズなものにする必要がある場合でも。すべての反復で「私はこれに誇りを持っていますか？」と考え、次の反復ではそれらを修正してみます。
最近ひどく失敗したプロジェクトがありました。あなたはできます 私の考えを読んでください 失敗した理由についてですが、もう一度機会があれば、これは私がこのようなことをする方法を要約しています。
ジャロッド・ネトルズの答えは良いです。私はこれを追加します：
- 他の3人のうち少なくとも1人が完全に役に立たなくなることを期待してください。
- 仕事のほとんど（またはすべて）を行っているように感じられることを受け入れてください。物事を「公正」にしようとする試みは、不必要な衝突を引き起こし、あなたを遅くするだけです。
- 良いチームメンバーと連絡を取り合う。そのような人々は見つけるのが難しく、あなたは彼らと再び仕事をしたいと思うでしょう。
多くの人がいると思いますので、私は数回同じような立場にあります。しかし、主なことは、全員を満足させて幸せに保つために最善を尽くすことです。したがって、上記の誰かのように、チームリーダーのタスクを引き受けたいと思うのは良いことだと思います。代わりに仕事をすべきだと感じるかもしれません。
お互いに連絡を取ることは誰もしていませんが、会ったことのない人と仕事をしているとかコミュニケーションが難しいとか、そういう状況は人によっては難しいこともあると思います。
まずは全員に宛てて、プロジェクトへの取り組み方をあなたに伝え、役割、目標、締め切り、コミュニケーション時間、交流会の責任を負ってプロジェクトを主導したいことを知らせるメールから始めます（必要な場合）、プロジェクトの更新。
他の人に完全に影響を与えることはできませんが、誰が何をしていて誰がしていないかを追跡できます。ジョブを委任することで、スキルセットやレベルが異なる人々に作業を均等または適切に分割できます。
このようにして、特定の作業が行われていない場合、実際に作業に熱心な人々の間で作業を分割することができます。このようにして、最後にプロジェクトが失敗することはありません。日付、時刻、および問題が発生した場合に最後に表示できるすべての関連情報を伝えようとした記録があります。一部の人々が自分の体重を引っ張らない場合にあなたを右に保つすべての事柄。
ヒントに関して：
私はここにある共同作業環境を個人的に気に入っています： https://docs.google.com/
これにより、Word文書、スプレッドシートなどを共有できます。これは、共同作業を行うための優れた方法です。時々これがいかに役立つかを強調することはできません。現在、その国にいない、一緒に仕事をしている人たちと一緒に使っています。
これが誰かのお役に立てば幸いです。私たちがプロジェクトをリードすることには、多くの側面があります。少なくとも、これは少しは役に立ちます。