SCRUMとのチーム同期

スクラムの最大の問題の1つは、チームのメンバー間の完全な非同期であるように思えます。 この問題に対する単一の安定した解決策はまだありません。 もちろん、標準的なツールはありますが、常にそうではなく、すべての質問に答えてすべての穴を塞ぎます。









私たちを訪ねて、アルファ・バンク・カンパニーの「オンライン住宅ローン」のチームがそれ自体の中で同期の問題にどのように苦しんでいるかを見ることを提案します。



記事は、 Marina 、 Dima 、 Nastya 、 Veronika 、 Tolyaの各チームのメンバーによって作成されました。



少し前（6か月前）に、Alfa-Bankは新しいプロジェクト「Online Mortgage」を立ち上げました。 プロジェクトのチームはゼロから組み立てられました。 人々はプロジェクトのさまざまな場所から来ました。 このガイドには、DevTeam（JS、Java、QA、アナリスト）、スクラムマスター、プロダクトオーナーのすべてが正しく書かれていました。 誰もスクラムフレームワークに取り組んだことがありません。

最初の同期点：DOR

だから、私たちは皆集まって会い、ほとんどすぐに仕事に取りかかりました。 私たちの前には、多くの明白でない（一見した）アイデアがありました。 それらのほとんどは後に一般的かつ論理的になりました。 しかし、ここに長い間克服できなかったものがあります-これがタスクの想像上の理解可能性です。 スプリントでタスクをとることがよくありますが、一見したほど単純ではない（時には難しい）ことがわかります。



Rassynchronは次のとおりです。

• ビジネスが存在するさまざまな世界と9つの
• テストのためのさまざまな程度のユーザーストーリーの準備、
• タスクの完全性に対する異なる理解。

解決策は何とかそれ自体でもたらされました。 標準ツールを使用して、試してみることにしました。 DOR（Definition Of Ready）を使用すると、タスクの不確実性の度合いを軽減し、タスクの作業を開始する前にPO（製品所有者）と9のアクションを調整できます。 このアプローチを使用すると、開発中に発生する不確実性の程度を常に明確に決定し、複雑さを評価する際にそれを考慮することができます。



この体験は大成功でした。 私たちはより団結的かつ生産的に行動し始めました。 グルーミングでは、DORを目の前に置いて、タスクを解析するためのチェックリストとして使用しました。 POは、ほとんどの場合、タスクの欠落を事前に発見し、できるだけ早く情報を更新しようとしました。 そうでなければ、そのようなタスクは単に次のスプリントに落ちませんでした。



一般的なバックログの上位タスクからスプリントまでスパイク（研究）を行う必要がありましたが、これは非常に大きな結果をもたらしました。 不確実性は減少し、タスクの複雑さを正しく評価し始めました。



各チームが独自のDORを持つ必要があることに注意してください。 事実は、雇用主からの一連の明確な指示を構成すべきではないということです。 むしろ、それはタスクの最小限の説明と落とし穴の研究のためのチームの要件であり、作業の利便性と加速のために完了する必要があります。

2番目の同期点：DOD

チーム全体がどのタスクをスプリントに入れることができ、どのタスクがその価値がないほうがよいかを理解しているとき、それは非常に良いことです。 DORの条件を満たした後、次の問題に遭遇しました。タスク（ユーザーストーリー）を実行しますが、それが正確に準備できていることをどのように理解できますか



もちろん、すべてのサブタスク（サブタスク）を見て、それらのタスクの準備状況を評価できます。 しかし、ドキュメント、テスト、またはアクセス設定のサブタスクを開始しなかった場合はどうなりますか？ そのようなサブタスクを毎回開始する必要がありますか？



まあ。 理想的には、サブタスクを開始し、時間通りに完全に閉じるとしましょう。 次に、マスターへのマージの直後にタスクを閉じるのが論理的です。 しかし、タスクはまだ戦いではありません！ ユーザーは私たちの仕事の利点を見ることができず、すべてが無駄になりました。



最初は、閉じられたタスクの事実について議論しました。 その後、私たちはいくつかの非常に正式なルールを採用しました。 これにより作業が大幅に簡素化されましたが、ときどき競合が発生しました。 次に、次の標準的な同期ステップに進みました。



DOD（Definition Of Done）を使用すると、完了したタスクの受け入れと一般的な理解の問題を解決できます。 DODはDORと非常によく似ています。 これは同じ基準のセットですが、今回は終了したタスクです。 それを見て、私たちは常に言うことができます：タスクの準備ができているかどうか。





その結果、タスクが閉じられたと見なすために何をする必要があるかについての共通の理解を深めました。 すべての項目を完了して初めてタスクは完了になります。

同期の最初の2つのステップをまとめる

