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

私はコードレビューはかなり新しいですが、博士号を取得している間は何年もコーディングを行ってきました。 レビュアーがコードを変更し、1行ずつコードを検討する場合、同意しない場合はどうしますか？Xを選択し、レビュアーがそれをYに変更し、Yを思い浮かべていたが、デメリットのためにそれを行わないことに決めたことがありますが、レビュアーはこれらのデメリットは重要ではないと断言します。意見の不一致を言葉で表現するべきでしょうか、それともそうではなく、それらに耳を傾けるべきでしょうか？ 批判を受け入れるのが苦手で、レビュアーが組織の上級者である場合は困難です。防御的すぎると出くわすのは良くありません。

16 teamwork  code-reviews 

私の会社は最近、正式なコードレビューを開始しました。プロセスは次のようになります：githubに送信し、プルリクエストを要求し、約3人がコードをレビューし、すべてのパスが完了したらコードを入力します。 このプロセスは公平に思えますが、コードレビューを行う3人は公平ではないようです。レビューのためにコードを挿入すると、100〜200のコメントが表示されます。私にとって一番の数は一度300コメントでした。もちろん大きな変更だと思うでしょうが、これは50行未満のコード（ユニットテストを含む）でも非常に小さな変更になる可能性があります。すべてのコメントは「やらなければならない」と見なされ、議論はありません。 それを念頭に置いて、ここでの私の主な問題は、それが少し過剰に見えることです。私はグループと話をしましたが、彼らは基本的に、PHPで長年開発してきたからといって、「開発者」であるという意味ではないと言っていました。もちろん、これはそうでないことよりも痛いようです。また、グループ内ではあまりコメントを生成していないようであり、ほとんどの場合、他のコメントや提案を無視したり、無視したりします。 私の質問は、これが公平かどうかです。それとも普通ですか？

16 teamwork  code-reviews 

前提条件 チームはDVCSを使用します IDEはコメントの解析をサポートしています（TODOなど） CodeCollaboratorのようなツールは予算的に高価です gerritのようなツールはインストールするには複雑すぎるか、使用できません ワークフロー 著者は中央リポジトリ機能ブランチのどこかに公開しています レビュー担当者が取得してレビューを開始します 質問/問題レビューアの場合、「REV」などの特別なラベルを付けてコメントを作成します。そのようなラベルは、製品コードに含めることはできません-レビュー段階でのみ： $somevar = 123; // REV Why do echo this here? echo $somevar; レビュアーがコメントの投稿を完了すると、愚かなメッセージ「comments」でコミットし、プッシュバックします 作成者は機能ブランチをプルバックし、同様の方法でコメントに回答するか、コードを改善してプッシュバックします 「REV」コメントがなくなると、そのレビューは正常に終了したと考えることができます。 作成者は機能ブランチをインタラクティブにリベースし、それを押しつぶしてそれらの「コメント」コミットを削除します。これで機能をマージして、通常は内部レビューが正常に完了した後のアクションを開発または実行する準備ができました IDEサポート 私は、カスタムのコメントタグがEclipseとNetBeansで可能であることを知っています。確かにそれはblablaStormファミリーにもあるはずです。 ご質問 この方法論は実行可能であると思いますか？ 同様のことを知っていますか？ それで何を改善できますか？

