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

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 「クロスファンクショナルチーム」の一般的な意味は、目標を達成するために必要なさまざまな分野の専門家を組み合わせたチームです。 しかし、アジャイルのクロス機能性とは、異なる専門家を組み合わせるだけでなく、それらを混合させることを意味するように見えます。Henrik Kniberg は、クロスファンクショナルチームを次のように定義しています。 しかし、線はどこに描かれていますか？必要な場合、開発者に反復のテスターに​​なるように依頼するのは普通ですか？

18 agile  team  organization 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 コーディング標準はどのソフトウェア開発組織でも一般的ですが、それに従うことはどれほど重要ですか？ある程度の一貫性の必要性は理解できますが、ブレースの位置、行の長さなどの単純なものを扱う場合、過度に厳しい標準がソフトウェア開発に大きく寄与するかどうかはわかりません。 事前定義された標準に準拠しているのではなく、コードが読みやすいことが重要ではありませんか？とにかくガイドラインに似ているようです。

18 coding-style  team  coding-standards 

プログラマーは、テストを設計する際にテスターをどれだけ助けるべきですか？ 私は彼らがまったく助けになるとは思わない。私の心配は、彼らがテスターが彼ら自身のコードのためのテストを設計するのを助けるならば、彼らが彼らの自身の偏見とそのコードに関する盲点でテスターに​​「感染」するだろうということです。 テスターがテストを作成するために必要な情報を提供するには、要件が十分でなければならないと感じています。プログラマーが気になる実装の一部がある場合、ユニットテストを実装してその部分をテストするか、独自の非公式のシステムテストを実行してその部分をテストすることは彼らの義務だと思います。 しかし、私が知っている誰もがこれに同意しているわけではありません（そして、ある程度彼らのポイントを理解しています）。他の人はこれについてどう思いますか？これはどこでも文献で議論されていますか？

17 team  testing 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 閉じた3年前。 そのため、私は過去1年間、プロジェクトリーダーと共に新しいプロジェクトに取り組んでいます。 最初は、別のgitリポジトリにある独自のサブプロジェクトがありましたが、彼のコードとのやり取りはほとんどなかったので、コードのにおいは気にしませんでした。約6か月後、プロジェクトでより大きな役割を担っていたため、彼のコードの機能を維持および追加し始めました。 私は両方のサブプロジェクト（チームが成長しようとしています。彼はまだ私の上にいます）の主任開発者です。 中括弧、大文字の関数、二重引用符の使用法（二重および単一の隠しロジック付き）、===を使用しない、巨大な関数を持つ巨大なクラスはありません。一番下の行は、より良いかもしれません。 通知/警告をオフにするPHPのオプションへの依存。コードには、変数と配列キーの未使用の使用法がたくさんあります。変数はifの内部で定義されます。 上記の2つの問題に対する議論： 人々にコーディングスタイルを強制したくない。 より短い/より効率的なコードに適した言語機能とみなされます。 いくつかのルールが必要であり、コードは防御的である必要があると思います。PHPStormのデフォルト設定をフォーマットに使用し、中括弧とコミュニティで受け入れられている命名規則を使用することを申し出ました。 私は両方のプロジェクトを切り離せないので、同じガイドラインを使用するように調整したいと思います。 私は間違っていますか？個人的な好みを課しますか？

16 php  coding-standards  team 

私はソフトウェア開発チームのリーダーであり（最近、新しいチームを管理しました）、最終的には高い生産性、優れた品質、組織的な優先順位を維持する責任があります。 私のチームには6人の上級開発者がいますが、ここでは混乱のように感じます。状況は、私たちの会社の約10の異なる連絡先からのJIRAリクエストに対処する必要があり、それらはすべて異なるビジネスユニットまたはクライアントを表しているということです。 私が抱えている問題は、私の仕事は主に一日中火を消すことと、すべての人の問題に取り組んでいることを確認することです。残念なことに、当社の文化は高い生産性（高速リリース）でありながら低品質（生産バグ）であり、クライアントは結果の突然の遅れを受け入れません。 これを処理する良い方法は何ですか？私にはたくさんの理論がありますが、私のような状況で実際に働いた経験のある人からの答えを探しています。 動作の簡単なリストを次に示します。 各開発者は、特定のアプリケーションと対話するサービスに対して責任を負います。 通常、リリースは、シミュレートされた実稼働サーバーでクライアントによってテストされ、ライブサーバーに展開されます。 各アプリケーションは平均50〜80人で使用され、合計8つのアプリケーションがあります。 ありがとう

16 .net  project-management  productivity  team 

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

