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

開発者-開発者、開発者-クライアント、開発者-チームマネージャーのコミュニケーションについて多くのことが書かれていますが、テスターと開発者のコ​​ミュニケーションと関係についてのガイドラインを示すテキストは見つかりませんでした。 テスターと開発者が別々のチームであるか同じチームであるかに関係なく（私の場合、私はアジャイル開発プロジェクトで唯一のテスターです）、テストが受け入れられるためには、テスターがどのように認識されるかが非常に重要であると信じています、そしてプロジェクトの質を向上させるという目標を果たすために（たとえば、彼らを警察と見なすべきではありません）。 テスターが開発者とどのようにコミュニケーションを取るべきかについてのアドバイスや研究はありますか？ 更新：回答ありがとうございます。彼らはすべて私が考えていたものを確認しました。今のところ、私のチームは私の役割を非常によく受け入れており、最終的には本当に進歩しました。答えとして複数選択することもできましたが、自分で決断する必要がありました。

9 communication  testers 

私のチームと私は、顧客との対話に使用するソフトウェアを開発しています。さらに、私たちは自分たちのドッグフードを食べ、ソフトウェアを使用して顧客と対話します。 したがって、私たちの従業員はオペ​​レーターになることができ、お客様はオペレーターになることができ、お客様のお客様は訪問者になることができるため、ユースケースやシナリオを説明するのは難しい場合があります。 ただし、お客様はオペレーターの従業員とやり取りする訪問者である場合もあり、お客様のお客様は私たちの顧客または従業員とやり取りする訪問者である場合もあります。 ここにモデルがあります： A is an employee B is a customer C is our customers' customer X interacts with Y Operator --> Visitor A --> B A --> C B --> C 時にはお客様がさまざまな役割を演じることがあるため、従業員と顧客ではなく、オペレーターまたは訪問者という特定の役割を参照する必要がある場合があります。 いつも「お客様のお客様」と言っても一口です。 他の開発ショップがこれらのセマンティックの詳細をどのように処理するのか、それらのユースケースとシナリオを書くときに疑問に思いました。 第3レベルの俳優を含む製品に適用できる一語の一般的な用語はありますか？ 特定の役割であるオペレーターと訪問者を使用する以外に、顧客の顧客を識別するためにどのような言葉を使用できますか？ 単語は、組織内で採用されるように十分に短くする必要があります。2音節より長い場合でも、短縮形は他の俳優と区別する必要があります。

9 communication  naming  specifications 

たまにはこういうコメントをします # We only need to use the following for V4 of the computation. # See APIPROJ-14 for details. または # We only need to use the following for V4 of the computation. # See https://theboringcompany.atlassian.net/browse/DIGIT-827 for details. そうすることに関する私の主な懸念は、JIRAへの依存度が高まることです。そのため、別のプロジェクト管理システムに移行する場合、これらのコメントはまったく意味がありません。近い将来に発生することは予測できませんが、組織コンポーネント（この場合は、コード、コードリポジトリ、プロジェクト管理システム）の結合の増加に引き続き注意します。 ただし、コードベース全体で、文書化された設計の決定と機能のインスピレーションへの参照があることの利点はわかります。私の知る限り、メリットは 設計の決定への明確な道筋。これは、見慣れないコードの特定のセグメントのデバッグと強化に役立ちます。 複数行のコメントが少ないため、コードがよりクリーンになり、新しい貢献者を脅かすことが少なくなります。 （潜在的に）現在の技術的および非技術的利害関係者への明確な道筋 前述の理由により、「なぜここにあるのか」という質問の数は減少しています。

8 project-management  coding-style  communication  comments  jira 