16 teamwork  code-reviews  workflows  dvcs 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 7年前に閉鎖されました。 私の大学には、実際のクライアントとのソフトウェア開発のためのモジュールがあります。私のチームメンバーの何人かは常にコンピューターラボで働いていますが、これは非常に騒がしい環境であり、多くの中断や注意散漫があります。常に約30人が会話しています。人々は常に「仕事」をすることに加えて、FacebookやYouTubeに行ったり、お互いに冗談を言ったりします。私のチームメンバーの一部は、この環境で毎日3時間働いています。 私は毎週のチーム会議に出席し、オンラインプロジェクト管理システムを広範囲に使用しています。私はすべての電子メールに対処し、ビジー状態のチャットクライアントを持っていますが、メッセージを受け取ります。私は自分の問題を解決するときにオンラインリソースをよく使います。ただし、チームミーティングとペアプログラミングセッション以外は、集中して集中できる静かな環境でほとんどの作業を行い、すべての外部および内部の中断をブロックします。私は自分の仕事に100％集中しています。私は、この方法により、ラボでの生産性が約10倍向上し、多くの仕事をこなせるようになりました。 問題は、私たちの家庭教師や「管理者」が私が研究室で仕事をしているのを見ないということです。したがって、私は彼らに働いているようには見えません。したがって、彼らは私がチームワークをしていないと思います。チームと多くのコミュニケーションをとっているのに、チームワークをしていることを彼らに納得させるにはどうすればいいですか？私が単独で多く働いており、必ずしも研究室ですべての仕事をしているわけではないという理由だけで、私はチームの生産的なメンバーであるということを証明したいと思います。 UPDATE Managementは、問題はチームで60％の時間を費やし、40％の時間だけで仕事をしていることだと言っていました。彼らは、私がチームと一緒に研究室（別名オフィス）で99％の時間を過ごすべきだと言った。 いくつかの答えのいくつかの関連するコメント、いくつかは見逃すかもしれません： 「問題は、私が自分でグーグルで検索するので、チームに何も質問する必要がないということです。そして、何らかの理由で、スーパーバイザーやチームメンバーよりもグーグルを信頼しています。基本的に私は「ウェブ」の仕事をしているので、チームの仕事をしています。 「私は、スーパーバイザーやチームメイトの専門知識よりも、オンラインで見つけた（つまりSE）情報を信頼しています。」 更新2 自宅で真面目な仕事をやめるのをやめました。今は研究室にとどまり、チームで楽しんでいる一方、時々仕事をしています。受け入れられた答えが示すように、これは私が生産的であるということではなく、むしろマネージャーとチームメイトの期待を満たすことです。私と上司がソフトウェア開発の方法について異なる信念を持っている場合、彼らは私を失敗/解雇する力を持っているので、それは重要です。私の意見では、対面のミーティングはオンラインでの会話ほど効果的ではありません。また、騒がしいラボでの作業は、かなりの環境での作業ほど生産的ではありません。私は仕事の最中に、チームメイトがいつでも私を邪魔することはできないと思います。生産的な作業を単独で行うには少なくとも50％の時間、チームと同期するのに50％の時間が必要だと思います。とにかく、

16 productivity  teamwork 

同僚がコードを編集している場合、何をすべきですか？ 機能を追加したり、バグを修正したりせずに、外観を変更するだけです...

16 productivity  teamwork  communication  etiquette 

私は4人のチームの小さなアウトソーシング会社でiOS開発者として働いています。私と私と他の2人の開発者が入社する数年前に開始したプロジェクトに取り組んでいます。それ以前は、プロジェクトはほとんど1人で行われていました。 私がプロジェクトに取り組み始めたとき、それは完全な混乱でした。多くのコードの繰り返しがありました。同じ500のコードが、わずかなバリエーションで20の異なるファイルに対応しているのを見ました。さらに、それは正確に組織化されていませんでした：すべてのUI作成コードは、View Controllerでロジックと一緒に混合されました。 あちこちでリファクタリング、コードの冗長部分の排除、プロジェクトのファイル構造の改善などに最善を尽くしました。前の開発者はこれらすべてを本当に気にしていないか、経験がないと感じました。数か月の間、私は一人でかなり大きな機能に取り組んだことがありました。この機能の性質上、アプリ全体で多くのコードに触れる必要があったため、いくつかの改善を試みました。 他の開発者がプロ​​ジェクトに参加したとき、彼らは異なるコーディングスタイル（時には完全に異なるスタイル）を使用し、プロパティアクセサーなどの最新の言語機能を使用しないことに気付きました（これはObjective-Cの比較的新しい機能です）。フレームワークの類似の機能を使用する代わりに、独自の自転車を発明したり、他のプログラミング言語や学習したパターンをコードベースに転送したりすることもありました。多くの場合、悪い英語のためにメソッドや変数に適切な名前を付けることができません（Objective-Cは長い名前を作成する言語です）。 IDE用でない場合は、インデントや書式設定を一切行わずにすべてのコードを記述すると思うことがあります。 基本的に、私は彼らが書いたコードが嫌いです。フォーマット/構成が不適切で、プロジェクトの他の部分とは根本的に異なる場合があります。彼らがスパゲッティを私の作品に追加すると、とても気分が悪くなり、仕事の気分や生産性に影響します。 学習することや気にしないことはますます難しくなっているように感じます。彼らは彼らから求められていることをして、家に帰るだけです。私は機会があったときに彼らにいくつかのヒントを与えようとしました（例：彼らのPRにコメントしたり、GitHubでコミットします）。私はかつて、既存のコードの大部分のコーディングスタイルとフォーマットに従うようにきちんと要求しました（残念ながら、正式なコーディングスタイルのドキュメントはありません）。しかし、うまくいきませんでした... 「悪い企業文化」や「経験の浅い卒業生」などに焦点を合わせずにこの状況に対処し、実際に状況を改善し始めるにはどうすればよいでしょうか。

