タグ付けされた質問 「teamwork」

同僚やチームとの共同作業に関する質問。(チームワークの質問は、キャリアのアドバイスや教育について「話題から外されている」というリスクにさらされています。)

8
チームリーダーとしてのパフォーマンスについてチームに尋ねるべき3つの最も重要な質問は何ですか?
私は、小さなソフトウェア会社内の小さな開発チーム(私を含む4人のメンバー)のリーダーとして1年のマークに近づいています。チームの開発者でもあるチームリーダーとして自分がどのように働いているかを評価する機会をチームに与えたいと思います。 オープンエンドの「元気ですか?」で良いフィードバックを得るのは難しいと思います。質問ですので、どの特定の質問が最も重要ですか?理想的には、私のチームが答えられる3つの簡単な質問を提供できるようにしたいと思います。チームリーダーにフィードバックを提供したい最も重要な部分はどれですか? 私の最初の考えは、私のチームがこれらの質問に匿名で回答できるようにすることでしたか?これはいい考えですか?

17
一貫したコーディングスタイルを持っていない同僚に対処しますか?
スタイルが悪いコードを書く傾向がある人と仕事をしているとき、あなたは何をしますか?私が話しているコードは通常、技術的に正しく、合理的に構造化されており、アルゴリズム的にもエレガントかもしれませんが、見た目はいだけです。私たちは持っている: 異なる命名規則とタイトルの混合(underscore_styleおよびcamelCaseおよびUpperCamelおよびCAPSすべては、同じ関数内の異なる変数に多かれ少なかれランダムに適用されます) 奇妙で一貫性のない間隔、例えば Functioncall (arg1 ,arg2,arg3 ); コメントおよび変数名に多くのスペルミスのある単語 私が働いているコードレビューシステムは優れているので、最悪のものを調べて修正することができます。ただし、50行の「ここにスペースを追加します。「イタレーター」を正しく入力してください。この大文字化を変更します。」などの50行で構成されるコードレビューを送信するのは本当にささいなことです。 この種の詳細にもっと注意を払い、一貫性を保つよう、この人にどのように勧めますか?

2
優れた/より良いソースコード管理慣行を実施する方法
私は間違った問題に焦点を合わせているのではないかと思うので、まず、私が思い描くかもしれない準最適な解決策を提示する前に、問題が何であるかを説明します。 現在の状況: 現在、私の同僚は、変更がプロジェクト全体に広がっている巨大な塊で、長い時間を経て初めてコードの変更をコミットします。かなり前のことですが、彼らはネットワーク共有に.zipアーカイブを置くだけだからです。それでも、マージは悪夢です-率直に言って、私はそれで十分でした。また、話したり説明したり、物beいをするのもうんざりです。これはやめなければならない-私なしで常に「悪者」である。 私の解決策: 問題に気づいていない、および/または問題に関心がないようであり、数日以上続く努力は期待できない...それを何時間も打って、subversionサーバーにそれをしてもらいたいしつこい。 私の質問: 私はここから離れたところにいるのでしょうか、それとも間違った問題を見ていますか?私は何かを見逃しているようで、問題を解決するツールを見ることで間違ったことを尋ねていると思います。 この問題を解決するツールを探しているべきですか、それともこれを修正するために何をすべきですか?