いいね！ 仕事がずっと便利になりました。 話すことについての不必要な手続き、準備ができているタスク、および最終決定する価値のあるものに時間を費やすことはもうありません。 一方、スプリントのタスクを実行することを恐れなくなりました。 しかし、これらのイベントの間はどうなりますか？ 不和、荒廃、カオス。



アナリストは、最初にスプリントのすべてのタスクを常に最初にチェックできるとは限りません。 開発者の1人は、他の開発者に影響を与える変更を（ロールバックすることなく）行うことができます。 結局、POも人間であり、スクラムではあまり歓迎されない場合でも、スプリント中にタスクが変わる可能性があります。



実際、仕事の雇用段階と完了段階の間で、競合や非生産的な作業につながる可能性のあるケースが多数あります（略してDORとDOD）。 ほとんどすべてのチームで同じ問題を見ることができます。 誰かが何かをどこかに注ぎ込んで、2人目の開発者が今苦しんでいます。 これは、対立と否定性を引き起こします。 そしてもちろん、この問題はほとんどの場合、複数の開発者が同じタスクに関与しているときに発生します。



最初に、DORやDODのような既存のものから何かを見つけようとしました。 残念ながら、似たようなものや私たちにふさわしいものは見つかりませんでした（ひどく見た目が多かったのかもしれません）。 進行中の作業を1つ試しましたが、失敗しました。 各タスクは、異なる部分で構成されています。 私たちの経験では、このアプローチでは開発者の1人が常に退屈している一方で、誰かが仕事を続けて「半分」を終えることを余儀なくされています。 少し前に、私たちは集まって別の中間段階について考えました。

3番目の同期ポイントは、独自のアイデアです：DOT

DOT（テストの定義）は、タスクをテストし、テストベンチで単一のユニットに組み立てるための一連の基準です。 また、DOTが完全に完了するまで、Deptimがそれ以上のアクション（プルリクエストなど）を続行できないルールを設定します。



図を見て、アイデアをより詳細に解析してみてください。 まず、タスクごとに1人の開発者しかいないと想像してください。







すぐに、ここで重要な機能に注目します。 テスト領域を離れる前に、何をする必要があり、何をできないかがあります。 これには、プル要求の通過、マスターでのマージ、ロールアウトなどが含まれます。



すぐにDORやDODとの違いに注目する価値があります。 DORについて話すとき、問題を解決するために必要なものについて話します。 DODについて話すとき、どのタスクが完了したと見なすことができるかを言います。 DOTでは、いくつかのタイプの状況の影響を受けます。 一方では、タスクの開発を完了する必要があります。 一方、タスクを完全に完了した状態にするために多くのアクションを実行する価値はありません。



このアイデアは、1つのタスクで複数の開発者がいる場合に明らかになります。 そのような場合を見てみましょう。 この例では、前面と背面があります。





スキームは非常に近似しています。 わが国では、ある専門家が別の専門家を支援（または妨害）できることは明らかです。 タスクを改善する必要性がより早く出てくるかもしれません。 また、別の人が戦いに参加することができます。 主なものは異なります。 BEFOREとAFTERが明確に定義された特定の領域があります。 さらに、すべてのDOT条件が満たされるまでAFTERは発生しません。 そして、その後でのみテストから問題を解決できます。



ここで他に重要なことは何ですか？ 写真からわかるように、開発はさまざまな時点で開始できます。 ここで最も重要なことは、何人かの開発者が異なる時間にテストエリアに入ることですが、彼らは一緒に抜け出すことしかできません。 現時点で彼らが忙しいこと-あなたは同意することができます。



タスクが完全にテストされた後、すべての開発者はテストから魔法のようなOKを取得し、今では1つのポイントから開始します。 興味深いことに、同期に問題が生じる可能性はほとんどありません。 残りのアクションには、ほぼ同じ時間がかかります。



DOTの必要性は、開発者間の緊密な同期の必要性です。 複数の開発者が一度に異なる時間に参加しますが、常に単一のポイントで出てきます。



このアプローチの欠点は、形成段階でタスクの編成を熟考するための追加の時間です。 しかし、実際には、そのようなコストは簡単に報われます。 同時に、タスクはより構造化され、予測可能になります。

おわりに

もちろん、DOTは新しい世界ではありません。 これは私たちのチームで同期を見る方法です。 このプラクティスがどれほど優れているか、そしてそれが何をもたらすかを言うのは時期尚早です。 私たちは、各企業、さらには社内のチームでさえも異なる作業プロセスを持っていることを理解しています。 反復的なアプローチと経験に基づいた改善を信じています。 試してみます。 結果を取得します。 次に何をすべきかを決定します。 それにもかかわらず、これは興味深い経験であるように思えます。 近い将来、我々の実験結果を確実に共有します。 ご清聴ありがとうございました！