会ったことのない人々とのプログラミング


50

APコンピューターサイエンスクラスからグループプロジェクトを割り当てられ、他の3人と協力する必要があります。私は以前彼らと話したことがなく、彼らのスキルレベルがわからず、彼らのメールアドレスしかありません。要約すると、割り当ては次のとおりです。

「チームとして、クラスに少なくとも3つのモジュールを完了します。...」

私は「チームキャプテン」になろうとしていますが、彼らは誰もお互いに連絡をとろうとしませんでしたが、私は興味があります。私は彼らにメールを送り、お互いにメールを送るよりもコミュニケーションの方が良いかどうか尋ねましたが、実際にプロジェクトを開始したら、誰が何をしているのかを把握する必要があります。

私は何をすべきか?会ったことがない3人を「担当」し、リードするにはどうすればよいですか。

以下は実際の割り当ての抜粋です。

したがって、各チームメンバーが週の初めにこのプロジェクトで果たすさまざまな役割について話し合う必要があります。Pronto(またはBlackboard IM)、電子メール、Wiki、Googleグループ、ブログ、またはその他の適切な方法を介して通信できます。週の終わりまでにグループメンバーがグループに参加しない場合は、インストラクターに知らせて、追加のガイダンスを提供します。
...
また、プロジェクトの終了時にチーム評価が行われます。この評価では、各チームメンバーがこのプロジェクトの完了への貢献度と推奨成績を評価します。

編集:多くの人々は、私が彼らにコーヒーショップなどで会うことを提案しました。唯一の問題は、私たち全員が異なる状態にあるということです。また、そのうちの1人がFacebook / Skype / twitterの使用を許可されていないこともわかったため、yahooメッセンジャーとメールでメッセージを送信することに頼らなければなりません。


10
指示についてSEに尋ねるのではなく、「この人々に話しかける」、「彼らと知り合う」、「彼らがそのプロジェクトに望むものを聞く」、「あなたの心で考える」のはどうでしょうか。ここの誰もそれらを知りません。もし彼らに何らかの行動障害があり、彼らが権力の座にいるなら、方向を尋ねることは理にかなっているかもしれません...しかし、それらはあなたのような男です。あなたはサンドボックスにいます:物事を理解する時です。
ZJR

6
@zjrガチョウを燃やしたのは誰ですか?もちろん、私は彼らと一緒に仕事をしていて、何かを理解しようとしています。しかし、私はこのプロジェクトをやみくもに行うのではなく、以前にこのタスクを処理したことがある人々からアドバイスをもらいたいと考えました。また、人々はいくつかの素晴らしいプロジェクト管理アプリケーションに言及し、私はいくつかの新しいことを学びました。
ガブリエル

2
@ZJRそれが彼の質問のポイントなのかわかりません。彼は以前に彼らと実際にコミュニケーションをとったことはないと言っていましたが、彼の質問はこれがプログラミングプロジェクトであり、彼が対処するために与えられたチームとどのようにアプローチするべきかに関するものでした。
ジャロッドネトルズ

回答:


90

このプロジェクトのリーダーは、最初にステップアップして担当する人です

これは、ソフトウェア開発だけでなく、人生のほとんどのものに当てはまります。他のみんなが頭のない鶏のように走り回っているとき、物事を考え、前進し、「これが私たちがやろうとしていることであり、これをどうやってやろうか」と言う人。通常、プロジェクトの残りのリーダーとして見られる人です。これを行うことにより、プロジェクトの最終的な成功または失敗に対して責任を負うことに留意してください。

このプロジェクトをリードしたいですか?大きなインパクトを与えるために、すぐ始められることがいくつかあります。

  1. Trelloなどのプロジェクト管理ツールを使用して、全員に招待状を送信し、プロジェクトの一部を人々に割り当て始めます。
  2. バグデータベースを生成し、タスクとバグの追加を開始します -再度、割り当てを開始します。
  3. バージョン管理リポジトリをセットアップし、誰もが作業できるコードの適切な初期チャンクをチェックインします。他の形式のコード制御の処理を拒否します。
  4. バージョン管理システムとバグデータベースの使用方法を示すことで、人々が開発を進めるのを支援します。
  5. プロジェクトのステータスと前週の進捗状況を詳しく記載したメールを毎週送信します。

これらの手順はいずれも特に難しく、時間もかかりませんが、今後の時間を大幅に節約できます。さらに、それはあなたのチームがお互いに話し合い、彼らにあなたが担当しているのを見ることに慣れさせます。


