開発チームの一部が外部の会社から来ている場合、スクラムプロジェクトを効率的に処理するにはどうすればよいですか？

Question

プロジェクトの1つに関する私の組織では、アジャイルスクラムの方法論に従い、プロジェクトの人的資源の配分を以下に示します。

Scrum Team: SM ProxyDev1(Internal): 50% in the project ProxyDev2(Internal): 50% in the project Dev3(Internal): 100% in the project Dev4(Internal): 100% in the project Dev5(External): 100% in the project Dev6(External): 100% in the project Dev7(External): 100% in the project Dev8(External): 100% in the project

上記のように、外部企業の開発者がいます。また、内部にはプロジェクトに50％しか関与していない開発者が2人います。これらはプロジェクトで最も経験豊富な開発者であり、他の開発者はプロジェクトに比較的新しい開発者です。

スプリント期間は4週間で、3つの改良（PO、ProxyDev、SMによる2つの改良、プロキシdev、devs、SMによる1つの内部改良）、2つの計画（Proxydev、SM、POによる1つの計画、PD、SMによるその他の計画）があります。、PO、Devs）、1つの見積もり（すべて参加）、およびすべてが参加する通常のレトロおよび毎日。

ご覧のように、proxydevsはすべての会議に参加しており、経験豊富であり、これらの会議ですべての開発者の時間を無駄にすることがないため、時間を大幅に節約できます。スクラムイベントに使用する時間を短縮できます。 POは他の会社からのものです。

SMが直面している問題は、外部の開発者はプロジェクトの経験が少なく、それらを説明するために多くのオーバーヘッドがあり、期待が正しく理解されていないことです。したがって、コンセプトワークなどの作業は私たちが行う必要があり、それらは実装を行うだけです。外部開発者からのオーバーヘッドをどのように減らすことができますか？

プロセスをスムーズに実行するためのここでの私のオプションは何ですか？外部開発者と連携するために、他のフレームワークを再構築または使用する必要がありますか？さらに、内部チームを再編成することで生産量を改善できますか？私たちはどんな犠牲を払っても外部企業と協力しなければなりません。

どうもありがとうございました

Petras Purlys · Answer

外部開発者はその名前が言うとおりです-外部。彼らが大規模に貢献し理解することを期待しないでください。コアチームだけがそれを行うことができます。それはすべての会議に出席することよりもはるかに多いので、それらの多くを組織することによって物事が良くなることを期待しないでください。人がプロジェクトについて学び、理解するための最良の方法は、aからzまでプロジェクトに参加することです。プロジェクト形成の決定が下される議論に参加することは非常に重要です。なぜなら、それはすべての質問が質問され、答えが受け取られる場所だからです。外部の人々は本質的にそれを経験することはできません。なぜなら、彼らは「雇う筋肉」であり、プロジェクトを頻繁に変更するからです。

そうは言っても、私は外部の開発者が意味のある方法で貢献できないことを示唆しているわけではありません。それどころか、しかし、いくつかのことを考慮に入れる必要があります。最初に、彼らがプロジェクトについてあなたほど多くを知らないことを認めてください。コアな人々はそれを簡単に忘れて、他の人が彼らのレベルにいることを期待します。これは、プロジェクトがどのように機能するかを説明する図が見落とされたり、更新されなかったり、そもそも完全に作成されていない理由でもあります。そして、私はUMLについて話しているのではありません。単純なペンと紙の概念図は、すべてのパーツがどのように機能するかを理解するための黄金の出発点です。第二に、前述の理由により、外部の人々は、タスクドメインがあまり変更されていないときに最高のパフォーマンスを発揮します。これは、やがてその特定のドメインをますます理解し、パフォーマンスを向上させることができるためです。第三に、それがあなたの力にある場合は、50％ではなく100％をコミットできる外部開発者を選択してください。マルチタスクとコンテキストの変更は生産性の向上にはつながりません。

Marshall Tigerus · Answer

これを処理する正しい方法は、チーム全体を計画およびグルーミング会議に招待することだと思います。グルーミングの目的は、チームのすべての開発者が理解できるようにストーリーが十分に開発されていることを確認することです。あなたの話はそのレベルの理解に書かれていないようです。

