序文として
モニターの前に座って朝の郵便物を仕分けしていると、突然周囲の空気が震え始めます。
-何が起こっているの！？
すべてが急激に暗くなり、いくつかの長い間、何も見えたり聞こえたりしません。 独自のハートビートのみ。 光が戻ってくる次の瞬間に......
-私はどこ？ この場所は何ですか？
話し始めると、あなたの注意は、フードをかぶった男が目を覆った状態になります。
-ご挨拶、％UserName％、あなたは魔術師の拠点です！ あなたはSource of Powerを使用できることを知っています。 彼についてお話します。 ソースには、地球、空気、水、火、精神の5つの部隊が含まれています。 地球は持続可能性、空気-自由、水-変化、火-力、精神-規律を表します。 ほとんどの場合、必要なアクションを完了するには、5つの部分のいずれかで十分です。 したがって、火の流れにより、ろうそくに火をつけ、炎の燃焼を制御することができます。 しかし、より複雑なタスクには、より多くの部隊からのフローを織り込む必要があります。 たとえば、天気に影響を与えたい人は、空気、水、スピリットの流れを同時に織り込む必要があります。 しかし、トレーニングを開始するには、テストに合格する必要があります...
あれは何だった？
実際、私はエンジニアリングのアジャイルプラクティスを導入しようとして無駄に説教することにうんざりしていました。
私はあなたのことは知りませんが、私が対処しなければならなかった開発者の中で、実際にアジャイル禅を知っていたのは10％しかいませんでした。 これは非常に悲しい統計です。 そして、私はあなたがそれについてできることがあると思いましたか？
複雑なエリアをマスターする場合、これは常に当てはまります。 最初は、すべてが非常に複雑で、これはしばらく続きますが、突然、簡単で馴染みのあるものになります。 たとえば、車を運転することは、特にメカニックの場合、そのようなトピックです。 そのため、最新のエンジニアリング手法（自動テスト、CI、CD、その他のDevOps）はほぼ同じ方法で習得されます。 問題は、ほとんどの人にとって、開発プロセスが次のように見えることです。
アジャイルプラクティスを習い始めたばかりの人にとっては、あまりにも多くの努力が払われているようで、決して終わらないこと、そして常にそうであるように思われます。 しかし、すでにこれらのプラクティスを習得している人は、ある時点で脳にスイッチがあり、劇的に簡単になることを知っています。 練習はネイティブになり、その後、あなたはそれらなしで生きる方法を想像することはできません。
そして、アジャイルプラクティスを習得するという困難な道のりで人々が最後までやる気を起こさせる方法は？
私の力に絶望と不信の瞬間に、奇跡的にゲーミフィケーションコースに出くわしました（必要になると、突然、興味深く有用なものが私の人生に現れることに何度も気付きました）。 ゲーミフィケーションは、学習と動機付けのための優れたツールです。 たぶんこれはあなたが必要なものですか？
ギャンブルシステムの目標として、製品のエラー数を20％減少させ、同時に変化率を20％増加させることを決定しました。
私の論理によると、ギャンバードシステムの参加者（以下、プレイヤーと呼びます）による新しい作業スキルの段階的な開発は、現代のエンジニアリングプラクティスの必要性に関する独立した結論につながります。 そして、最新のベストプラクティスを習得し、適用することで、定められた目標の達成につながるはずです。
おそらくすでに明らかになったように、私のシステムでは魔法のテーマを選びました。
魔法は特別な原則に従います-それは一種の魔法の物理学です。 呪文は、さまざまな種類の力のストリームを目的の順序と正しいパターンでインターレースすることによって構築されます。 力の流れは、火、水、土、空気、精神の5種類です。
各フォースには、次のようないくつかの有用なスキルが関連付けられています。
- 地球は持続可能性です。 製品の品質-自動テスト+コードレビュー。
- 空気は自由です。 サポート/メンテナンス、ドキュメントの作成、QAおよび運用の転送の自由。
- 水は変化しています。 変更に耐えるコードの作成-技術的負債の最小化（リファクタリング+コードレビュー）。
- 火は力です。 ルーチンを焼きます-内部自動化。 生産性を向上させるさまざまなツールとユーティリティの使用。
- 精神は規律です。 彼らの仕事を分解し、毎日いくつかの仕事を「準備完了」の状態にする（物事を実行する）。
呪文を編むには、まず呪文に必要な力を蓄積する必要があります。 力はタスクを完了することで蓄積されます：
- 分解して征服する-タスク追跡システムでは、合計で約4時間のタスクを「準備完了」状態（+3スピリット）にする（下にする）必要があります。
- 原稿-Gherkin（+4 Air）で実行された作業を文書化する必要があります。
- 支払いによる技術的負債は赤です-プログラムコードの循環的な複雑さを軽減する必要があります（+5水と+2火）。
- 手動テストには寿命が短すぎます-現在の開発（+5 Earthおよび+3 Fire）の自動テストを作成します。
- ジョイントクラス-同僚の仕事に関する3つのレビューを書く（コードレビュー）（+2 Spiritと+1 Air）。
タスクの例：
技術的な負債の支払いは赤です。
コードの匂いを見つけて、それらを取り除く必要があります。
-何？ コードはどのように匂いがしますか？
-はい、それは間違いなく臭いがすることはできません...しかし、それはカンニングするのは簡単です。
タスクを完了するには、以下を行う必要があります。
- コードに変更を加える前に循環的複雑度を計算します。
- 機能のリファクタリングを実行します。
- コードを変更した後、循環的複雑度を計算します。 メトリックは少なくとも5減少するはずです。
- 進行中のタスクへのリンク、実行された作業の説明（最適化されたメソッドの名前とそれが配置されているモジュール）、および変更の前後のメトリックを含むコメントをプロファイルに残します。
- クロスレビューのために2人の同僚とアレンジします。 その結果、各同僚は、実施された作業の評価と評価の根拠を記載したパラグラフ3のコメントへの回答を残す必要があります。 クロスレビュー期間は3営業日に制限されています。
- クロスレビュアーの評価に基づいて、当然の強さを取得します。
理想的には、メソッドの複雑さは15〜19の値を超えないようにする必要があります。
評価のクロスレビューアは、次の基準から進める必要があります。
| 格付け | 強さ | 解説 |
|---|---|---|
| 1 | 1水 | 循環的な複雑さは減少しましたが、変更を加えるとエラーが検出されました |
| 2 | 2つの水 | 循環的な複雑さは減少し、エラーは認識されませんでしたが、コードはこれからより明確になりませんでした |
| 3 | 3水 | 循環的な複雑さは減少し、エラーは認識されず、コードはもう少し理解しやすくなりましたが、リファクタリングに関する重要なコメントがあります（たとえば、メソッドの強調表示のためにコードの論理部分が誤って選択されました） |
| 4 | 4水
1火 | サイクロマティックの複雑さは減少し、エラーは認識されず、コードはより理解しやすくなりましたが、いくつかのコメントがあります（たとえば、変数の命名や新しいメソッドへ） |
| 5 | 5水
2火 | 循環的な複雑さは減少し、エラーは認識されず、コードはより理解しやすくなり、リファクタリングに関するコメントはありません |
リファクタリングの作成者がレビューに同意しない場合、評価を修正するために彼は大魔術師の輪に目を向けることができます。
蓄積された力を呪文に費やすことができます。 現在開いているすべての織物が含まれている公開スペルブックがあります（スペルリストが開いているため、プレイヤーはシステムのマスターに新しいスペルを提供できます）。 各ウィービングにはコストがかかり、たとえば、プレーヤーの現在のレベル（初心者、養子、またはメイジ）、回復時間（呪文を編むことができる頻度）など、いくつかの制限もあります。 呪文の例：
- アーケインインテリジェンス-5営業日以内にプレイヤーが毎日少なくとも3つの毎日のタスクを実行する場合、プレイヤーは呪文に費やされるエネルギーの2倍の量を受け取ります
- 呪文を離れる。
- 後で仕事に来て/早く出てください。
- 日常業務に対する保護。
- 賢者の石は、蓄積された力を別の力に変換することです。
また、優れた結果を得るために、開催された魔術師は意思決定に参加するために最高評議会に参加する機会があります。
システムのスケーリング
説明したゲーミファイドシステムは、ほぼすべてのユニットに「ねじ留め」できます。 これを行うには、いくつかの手順を実行するだけです。
- スタッフに教え込む必要がある強みとスキルを比較してください。
- タスクを作成するには、前の段落のスキルを「ポンピング」します。 さらに、タスクは特定のフォースに厳密に対応する必要はありません。
- スタッフが蓄積されたリソースをどこかで使うことができるように、魔法の本の織り方を発明する。
- 蓄積されたリソースの量と製織のコストのバランスをとります。 たとえば、私はキー織り「レジャー」から始めました。 私の考えによれば、すべてのタスクが毎日完了していれば、18〜20営業日ごとに約1回織ることができます。 残りの織りのコストは、「離脱」に対する「関心」の度合いに基づいてすでに調整されています。
同時に、各ユニットが独自の「インスタンス」システムを使用する必要はありません。異なる学校/魔法の学校（たとえば、魔術師、司祭、シャーマン、ドルイドなど）として共存できます。 これにより、集合的なPvEコンテンツなど、システムをさらに発展させるための広い範囲が開かれます。
結論として
パイロットチームでゲーミファイドシステムを3か月間使用したところ、驚くべき結果が得られました。
- コードをテストでカバーし始めました。
- gitに移動しました。
- 個々のコードの所有権はもはやそれほど顕著ではありません。
- 「仕事に触れないでください」という言葉に触れることを誰もが恐れていたコードの一部は、現在正常に復元されています。
- コードレビューは相互学習ツールというよりも制御ツールではないため、チームメンバーはお互いから学びます。
- 大量インシデントの数は減少しました（その理由は主にゲーミフィケーションとアジャイルプラクティスにあると考えています）。
- 時々、チームメンバーの間で何か新しいことを学びたいという欲求が高まりました。
- 途中で、ビルドサーバーの使用を開始しました。
これらすべてを、2016年全体でさまざまな方法で達成しようとしました。
次のステップとして、クエストチェーンを使用して新しい従業員を適応させることを考えています。 計画どおり、新しい人は遊び心のある方法で、内部プロセスがどのように配置され、チームに参加するかをすばやく把握する必要があります。
ここでは、プロジェクトオフィス、QA、運用サービスなど、ITに関連する他のサービスで説明されているシステムを使用することに関するトピックを共同で再作成するようにコメントで提案します。
また、織り方の興味深いアイデアについて一緒に考えることも面白いでしょう（私は、魔法の本を厚くしたいです）。
それでも、私はどんなフィードバックにも感謝します。
物語を完成させた著者は、火のループを作り、スピリットと織り交ぜられた空気を通過させ、次に水の流れを織り、地球の流れの周りにそれを結び付けることでパターンを修正します。 パターンが安定し、ポータルがその場所で点滅し始めます。 彼はポータルに足を踏み入れ、姿を消します...