15 team  teamwork 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 何年も変更されておらず、最終的に製品とチームの障害につながる現在のソフトウェア開発プロセスに対処する方法を知りたいと思っています。はい、おそらくこれを解決するより簡単な方法は仕事を変えることですが、この経済では言うよりも簡単です。ただし、特定の例があり、同じ状況で複数回見たり、経験したことがあり、これらの問題に対処する最善の解決策が会社を辞めることだと思う場合は、回答をサポートしてください。重要なのは、特にこの問題に関する複数の専門家が最終的なルートがルートAであることを示す場合、この質問には本当に答えがあるということです。 私は、多くの開発者が同じような状況にあったことを知っています。これは、企業が市場で第1位から最後に、あるいは市場から外れてしまう主な理由の1つです。この投稿の回答が、同様の障害に直面している他の開発者の助けになることを願っています。小規模または大規模な開発チームでは、通常これが発生します。 一部の開発者は気にせず、フローを採​​用することを決め、多くのコードをそのまま残し、開発プロセスをそのままにすることを好むようです。 他の人は変化に飽きて辞任し、別の会社に移動します。 他の人は話をすることを恐れて静かに過ごすことを好むようです。 時には非常に少数の開発者またはたった1人の開発者が製品の改善について意見を表明し、クライアント、ユーザー、およびチームのコーディングのベストプラクティスとその利点に従うことの重要性をチームに伝えます。これらのタイプの開発者は通常、会社が提供するメリットが非常に少ないソフトウェア会社や製品に多くの可能性があるなどの理由により、チームに留まることを決定します。 私たちのチームの製品は、製品の傘を持っているため、会社が収益を得る場所のほんの一部です（この会社はソフトウェア/ハードウェア会社ではないため、少なくとも今のところ、雇用を創出する継続的な特許訴訟はありません）不安定）。ここ数年、他の開発者の経験からこれまでに学んだことと、私の経験では、開発チームを本当に知るには、数日でも数週間ではなく、数か月かかるということです。チームがあなたを雇いたい、またはあなたを必要とする場合、面接プロセス中。彼らはすべてを素晴らしい音にし、あなたが聞きたいことをあなたに伝えるかもしれません。ただし、そのチームで作業を開始し、コードの内部を掘り始めて、完全なSDLCプロセスに移行するときの現実は異なります。これは、開発者として、あなたが仕事に就いたことの現実を見始めたときです。この現実により、ある会社から別の会社に移動したいと思うのは難しくなります。なぜなら、あなたが移動する会社が良いか悪いかを知るのは難しいからです。はい、Glassdoorのレビューなどを読むことができますが、HRからではなく、実際のオンラインレビューの数はどれくらいですか？ マネージャーは最初から常に変化に抵抗しており、以前の開発者は何年も同じことをしてきたことを考慮して、以下に概説する問題に取り組む最良の方法は何でしょうか？ 長年にわたる製品革新の欠如：製品には多くの可能性があり、会社に良い収益をもたらしますが、製品は20年前に作られたように見えます。一部のユーザーは、製品が使いやすくも直感的でもないと不満を述べ、他の人は、Gmailのようなアプリに使用され、同様の機能がないために製品を使用するときにイライラすることを述べています。ここでの主な問題は、開発者として製品に変更を加えて、製品の主要な要素を数ピクセル離れたところに移動しようとすると（ユーザーフレンドリまたは直感的に）、マネージャーがパニックして、元の場所に戻します。ユーザーの生産性を向上させる機能を追加しようとすると、「ユーザーはプロセスを行うのに慣れているなどの理由で」削除するように求められます。あなたは、変化、改善、革新に対する抵抗のポイントを得たと思います（開発者としてあなたが利益の強い議論を提供したとしても、マネージャーは変化に対して開かれていません）。同社はこの分野でいくつかの競合他社を抱えていますが（そのうちのいくつかの製品ははるかに競争力があります）、何とかして現在の顧客を何年も維持しています。 プロジェクト管理の調整の欠如：この結果、一部のプロジェクトがバグで遅れて配信され、一部のクライアントから苦情が寄せられたり（クライアントからもバグが報告されたり）、プロジェクトの配信前に予算が早すぎたりするなど。いくつかのプロジェクト調整のヒントとアイデアが、プロジェクトと実行するタスクの進捗を追跡するために定期的に使用されています。 悪いソフトウェア開発プラクティス：コードの臭いは、すべてではないにしてもほとんどのファイルに見られ、ドキュメント、コードの冗長性、フロントエンド層とバックエンドが同じファイルに混在している、古い開発ツール、実際のテスト環境もテストツールもありません（コピーアンドペーストのみ）開発環境から本番環境へのファイルを作成してから、手動でテストして問題が発生していないことを確認してリリースします）。チームがコード開発とソース管理に2つのIDEのみを使用しているため、チームが知らないところで開発とテストに使用する開発ツールのほとんどは、開発環境でのみ使用できます。他の開発者は最新のフレームワークを使用して現在の問題を改善しようとしましたが、マネージャーは「あなたが去ったら、そのコードを維持するのは誰ですか？、そのままにしておきましょう」という理由でそれを好まない去り、別の会社に移った。 要約すると、他の会社の多くの開発者にも同様の状況が起こると確信していますが、状況が異なるため、開発者は（仕事の都合、仕事の柔軟性、会社の利益、またはより良い機会が届いていないという理由だけで）。私が知っている完璧な会社はありませんが、開発者としてあなたがどのように行動し、物事をポジティブに保ち、最終的に製品の改善とソフトウェア開発プロセスの改善のための変更を促進するためにこれらの問題に対処しますか？長年の開発経験またはほんの数年）？これは投稿が長いことは知っていますが、より有用なフィードバックを得る可能性を高めるために、詳細を追加することを好みました。 フィードバックと時間をありがとうございました

