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

私は5人のメンバーからなるチームの開発者であり、私たちのプロジェクトは災害に向かっていると信じています。理由をすぐに説明しますが、私の質問は次のとおりです。 締め切りは1.5か月で、私たちが何をしようとも、このプロジェクトは失敗するでしょう。私はただプロジェクトを終了して時間を無駄にするのをやめるべきだと思うが、政治的に私たちのマネージャーがそうすることは不可能だと思う。 この場合、どうすればよいですか？余分な努力をする必要がありますか、それとも簡単に取る必要がありますか？そして、私はマネージャーに何を言うべきですか？ このプロジェクトが失敗に向かう理由： 期限が近づいているため、必要不可欠な機能の多くは終了していません アプリケーションが不安定で使用が非常に難しい システムは非常に複雑で、コードを理解するのが非常に難しく、変更するのは非常に難しい-データモデルは複雑なリレーショナルデータベース（100以上のテーブル）によって駆動されている 不明確なリーダーシップ。マネージャーは、大きな変更を伴う新しい情報に対応します 自動テストやユニットテストはほとんどありません 他のシステムに大きく依存していますが、統合テストはまだありません 実際、私たちは実際にこのプロジェクトを（混乱と共に）数か月前から同じマネージャーの別の開発チームから1〜2か月前に継承しました。

335 project-management  team  project  failure  legacy-code 

私のチームメンバーの1人は、自分のコードでコメントを作成することを常に避けています。 彼のコードは自己文書化されておらず、他のプログラマーは彼のコードを理解するのに苦労しています。 私は彼に彼のコードをコメントするように何度も頼んだが、彼はただ言い訳をするか、または彼が後でそれをすることを主張する。彼の懸念は、コメントの追加に時間がかかりすぎてプロジェクトが遅れることです。 彼に彼のコードを適切に文書化するよう説得するために、どのような議論を彼に提示できますか？ そのメモでは、コードのコメントに焦点を当てるのは間違っていますか、これは対処すべき大きな問題を示していますか？

183 teamwork  team  comments 

特定のサイト用のオープンソーススクリプトがあります（ここでは名前を付けないようにしています）。私と他の少数の開発者が最近GitHubに移動しました。特に非常にアクティブなシステムを含め、新しいシステムに移行して以来、いくつかの新しい開発者を獲得しています。しかし、このアクティブなものはプロジェクトの多くを変え始めました。 まず最初に、彼はバージョン管理システムを削除し（Gitのようではなく、そのように-バージョンと呼びますv4.1.16）、準備ができたと思われるときにコードを単にサイトにプッシュする方が良いと言いました。今では、リリースノートを置く一元化された場所はありません。 荷物をまとめて行く準備ができたのは、プッシュスクリプトでした。プロジェクトの別の開発者は、単純なPythonベースのプッシュスクリプトを作成しました。さまざまな場所で複数のバージョンのスクリプトをオンラインで保持しているため、Pythonスクリプトに代わるグラフィカルインターフェイスを備えたより大きなJavaプログラムのコーディングを開始しました。私はIRCに行ってそれをみんなに通知し、古いPythonベースのスクリプトが私のできることをすべて行うことができ、はるかに軽量であると言って非常に迷惑な応答を得ました（彼はまた彼が考えた事実についてコメントしましたPythonはJavaなどよりも優れていました）。古いプッシュスクリプトのコードを調べたところ、彼が言った機能がどれも存在しないことがわかりました。 だから今、私は何をすべきかを知りたいです。私はこのプロジェクトに多くの時間を費やしてきたので、ただ立ち上がって去りたくありませんが、この新しい開発者と仕事をするのは難しいと感じています。反対に、彼は現在、プロジェクトのトップコミッターであり、主任開発者よりも多くのコミットを行っています。私はこれについてどうすればいいのかよく分かりません。他の誰かがこの問題を経験しましたか？もしそうなら、あなたは何をしましたか？ 更新1：全員のコミットアクセスを無効にし、プルリクエストを通過するように要求しています。他の問題を解決するためのいくつかの手段も提案しました。他の人は誰もそれをサポートしていません。面倒な開発者は、「コミットアクション」に従わない人は、プロジェクトが実際にはそうでない場合でも混乱していると考えることができると単純に言っています。私は明らかにこれに同意しないので、プロジェクトから辞任することを真剣に考えています。 更新2：リード開発者は、私のコミットの1つがコード内の3つの改行を削除したという事実について暴言を始めました（リバートコミットはディスカッションを投稿した直後に表示され、「コミット」も参照しません）。 2人は私のコミットアクセスを取り消すかどうかの議論を始めました。だから、私は論理的なことをして、プロジェクトを去った。皆さんのご協力に感謝します！