16 coding-style  teamwork 

GitHubリポジトリのブランチ設定を変更したばかりなので、[次の]ブランチではプルリクエストでCIビルドを渡す必要があります。 テストの失敗について、多くのチームメンバーとの議論が続きました。 コンテキストのために... リポジトリには、リリースがあるときにのみPRされる[master]ブランチがあるため、[master]には、メジャー、マイナー、ホットフィックス、ベータ、アルファ/アルファに関係なく、最後のリリース時点のコードが含まれます。プレリリースビルド。 [次の]ブランチは「デフォルト」ブランチで、「リリース準備完了」コードを保持するつもりです。技術的には、そのブランチはいつでも[マスター]にPRされ、リリースされます。 個々のフォークには独自の開発ブランチがあり、貢献者は[次へ] PRを行います。 自明ではないPRをレビューするとき、貢献者のdevブランチを「レビュー」ブランチにマージし、すぐに修正できるものを見つけたら、変更と新しい（時々失敗する）テストをコミット/プッシュし、PR貢献者の開発ブランチに戻ります。彼らが私の変更をマージするとき、新しい失敗したテストをパスさせてプッシュし、それらのPRが同期します。それからPRを[次へ]にマージします。 しかし、この質問はテストに合格することではなく、失敗するテストに関するものです。 テストに失敗すると、修正する必要があるものが文書化されます。 既知のバグにはテストが記述されている必要があります。これにより、何が機能していないかがわかります。 技術的には、GitHubの問題リスト（バグやクリティカル ラベルに対してフィルター処理されています）も同様です。バグを文書化するために多数の失敗したテストを用意することは良い習慣ですか？ [次へ]上の障害のビルドは、私たちがリリースする準備ができていないという意味では...しかし、その後、「リリース用であることは、」ビット子供を持って「準備ができている」のようなものでしょう-あなたは決してならない、非常にこのための準備ができて、何か、どこかで（変数の重要性が）リリースで必然的にうまくいかないでしょう。 したがって、合格したテストを[次へ]にプッシュするだけです。失敗したテストをどこにプッシュしますか？つまり、PR /レビュープロセスの外ですか？ たとえば、ユーザーが問題リストに新しいバグを報告し、失敗したテストスイートを作成したい-何をする必要があるか、どこで行うかを指定して、新しい貢献者がピックアップしやすくする最終的にはPRを修正します。 これらの失敗したテストをどこにプッシュすればよいですか？または、失敗したテストをどこかにプッシュすることをお勧めしますか？