14 project-management  programming-practices  team  project  legacy-code 

私は自分の部署にMercurialを紹介しました。私はそれが大好きですが、それは私の最初のバージョン管理の経験です。Web開発用にNetBeans PHPで使用しています。 社内のアプリケーションで作業する別の開発者は、Visual Source Safeの使用を好み、切り替えたくないと考えています。彼はVisual Studio環境で働いています。 他のすべての開発者は、これを除いてMercurialに買収しました。しかし、ほとんどの場合、私たちは皆独立して仕事をしています。 私はこの部門を正しい方向に動かそうとしています。Kilnのアカウントで全員を設定しました。Fogbugzを使用しているすべての人にも道を譲りたいと思っていました（現在、バグデータベースが維持されていないため） VSSを使用したことはありませんが、非常に悪いことを聞いています。 それが彼が好むものであるなら、彼にVSSの使用を続けることを許可するほうが良いでしょうか、それともMercurialで彼を乗せるのが最善の利益でしょうか？

14 project-management  version-control  team  visual-studio  mercurial 

私の会社は最近、アジャイルな作業方法に切り替えました。その一環として、SCRUMの使用を開始しました。私はこれに非常に満足しており、この方法は従来の方法よりも優れていると感じていますが、チームメイトの一部は同じ意見を共有していません。実際、彼らは「すべてのアジャイルなもの」について非常に懐疑的であり、それを真剣に受け取らないでください。例として、チームメイトの1人は常に会議に遅れており、実際には気にしません。管理IMOはこれに気付かないようにします（おそらく新しいため、人々がそれに慣れるには時間がかかります）。 私の質問は、チーム内で対立を起こさずにこの問題に対処する方法です。

14 team  scrum 

私は何度も悲しい悲劇を目の当たりにしました。発生することは次のとおりです。 新しいプロジェクトのチーム設計レビュー。 かなりの数の穴があるシンプルなデザインが見えます。 何気なく穴とそれらを回避する方法に言及します。 警告は「実生活では決して起こらない」などのコメントでは無視されます 最終的に「決して起こらない」ことが起こる 壊れたプロジェクトの緊急チーム設計レビュー。 だから私は何をしますか？「私はあなたにそう言った」という態度を取り除いても、友人を獲得し、人々に影響を与えるつもりはありません。とにかく、時が経つとステップ3のコメントが忘れられることがあります。私は間違いなく、世界に落とし穴を思い出させる迷惑な害虫になりたくありません。タイタニック号がヨーロッパに向かっているのをよく見ます。 悪いデザインが前進するのを見るとイライラします。また、現在のパスの保留中の危険性を他の人に納得させることができないように思われることもイライラします。私は、チーム会議で最悪のことをします。そこでは、誰もが異なる用語を理解する異なる方法を持っています。また、エゴは理性と思考に勝つ傾向があります。グループの人々にいくつかの新しい複雑なアイデアを使うよう説得するための良い戦術を探しています。

14 design  team 