65 open-source  team 

APコンピューターサイエンスクラスからグループプロジェクトを割り当てられ、他の3人と協力する必要があります。私は以前彼らと話したことがなく、彼らのスキルレベルがわからず、彼らのメールアドレスしかありません。要約すると、割り当ては次のとおりです。 「チームとして、クラスに少なくとも3つのモジュールを完了します。...」 私は「チームキャプテン」になろうとしていますが、彼らは誰もお互いに連絡をとろうとしませんでしたが、私は興味があります。私は彼らにメールを送り、お互いにメールを送るよりもコミュニケーションの方が良いかどうか尋ねましたが、実際にプロジェクトを開始したら、誰が何をしているのかを把握する必要があります。 私は何をすべきか？会ったことがない3人を「担当」し、リードするにはどうすればよいですか。 以下は実際の割り当ての抜粋です。 したがって、各チームメンバーが週の初めにこのプロジェクトで果たすさまざまな役割について話し合う必要があります。Pronto（またはBlackboard IM）、電子メール、Wiki、Googleグループ、ブログ、またはその他の適切な方法を介して通信できます。週の終わりまでにグループメンバーがグループに参加しない場合は、インストラクターに知らせて、追加のガイダンスを提供します。 ... また、プロジェクトの終了時にチーム評価が行われます。この評価では、各チームメンバーがこのプロジェクトの完了への貢献度と推奨成績を評価します。 編集：多くの人々は、私が彼らにコーヒーショップなどで会うことを提案しました。唯一の問題は、私たち全員が異なる状態にあるということです。また、そのうちの1人がFacebook / Skype / twitterの使用を許可されていないこともわかったため、yahooメッセンジャーとメールでメッセージを送信することに頼らなければなりません。

50 project-management  team  project 

私は、コードベース全体のチームの所有権が、コンポーネントの個々の所有権よりも優れているかどうかについて、一部の同僚と議論している最中です。 私は、チームのすべてのメンバーにコードベースのほぼ等しいシェアを割り当てることを強く支持しています。これにより、人々は自分の作成に誇りを持ち、バグスクリーナーに着信チケットを割り当てるための明らかな最初の場所を与え、「壊れたウィンドウ症候群」を軽減するのに役立ちます。 また、特定の機能に関する知識を1人（または2人）のチームメンバーに集中させ、バグの修正をはるかに容易にします。 何よりも、委員会ではなく、多くの意見を持っている一人の人との主要な決定について最終決定権を置きます。 他の誰かがあなたのコードを変更したい場合、許可を要求することを支持していません。多分、コードのレビューは常に所有者に委ねてください。また、知識のサイロを構築することもお勧めしません。この所有権について排他的なものはないはずです。 しかし、同僚にこれを提案したとき、私は予想以上に多くのプッシュバックを得ました。 だから私はコミュニティに尋ねます：大規模なコードベースでチームと協力することについてのあなたの意見は何ですか？集団所有権を慎重に維持することに関して私が逃しているものはありますか？

48 team  organization  code-ownership 