しかし、私がとる最初のアプローチは、それらの開発者に、問題が何であると思うか、そして何が彼らにとって物事を容易にするかを尋ねることです。すべての会議に参加する必要のない実行可能なソリューションを提供できれば、時間を節約できます。

Christophe · Answer

本当の問題は何ですか？

あなた自身の分析によると、問題は、プロジェクトの外部の人がプロジェクトでの経験が少なく、期待を理解していないことです。これには、他の人からのより多くの作業とオーバーヘッドが必要です。

根本的な原因が、外部の人が製品や期待について十分な知識を得る機会がないことなのか、それとも彼らがより概念的な仕事をすることができないことなのかは、あなたの物語からは明らかではありません。

それはスキルですか？

能力に関するものであれば、4人の外部開発者全員で同じであるため、問題は個々のスキルに関連しているようには見えません。したがって、それは契約上の設定にのみ関連する可能性があります。これは、たとえば、仕様からのみ機能する純粋なコーダーを目指して（そして最終的には、チームの他のメンバーとの口頭でのやり取りのために英語を十分に習得できない）、伝統的な仕事の分割を想定してプロファイルが選択された場合に発生する可能性があります。この場合は、契約を変更するだけで済みます。

それともプロセスですか？

しかし、それが本当に能力の問題であることに私は驚きます。だから、ここにあなたのためのいくつかの質問があります：彼らはどれくらいチームの一員ですか？製品と期待についてもっと学ぶために、どのような機会を彼らに与えますか？既存の機能に関する知識獲得をどのように組織しましたか？新しい内部開発者は外部よりも貢献できますか？もしそうなら、なぜですか？

答えがありません。しかし、私はあなたが外部に彼らのチームの役割で成長する可能性を与えていないのではないかと思います。実際、計画に参加させないことで、すべての改良がオーバーヘッドの節約に見えるかもしれません。しかし実際には、この慣行により、これらのチームメンバーは、何が受け入れられるかどうかについての重要なフィードバックを奪われるため、チームメンバーは追いつくことができず、不足している情報を提供するために常にあなたの善意に依存します。

覚えておいてください：

一人でもっと速く、一緒にもっと遠くへ

したがって、長期的なメリットを探す場合：

外部メンバーを内部メンバーとまったく同じようにスクラムチームに統合し、すべてのスクラム原則を適用します。これには、追いつくためにいくつかの初期知識の伝達が必要です（たとえば、既存のストーリーを拡張するときに内部でピアコーディングを行うなど、建設的に行うことができます）。
または、作業を別の方法で整理しますが、それをスクラムと呼ばないでください。次に、制限を認識して受け入れる必要があります。特に、一部のチームメンバーは完全に自律的な作業に十分な知識を持たないため、入力と準備作業に完全に依存して、専門家の役割に固定されたままにする必要があります。したがって、非常にハイブリッドな方法で動作します。

私は最初に行くことをお勧めします！

aerohammer · Answer

正解はあなたの困難を部分的に受け入れることだと私には思えます。 PetrasとChristopheがほのめかしたように、外部の開発者は基本的に、少なくとも内部のスタッフが行うプロジェクトについてのレベルの理解を持っていません数週間の間に。

これを認識し、受け入れてください。内部スタッフ（および私はおそらくPOでしょうか？）はプロジェクトとその期待をよりよく理解しているため、設計ドキュメントの作成と改訂をさらに行う必要があります。これを実行する際には、プログラムの設計自体が同じプログラムをコーディングする行為と同じであることを忘れないでください。プログラミングは家を建てることに類似している場合もありますが、プログラミングの実際の建設作業はすべてコンピューターによって行われるため、欠陥があります。私たちはすべてここの建築家です。私たちの一部は、粗くて一般的な超高層ビルを設計しているだけです。ファッション、他の人はより詳細に個々の床を設計します。これを認識し、それに適応してください：