SCRUMミーティングで、製品チームは、モバイルアプリで使用されるAPIの機能について議論していました。私たちは、画面がどのように見えるべきか、そしてどのキー要素を含むべきか（「レイアウト」）を示すモックアップを用意しました。 これと製品所有者との議論に基づいて、API応答のプロトタイプ（HAL + JSON）を作成しました。それは非常にシンプルで、HALに準拠したJSONであり、モックアップにあるものを表すことしかできませんでした。ビジネスマンは頻繁にアイデアを変更する傾向があるため、私は将来のアイデアに影響されることはなく、ミニマルなアプローチを取ることにしました。私の提案はチームによって却下され、7対1に投票されました。 チームは、レイアウトをより柔軟に配置できる、より複雑で非セマンティックな抽象json構造を使用することにしました。そのアプローチの欠点は、設計上、nullおよび空のプロパティを持つ可能性のある一連の均一なオブジェクトになってしまったことです。彼らはまた、A / Bテストを可能にすると良いと思っていましたが、そのような要件がなかったため、予測に基づいていました。 ほとんどの場合、スプリントの一部ではなく、モックアップで言及されていないことについて議論していました。説明された問題は、「将来のマーケティングがどうなるか...」、「ビジネスが私たちに望むならどうなるか...」でした。 私と製品所有者は経験豊富なプログラマーであり、過去にこの種の問題を見てきました。YAGNIとKISSの原則に従うよう努めています。チームの他のメンバーは少し経験が浅く、これらの原則を知っていますが、理解していないようです。 チーム全体が私たちにとってより重要であり、私たちはそれほど重要ではない何かをめぐって戦いたくなかったので、私たちは彼らの解決策に同意しました。しかし、そのようなことが今後のより複雑な議論の先例になり得るのではないかと心配していますか？そのような行動に対処する方法は？チームリーダーとして、私がもっとうまくできることはありますか？ 製品は初期段階のMVPであることに言及する価値があります。

13 design  scrum  team  leadership 

まあ、質問はそれ自身を言いました。私の職場ではそのようなケースが起こりますが、多くのアジャイルの本は同じ職場で働き、仕事のペースを速くするために現在のプロジェクトに集中することを促進しています。 たぶん、私はそのトピックについて知らされていないかもしれませんが、それほど厳密ではないかもしれませんが、そのような場合にアジャイルが提案することを知りたいと思ったのはそのためです。 誰か？

13 project-management  agile  team  scrum 

自動受け入れテストでユーザーストーリーを100％網羅したBDDを使用してプロジェクトを実行する場合、テスター/品質保証担当者の役割は何ですか？ 開発者が受け入れテストを製品所有者と一緒に書くことを想像していると思いますが、それが馬鹿げた仮定のように思えたら教えてください。

13 testing  team  qa  bdd  acceptance-testing 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ソフトウェアチームに1-2人の新しいエンジニアを雇おうとしています（3人の開発者、1人のテスターで構成されています）。 それらをチームに統合する手順は何ですか？ 私のアイデアは次のとおりです。 ドキュメントを読む（コーディング標準、使用する開発方法論のドキュメント） 既存のコードを読ませる それらにいくつかの簡単なタスクを割り当てます 最後に、コード部分の責任を負わせる 他に何ができますか？ このプロジェクトは医療分野（超音波システム）であり、すでに5年が経過しています。1年に1回のリリースがあり、1〜2人のエンジニアを追加するときに1つのリリースを終了します。 プロジェクトはメンテナンス段階にあります（レガシーコードのリファクタリング、および新しい機能の追加）。物事はほぼスケジュールどおりです（多少なりとも）。

12 team  integration 

最初に用語を作成します： コード目標の調整：午前中にコードをチェックアウトし、他の開発者が前日にファイルごとに行ったすべての変更（特に最初に開発したコードファイル）を静かにレビューし、フォーマット、ロジック、変数名の変更、リファクタリングを修正します長いメソッドなど。その後、VCSに変更をコミットします。 このプラクティスには、私が特定したいくつかの長所と短所がある傾向があります。 Pro：コードの品質/可読性/一貫性が維持されることが多い Pro：他の開発者が元のコードにあまり慣れていないため、いくつかのバグが修正されています。 Con：多くの場合、目標を設定する開発者の時間の無駄です。 Con：前日、バグのないコードを書いたと考えていた開発者が、髪を引っ張る怒りを引き起こすバグをときどき紹介します。 コン：他の開発者は、過度つべこべで悪化し、目標入札のコードに貢献嫌いし始めます。 免責事項：公平を期すために、私は実際には開発マネージャーではなく、実際に「目標管理」を行っている開発者です。 私の防御では、これを正当な理由で行っていると思います（非常に大きなコードベースを油を塗ったマシンに保つため）。また、マネージャーがこの問題に対処する必要があることも間違いなく心配しています。 あなたがマネージャーだったら、この問題にどのように対処しますか？ 更新：これがあまりにもローカライズされているという意味ではありませんが、一部の人は質問しているので、おそらくいくつかの背景が明らかになるでしょう。私は3年前に巨大なプロジェクト（200K LoC）を割り当てられましたが、最近（1年前）にプロジェクトに追加された開発者が追加されました。通常、製品の全体的な安定性について回答する必要があります。コードベースのコアアーキテクチャ部分に驚くほど変更が加えられると、特に緊張します。この習慣は、最初は他の開発者の貢献について楽観的だったために発生しましたが、数週間後までは発見されない深刻な問題を引き起こす過大なミスを引き起こしました。しばしばこれらの

12 version-control  code-quality  management  teamwork  team