あなたの開発プロセスで現在抱えている問題は、チームをより機能横断的にしない人が数人いることです。
そのため、この人がプロジェクトの一部のボトルネックになることがあります。彼らは共有知識の問題にWikiを使用することを好みません。問題トラッカー システムのチケットに十分なコメントを投稿しません。
この問題のために、私たちの経営陣は、開発者を解雇できない場合があります (彼らがそれを非常に望んでいても)。
この問題はcode-reviewだけでは解決できないと思います。問題に直面するまで、チケット用に十分なドキュメントが作成されていないことに気付くことができない場合があるからです。
チームが分散しているため、ペアプログラミングは私たちの状況では適用できません。
私たちは会議でこの問題について多くのことを話しましたが、概念的な問題のように思えます。この人の態度を変えることはできますか？この問題はどのように解決できますか?
あなたは、彼らの仕事に慣れるのに多くの時間を費やすことになるので、この開発者をクビにすることはできないと言います。コミュニケーションが取れないために、毎日どれだけの時間を無駄にしているのかと思います。ある時点で、誰かが問題のドメインをよく知っているからといって、その人がルールを無視して好きなようにできるわけではないという単純な事実に対処する必要があります。
私はあなたがこの個人と話し、彼らが規則に従い始めるか、あなたが彼らを手放すことを余儀なくされることを彼らに知らせる必要があると思います. このやり方を続けると、彼らの行動に対処するために多くの時間を失うことになり、誰かが彼らのコードを理解できるようになることはありません.
冷酷であることを学びましょう。人々があなたのショップで定義されたプロセスに従わず、チームに損害を与えている場合、彼らは行く必要があります。チームの「メンバー」に作業の問題を通知した後、試用期間を設けます。その人がまだ手順に従わない場合は、問題を通知した会議中に設定した結果を実行してください。
これは今のところの問題ではなく、チームの将来にとって大きな問題です。この人が自分の役割を果たすことを拒否した場合、解雇されるまで拒否します。あなたが今持っている知識のギャップは修正可能ですが、この人を維持した場合に生じる知識のギャップは、その人が形を整えるか手放されるまで続くため、修正できません.
これは機能横断的ではなく、すべてのチーム メンバーが合意したプロセスに従うようにすることのように思えます。
プロセスの最初に戻って、開発プロセスがどのように機能するかについて全員に関与してもらい、賛同してもらうことをお勧めします。前述の「解雇できない」開発者を含めます。参加に同意しない開発者が含まれない場合、彼の投票は共謀です。
開発者がその後のプロセスに従わない場合は、決定の時です。開発者のアウトプット (プロセス外ではありますが) と開発プロセスに従うことのどちらがより価値があるでしょうか?
私は推測することができます：誰もかけがえのない人はいません。開発プロセスが重要で、誰かが参加しない場合は、ドアの外に送り出してください。開発者が何をしたかを理解する問題は短期的な問題であり、対処/管理できます。