7
チームメイトに基本的なルールに従うよう説得する方法
チームメイトに問題があります。簡単に言えば、私たちはコンテストのプロジェクトで働く3人の学生です。このプロジェクトは、2つの個別のアプリケーションで構成されています。1つはWindows用(もう1つは開発中)、もう1つはAndroid用(私の同僚が開発に責任を負います)です。コードベースが交差することはなく、アプリはサードパーティのツールを介して通信します。 問題は次のとおりです。昨年大企業でインターンシップを行ったときにチームで働いた経験があり、コードのコーディング標準を強制しようとしています。また、コードをプッシュしたり、アイデアを書いたり、プロトコルを文書化したりするために使用できるgitリポジトリ/ wiki /コラボレーションソフトウェアも設定しましたが、これらのツールを使用しているのは私だけであるようです。 質の高いコードを書いて、すべてのステップを文書化することは長期的には私たちに利益をもたらすと彼らに伝えようとしましたが、彼らはそれの利点を理解していないようです。また、いくつかの統合テストを追加することを考えていましたが、私が見ることができることから、彼らが生活を楽にするために現在のツールを使用しない限り、統合テストの有用性を説得することはできないと思います。 ピアのコードのほとんどは自分のコンピューター上にあり、共通のコードベースを共有していません。私が知ったように、彼らはusbスティックを介してコードを会議および共有することで、それらの部分を統合しました。 私の質問は次のとおりです。いくつかの不条理なルールを施行しますか?これは小さなプロジェクトであり、要件は非常に明確であることに注意してください(アプリケーションの動作を指定するドキュメントを作成しました)。3人の熟練した開発者が3〜4日でこれを行うことができます。現在のメソッドが機能する限り、コードを作成します。 gitなどを使用してコードをドキュメント化することの利点を示す方法はありますか?

13
私たちのチームの色盲のメンバー
私のチームは、作業する必要がある機能の概要を示すために、コード内の色に大きく依存しています(注意が必要なコードの行に色を付けます)。私たちには色盲の親友がいて、私たちのチームに参加したいと思っています。色を使用せずに作業が必要なものを強調するために何ができますか?チームには約25人の従業員がおり、全員がラインのカラーリングシステムに慣れており、最も効率的であることがわかりました。
28 teamwork  color 

13
プログラマーが宝くじに当たった場合、会社が水中に進まないようにする方法[非公開]
私の下には数人のプログラマーがいますが、彼らはすべて非常に優れており、明らかに賢明です。どうもありがとうございました。 しかし、問題は、それらの各自が1つのコア領域を担当していることです。チームの他の誰も、それが何であるかについて最も曖昧な考えを持っていません。これは、それらのいずれかが取り出された場合、それらは交換できないため、ビジネスとしての私の会社は死んでいることを意味します。 彼らがバスに遭ったり、辞任したりする場合に備えて、新しいプログラマを招いて彼らをカバーすることを考えています。しかし、私はそれを恐れています 古いプログラマーは、バックアップによって価値が低下するのではないかと恐れて、知識移転の考えに積極的に抵抗するかもしれません。 異なる開発者間の技術移転を促進するシステムがないので、たとえ彼らにそれを行うように頼んだとしても、彼らがそれを適切に行うという保証はありません。 私の質問は、 彼らが同意するような古いプログラマーにそれを置く方法 この種の「バックアップ」を容易にするために使用するシステムは何ですか?コードレビューができることは理解できますが、これを行う簡単な方法はありますか?チェックインコードレビューによる本格的なチェックインの準備ができていないと思います。

13
時代遅れの同僚を扱う
私はかなり若いプログラマーであり、中規模の会社のIT部門で働いています。同僚がいますが、彼は本当に優れたVisual Basic 6プログラマです。そして、私は本当に良いことを意味します。正直に。彼は、最初のコーヒーを手に入れてマシンを起動する必要があるときに、バグをほとんど含まない実用的なアプリケーションを提供できます。彼はちょうどいいです。 事は、私達はチームと協力しており、彼の働き方は完全に時代遅れです。彼はソフトウェアのバージョン管理を信じていません(コードが正しいことを確認するだけであれば、そのナンセンスは必要ありません)。展開を信じていません(実行可能な実行可能ファイルを配信できます。展開方法は、システム管理者が判断するためです)。抽象化を信じていません。(「サブルーチンを作成したい場合は、先に進みますが、そのサブルーチンからサブルーチンを呼び出さないでください。そのように面倒になり、コードを追跡するのが難しくなります。 'または'はい、そのライブラリを使用してそれを行うことができますが、その方法では何が起こっているのか本当に理解していません)」と確かにOOPを信じていません。(VB.netで作業しています) 彼は自分の仕事がとても上手で、私よりも早くアプリケーションを配信できます。しかし、チームでは機能しません。私たちの他のチームメンバーは静かで、発言するのは好きではありませんが、彼は同意する傾向があります。私たちのマネージャーは、私が正当な点を挙げていると思いますが、プログラマーではありません。 私は彼が書いたプログラムを維持するのに本当に苦労しており、それは良いチームの雰囲気にはなりません。私にとって何が一番いいと思いますか?

