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

免責事項：私は新参者であり（これが私の仕事の3日目です）、私のチームメートのほとんどは私よりも経験が豊富です。 私たちのコードを見ると、次のようなコードのにおいと悪いエンジニアリング手法が見られます。 多少矛盾した命名ガイドライン 可能な場合、読み取り専用としてマークされていないプロパティ 大規模なクラス-何百もの拡張メソッド（多くのタイプ）で構成されるユーティリティクラスに気付きました。2500行以上でした！ 大規模メソッド-150行のメソッドをリファクタリングしようとしています。 後者の2つは本当の問題のようです。チームメイトに、より小さなクラスとメソッドを使用するよう説得したいと思います。しかし、私はそれをする必要がありますか？はいの場合、どのように？ 私のチームは、メインチーム（私たちはサテライトチーム）からメンターを獲得しました。最初に彼に行くべきですか？ 更新：いくつかの回答がプロジェクトについて尋ねたので、それが機能しているプロジェクトであることを知ってください。そして、私見、そのサイズの巨大なクラス/メソッドは常に悪いです。 とにかく、チームを怒らせたくありません。それが私が尋ねた理由です-私はそれをするべきですか？ 更新：受け入れられた答えに基づいて何かをすることにしました：私は初心者なので、すべてを「新鮮な目」で見るので、見つけたすべてのコードの匂いに注意します（位置、それが悪い理由、どうすればできるかより良い、...）、しかし、現時点では、私はチームから敬意を集めるために一生懸命努力しています：「より良いコード」を書き、人々を知り、なぜそれをしたのかを知っています...新しいコードポリシー（命名ガイドライン、小規模なクラス、小規模なメソッドなど）についてチームに問い合わせ、可能であれば古いコードをリファクタリングします。動作するはずです、私見。 ありがとうございました。

27 .net  code-quality  team  refactoring 

これはすべてのチームで起こっています。 何らかの理由で、チーム内で競合が発生し、全体的な動機と生産性に影響します。 その一般的な問題を解決するために推奨されるアプローチは何ですか？ 例： チームの一部は依存性注入の実装を望んでおり、もう一方は時間の無駄だと考えています。 一部の開発者は、チームの残りの部分が開発を遅くしていると考えています（これにより、スケジュールが遅れる理由が説明されます） 1人以上の開発者間の個人的な非互換性 ある開発者が別の開発者と話すことを拒否する（明白な理由なしに）

26 team  problem-solving 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 4年間、私は小さな会社のソロ開発者でした。ニッチ業界で確立された製品がいくつかあります。私たちはすぐに1-2人の開発者を雇用する予定であり、それはおそらくここでの動作を変えるでしょう。 「本物の」タイトルは持っていませんが、このチームを「担当」します。私がやりたいのは、会社のために非常に組織的で生産的なプログラミング部門を設立することです。私は大学でこの単独の仕事を手に入れたので、この業界のプログラマーとして熟達しましたが、チームプログラミングの経験はあまりありません。右足でスタートすることが重要だと感じています。 今のところ、私、数台のコンピューター、SVNサーバーだけです。チームをゼロから構築するための一般的なガイダンスを探しています。

25 teamwork  team  solo-development  knowledge-transfer 

