私たちのマネージャーは、すべてのプロジェクトで Git コミットを監視しています。通常、これは問題ではありません。バージョン管理は、特に後の監査と分析(何か問題が発生した場合)のために、発生しているすべての作業のログを提供するという事実が気に入っています。
ただし、マネージャーは、「スタイルの修正」を読み取るコミット、またはタスク管理システムでチケット番号を参照しないコミットメッセージが表示された場合に、ユーザーが何に取り組んでいるかについていくつかコメントしました。
これに対する社会的または技術的な解決策はありますか?
詳細情報:これはメンテナンスプロジェクトであるため、「A、B、C、D、そして最後にXを実装する」という一連のタスクが発生しています。
詳細:マネージャーでフラグを立てた特定のコミットメッセージは、「X、Y、およびZへのより良い方法を含む」に近く、単純なスタイルの修正というよりはリファクタリングメッセージでした。
これに対する社会的または技術的な解決策はありますか?
たぶん、これは問題ではありません。
あなたの上司すべき君たちが何をしているか知っている。彼らは、価値のない一連の作業を行っていないこと、または非チケット作業が優先された理由を確認する必要があります。これには害はありません。理想的な世界では、マネージャーがビジネスに期待を寄せることができ、プレッシャーや中断なしにすべての作業を完了できるため、それは利益をもたらします。
これは、マネージャーがチケット作業のみを実行する必要があると考え、技術的なクリーンアップ作業をチケットから除外した場合にのみ問題になります。片付けには常に技術的負債があります。明確で直接的なビジネス上のメリットは得られない場合でも、常に調整する必要があります。
スタイル修正が作業中のチケットの一部であり、それが関連している場合は、識別しやすくするために、作業していた同じチケット番号で個別にチェックインしても問題はありません。
必要な変更を発見しただけで、それらが現在作業中のチケットに関連していない場合は、技術債務関連のチケットを作成し、後で再ハッシュするためにバックログに入れることをお勧めします。
計画中に、技術債務関連のチケットを調べ、この方法で作業することを計画している実際のメンテナンスチケットにそれらを添付して、より関連性を高めることができます。
これにより、「どこからでも」修正を排除し、作業中の特定の問題/チケットのカテゴリにすべてをカプセル化しておくことができます。
これは私にもバグがあります(意図的なしゃれはありません:)。
最も役立つチェックインには、変更されたものだけでなく、その理由だけに固有のコメントが含まれています。段落のコメントを付けてしまうことがあります。
開発が始まると、UI要件が前後に跳ね返って、基本的にコードを跳ね返さなければならない状況に時々遭遇します(そうです、現実の世界では時々不便です)。これらのケースでは、バウンドする理由を明確にするためにコメントを提供することがさらに重要だと私は考えています。そうすれば、顧客と話をした後で経営陣が戻ってきて、その理由を知りたいときは、ターンバイターンの全体的な経験を覚えていなくても、顧客を紹介できます。