コードで作業するとき、チームメートと同じ課題の多くに直面します。また、有用な関数とクラスをいくつか作成しました。良好なコミュニケーションがあれば、誰かがまとめた素晴らしいことを聞くことができます。6か月後に必要になったときにそれを覚えて、その関数を呼び出して時間を節約できます。覚えていない場合、またはまったく知らない場合は、おそらく車輪を再発明します。 これらの種類のものを文書化する特定の慣行はありますか？どのようにしてそれらを見つけやすくしますか？ チームにそのようなドキュメントがない場合、ホイールがすでに存在するかどうかをどのように確認しますか？ 編集： これまでのところ、答えの1つを除くすべてが理想的な状況を扱っているので、これらのソリューションを要約します。ドキュメントとコミュニケーション。wiki、スタンドアップミーティングなどはすべて素晴らしいものですが、ドキュメントを作成し、ミーティングに参加し、メモを取り、すべてを覚える時間（およびスキル）を持つプログラマーに依存しています。 これまでで最も人気のある回答（Calebの回答）は、文書化や会議ができないプログラマーが使用できる唯一の回答であり、プログラミングを1つだけ行います。プログラミングはプログラマーが行うことであり、もちろん、優れたプログラマーはドキュメント、ユニットテストなどを作成できますが、それに直面しましょう-私たちのほとんどはプログラミングよりもドキュメントを好みます。彼の解決策は、プログラマが再利用可能なコードを認識し、それを独自のクラスまたはリポジトリなどに引き出し、それが分離されているという事実によって、それが見つけやすくなり、それを使用するための学習曲線を容易にすることです... 。そして、これはプログラミングによって達成されました。 ある意味では、このように見えます。3つの関数を書いたばかりで、他の誰かがそれらについて知っておく必要があると思います。私はそれらを文書化し、書き、会議で発表することができます-私はできますが、それは私の強さではありません-または....私はそれらをクラスに抽出し、それをうまく命名し、それらをブラックボックス、および他のクラスファイルが行く場所に貼り付けます。その後、それを発表する短いメールは簡単です。他の開発者はコードをスキャンして、完全に理解していないコードで使用されている分離された関数よりもよく理解できます。そのコンテキストは削除されます。 これは、適切な名前のメソッドを備えた適切な名前のクラスファイルのセットを持つことは、優れたプログラミングによって達成される優れたソリューションであることを意味するため、これが気に入っています。会議を必要とせず、詳細な文書の必要性を和らげます。 この流れに他にもアイデアはありますか？

43 documentation  teamwork  team  code-reuse 

最近、私は次の5種類のボスと 最悪のボスの服装を説明するそれらの対処方法を読みました。ソフトウェア開発者の小さなチームを率い始めたばかりです。 プログラマーが上級プログラマーに期待する主なものは何か、またはチームを管理する際に避けるべきものは何かを知りたい。 また、プログラマを満足させ、チームのために生産的で完全な環境を作成する方法を知りたいです。

41 management  team  team-leader  team-building 

私は小さな会社で唯一の開発者です。ここでゆっくりと開発に移りました。4か月前までは、私の時間の50〜75％が運用に費やされていました。現在、私の時間の50〜75％が開発に費やされ、残りは運用とさまざまなITスタッフに分けられています。私は定期的に週に50時間以上働いています。 私は、ビジネスの多くが依存している、かなり貧弱に書かれたアプリケーション（以前は2人が保守していたアプリケーション）を継承しました。これらを継続して実行し、新しい小規模なアプリケーションで作業し、その他の責任を負っています。 スケーラブルであるために、既存のソフトウェアは重要なリファクタリングと追加機能を必要とします。これまで、適切に作成または設計されたソフトウェアに取り組む喜びはありませんでした。このタスクの複雑さは、私が以前にやったことをはるかに超えています（これは大学卒業後の私の最初の仕事です）。私は雇用主や自分自身でそれを一人でやろうとはしないでしょう。 私は自分の未経験について非常に直接的でしたが、過去には、経験豊富な別の開発者を雇うことがおそらく必要であると述べました...私たちが成長し、開発および保守するソフトウェアが増えています。私は別の開発者を雇うことで大きな恩恵を受けることを知っています。誰かから学び、アイデアを跳ね返すことは素晴らしいことです。StackOverflowは、個々のコーディングの問題や概念へのアプローチを決定するのに最適ですが、特定のビジネスドメインに固有のより広いまたはより重要なスケールでの議論に代わるものではありません。最近カジュアルな会話で別の開発者を雇うことについて言及したとき、彼らはそれがそれほど重要または必要だとは思わなかったようです。 tl; dr：現在のパッチジョブとその他の責任はすでに仕事に費やしています。既存のアプリケーションの作業はスキルセットを超えており、計画中の新製品に取り組む時間はほとんどありません。雇用主は当初、別の開発者を雇うことに消極的のようです。 怠け者や無能だと思わずに、他の開発者を雇うにはどうすればよいのでしょうか（私はどちらでもないと思いたいです！）。 編集：ちょうど私がポイントを証明するためにどんな種類の敵対的な行動を取ることに興味がないことを明確にしたかった（すなわち、私がいなかったら彼らがねじ込まれていることを示すために休暇を取る）。ここで働いているコンテンツは、残業中であっても、自分自身がかなり補償されていると考えています。そのため、私はまだ新しい仕事を考えていません。そうは言っても、「残業はもうありません」という答えを受け入れました-仕事をやりすぎてもかまいませんが、そうすることで誰かに恩恵を与えることはありません（より多くのエラーが発生しやすく、疲れ果てます）。短期的にははるかに長期ではありません。私はスーパーバイザーと問題について議論するときにこれを強調し、おそらくより経済的に好ましい最初のアプローチとして請負業者を雇うことをお勧めします。