8
スクラムマスターとしての開発マネージャーのマイナス面は何ですか?
チームマネージャーがスクラムマスターであってはならないということは一般的に認められていますが、その理由を理解するのに苦労しています。コンテキストでは、私はスクラムチームに4人の開発者がいるアプリケーション開発マネージャーです。私はスクラムマスターのバックグラウンドを持ち、組織にスクラムを導入しました。私はチームをゼロから構築し、私がやることはすべてチームを促進することであり、彼らが決定を下すことを明確にしました。チームとして私たちは非常にオープンです-彼らは私たちが取得し始めていた「報告」の感覚を排除するために、しばらくスタンドアップで私を黙らせさえしました。一般的に、オープン性の欠如は、スクラムマスターとしてのマネージャーに対する最大の議論ですが、適切に処理されれば、適切な文化で簡単に克服できます。 経験豊富なスクラムコーチから、これは危険な状況であり、「物事がうまくいかない場合」のリスクがあると警告されています。私の考えでは、2つの役職は対立しません。どちらの役割においても、チームと個人の目標は同じです。スクラムは、チーム内の競合を解決します。これは、従来はマネージャーの役​​割でした。スプリントの自己管理の性質により、マネージャーが従来行っていた作業の割り当てがなくなります。 開発者マネージャーが個人のニーズを満たしていること、キャリアの目標、職場などを確認しているので、ピックアップするのは本当に残っていると思います。これの多くは、チームに直接関係しています。または、とにかくスクラムマスターとしての私の役割に関連しています。 大規模な組織では、これが管理不可能で別の役割になることを理解していますが、小規模な組織では、別のスクラムマスターまたは開発マネージャーを正当化することはできません。 スクラムマスターとしての開発マネージャーの落とし穴について教えてください。上で挙げた点と既に克服した点を除きます。
27 scrum  teamwork  team  roles 

7
気分を害することなくどのようにコーディングしますか?
つまり、何年も取り組んでいて、それに精通している開発者と共有するコードベースでどのように開発しますか? 私は誰かの足の指を踏みつけたくありませんが、コードのホワイトスペースの方法やSVNへのチェックインの頻度(あまりにも頻繁に)について、私は物事のやり方についてそれほど微妙な不満はありません。そのため、これらのことは簡単に変更できますが、一般的にはより良いチーム開発者になりたいです。 質問する以外に何をすべきかはわかりませんが、おそらく皆さんは私が実践できる考えを持っているかもしれません。 更新 話すべきスタイルガイドはありません。コードベースの共有に慣れていないだけです。誰もが独自の小さなサイロ化されたコード世界を持っています。 これはperlショップですが、これらはどの言語にも当てはまると思います 更新2 後にCEOになったCTOは完全な誇大妄想であり、これらの不満の主な原因でした。Macを使用しているか、Emacsを使用しているか、2つではなく4つのタブスペースを使用しているか、特定の方法で服を着ているかどうか、彼が好きなことを正確に行わなかった場合、あなたは劣っていました。それは私が修正しようとした恐ろしい状況でしたが、私にとって唯一の正しい答えは去ることでした。 これは職場でのいじめの一例であると確信しており、その後、職場環境での微妙ないじめや不適切な行動が何であるかをよりよく認識しています。 このような状況への回答を探している開発者には、すぐに離れてください。悪いチーム状況から抜け出すためにチームワークすることはできません。
27 teamwork 