15 unit-testing  git  teamwork  continuous-integration 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私はJavaで、非常にオブジェクト指向のスタイルで、自分でプログラミングしています。他のプログラマーと仕事をする機会がなかった（少なくとも私はプロではない）。 好奇心から、私は尋ねたいと思いました：プロジェクトでチームと働くことは、特にオブジェクト指向プロジェクトで働くとき、どのように働きますか？ 分割タスクはどのように機能しますか？他のプログラマーが開発したものとうまく機能するものをどのように開発しますか？ プログラマはいつ、どのように通信しますか？ ありがとう

15 object-oriented  teamwork 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私のチームでは、ほとんどの上級プログラマーに真新しいジュニアプログラマーを訓練/指導することをしばしば要求します。ただし、これらの同じ上級プログラマーは、実際の重要な作業の大部分を実行しているプログラマーです。 私は上司に、高い適性を示している若いプログラマーに新しいプログラマーを彼らの翼の下に連れて行くのは理にかなっていると主張しようとしました。まず、上級開発者がより重要なイニシアチブに取り組むことができるようにします（メンタリングは重要ではありません）。次に、ジュニアプログラマーは、そのような責任を求められ、教えることで何かを学ぶことができるという彼らの仕事に少しの誇りを与えます。最後に、上級開発者は後輩よりも多くの費用がかかるため、会社のお金を節約できます。 これが明らかに時間の始まりからこのチームで働いている方法なので、私のボスは説得できませんでした。何らかのトレーニング/メンタリングが必須であるという決定がなされたと仮定すると、誰かが私にいくつかのより良い議論を提供したり、私が間違っている理由を教えてもらえますか？あなたのチームは何をしていますか？ **年功序列は必ずしも能力を示すものではないので、「シニアプログラマー」、つまり「トッププログラマー」を意味するものとみなすことができます。

15 teamwork  knowledge-transfer 

あなたの先輩であり、常に他の人のプロジェクトに飛びついて、一晩または週末にそれらを完了するチームメンバーにどのように対処しますか？彼女は、緊急事態が発生したかどうかにかかわらず、週80時間働いているようで、todoリストのどの部分を次に攻撃するかを予測するのは少し難しいです。月曜日の朝に、先週のほとんどの作業に費やしたプロジェクトを完了したチェックインを見つけるため、作業の日数が無駄になることがあります。 品質を尋ねる人々へ：通常、それは非常に良いですが、他のチームメンバーが「所有する」コードを含むコードのリファクタリングもたくさんあります。

15 management  teamwork 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 チームに参加するジュニア開発者や、一緒に仕事をしなければならない人について、一般的な不満は何ですか？明らかに彼らは経験が浅いので、すべてを知ることは期待できませんが、どのようなスキルが不可解に不足していることがよくありますか？そして、具体的にどのようにこれらの不足しているスキルを強化するのに役立ちますか？ 「アドバイスを聞く」などの対人スキルを意味するのではなく、次のような技術的な問題を意味します（該当する場合）。 「SQLを実行したことはありませんか？」 「ユニットテストを書いたことはありませんか？」 「Unixコマンドラインの使用方法がわかりませんか？」 あなたが期待すること-新しいプログラマーにこれらの特定の欠点を乗り越えるように教えるためのあなたの観察と技術を聞きたいです。

15 teamwork  knowledge-transfer 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 2年前に閉店。 1つのチームに上級プログラマーが多すぎると、悪いことになることがありますか？ 同様に、6〜7人のチームで4〜5人の上級プログラマーがいます。このような状況で最適な数/比率は何ですか？ これにより、アイデアに関する哲学や議論が過剰になりますか？ 誰かがそのような経験を持っていて、それを私と共有できますか？