17
2人のチームメンバーがこのアプローチを試みる場合、注意してください。制御し、リードするための闘争は災害になる可能性があります-何もしないチームメートの束よりもはるかに悪いです。
コービン

3
@CorbinMarch同意しました。これは、チーム内に明確なリーダーシップの欠如がある場合にのみ機能します-誰もが他の誰かが物事を進めるのを待っています。すでにリーダーとして登場している他の人がいる場合、プロジェクトでできる最善のことは、その人の後ろに立ち、彼らをサポートすることです。
ジャロッドネトルズ

4
これを読んだ後、Trelloをチェックアウトしましたが、そのシンプルさにすぐに魅了されました。リンクの+1。ローカルにこの事をインストールする方法があれば、それは最も完璧なものだろう...
ラドゥMurzea

2
The leader of this project will be the person who steps up and takes charge at the beginning.すべてがブログオーバーロードを
称えます

5
そもそもコーヒーショップで彼らに会ってみてはいかがですか?彼らが持っているスキルがわからない場合、どのようにタスクを割り当てますか?個人的には、以前に会ったことなく「ここにTrello、ここにバグトラッカーがあり、ここにあなたのタスクがあります」というメールを受け取るのは好きではありません。
サイモン

24

Jarrod Nettlesの答えは、私が提案しようとしていたことをかなり要約しているので、同様の状況での最近の経験でうまくいったものをいくつか紹介します。

メールではなく、声で話す方法を見つけることをお勧めします。同じエリアにいない場合は、すべてSkypeで入手してください。あなたが地域にいるなら、コーヒーショップか何かで彼らに会ってください。最初の会議で直接話すことは、実際に意思決定を行い、その場で仕事を終わらせることにつながります。電子メールスレッドを使用すると、恥ずかしがり屋であったり、コンピューターを使用していない人でもプロセスを遅らせることができます。

あなたの最初の会議では、私はあなたのグループがプロジェクトに取り組もうとすることを知るようにします-しかし、プロジェクトを無視しないでください!4人のうち、10分または20分間のアイスブレークで十分でしょう。

プロジェクトについて話すときは、プロジェクトに関係すると思うもの実行することを勧めします。これがあなたの理解であることを明確にすることが重要だと思います。あなたが彼らに何をすべきかを正確に伝える場合ではありません。誰もが自分の考えやアイデアがあればそれをリングに投げ入れることができなければなりません。そして、あなたがグループとしてプロジェクトに伴うことを十分に理解して、最初の会議から離れるべきです。

将来の(定期的な)会議では、プロジェクトのさまざまな部分をより詳細に調べ始めることができます。正確に何をする必要があるか、どのリソースが必要か、どれだけ時間が必要か、誰が何をすることができるかを見てください。必要に応じてピースをさらに分割します。おそらく、いくつかのソフト期限を設定してみてください?


4
音声連絡に言及する場合は+1。個人的には最高、ビデオチャットは次に最高、電話会議は単なるメールよりも優れています。
-Barend

@andybursh残念ながら、1人の学生はFacebookさえも使用できません。したがって、Skypeは問題外です...テキストで物事を理解できることを願っています。
ガブリエル

10

あなたがオンラインで会ったことのない人々のグループと仕事をした経験がありますか?あなたは彼らと直接会うことはできませんが、一緒にプロジェクトを完了する必要がありますか?

予算不足、ばかげた期限、そしてマーケティングによる川下での売り上げを追加すると、現実世界のソフトウェア開発プロジェクトの約65%のように聞こえます。

おそらく、一方的に担当してタスクを割り当てるのではなく、興味のある部分についてボランティアにボランティアをしてもらうのが一番良いでしょう。彼らはおそらく、彼らがどのように担当するべきかを考えてそこに座っているでしょう。または、どのようにすれば、すべてのグループワークをするのが面倒な貧しいソッドを取得して、彼の成績に乗ることができますか。


2
あなたは、私たちの多くが以前に会ったことのないオフショアチームと協力しなければならないという事実を忘れていました。
maple_shaft

7

このような場合に最初に行うことは、課題追跡を確立し、その使用方法を学ぶことです。

あなたが説明するような開発の処理方法に関するより基本的な紹介については、Martin Fowlerの記事「Offshore Developmentでのアジャイルソフトウェアプロセスの使用参照してください。この記事では、分散型チームコミュニケーションのセットアップの基本と高度な概念について説明します。

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