6
一連の悪い雇用主がいた場合はどうしますか?[閉まっている]
だから、私は一連の本当に悪い経験をしていて、私が何を間違っているのだろうと思っています。 私は主要な大学で非常勤プログラマーとしてスタートしました。手首に問題が発生し、人間工学に基づいた宿泊施設で(いいかい)助けを求めました。 私の上司は私に向かって叫び始め、その後彼女に向かって叫んだと主張しました。それについて質問すると、彼女はすすり泣き始めた。幸いなことに、叫び声を聞いて、私が真実を語っていることを知っている他の人たちがいた。彼女は最終的に手放されました。 私は契約を結び、今回はスタートアップに転職しました。まあ、私は開発マシンを手に入れずに数ヶ月間行きました。経済が衰退したとき、彼らは異常な量の残業を求め始めました。仕事を探すことを恐れていたので、私は従いました。最後のストローは、問題を解決するために父の葬儀の直前に私に連絡したことです。 私は解雇され、期限内に最終チェックを受けなかったため、会社は数か月間処方箋を入手できなくなるまでCOBRAをねじ止めしました。彼らは最近、彼らがしたことに対してX州から罰金を科された。今、私は彼らのために心を尽くし、彼らは罰金を科される前に喜んでいたが、彼らは参照を提供することを拒否している。 主に健康保険の設定が本当に必要だったので、私はすぐに新しい仕事に就きました。彼らは私に数週間で数ヶ月の仕事をしてほしかった。彼らにはプロジェクト計画がありませんでした。誰かがスペルチェックを実行すると、アプリケーションのセクション全体が機能しなくなるため、顧客は真剣にうまくいっていませんでした。彼らは私の仕事についてまったく予想外の期待を持っていたにもかかわらず、彼らはスペルチェックのバグを修復するのに数ヶ月かかると喜んでいた。トレーニングはほとんどありませんでした。 彼らは私に候補者にインタビューしてもらい、私は1人を選びました。どうやら、私は数ヶ月後に手放されたので、その人は私の代わりでした。 最近、私の元上司が私の現在の雇用主に電話をかけ、彼の会社でのポジションの採用を人々に思いとどまらせているとの申し立てを行いました。 「気が狂っている、または誰かを蹴ってひどい扱いをしてもらいたいなら、私を雇ってください」と言うTシャツがあるように感じます。 再び、プログラマーの履歴書を見ると、ホラーストーリーも見られます。 これらの問題を回避するために私が異なる方法でできることはありますか?人々に基準がないというのは、私たちの職業の一部ですか?おそらくそれは人格の問題であり、純粋に私にあるのでしょうか? 他の誰かが一連の悪い経験をして、物事を好転させましたか?

11
一部のタスクで会社でサポートされていない言語を使用しても大丈夫ですか?
COBOL、VB6、C#、Javaなどの複数の言語をサポートする会社で働いています。 私はこれらの言語を主な仕事に使用しますが、Pythonでいくつかのマイナープログラム(スクリプトなど)をコーディングすることにしばしば気づきます。 たとえば、アナリストが複雑なCSVファイルを提供していくつかのDBテーブルにデータを入力するため、Pythonを使用して解析し、DBスクリプトを作成します。 どうしたの? 主な問題は、これらの迅速で汚いスクリプトのいくつかの部分が徐々に重要性を増していることです。 私の会社はPythonをサポートしていません バージョン管理されていません(別の方法でバックアップします) 私の同僚はPythonを知らない アナリストは、電子メールでそれらを参照し始めています(「エクスポートするスクリプトを起動します...」)ので、私が最初に思っていたよりも頻繁に必要になります。 これらのスクリプトは、メインプロジェクトの一部ではない単なるユーティリティであることを付け加える必要があります。単純なタスクをより短い時間で完了するのに役立ちます。私自身の小さなタスクのために、彼らは多くのことを助けます。 つまり、私が宝くじに当たって事故に遭った場合、同僚はこれらのスクリプトがなくてもプロジェクトを維持する必要があります。たとえば、手作業でCSVエラーを修正するのに時間がかかります。 これは一般的なシナリオですか?私は何か間違っていますか?私は何をすべきか?