で、私の時代遅れの同僚の取り扱い質問を、様々な人々がいる同僚に対処するための戦略を議論したくないチームで自分のワークフローを統合します。 可能であれば、現代の技術やツールに無知で、おそらく少し無関心な同僚を「教える」ためのいくつかの戦略を学びたいです。 会社の別の部分で、最近まで比較的孤立して働いていたプログラマーと仕事を始めました。彼は幅広い分野の知識を持ち、最も重要なことには、多くの候補者が欠けているように見える、優れた問題解決スキルを実証しています。 しかし、私が見た実際の（C＃）コードはVB6時代への先祖返りです。手続き構造、ハンガリー語表記、グローバル変数（の乱用static）、インターフェースなし、テストなし、ジェネリックの不使用、スローSystem.Exception...アイデアが得られます。 このプログラマーは私よりもかなり古く、少なくとも第一印象では積極的な変化を積極的に求めていません。私はそれが主にトピックがどのようにブローチされるのかという問題だと思うので、私は変化に抵抗するとは言いません。 プログラマーは頑固な人である傾向があり、銃を燃やし、コードのレビューと厳格に施行されたポリシーを厳格に施行することは、私が望む最終結果をもたらさない可能性が非常に高いです。これが新しいプログラマーである若手のプログラマーである場合、「メンター」スタンスを取ることについては二度とは思いませんが、経験豊富な従業員を無知な初心者として扱うことには非常に警戒しています（彼はそうではありません-彼はただ分野の特定の進歩に歩調を合わせました）。 穏やかな説得と非物質的なインセンティブを介して、この開発者のコ​​ード品質基準をデールカーネギーの方法で高めるにはどうすればよいでしょうか？敵対的な状況を作り出すことなく、微妙な段階的な変化をもたらすための最良の戦略は何でしょうか？ 他の人々、特にリード開発者は以前にこのような状況にあったことがありますか？どの戦略が興味を刺激し、ポジティブなグループダイナミックを生み出したのでしょうか？どの戦略が成功しなかったので、避ける方が良いでしょうか？ 明確化： 質問のすべての詳細を実際に読むことなく、個人的な感情に基づいて回答している人が本当にいると感じています。次の点に注意してください。これは暗示されるべきでしたが、現在明示的にしています。 この同僚は、年齢のおかげで私の「シニア」だけです。彼の肩書き、影響範囲、または組織での年数が私のものを超えるとは言わなかったが、実際には、それらのいずれも真実ではない。彼はLOBプログラマーであり、メイン開発ショップに夢中になっています。それでおしまい。 私は新入社員でも、若手プログラマーでも、一晩で会社を変革するという壮大な計画を持った他の未熟なバカでもありません。私は基本的にソフトウェアプロセスを担当していますが、「リーダー」として働いた多くの人が知っているように、責任は必ずしも組織図と正確に相関するとは限りません。 私は、どうやって自分の道をたどるのか、地獄に行くのか、満水になるのかを人々に尋ねているのではありません。私が望むなら、それを行うことができ、最終的な結果として、この人はresり、そして/または辞めます。私は変化を促進する社会的で協力的な方法を探していることを理解してみてください。 「...グローバル変数...テストなし...投げるSystem.Exception」という言及は、問題が単なる表面的または審美的ではないことを実証することを目的としています。比較的小さなCRUDアプリで機能するプラクティスは、大規模なエンタープライズアプリで必ずしも機能するわけではありません。実際、これまでのコードで実際に統合テストに合格したものはありません。 質問を額面通りに受け止め、私が話していることを実際に知っていることを受け入れ、実際に尋ねた質問に答えるか、先に進んでください。 PS前提に反論するのではなく建設的なアドバイスを提供してくれた人々に心から感謝します。現実世界の体験の方法でもっと多くのことを聞きたいので、私はこれをしばらくオープンにしておきます。

24 programming-practices  project-management  team  team-building 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私のチームが開発する新しいオープンソース製品に貢献することを考えていました。できるだけ多くのコミュニティからできるだけ多くのサポートを得ることが奨励されていますが、これは多くの時間を費やし、オフィスの外にあるサードパーティがコード品質などに関して順調に進んでいることを確認できます。また、プロジェクトの開始時に、システムの設計、スパイクなどに関してコアチーム内で多くの非公式な議論が行われる可能性があり、これらをオンラインでコミュニティに参加させることは時間がかかり、議論はあまり効果的ではありません。 これにはもっと人間的な側面があり、おそらく検討する必要があります。設計プロセスへのコミュニティの関与を許可することは、プロジェクトの所有権の認識に関しても利点があり、初期の関与がコアの問題を拾う可能性が常にありますチームは気づいていません。 では、質問：オープンソースプロジェクトのどの段階で、コミュニティからの貢献を招待すべきでしょうか？