あなたのプロジェクトでは、そこに記載されているすべてのヒントやコツをたどることはできません(たとえば、大使も連絡先訪問もない可能性があります)。とにかく勉強する価値はあります。

  • 上記のすべてを持っている多くのチームにとっては、間違いなくやり過ぎです。それでも、そのような包括的なチェックリストを持っていると本当に助かります-スキップされたアイテムでもチェックされ、拒否の理由が明確に文書化されます-ただ重要なものが見逃されなかったことを確認するためです。

6
私はそれらの点に同意しますが、彼のチームは非常に短い間だけ集まっており、これらの提案のほとんどは彼が必要とするものに対して深刻なやり過ぎです。しかし、より高度な常設チームに非常に適用可能です。
ジャロッドネトルズ

私は答えに更新-良い点だおかげ@JarrodNettles
ブヨ

3
...ええ、実際のコードを一切生成せずに、それらを官僚主義の地獄に高速追跡しましょう。お願いします。
ZJR

1
@ZJRとして、私は彼のリストには、この種のプロジェクトのために少し広範囲であるが、適切なチームとコードの組織は彼らが作り出すようになると述べた作業コード自分の画面上だけではなく、コードを。
ジャロッドネトルズ

@ZJRは、ファウラーによってリストされたものに適しています。むしろ、「官僚的な」標準に従うことを好みます。バグを追跡し、コードの変更を統合し、チームの知識を共有する独自の創造的な方法を発明するというアイデアは、どういうわけか私の火をつけ
-gnat

5

あなたはこれのためにどれだけの時間を費やしているか、またはあなたが働いている言語を教えていない(私は単一のクラスは非常に小さいと言うだろうが、おそらくあなたの言語ではそれはかなりのことだ)。

まず第一に、どんなコストでも動作する製品を持っています。

プロジェクトが2週間以下続く場合は、あなたが何かをしている唯一の人であり、あなたが得る助けに非常に満足していると仮定します。皆のために物事をスケジュールしようとしますが、誰も何もしなければ、あなたがまだ機能する製品を持っていることを確認してください。誰かが何かをしたとしても、それらに継続することに頼らないでください。誰かがいつでも中退できるように準備してください。

1週間以上ある場合は、製品をマイルストーンとしてマークし、可能な限りそれを維持する曜日をスケジュールすることを検討してください。キックできるものがあることを確認し、次の欠陥を確認します。最悪の事態が悪化した場合、これがあなたの手に渡ります。作成するたびに、物事をどれだけ改善できるかがわかります。オン。あまり先のことを計画しないでください。確かに、最終的にはどうなるかを把握する必要がありますが、最も具体的な計画を短期的に維持してください。

これらの2つは少し重なっていることに注意してください。2週間は2つの反復を行うのが難しい灰色の領域であるため、これは意図的なものですが、1つの反復で作業するだけでは危険です。

最悪の場合を想定しています。プログラミングが初めての人と一緒に仕事をすることになります。私の一般的なアドバイスは次のとおりです。

  • すぐに実装したい機能のリストと、その機能を誰が担当するかを保持してください。JarrodはTrelloを提案しましたが、私はそれを全面的に支持します。チームメイトがそれほど経験が浅ければ、それは大いに役立つでしょう。そこにバグを残してみることもできます。
  • 4人で構成されるチームでは、バージョン管理が必要です。他の人がそれをどのように使うか分からない場合、貢献することをためらうかもしれませんが、それは価値があります。
  • 外部の依存関係は初心者を怖がらせるかもしれません。単体テストを作成する場合、それらを壊すことを心配するべきではないことを人々に伝えてください。特に最初は、ビルドを壊すことを心配しないでくださいと人々に伝えます。バグのあるコードをコミットする人よりも、コードをコミットしない人を修正するのははるかに困難です。
  • ここで提案されていることが本当に当てはまるかどうかを確認してください。「継続的インテグレーション」は空想的な用語です。小さなプログラムの場合、「このプログラムが実行され、すべての機能を使用できる」ことを意味する場合があります。サイトもありますか?チームに分割することは役立ちますか?
  • YAGNI、百回以上。本当に必要な場合は、自分で作成する機能について事前に記述してください。動作させてからリファクタリングします。そうしないと動作しません。
  • リファクタリング。動作したら、しばらく時間をかけて修正します。チームメイトもコードを読む必要があることを忘れないでください:lyい部分を修正し、シンプルなソリューションをパフォーマンスの良いものに置き換えるのに1日も無駄になりません。
  • すべての部品に注意してください。変更ログをスキミングし、ときどき他人のコードを読むことで、すべてが強制する必要があると感じる品質基準に達していることを確認し、人が脱落した場合に飛び込むのが難しくないことを確認できます。
  • 指定されたものとは対照的に、最も重要なことに取り組むことをheしないでください。誰かが予定より遅れている場合は、それをどこかに書き留めて、自分でそれをしてください。最初に質問しますが、答えない場合、または1回または2回質問した後、まだやらないように感じる場合は先に進みます。
  • あなたが誇りに思うものを作ることに焦点を当てます。割り当てから外れても。あなたが持っているものをよりスムーズにするために大きな機能をカットする必要がある場合でも。すべてのイテレーションは「私はこれを誇りに思っていますか?」と考え、次のイテレーションではそれらを修正しようとします。

最近、ひどく失敗したプロジェクトがありました。あなたが望むなら失敗した理由についての私の考え読むことができますが、これは私が別の機会があった場合にこのようなことをする方法を要約しています。


興味深いの読み取りは、私は似たような状況にしてきたし、欠点のいくつかは非常に共通しているようだ
ジョー・テイラー

4

Jarrod Nettlesの答えは良いです。これを追加します:

  1. 他の3人のうち少なくとも1人は完全に役に立たないことを期待してください。
  2. ほとんどの(またはすべての)作業を行っているように感じるが、誰もが平等に評価されることを受け入れる。物事を「公正」にしようとする試みは、不必要な競合を引き起こし、あなたを遅くするだけです。
  3. 優秀なチームメンバーと連絡を取り合う。そのような人々を見つけるのは難しいので、あなたは彼らと再び働きたいでしょう。

私はあなたの最初の2つの点に同意しません。最悪の人々を期待しないでください、またはそれはあなたが得るものです。あなたはresりを抱き、あなたの軽daを感じた場合、有用なチームメンバーのサポートを失う可能性があります。その言語に不慣れな子供を指導することは、素晴らしい経験となり、仕事の負担を減らすことができます。(ただし、考えることを拒否するヒルには注意してください。)また、プロジェクトには「チーム評価」があるため、作業を行う人は誰でも信用を得ることができます。(または、誰もが汚れを何も得ないように感じさせた人は誰でも)残酷に正直になり、何もしなかった男が失敗することを心配しないでください。それはあなたのチームにとって公平です。
idbrii

3

多くの人がいると確信しているので、私は何度か同じような立場にあります。しかし、主なことは、すべての人に満足と幸せを保つために最善を尽くすことです。したがって、上記の誰かのように、チームリーダーの仕事を引き受けたいと思うのは良いことだと思います。代わりに仕事をするべきだと感じるかもしれません。

誰もお互いに連絡を取ることはありませんでしたが、会ったことのない人と仕事をしている、コミュニケーションが難しいなどと言っているように、時にはこれらの状況は人々にとって難しい場合があります

私は、全員に宛てた電子メールから始めて、プロジェクトの対処方法をあなたが誰であるかを伝え、役割、目標、期限、コミュニケーション時間、ミートアップを設定する責任を負ってプロジェクトをリードしたいことを知らせます必要に応じて/望まれる場合)およびプロジェクトの更新。

他の人に完全に影響を与えることはできませんが、誰が何をして、誰がしていないかを追跡できます。ジョブを委任することで、異なるスキルセットまたはレベルを持つ人々に作業を均等または適切に分割できます。

このように、特定の作業が行われていない場合、実際に作業を行うことに熱心な人の間で作業を分割することができます。この方法では、最後にプロジェクトが失敗することはありません。問題が発生した場合、最後に表示できる日付、時刻、および関連するすべての情報を伝えようとする記録があります。一部の人々が自分の体重を引っ張らない場合にあなたを正しい状態に保つすべてのもの。

ヒントに関して:

個人的には、https//docs.google.com/にある共同作業環境が大好きです

これにより、単語文書、スプレッドシートなどを共有できます。これは、共同作業の優れた方法です。これがときどきどれほど役立つかを強調することはできません。私は、現時点でこの国にいない人と一緒に仕事をしています。

これが誰かを助けることを願っています、私たちが永遠に続けることができるプロジェクトを導くことの非常に多くの側面がありますが、それは非常に多くのものに依存しています。少なくともこれは少し助けになります。


P.SEへようこそ!ここでのアドバイスのために+1。いいアドバイス。
ジャロッドネトルズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.