誰もが開発ツールを扱うので、必要に応じて独自のツールを作成するだけでなく、誰もがそれらについて設計フィードバックを提供します。個人用ツールに許可されているものに寛容になるようにしてください。マクロはコードの実際の構造を隠していても、隠している特定の構造（一連のエラー処理）があるため、vmプロジェクトで多くのCマクロを使い始めました。いくつかの標準化されたパターンの）は、コードが実行していることの観点からは実際にはノイズです。マクロを交換した後は、コアシステムを最終的にコンパイルできたとき（数KBであるにもかかわらず、実際に実行するにはまだ十分ではありませんでした）まで、以前よりもはるかに簡単にバグを見つけることができました。私がやろうとしていたのはbootstrapテストの意味のある開始点まで）、括弧の間違いを含むバグ以外に1つまたは2つのバグがあったのかもしれません。それらを記録する気になりませんでした。
あなた、プロキシ、POは設計ドキュメントを最も処理しているので、あなた4人はバグ修正を実行する必要があります。はい、すべての実用的な目的のために、それらは一種のコードとして数えられるべきです。外部開発者がドキュメントの理解に問題がある場合、それらのドキュメントには「バグ」（またはいくつか）があり、修正する必要があることを意味します。これは一種の自己テストコードであると考えてください。
外部の開発者は実装に最も重点を置くため、当然、テスト/ドキュメントなどを記述する必要があります。そのために。設計ドキュメントは、ドキュメントの使用がかなり効率的になるように作成（および場合によってはインデックス付け）する必要があります。彼らはすべて、メモ帳などを用意して、「ドキュメントバグ」のメモを書き留めると同時に、追加するコードの最初のパスを記述します。そのコードと「バグのメモ」は両方とも「コンパイル」する必要があります。同時に。関数（例として）は、「バグノート」が準形式化されてどこかに書き留められるまで、おそらくreallyが正常にコンパイルされていません。問題のコードの先頭にあるコメント。理想的には、VCSリポジトリにファイルを送信すると、これらのメモを自動的に抽出してデータベースに追加するツールがあります。特に微妙なバグは見つけるのが難しい傾向があり、したがって情報を入手することがより重要であるため、あいまいなレポートは問題ないことを外部の開発者に明確にしてください。簡単な例では、「あまり気にしない」という表現は「あまり気にならなかった」という意味で使用されていますが、実際の意味は正反対です。設計ドキュメントに記述されていれば、非常に可能です。間違いに気付かないように（または、一部の人の場合は間違いだと気づかないで！）、同じ段落の後半で文の意味を微妙に変更して、同じチームの異なるメンバーを引き起こす可能性があります彼らがすでに持っているよりもさらに異なる意図の印象を得るために。用語の不一致、2つの事柄が実際に異なるという事実を完全に明確にしていないこと、および他のそのような事柄は同じ方法で気づくことができます。私の以前の仕事（無関係な分野ではありますが）では、1人の同僚が、3年間、データのサブセットごとに個別に追跡することになっていた特定の値を実際に誤って計算していましたが、それは次の理由でのみ発生しました。グループの監督者は、問題の値の計算方法の明確な文書を提供しなかったことに気づかなかった。
たとえば、次のような苦情を投げることに消極的であることは、心理的に自然で適切です。特にそれが何らかの意味で経営者によって行われた場合、それらを作成した人への設計文書。したがって、人々がただ出てきて、彼らが抱えている問題をあなたに話すことが望ましい一方で、それは一貫して起こりません。さらに、彼らは苦労した何かの重要性を理解していないか、他の誰かが問題を抱えていることを理解していないかもしれません。したがって、バグを「集約」する人は誰でも、問題の開発ドキュメントのセクションとともに、すべての開発チームメンバーに対する開発ドキュメントの理解不足に関連している可能性があると思われるバグを取り上げることを強調する必要があります。ドキュメントのそのセクションをテストし、それに対するいくつかの潜在的な改善を設計するための一種のマイクロスクラムを持っています。おそらく、個々のプログラマーまたはプログラマーペアごとに最大15分です（プログラマーのペアでこれを行うかどうかは、実際にペアプログラミングを使用しているかどうかに依存するのではなく、individualペアリングは、ペアとして、または個別に、より多くのフィードバックを生成する可能性があります）。あなたは、スクラムマスターとして、あなたがこの役割を担うべきだと思います。これを行うときは、正確ではありませんその特定の会議で開発者ドキュメントをバウンスしている人のためにこれを行うのではなく、代わりに一般的にチームにとって、ドキュメントで誰かが持っている小さな問題は、実際には大きな欠陥よりも実際にはより価値があるかもしれません。ドキュメントの半分とコードの半分は、微妙な誤字よりも。
「設計ドキュメントのバグ」のレポートは、次のように正確に扱ってください。設計ドキュメントのバグレポート。それらを集約し、類似性のためにそれらを並べ替え、報告されていない追加のケースを探し、類似性を形式化し、「パッチ」を考案し、適用し、再確認します。洗浄、すすぎ、繰り返し、永遠に;または、少なくともそれが物事を改善すると思われる他の何かを理解できなくなるまで。これは、一種の独自の「オープンスクラム」であり、PO、SM、および2つのプロキシがあり、外部開発者がいつでもポップインします。彼らが育てたいと思う何かを持っています。この目的のために、チーム全体がすべて同じ場所にあり、この会議が少し前に終了するときに、そのための多くの作業（とにかく、レビュー、遡及、および計画の各段階の一部）を行う必要があります。マッチングプロジェクト全体の会議。開発ドキュメントは適切に独自のプロジェクトであるため、開発ドキュメントの開発作業tooをより大きなプロジェクトに密接に結合することは良いアイデアではありません。プロジェクト内のプロジェクトのようなものであり、開発者の大多数は、結果をじっと見つめる時間がなくなるまで、その結果について特に何も考えないでしょう。彼らがいくつかのドーナツまたは何かで部屋に保つようにしてください、そして彼らが彼らの電子メールまたは何でも同様にチェックすることができることを確認してください、あなたが彼らが知っている何かに出会った場合、彼らは迅速な健全性チェックを行う可能性が高くなります。その会議が終了したら、通常どおりにクリーンアップし、通常のプロジェクト会議で持ち出す予定の内容を確認して、テーブルの反対側のホワイトボードなどに移動します。ただし、プロジェクト情報を追跡し、「戦術的」なものと「メタ」なものを同じ領域に配置して、そのように調整してみてください。ただし、メンタルシフトを簡単にするために少し分離しています。おそらくそれを行うための最良の方法は、プロジェクト固有の会議室を囲むいくつかのオフィスを持ち、その一方の側を「戦術的」に、もう一方の側を「メタ」に専用にすることですが、現在のテーブルは、プロジェクトソフトウェアで「メタ」タグと「戦術」タグと組み合わせると、実行可能なソリューションを提供するはずです。
開発者固有の開発ツールについては寛容であると述べましたが、これらのツールは、特定のニーズを満たす場合、プロジェクト全体で採用されることもあります。そのため、実際のツールに制限を課さないでください。ただし、外部および内部の開発者に、プロジェクトの個人用ツールのリスト（またはいくつか）を保持させ、別の開発者が使用する場合に備えて、ツールの目的について簡単に説明してもらいます。同じことが必要です。これらのリストは開発者向けドキュメントの入力ドキュメントであるため、開発者向けドキュメントを作り直すときに新しいバージョンを含める必要があります。これをサポートするには、それらと個人的に開発した開発ツールの両方がVCSリポジトリにあることを確認します。これにより、互換性のために元の開発を古いバージョンにロックせずに、必要に応じて特定のバージョンを「プロジェクトツール」にプルできます。元の用途が分岐し始めた場合の「拡張用途」。
同様に、開発ツールのドキュメントは開発ドキュメントの一部です。ツールは1人の開発者に固有のものですが、その目的についての簡単な説明で十分ですが、外側に移動すると、もっと重要なものが必要になります。ツールが比較的大きく複雑である場合（たとえば、いくつかのコマンドラインスイッチを含む実行可能ファイルなど）、長期間（数週間ではなく数か月または数年）プロジェクトを使い続ける場合は、適切なドキュメントなので、それを開始する必要があります。

tl; dr：設計ドキュメントは、コアチーム（PO、SM、およびプロキシ）と、いくつかのハイブリッドユーザー/開発者/テスター（外部開発者）を含む開発プロジェクトとして扱う必要があります。これをプロジェクト内の一種のプロジェクトにし、すべてのプロジェクトメンバーが内部プロジェクトにも協力します。そして、あなた（SM）は、そのために多くの「秘書」の仕事を処理する必要があります（他の人はそうではないように見えますが、フルタイムでいるようです）また、開発者が作成した開発ツールに関する情報の一部は、関連する開発者から「採用」する必要があるため、それらの開発者ドキュメントは、適切な場合に同じプロセスで改善できます。