23 project-management  open-source  team  contribution  planning 

最近、私の会社では、1人の開発者が1つの機能に集中する（そして1人だけ）ことが推奨されています。それは、開発者を通常のチームルーチンとは別に設定し、他の責任（会議など）から解放するようなものを意味します。この人は、テクノロジに関して「唯一の」責任を負います。 記録のために、SAFe内でSCRUMを使用し、チームごとにフルタイムの開発者がいて、2つのチーム（AndroidとiOS）の間でQAと製品所有者を共有しています。 これは短期的に生産性を高めることに同意しますが、多くの理由でこれは悪い習慣であると感じています（そして大学で学んだと思います）。 コードレビューは価値を失います。 最小限の知識共有。 リスクの増加。 チームの柔軟性の喪失。 私は正しいですか、それとも悪い習慣ではありませんか？

22 agile  team  code-ownership 

私は、会社のWebサイト/ Webアプリケーションの世話をする11人のソフトウェア開発者のチームのマネージャーであり、最大4つの同時プロジェクトに加えて、毎日のサポートをいつでも実行しています。11人の開発者には、技術的なスキル、役職、経験が混在していますが、チーム構造はフラットで、11人の開発者全員が私に直接報告しています。 単一のマネージャーを持つチーム全体が、あまりうまくスケールしないことが証明され始めています。私はあまりにも薄く広がり始めているので、直接報告の数を減らしたいです。これを行うために私が考えることができるすべての方法には、重大な欠点があります： ジュニア開発者にシニア開発者に報告してもらいます。これにより、最高の技術者が開発に費やす時間を削減できます。 チームをソフトウェア製品で分割します。たとえば、開発者1〜6はイントラネットで作業し、7〜11は外部サイトで作業します。各セクションには新しいチームリーダーがいます。 ）。これにより、人工的なサイロが追加され、「イントラネット開発者」が外部のWebサイトで作業するのが困難になる場合があります。 構造を平らに保ち、プロジェクトマネージャー/チーム管理者の形をした管理サポートを追加して、プレッシャーを取り除きます。チームはこのように永遠に成長することができないため、これは問題を解決しません。 この問題を解決する標準的な方法はありますか？ そうでない場合、他の人はこの問題をどのように解決しましたか？

22 management  team 

私がキャリアで出くわした繰り返しのテーマは、チームに到着する新しい開発者であること、そして既存のユニットと統合テストスイートに対する固有の不信をすぐに持つことです。 面接中に、経営陣から「ユニットテストを強力にサポートしている」ことと、それを公然と奨励していることが伝えられます。彼らはそうしますが、テスト自体についてのすべては単に間違っています。100％の統合テストカバレッジがあり、10％未満の反復可能な単体テストカバレッジがある場合、100％のカバレッジを主張しているという事実と同様です。私が見つけた他のいくつかの問題： 単体テストと統合テストの間に明確な兆候はありません。単体テストと統合テストは、同じクラスに混在しています。 特定の環境のデータベース上の非常に特定の動的データに対する未宣言の明示的な依存関係がある統合テスト。 非トランザクション統合テスト。基本的には、後からクリーンアップするかどうかわからないテストであり、テストを再現可能にするために手動のデータベース「スクラビング」が必要になる場合があります。 モッキングは一切行われません。アプリケーションコードでは、モッキングを可能にするためだけに大幅な見直しが必要です。つまり、テストを考慮せずに設計します。 テスト名をすばやく確認して、実行中のテストを大まかに判断するための明確な命名規則はありません。 これは、すべてのテストが役に立たないか悪いというわけではなく、かなりの数のテストが非常に良く、維持する価値があると言っているわけではありませんが、金のためにパンするような気がします。ブラックボックステストケースのデータベースを台無しにするのが怖かったからといって、意図的にテストを実行することは避けました。 これは本質的に、私が個人的に何らかの方法で書いたりレビューしたりしていないユニットおよび統合テストの固有の不信感を与えました。あるレベルでは、テストスイートの品質を信頼していない場合、チームやプロジェクトにはまったく価値がありません。 この状況に陥ったとき、あなたはどうしますか？攻撃の最善の計画は、このようなものに取り組むことだと思いますか？ すべてのテストをリリース間で途方もない努力でリファクタリングする必要がありますか？このレガシープロジェクトが1日の強固な単体テストの対象となる可能性があるという考えを捨てる必要がありますか？