15 team  teamwork 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 夢の会社をどのように構築し、優れたプログラマーにとって非常に魅力的な会社にする方法を考えてみました。多くの「良い」プログラマーの代わりに少数の「スーパースター」プログラマーを雇うことができれば。 私が個人的に楽しみたいことの1つは、いつでも好きなときに仕事をする自由です。そのため、気分がよければ遠隔地でさまざまな都市を旅行したり、クランチモードがあるときに家に座ったりすることができました。しかし私の経験では、物事について話し合い、会社の「文化」を持つことができる仲間とのオフィスが必要です。 おそらく、さまざまな国や都市の優秀な人材プログラマーを雇いたいとします。キャンパスと競争するためにどのように設定しますか？完全にオフィスのない会社を持つことは少し最適ではないように思えます。おそらく、人々が出会って仕事をすることを選択できるオフィススペースが必要でしょう。 私ができることは、さまざまな国に小さなオフィスを持ち、人々が選んだオフィスから仕事をさせることだと思います。プログラマーは、必要に応じて「クランチモード」を開始することができますが、チームワークと対面が必要な場所で作業することもできます。 別のモデルは、他のプログラマーが働くオフィスにあなた自身の賃借席のオフィスを持つ代わりになります。そのようにすれば、あなたの街に従業員が1人か2人しかいなくても、リモートで仕事をするのが「寂しい」と感じたら、会社を得ることができます。 もう1つのアイデアは、隔月で1週間のように、チーム全体を同じ場所に連れて行くことです。オフィスではないかもしれませんが、興味深い都市や魅力的なリゾートになり、そこから一緒に働くことができます。配偶者を持つ人々はそのようなものに問題があるかもしれません。 さまざまな都市（2〜3人用）に会社のアパートのネットワークがある場合もあります。オフィスやその他の場所の両方で、プログラマーやチーム、プログラマーが自由に歩き回って「まとまり」ます。 それが合法だった場合（国ごとにどのように異なるかはわかりません）、2匹のハエを一度に叩いて、異なる都市のオフィス/アパートを組み合わせることさえできます。「ハックパッド：ロンドン」「ハックパッド：ベルリン」など a）だから、私の質問は、このような設定が実行可能かどうかだと思いますか？コンセプトをどのように改善できますか？ b）この種の自由をあなたに魅力的に与えてくれる会社を見つけますか、それとも毎日大きなオフィスを持つ会社を好むでしょうか？ つまり、基本的に、「スーパースター」プログラマーが、Google、Facebook、またはMicrosoftキャンパスで代わりにこのような会社のセットアップで働くことを選んだのは、多くの才能ある個人の楽しさと会社です。

15 productivity  teamwork  communication 

アジャイルプロセスには2週間のスプリントがあります。タスクは毎日配信され（毎日ビルド）、テストチームは翌日または同じ日にテストを完了します。 Devコードレビューもありますが、これには時間がかかります（1〜2時間）ため、週3回、月曜日から水曜日にスケジュールされます。開発者が集まり、コードを改善/リファクタリングする方法を提案します。 問題は、コードレビュー後にアクションアイテムが登場するまでに、ほとんどのタスクが既にテストされていることです。テスターは、既にテストに合格したものを再テストしたくない。内部の開発者の変更を気にしません。 アジャイルプロセスを誤解していますか？コードレビューは毎日のリリース/テストサイクルと互換性がありませんか？毎日コードレビューを行うことはできません。すべての人の時間がかかるからです。

14 project-management  agile  teamwork  code-reviews  sdlc 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 コーディングプロセス中に非IT担当者がプログラマーと連携する経験はありますか？ それはペアプログラミングのようなものですが、一人はビジネスについて多くのことを知っている非ITの人です。おそらく、物事の計算方法を知っており、非慣用的な手続きコードを理解できる数学のバックグラウンドを持つプロセスエンジニアです。 PL / SQLのような手続き型のドメイン固有言語は、IT以外のエンジニアでも非常に理解しやすいことがわかりました。これらの人物は最終的にコードの共著者となり、式、要因などの正確性を保証します。 この種のペアプログラミングは非常に生産的であり、この種のエンジニアリングタイプのユーザーは、コードの「所有者」および「作成者」であると感じ、コミュニケーションプロセスの誤解を最小限に抑えます。テストケースの設計にも役立ちます。 この慣習は一般的ですか？ 名前はありますか？ 同様の経験がありますか？

14 teamwork  requirements  client-relations  business-logic  pair-programming