40 project-management  team 

私は小さなチームで働いており、別の小さなチームと一緒に大規模な新しいプロジェクトに取り組み始めます。他のチームは現在、長年取り組んでいるレガシーシステムで作業しています。 マネージャーは、私のチームの開発者が、レガシーシステムで作業している開発者を置き換えるために、数か月ごとに交代することを決定しました。そうすれば、他のチームは新しいプロジェクトに取り組み、新しいシステムをよりよく理解できるようになります。 2〜3か月ごとにプロジェクトから開発者を交代することの利点と欠点（ある場合）を知りたい。 これは「主任開発者を交代させるのは良い考えなのか悪い考えなのか」と似た質問であることを知っています。、しかしその質問は主任開発者に焦点を当てています。この質問は、プロジェクト全体でチーム全体をローテーションすることに関するものです（新しいプロジェクトの技術リーダーはローテーションされる場合とされない場合があります。まだわかりません）。

38 project-management  teamwork  team 

「典型的な」SCRUMチームがあり、スプリントで働き、バックログを維持することを約束します。最近、帯域外作業（通常の労働時間/スプリント以外で作業することを選択）を行っている、過剰に達成している開発者の作業を統合/処理しようとする問題に遭遇しました。 例として、チームが50ポイントの仕事を引き受ける場合、スプリントの終了までにSCRUMフレームワーク内ですべての仕事を完了し、彼らと会社は満足しているとしましょう。チームメンバーの1人が、自分で、バックログアイテムで、自分の自由時間に取り組むことにしました。彼らはこの作業をチェックインせず、代わりに保存します（TFSを使用し、シェルフセットにあります）。 これを処理する方法は？問題のいくつか.. 次のスプリント中に、このチームメンバーは、プログラミング作業が99％完了し、コードのレビューとテストのみが必要であると言います。SCRUMおよびアジャイル方法論でこれをどのように扱いますか？ 他の開発者は、作業が帯域外で行われたため、これらのストーリーに関連する設計決定に関与していないことに不満を述べています。 私たちの製品所有者はこの「無料」の仕事を引き寄せようとしますが、チームがスプリントで達成できないような機能を製品に追加するために、過剰達成メンバーが意図的にこれを行っている可能性があります。これが「プロセス」を壊しているという見方があります。明らかに、QA、UI、およびドキュメントの作業をこの作業で行う必要があります。 SCRUMチームに時間外労働を強制しないことについて多くの議論がありますが、スプリントの計画と実行中に出された期待以上の仕事をしているチームメンバーはどうでしょうか。私はこの人物を統治することをheし、あなたが余分に働くことはできないと言います（もちろん燃え尽きないように注意してください）が、同時にそれはチームの特定のメンバー（しかしすべてではない）でいくつかの問題を引き起こしているようです。 達成度の高いメンバーが行った作業を、ソフトウェア開発のSCRUMおよびアジャイルプロセスに統合する方法

32 agile  scrum  team 