21 unit-testing  team  refactoring  bad-code  integration-tests 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私のチームリーダーは、データベーススキーマをいじり、コードベースに深刻な破損を引き起こすような変更を行うというひどい習慣を持っています（変更がコードベースにどのように影響するかについて実際に相談することなく）。 通常、私はそれと一緒に暮らしますが、2週間で締め切りがあり、1ヶ月半前に始めてからこれが起こっています。私はプロジェクトの開発をスピードアップするために連れてこられました。 締め切りのために、私はすでに週に60時間以上を費やしており、これに対処するためのエネルギーが残っていません（すでにいくつかの方法で試しています）。私たちはたった2人のチームであり、データベースを毎日変更する以外に、彼は実際の開発（コーディング）という意味ではあまり貢献していません。 現在、私はすべての作業を行っているように感じていますが、加えて彼の変更で彼が壊したものを「修正」する必要があります。 これにどのように対処しますか？開発部門での彼の努力の欠如について、私はすでにマネージャーに話をしました。彼は私よりも6ヶ月長い間そこにいましたが、彼が「貢献した」第5正規形データベースの怪物を除外すると、コードの95％を書きました。 助言がありますか？ 事後分析： 金曜日に私たちはマネージャーと話し合いをし、心配を知らせました。これは少し対立につながりましたが、全体的に私はマネージャーが私と一緒にいると感じました。それで、少なくとも今はデータがフリーズしているので、ここからどうなるか見てみましょう。

21 communication  team 

私たちは定期的にフロアボールをしている人々のグループです。すべてのセッションは、チームを分割するという困難なタスクから始まります... では、チームを自動的に選択するアプリケーションよりも優れているのは何でしょうか？ したがって、チームの組み合わせと結果の履歴、およびこの特定のセッションに参加する人々のリストを考えると、最適なチームを見つけるための良い戦略は何でしょうか？最適とは、チームが可能な限り平等であることを意味します。 何か案は？ 編集：明確にするために、ピッキングの基礎となるデータは次のようになります。 [{ team1: ["playerA", "playerB", "playerC"], team2: ["playerD", "playerE", "playerF"], goals_team1: 10, goals_team2: 8 }, { team1: ["playerD", "playerB", "playerC"], team2: ["playerA", "playerE", "playerG"], goals_team1: 2, goals_team2: 5 }, { team1: ["playerD", "playerB", "playerF"], team2: ["playerA", "playerE", "playerC"], goals_team1: 4, goals_team2: 2 }]

20 algorithms  strategy  team 

