Tell mode, Ask mode
ある本を読んでいて「Tell mode, Ask mode」という知らない単語を見かけたので調べた。
本の中ではリリース手法とブランチ戦略についての解説に登場した文言。
結論から言うとTesk Mode, Ask Modeはコード品質を上げるためのプロジェクト管理の方針の一つ。
Tell Mode, Ask Modeともレビューを厚めに構えることでチェックイン頻度を下げ品質を担保するという考えがベースとなっている。
現代のスピーディな開発やCICDの流行りには逆行するような方針にも見える。個人的には今もマージリクエストによるレビュープロセスは標準的であるが、Tell Mode, Ask Modeはチェックイン頻度を下げることを目的として明言している点で今の開発プロセスと着眼点が異なると思う。（調べたところ見つかった記事は2004年, 2015年のものなのでやや古い考えかもしれない。日本語の記事もなかったため普及しなかったのだろうか。）
定義としては以下のようなもの。
Tell Mode
部門内のチームには、好きなようにバグを修正する裁量が与えられる。ただし、そのバグを選んだ理由をShiproom*1で発表・説明する必要がある。
そうすることで、事業部内の共通のハードルが確保され、修正のスピードが遅くなり、徐々にビルドクオリティが上がる。Ask Mode
部門内のチームはチェックインする前にShiproomの許可を得る必要がある。
askモードのバグは、夜間の自動化テストとバディテストを経て、問題の発生を防ぐ必要がある。
見ての通り、チェックインにブレーキをかけることで品質を担保しようという方針であるため、トレードオフと適不適がある。
この手法の背景としてあるのは、大規模プロジェクトにおけるリグレッション起因のバグ再発ループである。思うに「開発者が大した影響のないバグにも修正を試みて新たなバグを生んでしまうという状況が品質の低下につながってしまう」という考えから、修正対象を選んだ理由を説明させるTell Modeと修正を承諾制にしたAsk Modeが生まれたのではないか。
こういったプロセスを導入することで、開発者がバグを修正する前に「なぜそのバグを修正するのか」を自発的に考える習慣が生まれるのは良いことだと思う。
参考文献
*1:バグが検討・評価され修正するかどうか判断するデイリーミーティング。恐らくミーティングではなく特定のマネージャの判断で代替することも可能