私は数ヶ月前に作成されて以来、組織的にフラットなチームで働いています。私のマネージャーは非技術的であり、これは私たちのチーム全体が意思決定に責任があることを意味します。 私のマネージャーは、リード開発者（タスクの単一の連絡先と単一の責任者）と私たち（紛争解決、組織的な技術ガイダンスなど）の両方のために、リード開発者を持つことにはいくつかの利点があることに気付き始めています。 チームがフラットであるため、1つの懸念は、1人のリード開発者を選ぶと他の開発者を落胆させる可能性があることです。開発者以外の人が、この問題を回避する方法として、開発主任を交代させることがマネージャーに提案しました。1人の開発者が1か月間、別の開発者が1か月間、というように続きます。 これはいい考えですか？なぜですか？ これはすべての開発者を意味することに留意してください—すべての開発者は優れていますが、必ずしもリーダーシップに等しく適しているわけではありません。 そうでない場合、単に利己的な理由であるように見えることなく、このアプローチを避けることをどのようにお勧めしますか？

31 project-management  team  team-leader 

Webのスタートアップで、機能のフロントエンドとバックエンド（基本的に機能全体を担当する）を担当するエンジニアがいる方が一般的ですか？または、エンジニアはバックエンドとフロントエンドを分離しましたか？ どちらがより有益で、どのような状況に適していますか？ 機能全体を担当するエンジニアが1人いることの欠点は、フロントエンドまたはバックエンドの開発のどちらかではなく、両方ではなく、スピードと品質が低下することがあることです。 1つの機能にフロントエンドとバックエンドの開発者を配置すると、機能の速度と品質が向上し、コラボレーションが促進されます。しかし、1人のエンジニアを別の機能に配置して作業を行うことができるため、2人のエンジニアが1つの機能を使用してリソースの使用率が低い可能性があることを心配しています。 小規模の初期段階のスタートアップでバックエンド/フロントエンドのエンジニアリングリソースを割り当てるための一般的/ベストプラクティスは何ですか？そして、成長するにつれてどのように変化しますか？

31 web-development  project-management  team 

私の経験では、ソフトウェア開発者は複数の帽子をかぶって、複数の役割を異なる責任で満たす傾向があります。コーディングだけでなく、SQLの作成、ユーザーインターフェイスの設計、データベースの設計、グラフィックス操作、QAテストまでも行います。 主な役割がソフトウェア/コードの作成である場合、開発者はどのような役割を引き受けるべきではありませんか？ いずれかがあります？ この質問の意図は、開発者が別の役割を果たせないためではありませんが、追加の役割を持つことは実際には主な役割に対して機能するか、実際には主にプログラムしない人の専用の役割でなければなりません。

29 team  roles 

バックグラウンド： 私は現在4人のチームの一員です。1人のマネージャー、1人のシニア開発者、2人の開発者です。約3500人のスタッフを抱える組織のために、さまざまな特注の社内システム/プロジェクト（6〜8週間など）を実施しているほか、以前に作成されたシステムに必要なすべてのメンテナンスとサポートも行っています。潜在的に私たちがやってくるすべての仕事をするのに十分な人はいません-人員が不足しています。経営陣はこれを認めていますが、予算の制限により、チームに追加のメンバーを採用する能力が制限されています（たとえ給与を貯金に戻したとしても）。 変更 これにより、現在の場所に残ります。私たちのマネージャーは、牧草地の役割を新しいままにして、チームに空席を残す予定です。経営陣はこの機会を利用してチームを再構築し、チームマネージャーの役​​割が別の開発者と別の上級開発者に置き換わるようにします。彼らの論理は、より多くの開発者が必要であるということなので、ここに資金提供の方法があります（役割の1つは、別の空いているポストから部分的に資金提供されています）。 チームには直接的なラインマネージャーはなく、役割と責任はシニアと（比較的新しいポストの）サービスマネージャーに分けられます（技術知識がほとんどない開発知識/経験があり、焦点が共有されています）他の多くのチームや個人の中で）-フードチェーンの次の実際のマネージャーになる人。 最後の質問は： マネージャーなしで開発チームを実行することは可能ですか？これを経験したことがありますか？そして、どのようなことがうまくいかない/私たちに利益をもたらす可能性がありますか？ 理想的には、「光を見る」ことと、この方法で物事を行うことの利点、またはそれに対する議論のためのいくつかのポイントを考えたいと思います。

28 project-management  team  organization  team-leader 

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

27 scrum  teamwork  team  roles