私は個人的なプロジェクトにDVCSを使用しており、他の人からプロジェクトへの貢献を管理するのが簡単になることを完全に見ることができますが（たとえば、典型的なGithubシナリオ）、「伝統的な」チームにはいくつかの問題があるようですTFS、Perforceなどのソリューションで採用されている集中型アプローチ（「従来」とは、誰もが同じコードに触れる可能性のある、誰も「所有しない」1つのプロジェクトに取り組んでいるオフィスの開発者チームを意味します。） これらの問題のいくつかは私が自分で予見しましたが、他の考慮事項でチャイムしてください。 従来のシステムでは、サーバーに変更をチェックインしようとすると、競合する変更を他の誰かが以前にチェックインした場合、チェックインする前にマージを強制されます。DVCSモデルでは、各開発者がローカルで変更され、ある時点で他のリポジトリにプッシュされます。そのリポジトリには、そのファイルのブランチがあり、2人が変更しました。今、誰かがその状況に対処する責任を負わなければならないようです。チームの指定された人は、すべての競合のマージを処理するためにコードベース全体の十分な知識を持っていない場合があります。したがって、誰かがそれらの開発者の1人にアプローチし、プルしてマージを実行してから再度プッシュするように指示する（または、そのタスクを自動化するインフラストラクチャを構築する）必要がある追加のステップが追加されました。 さらに、DVCSはローカルでの作業を非常に便利にする傾向があるため、開発者がプッシュする前にローカルリポジトリにいくつかの変更を蓄積して、こうした競合をより一般的で複雑にする可能性があります。 チームの全員がコードの異なる領域でのみ作業する場合、これは問題ではありません。しかし、私は誰もが同じコードで作業している場合に興味があります。一元化されたモデルは、競合を迅速かつ頻繁に処理することを余儀なくし、大規模で痛みを伴うマージを行う必要性を最小限に抑えるか、誰かにメインリポジトリを「ポリシング」させるようです。 あなたのオフィスであなたのチームとDVCSを使用している人のために、あなたはそのような場合にどのように対処しますか？毎日の（またはより頻繁に、毎週の）ワークフローが悪影響を受けていると思いますか？職場でDVCSを推奨する前に注意すべきその他の考慮事項はありますか？

20 version-control  dvcs  team 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私は12歳からプログラミングを続けています（アセンブリからC ++、Javascript、Haskell、Lisp、およびQiまで）。しかし、私のプロジェクトはすべて自分のものです。 CSやコンピューターエンジニアリングではなく化学工学の学位を取得しましたが、今年の秋に初めて大規模なプログラミングプロジェクトを他の人々と一緒に作業することになり、準備方法がわかりません。私はこれまでずっとWindowsを使ってきましたが、このプロジェクトは非常に統一されたものになるので、最近、環境に慣れるためにMacを購入しました。 昨年、CSメジャーの両方である友人たちとハッカソンに参加できたのは幸運でした。しかし、彼らと一緒に仕事をするうちに、彼らのワークフローは私のものとは非常に異なっていることに気づきました。彼らはバージョン管理にGitを使用しました。一度も使用したことはありませんでしたが、それ以来、できることをすべて学びました。また、多くのフレームワークとライブラリを使用しました。ハッカソンにとってRailsがほぼ一晩であったことを学ばなければなりませんでした（一方、レキシカルスコーピングやクロージャが何であるかを知りませんでした）。私たちのコードはすべてうまく機能しましたが、彼らは私のものを理解していませんでしたし、私は彼らのものを理解していませんでした。 実際のプログラマーが日常的に行うこと-単体テスト、コードレビュー-への参照を聞きますが、私はこれらが何であるかについて漠然とした感覚しか持っていません。通常、私の小さなプロジェクトには多くのバグはありません。そのため、バグ追跡システムやそれらのテストは必要ありませんでした。 そして最後のことは、他の人のコードを理解するのに長い時間がかかることです。変数の命名規則（新しい言語ごとに異なる）は難しく（__mzkwpSomRidicAbbrev）、疎結合は難しいと感じています。だからといって緩くつなげないわけではありません-私は自分の仕事でそれが得意だと思いますが、LinuxカーネルやChromiumソースコードのようなものをダウンロードして見てみると、これらの奇妙な名前のディレクトリとファイルのすべてがどのように接続するかを理解します。車輪を再発明することはプログラミングの罪ですが、多くの場合、ライブラリを解剖するのに何時間も費やすよりも、自分で機能を作成する方が簡単だと感じます。 明らかに、生活のためにこれを行う人々はこれらの問題を抱えておらず、私はその点に到達する必要があります。 質問：他の全員と「統合」を開始するために実行できる手順は何ですか？ ありがとう！