9
「時期尚早な最適化がすべての悪の根源」についての誤解に対処する方法は?
私は、一般的な英語の意味で「最適化」とみなされるものに対して独断的に多くの人々に出会いました。そして、彼らは非常にしばしば「部分的な」引用「早すぎる最適化はすべての悪の根源」です彼らのスタンスの正当化として、私が話していることは何でも「時期尚早の最適化」であると解釈することを意味します。しかし、これらのビューは非常に馬鹿げているため、最も純粋な「単純な」実装からのあらゆる種類のアルゴリズムまたはデータ構造の逸脱、または少なくとも以前のやり方からの逸脱を排除します。「パフォーマンス」や「最適化」について聞いてからシャットダウンした後に再び「耳を開く」ように、このような人々にどのようにアプローチできますか?「この男は10行のコードに2週間を費やしたい」とすぐに思わせることなく、パフォーマンスに影響を与える設計/実装のトピックについて議論するにはどうすればよいですか。 さて、「すべての最適化は時期尚早ので、悪である」かどうかのスタンスがいるすでにここにカバーされてだけでなく、ウェブの他のコーナーで、すでに議論されている最適化は時期尚早ので、悪の場合に認識する方法が、残念ながら、現実の世界には、反最適化への信仰への挑戦に対してあまり開かれていない人々がまだいます。 以前の試み 数回、「時期尚早の最適化は悪い」↛「すべての最適化は悪い」と説明するために、ドナルドクヌースから完全な引用を提供しようとしました。 私たちは小さな効率を忘れてはなりません。約97%の時間です。早すぎる最適化はすべての悪の根源です。しかし、その重要な3%でチャンスを逃してはなりません。 しかし、見積もり全体を提供するとき、これらの人々は実際に、私がやっていることはPremature Optimization™であると確信し、耳を傾けて拒否します。それはまるで「最適化」という言葉が彼らを怖がらせるかのようです:数回、「optimiz(e | ation)」という言葉の使用を単に避けることで、拒否されずに実際のパフォーマンス改善コードの変更を提案することができました( 「パフォーマンス」も同様です-その言葉も怖いです)代わりに、「代替アーキテクチャ」や「改善された実装」のような表現を使用しています。このため、これは本当に独断的であり、実際に私が言うことを批判的に評価し、それを不要であるか、費用がかかりすぎると却下するのではないようです。

10
新しいプログラマーの自習能力を高めるのを助けて、そんなに聞かない?
私は現在、新しいプログラマーとプロジェクトに取り組んでいます。彼の仕事をスピードアップするにはどうすればいいですか?彼はよく私に質問をしますが、私は彼と、backbone.js(プロジェクトの一部)でプログラミングしました。 今、私は彼にプロジェクトを自分で処理してもらい、他のことに集中してプロセスをスピードアップできるようにします。彼は、物事をグーグルにしたり、問題が発生した場合にフォーラムで質問したりしたくない。彼はちょうど私のところに来ます。彼は何をすべきか?私は何をすべきか?私が彼を強制すると、彼はすぐに物事をします。自分でもっと仕事をするように彼をやる気にさせるにはどうすればいいですか?

12
コードへの感情的な愛着[終了]
会社の従業員として、コードを書くとき、添付ファイルがあるように感じますか?コードの所有権があると感じますか?または、他の場所に移動した後に何が起こるかを心配せずに、完全に切り離された状態で書き込みますか? 編集:私は悪いコードを書いて実行することについて話していません...

4
Git Stashをワークフローとして使用するのはアンチパターンですか?
最近、私と私のチームがGitをどのように使用し、ワークフローがどのように機能するかを調べてきました。現在、機能ブランチワークフローを使用していますが、うまく機能しているようです。 また、私たちのチームの何人かの個人がgit stashに基づくワークフローを使用しているのを見ました。ワークフローは次のようになります。 メインブランチで作業する(などmaster) 進行中にコミットする 変更を取得するか、ブランチを切り替える必要がある場合は、コミットされていない変更をスタッシュにプッシュします 更新が完了したら、変更をスタッシュからポップします。 このワークフローは、機能ブランチワークフローの代わりに使用されることに言及する必要があります。ここでの開発者は、ブランチを取得して作業する代わりに、単一のブランチでのみ作業し、適切と思われるスタックからプッシュ/ポップします。 実際、これは素晴らしいワークフローではないと思うので、この方法でgit stashを使用するよりも分岐が適切です。git stashの価値は緊急操作として見ることができますが、毎日の通常のワークフローで使用することはできません。 git stashを定期的に使用することはアンチパターンと見なされますか?その場合、発生する可能性のある特定の問題は何ですか?そうでない場合、利点は何ですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.