私は約3人の他の人（開発者以外）と一緒にまともな小規模プロジェクトに取り組んでいるソロ開発者です。これらの他の人々は開発以外の方法でプロジェクトに関与しており、1人は私のマネージャーでもあります。誰もがその場限りの議論にもかなりオープンです。 私のマネージャーはちょうど夢のように見えるものを私に与えてくれました-私はどの会議構造がプロジェクトに最適かを決定することを任されました。これは、会議の過負荷や無意味な会議に対処するための素晴らしい方法のようです。 今のように、大きな力には大きな責任が伴います。もし私が最終的に多くの無駄な時間をもたらす何かを提案した場合、それは私のせいです。 会議をどのように構成するかを考えるのにこれほど白紙の状態はありませんでした。私の考えは： 毎日の目標を伝え、前日の内容を確認するために、15分以下（スタンドアップミーティングと同様）の毎日の「タッチベース/ステータス更新」ミーティング。または、ホワイトボードを手に取り、自分の机に置いてこの情報を伝えることもできたようです。 特定の決定を下すため、またはチームのいずれかが持っている質問に対処するために必要に応じて会議 ...毎週の「ステータス」プロジェクト会議の必要性はないと思います。また、2番目の箇条書きで正式にスケジュールされた多くの会議が必要になるかどうかもわかりません。 私の懸念は、これらの「開発者に焦点を当てた」（つまり私）が他の人との疎外を引き起こしたり、この構造がほとんどのプロジェクトが実行されるものとはかなり異なるため、プロジェクトに対するコントロールの喪失を感じたりする可能性があることです。 1人の開発者が選択する必要のあるプロジェクト会議の構造は何ですか？ コメントへの対応： 他に貢献している人は何ですか？彼らはこのプロジェクトの対象ユーザーですか？開発の非側面（ウェブサイトのテーマと画像、DBA、QAテストなど）に取り組んでいますか？他のレベルの管理/管理？ 彼らは最終的なユーザーの一部であり、全体的なワークフローに関心があります。また、フォーム/ドキュメントのいくつかの領域にも貢献しています（その形式は開発作業に影響しません）。 他の2人のメンバーからフィードバックを得ることができますか？一部のマネージャーは、定期的に会議をスケジュールする必要があります。そうしないと、会議をスケジュールに合わせることができません。 時間を稼ぐことは今後の問題ではないようです。

8 project-management  communication  solo-development  meetings 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 質問自体はばかげているように聞こえるかもしれませんが、問題が私の仕事のパフォーマンスに悪影響を及ぼしていると感じているので、答えは私にとって非常に重要です。 ここで少し背景を説明します。私は、ソフトウェア以外の会社の中規模ソフトウェア部門の経験豊富な上級ソフトウェア開発者です。物事の技術的な面では平均を上回っていますが、私は物事を伝えたり説明したりするのが非常に苦手です。他の開発者に何かを説明するときでも。 最も難しいのは、特定の小さなコードがどのように機能するかを説明するときに発生します。 面白いのは、たとえば、個別のモジュールとサブシステム間の相互作用など、何かがはるかに高いレベルでどのように機能するかについての例を説明および提供する方がはるかに簡単だということです。 より明確にするために、私が「ソースコード説明スキル」と呼ぶのは、 a）コードの実行フローを明確に説明する機能-たとえば、「これはそのThingを呼び出し、そのオブジェクトを返します。これは後でメソッドAを呼び出し、オブジェクトBを...に渡します」 a）現在の設計の問題を明確に説明する能力、またはより重要なのは、「パフォーマンス上の理由から、オブジェクトをクラスのフィールドとしてキャッシュし始めた場合、キャッシュが常に最新の状態になるように、10か所の場所で変更を加える」など なぜ私が物事を説明するのが苦手で、説明を見つけられなかったのかを分析しようとしましたが、箇条書きで説明しているのかもしれません。また、私が説明しているとき、私は自分の発言や質問を見落としていること、人々の質問に集中しすぎているかもしれませんが、これらの質問はしばしば無関係であり、単に会話を引っ張ってしまいます。 何をすればいいのでしょうか（おそらく、間違いを何度も何度も練習すると思うので、実際には購入しませんが、「完璧にするための実践」を除いて）、私はソースを改善できます。スキルを説明するコード。

8 communication  source-code 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 4年前休業。 開発者がいるので、ジョン（現在試用期間中）を彼と呼びましょう（かなり小さな会社、約10人、開発者3人、そのうちの1人はこの会社で長く働いており、ビジネスプロセスを知っており、チームリーダーと見なすことができます）。 IDEをまったく使用したくありませんでした（テキストエディターを使用しています）。 このチームが取り組んでいるアプリケーションは、Spring Hibernateテクノロジースタックを備えた中規模のJavaアプリケーションであり、近い将来にそのアプリケーションの新しいバージョンを起動するための新しい機能をリファクタリング/追加します。 JohnがIDEを使用していないため、このアプリケーションでのIDEなしでのJohnのパフォーマンスは望ましくなく、チームリーダー（Billと呼ぶことにします）の想定によるものです。 ビルはジョンにIDEを使用するように説得しようとしますが、このアイデアは多くの抵抗を満たし、主な理由は「自分がしていることを完全に制御したいので、すべてのコードを自分で書く必要がある」です。 ビルはどのようにジョンにIDEを使用するように説得できますか？（ビルがジョンを会社の所有者からジョンのパフォーマンスに関するいくつかの不満からすでに保護しているという事実を考慮してください） 更新：ビルは、その試みが失敗した場合、もう一度ジョンを説得して説得することを決定し、ジョンにIDEの使用を強制せず、ジョンによって約束された機能が時間内に提供されているかどうかを調べます。

8 productivity  teamwork  communication  ide