19 programming-practices  development-process  team  solo-development 

私が取り組んできたより伝統的なプロジェクトでは、プロジェクトマネージャー（および、大規模なプロジェクトでは、1人の担当者が利用できない場合、アソシエイト/代理/アシスタントのプロジェクトマネージャーが存在する可能性があります）は、プロジェクトと顧客とのコミュニケーションの責任者ですヘルスとステータスの更新、スケジューリングと予算の決定、プロセスの管理、チームがタスクを完了するために必要なものを確保するなど。 ただし、スクラムでは、これらの責任はプロダクトオーナーとスクラムマスターの間で分割されます。製品所有者は顧客の声です。顧客と直接やり取りし、ユーザーストーリーを作成し、製品バックログやその他のユーザー/顧客が直面する問題を整理して優先順位を付けます。ScrumMasterはプロセスを処理し、会議（推定と計画を含む）を監督し、障害を取り除き、プロジェクトの全体的な健全性を監視し、必要に応じて調整します。 Wikipediaを含む複数の情報源で、ScrumMasterとプロダクトオーナーの役割は2人の異なる人物が担うべきだと読みました。私は読んだだけでなく、両方のアクティビティが1人の個人によって処理される、成功した「伝統的な」スタイルのプロジェクトに取り組みました。実際、1人から3人の人々がプロジェクト（人事/人員を含む）とプロセスレベルのタスクを処理する責任があることは、彼らがしばしば手をつないで行くので、より理にかなっています。プロセスの変更は、スケジューリング、予算編成、品質、およびその他のプロジェクトレベルの目標に影響を与え、プロジェクトの変更はプロセスに影響を与えます。 スクラムがこれらのアクティビティを2つの役割に分離する必要があるのはなぜですか？これは実際にどのような利点を提供しますか？プロダクトオーナーとスクラムマスターが同じ個人であるスクラムプロジェクトで成功した人はいますか？

19 project-management  scrum  team  roles 

10人の開発者からなる私たちのチームは毎週会合を開きます。会議はかなり退屈で、特に有用ではありません。良い会議をするためにどの形式/議題を利用していますか？ ピザを提供した会議室で毎週会います。形式は、部屋を一周し、作業中のさまざまなタスクのステータスをリストし、来週のタスクについて話し合います。マネージャーは、今後数か月および1年先の今後のプロジェクトと優先事項の概要を提供します。 更新 これらの会議の目標は多かれ少なかれです-一般的なチームの構築、誰もが取り組んでいるものの知識を共有し、変化する会社のイニシアチブを誰もが認識し続けることです。仕事の割り当てを正式に「配る」ことではありません（他の方法で行われます）。

19 management  communication  meetings  team-building  team 

どのチームでも、より多くの灰色の開発者と若い子犬が必要になります。いくつかの理由が含まれます： お金。多くの場合、同じレベルの経験を必要としないタスクが提供されるため、これらのタスクを遂行するために最高額を支払わないことが理にかなっています。 エネルギー。新しい人々がチームにもたらすことができるエネルギーと熱意があり、チームが古くなりすぎないようにします。より多くの高齢者がもたらすことができる落ち着きと知恵もあります。 知識の伝達とキャリアの成長。プロジェクトとスキルの両方の面で、人々に教えることや新しいことを学ぶことは便利で楽しいことが多いです。新しいチームメンバーの「参加」を支援することは満足です。 ジュニアよりもシニアの方が多いことが重要かもしれない最先端のプロジェクトがあることを理解していますが、一般的に、チームでの経験の理想的な組み合わせはありますか、それともプロジェクトに完全に依存していますか？

19 team  organization