検索エンジンでモビングやモビングを見つけようとすると、結果の大部分は「人々の心理的虐待」に関するものになります。 したがって、すぐに「mobプログラミング」を探す方が良いでしょう。 現時点（2019年2月27日）でのYandexの上位10の結果には、ロシア語の記事が1つしかありません（その1つは翻訳です）が、英語の記事は多数あります。 それらを流fluentに見ると、それらのほとんどは理論であり、実際のケースの分析ではありません。 チームがより効果的になり、プロジェクトの専門知識をローカルに配布し、人々のソフトスキルを開発するのに役立つと誰もが言います。 私自身、スクラムトレーニングの1つでモブを実際にテストしましたが、率直に言って大喜びでした！ チームと相談した後、テストモビングセッションを実施することにしました。
この取り組みの利点の中で、チーム内での専門知識の広がりや各参加者の追加スキルの開発などの価値を私たち自身で特定しました。 モビング専用の会議を開催して、3つの目標を設定しました。まず、実際にモビングを試してみることです。 第二に、私たちの場合、どのようなデメリットとマイナス要因があるのかを理解することです。 第三に、上記の価値をチームにもたらすかどうかを判断します。
モビングとは
仕事スタイルとしてのモビングの創始者ウッディ・ズイルは、彼を次のように説明しています：
1人のコンピューターの1か所で、一度に1つのタスクに一緒に取り組む素晴らしい人々。つまり、Mobbingは、チームが常に一緒に作業し、一緒にあらゆるタスクを「急襲する」作業スタイルです。 さらに、タスクはライフサイクルのすべての必要な段階を経て、各チームメンバーが全員と同時に同時に作業します。 したがって、チーム全体によるタスクの没入と理解が達成されます。
モブにはいくつかの役割があります。
- ドライバー：共通の職場に座って、ナビゲーターが彼に言ったことを正確に行います。
- ナビゲーター：ドライバーに指示を出します。 何をすべきかわからない場合は、暴徒（チームの他のメンバー）と相談し、ドライバーに必要なアクションをブロードキャストします。
- Mob：開発に参加し、ドライバーに何をすべきかをナビゲーターに伝えます。
- PO（製品所有者）：何が起こるべきかを正確に知っています。 チームの移動に必要な方向を設定します。 ドライバーおよびナビゲーターにすることができます。
- ファシリテーター：ルールへのコンプライアンスを監視し、シフトを発表し、アイデアをパークします。 この役割には一人がいることが望ましい。
モビングはセッションで構成され、セッションはサイクルで構成され、各サイクルはシフトで構成されます。
セッション-チームがタスクに取り組む期間。 セッションの前に、タスクが選択され、ステージに分割され、その目標が決定されます-結果として何を取得する必要があるか（たとえば、機能の増分）。
変更-ドライバーとナビゲーターの役割を変更する間の時間間隔。 原則として、変更は15〜20分続きます。 より短いシフトは、より速いスピードとより大きなチームの関与に貢献します。
ゲームのルール
シフト中、ドライバーは共有コンピューターの前に座り、ナビゲーターが指示したとおりに操作します。 チームは何をする必要があるかを観察し、必要に応じて話し合います。 ナビゲーターは、このディスカッションを構成し、ドライバーが今やるべきことをドライバーにブロードキャストします。 ドライバーはナビゲーターの指示のみを聞き、質問をすることができます。 ナビゲーターは質問をチームにブロードキャストできます。 進行役は、発言されたが何らかの理由で使用されなかったアイデアを「保留」します。
役割の変更が終了すると、ドライバーとナビゲーターの役割は所定の順序で他の人に移されます。現在のナビゲーターが暴徒に移動し、ドライバーがナビゲーターになり、キュー内の次の人が暴徒からドライバーになります。 チームの各メンバーがそれぞれの役割を訪問すると、「円が閉じる」、つまりサイクルが終了します。
モブセッションの後、私たちはそれぞれの印象を共有し、それに基づいて特定の結論が導き出されました。 その結果、Mobbingを使用する方が良い方法と時期、およびチームに適しているかどうかを理解できる結果が得られました。 否定的な印象から始めます。
負
ナビゲーターの役割が完全に明確でない場合があります。 たとえば、ある時点でアナリストがこの役割を果たし、開発者がドライバーになることができます。 ナビゲーターは、開発経験の不足のために、「これが何を意味するのか」を完全に理解するのではなく、チームが彼に言っていたことを語り直した。 その結果、最初に開発者がコマンドを聞くので、なぜ仲介者が必要なのか、ナビゲーターがコマンドの指示を送信するだけの意味をなさない状況が発生しました。 第二に、ドライバーはこの状況で行動する方法を理解していますが、役割のルールに従って、彼の手は縛られています。
また、ナビゲーターが開発環境の次のタブを見て次のステップを決定する必要がある場合は、このアイデアを表明して、タブがドライバーを切り替えるのを待つ必要があることに注意しました。 彼はドライバーに要求を表明しながら、誰もが「とても親切」で「ありがとう」と言って、これをしたでしょう。
問題は、2人の開発者がリモートで作業していることです。 まず、「カーソルへの権限の切り替え」などの操作に時間を追加しました。これにより、リモート管理者は画面上に何かを表示できますが、マウス制御を傍受できません。 これを行うには、会議制御ウィンドウを拡張し、適切な人がカーソルを制御できるようにし、ウィンドウを最小化する必要がありました。 それほど長い時間はかかりませんが、気を散らし、タスク（それは突入し始めたばかり）からノックアウトし、通常は干渉します。 その結果、シフトごとに、新しいナビゲーターは前のナビゲーターに今何をしたいかを尋ねなければなりませんでした。両方ともこれを覚えて、「同期」してから先に進む必要がありました。
一部の従業員の「リモート性」に起因する別の問題は、隣人です。 ある時点で、リモートナビゲーターの隣人が家全体に穴を開けることを決めたため、増幅を伴うあらゆる音が聞こえました。 ご存知のように、これはまったく役に立ちませんでした。
私たちの時間は非常に限られていたため（モビングセッションごとに1時間）、私たちのシフトは非常に短く、各5分でした（各参加者が少なくとも1回はこの役割を訪問する時間がありました）。 私の意見では、それは進歩にも強く反映されています。 前に述べたように、セッションのすべての参加者は、シフトの終了時（終了まで1〜2分）にのみタスクに没頭し、この短い期間の後、全員が切り替えに気を取られました。 このように多くのことをしないことは明らかです。
別のチームは、「黙って」考え、アイデアを議論するためにもっと時間を必要としていますが、頻繁に変化することで、理論で示唆されているよりも多くのことを手で調べようとしました。
私たちは、1時間の実験で最も単純なケースを取りませんでした。チームにとってあまり馴染みのない別のプロジェクトのタスクです。 ほとんどの場合、変更する必要のあるコードが一般的にどのように機能するかを見つけました。 合計7時間の作業（チームメンバーごとに1時間）の場合、どちらの側にこのタスクにアプローチするのか実際にはわかりませんでした。
要因は、チーム全体がテスターを含む特定の観点から問題の解決策を見ていることに留意されました。 将来（適切な段階に達したとき）、これはテストの客観性にマイナスの影響を与える可能性があることを示唆しました。なぜなら、誰もが「どのように機能するか」を知っており、無意識のうちにボトルネックを回避しようとするからです。 残念ながら、これは単なる仮定です。
しかし、他の仮説は確認されました。 セッションの前でさえ、同じタスクに取り組んでいる間に異なるビジョンを持つ人々に出会うと、アイデアのレースがあることを提案しました。 これがまさに起こったことです。一部の開発者は、統合テストを使用してローカルデバッグを実行することを提案し、他の開発者は、変更を行うはずのビジネスプロセスを完全に実装することを提案しました。 各当事者は説得力のある議論をもたらしました。 最初に1つのアプローチを試すことに決めたため、この状況から抜け出しました。合意された時間にこの方法がより多くの労力を必要とすることに気付いた場合は、代替オプションを使用します。
開発環境の設定は、つまずきの原因であることが判明しました。各開発者は、独自の特定のパラメーターに慣れています。 この場合、開発環境は1つしかありませんでした。もちろん、誰もがその設定を気に入っていたわけではありません。
私たちはなんとかファシリテーションのミスを犯すことさえできました：シフトの終わりの少し前に、将来のドライバーはお茶に行きました。 その結果、彼のナビゲーターもお茶を作るために去ったので、私たちは時間内に1つのシフトを失いました。
ご覧のように、組織的なエラーの結果としていくつかのマイナス要因が発生しましたが、それにもかかわらず、それらはより良い方法と理由を示しました。
ポジティブ
参加者は、このスタイルの作業により、通常ビジネスからタスクを受け取り、分析し、テストする人々が、これらの問題を直接解決するプロセスを掘り下げることができると述べました。 彼らは、反対側からの作業を見ました：タスクがその実装に至るまでにどのようなステップを経るか。 そのソリューションへのアプローチ方法を理解するために、開発者がどのようなアクションを行っているかが明らかになりました。 したがって、誰もが現在タスクで何が起こっているかを見て理解します。
開発者がタスクを説明する際により詳細な分析を必要とすることが多く、なぜ一見しただけで質問を明確にするのかというとてつもなくばかばかしいことがあるのは明らかです。
間違いなく、これは私たち一人一人にとって新しい貴重な経験です。 さらに、このような異常なコラボレーションは、チームの強化に役立ちます。つまり、一種のチームビルディングとして機能します。初めて、誰かが他の人の直接の仕事を見て、特定の状況で自分の考えを学びました。
結果
セッションについてお互いから受け取ったフィードバックについて話し合って、特定の結論に達しました。
私たちの結果によると、モビングではチーム全体と絶対に仕事をするべきではなく、少なくとも常に仕事をするべきではないことが判明しました。 私たちの現実では、チーム全体が1つのタスクのみに取り組んでいる場合、請負業者との交渉は行われず、ユーザーの要求は処理されません。 もちろん、あなたのシフトが来るまでこれを行うことができますが、気を散らし、誰もが解決しているタスクに切り替えてから、もう一度ドロップアウトして、シフトの前に停止したことを覚えておく必要があります。
ナビゲーターは、ドライバーよりも少し経験が必要です。 さもなければ、ナビゲーターが「それがどういう意味なのか」を完全に理解せずに、彼が言ったことを文字通り運転手に渡そうとすると、壊れた電話のゲームになります。 たとえば、ロールを順番に変更することはできません。 より強力なナビゲーターをカップルに提供できないが、専門性だけでなく人々に仕事を教える必要がある場合、私たちの意見ではペアプログラミングがより効果的です。
新しい開発者がチームに登場したとき、またはチームの誰かが明らかにプログラムを作成したいときに、モビングはうまく機能するという印象を受けました。 その後、経験豊富な開発者とモブを行うと、新参者はすぐにチームプロジェクトに突入し、一般に受け入れられている原則と仕事のルールを理解します。
同様に、チームの1人だけが専門知識を持っているタスクに取り組んで（そう、そのような人とそのようなプロジェクトがあります）他の人に知識を広めることができます。
暴徒は虎のチーム、つまり緊急の課題を解決するために結成されたチームに適しているという仮定がありました。 しかし、少なくともチームが同じ部屋にいて、大多数のために開発環境が準備されていれば、これは機能します。 そうしないと、不必要な通信要因による時間の損失が発生します。
チームが結成されたばかりで、理想的には新しいプロジェクトが一緒に結成されている場合、モビングはうまく機能します。 この場合、各参加者は、特定の概念、アーキテクチャ、およびその他の決定が行われる方法と理由を確認し、プロジェクトに関する知識に不均衡が生じます。
最終的に、シフトはより長く必要です。 5.の代わりに、少なくとも15〜20分。 そして、ドライバーは自分の頭のないナビゲーターの手にすぎないというルールで何かをする必要があります。
それで、私たちはチームの仕事の条件で実際にモブを試してみました。 いくつかのルールは私たちを妨害し、私たちは何かを誤解し、どこかで間違いを犯しました。 それにもかかわらず、私たちはそれが何であるか、それが可能かどうか、そしてこのスタイルで作業する必要があるかどうかを自分自身で感じました。 この実験の結果によると、私たちが自分にとって最も重要であると特定した値を完全には受け取りませんでした。 これらの結果が最も信頼できるものではない可能性があるため、あまりにも短いシフトで1時間だけモブを試したことを検討する価値があります。 「フルタイム」のモビングに取り組んでいるとき、いくつかの問題は発生せず、プロセスへの「適応」の後に克服される問題もあります。 おそらく、このような短い時間で必要な値を取得することができなかったのでしょう。 これを確実に知るためには、他の状況でモブを試してみる価値がありますが、これはまったく別の話になります。
PS
このトピックに関する次の資料を読んで確認できます。
GOTO 2017-Mobプログラミング：チーム全体のアプローチ-Woody Zuill
Woody Zuill-暴徒プログラミングの日
Agilixコンサルティングブログ：キューを削除してMobbingでチームを加速する