🐜 👲🏿 ♌️ オブザーバー効果 🐖 🏂🏻 🌾

スープが塩漬けかどうかを調べるには、2つの電極をその中にドロップしてから、それらに電流を流します。 塩素の臭いが現れる場合、スープはすでに塩漬けされています:)

物理学では、「観測者効果」というものがあります。観測がシステムで実行されると、その振る舞いに変化が生じます。この効果は、開発チームの作業の組織化（および実際にあらゆる生産プロセス）に現れている非常に興味深いものです。メトリックのカウントを開始するとすぐに、チームとその個々のメンバーの行動に変更を加えます。

「害を及ぼさない」

管理の観点から、数値的に測定する（メトリックを導入する）という考え方は、一見すると非常に堅牢です。正確なデータを受け取り、それに基づいて必要なアクションを実行します。しかし、残念なことに、すべてがそれほど単純ではありません。メトリックを導入するとすぐに、チームの行動が変わり始めます。チームとその各メンバーは、導入したメトリックに適応し始めます。

例に目を向ける必要はありません。誰もが「ヒンドゥー教のコード」の概念を知っています。開発者は、書かれたコードの行数に対して支払いを始めるとすぐに、多くの場合無意味なコードを書き始め、リファクタリングを忘れ、それを行うことは採算が取れなくなります。したがって、生産性の尺度は私たちに背を向けています。

しかし、逆説的に、これは非常に正確なメトリックです。チーム内の2人のプログラマーが、同じ期間、ほぼ同じ行数を修正します。もちろん、多くの規則（同様のタスク、コーディング標準の可用性、メソッドの最大長、重複の排除、リファクタリングなど）が必要ですが、それでもメトリックはパフォーマンスの推定値として使用しない場合は非常に正確です。

各開発者が作成したバグの数を考慮して、製品の欠陥の数を減らしてください。最高の開発者にはボーナスが提供され、最悪の開発者には制裁が適用されます。すべてがシンプルで透明です。しかし、実際には異なる結果になります。開発者はバグごとにテスターと議論します。イニシアチブの欠如とタスクを実行する意欲がないため、リスクを回避したいという恐怖と欲求があります（「タスクが少ない、バグが少ない」）。このテーマのhabrには非常に良いトピックがあります。「彼らはプログラマーとテスターのように生きています」とJulia Nechaevaが書いています。

反対側に進み、テスターが見つけるバグの数を考えてみましょう。各テスターはわずかな偏差を欠陥と見なすため、この状況では間接的な影響も現れます。

上記の例からの結論は簡単です。メトリックを導入する場合、まず、「害を及ぼさない」という原則に基づいて導かれる必要があります。

どうする？

測定がチームとその個々のメンバーの行動にどのように影響するかを分析します。さらに、分析は主に、すぐには現れないかもしれない非自明な側面に関して実行されるべきです。スクラムを使用する場合、たとえば、レトロスペクティブでディスカッションの基礎として役立つメトリックスを考えてください。たぶん、誰もあなたの測定値を本当に必要としません、そしてあなたは測定することができるという理由だけで測定しますか？

メトリック情報の収集にかかる時間を計算します。特にコードメトリックス、品質メトリックスなどについて話している場合は、このプロセスを自動化できる可能性が非常に高くなります。

他のイノベーションと同様にメトリックを導入する場合、デミングサイクル：Plan-Do-Check-Actを使用すると、チームからフィードバックを受け取り、必要に応じて変更を加えることができます。

オブザーバー効果

「害を及ぼさない」

どうする？

おいしいリンク

More articles: