認定スクラムマスターおよび認定スクラムプロダクトオーナーのトレーニングからの印象

本日、ワルシャワで6月29〜30日と7月1〜2日に開催されたInnovelとProCognitaの認定スクラムマスターと認定スクラムプロダクトオーナーのトレーニングに参加した感想を共有したいと思います。 ここでは、両方のトレーニングで提示された最も興味深いツールとテクニックを両方のトレーニングで検討します。これは、SCRUMで最初の一歩を踏み出し、プロジェクトで柔軟なSCRUMを適用した経験がある人の両方に役立ちます。 その後、より多くの情報を見つけたい人のために検索を簡単にするために、演習の元の名前を残しました。 さらに、この記事には、一部の演習の本質を説明する英語の記事へのリンクが追加されています。

認定スクラムマスター

コースは、 サイレントソートと呼ばれる演習から始まりました。 最初に、トレーニング参加者は、ステッカーに関するコースからの期待を書き留め、「期待掲示板」に配置するように求められました。 その後、すべての参加者は2つのグループに分けられました。 最初のグループは、ステッカーをカテゴリに分類することでした。 ルールは1つだけでした。ソートは、議論なしで、完全に沈黙して行われるべきです。 最初のグループは十分に迅速に対処しましたが、一部のステッカーは異なるカテゴリに数回移動しました。 その後、2番目のグループは、受け取ったカテゴリに名前を付けることでした。 最初のグループとは異なり、2番目のグループは彼らの行動について話し合うことができました。

演習の分析部分では、2つ目のグループは7つのカテゴリの命名に非常に多くの時間を費やしたことが判明しました。 結論としては、議論の間、多くの場合、時間の大部分が会話に費やされ、タスクの直接的な実行には費やされないということです。 ただし、あらゆる種類の作業から議論を完全に除外することには焦点を当てていません。 それどころか、「ブレーンストーミング」などの一部の活動では、議論は望ましい結果を達成するための最も重要な要素の1つです。 ただし、タスクのすべての参加者が同じ「コンテキスト」にいる場合、予備的な議論は省略できます。 この手法を使用した経験から、バックログタスクの評価に10〜15％使用すると、プランニングポーカーを使用する場合と比較して、プランニングに費やす時間が短縮されることがわかります。 ちなみに、同じコンテキストにいることの重要性は2番目のグループによって実証されました。カテゴリ名を思い付くのに費やした時間の大部分は、最初のグループがステッカーを分類したロジックを理解しようとして費やされました。



次の演習は一見したところ、訓練の参加者には非常に些細なことのように思えましたが、その後、仕事に非常に役立つことが判明しました。 運動は、いわゆるを開発することでした トレーニンググループの作業契約 。 一緒に働く人々のグループは、このグループが順守する「ホステル」ルールのセットを自分で開発する必要があります。 グループの責任には、必要に応じてルールを更新し、グループのすべてのメンバーによるルールの実装を監視することも含まれます。



チームでこの手法を使用する主な利点は、ルールが直接の参加者によって開発され、マネージャーによって課されないことです。 したがって、チームはルールを採用する「内部」動機を持ち、実装を妨害する可能性ははるかに低くなります。 さらに、チームメンバーの1人がルールに従わないようにしようとすると、彼の同僚は積極的に参加して真の道に戻ります。 また、この演習は、チームで自己組織化の開始を開始するのに最適です。 いくつかのSCRUMチームでテストし、素晴らしい結果を得ました。 チームで頻繁に発生する「病気」の1つは、「メインの作業から注意をそらす」あらゆる種類の会議に参加したがらないことです。 このような誤解は、さまざまな理由で会議の遅れや会議の失敗につながる可能性があります。 そのため、チームの1つはある時点まで分散され、別の部屋に住んでいたため、参加者は朝の立ち上がりを定期的に「忘れ」て遅れて到着しました。 そして、このチームのルールの1つはスタンドアップを開始しないことでしたので、全員が会議室に集まるまで、待機に長い時間がかかることがありました。 私も遅れて電話し、会議を思い出さなければなりませんでした。 別のそのような事件の後、このチームのSCRUMマスターは冗談で遅れた人を「罰する」ことを申し出ました。3分の1遅れごとに、チーム全体をいくつかのグッズで扱う必要がありました。 誰もがこのアイデアを鮮明に取り上げており、ルールは作業協定に含まれていました。 数日以内に、このチームのメンバーは果物とお菓子を楽しみました。 もちろん、この決定は遅刻を続ける人々の間では非常に不人気でした。 しかし、行く場所がありませんでした、なぜなら チームのメンバーの残りは、債務者に冗談や冗談で平和を与えませんでした。 その結果、1か月の間に遅延の数はほぼゼロに減少しました。 大企業を扱うためにまともな金額を費やすことを望む人はいませんでした。



私たちが会った次の練習は、 ボールポイントゲームと呼ばれていました。 その本質は、ボールの最大数を最初の参加者から最後の参加者に移すことです。 ルールは参照により記事で詳しく説明されているため、ここでは説明しません。 30分以内に、トレーニンググループは計画、作業の実行、回顧を含む7回の反復を行います。 各反復の後、グループは生産性を高めるようにプロセスを変更しようとしました。 これらの変更のおかげで、結果としてグループは生産性を6（！）回（20から120の目標まで）向上させることができました。 もちろん、実際には、ゲームシミュレーションでは会社の内部プロセス、チームの変更意欲、プロジェクトのビジネスドメインなどの要因が考慮されないため、結果はそれほどバラ色ではない場合があります。 それにもかかわらず、この演習では、反復的なプロジェクト管理方法論を使用することの利点を非常に明確に示しています。

SCRUMチームに相対的な成績での作業方法を教えるために設計された別の演習が注目に値します。 これは、Mike KochのZoo Pointsテクニックの修正版です。 ただし、評価用のオブジェクトグループとタスクの構成が異なるため、このオプションには大きな利点があります。 動物園ポイントでは、動物のサイズの推定を行うことをお勧めしますが、これは作業の難易度の実際の推定とはほとんど関係ありません。 同時に、Tomaszの演習では、最初は少なくとも1つのタスクとの相互作用を想定していますが、その実装条件は異なります。 参加者は、何かをする ことがどれほど難しいか尋ねられます。 たとえば、石、紙、ペン、または生き物を1メートル先に投げます。 ソフトウェア開発ではさまざまなタスクに直面することが多いため、この演習はZoo Pointよりも興味深いものです。

トレーニング参加者が運動中に学んだことは他にもあります。 まず、計画プロセスは、評価を取得するという事実ではなく、チームメンバー間でタスクの知識を同期させることを目的としています。 これは、トレーニングの各参加者が最初にタスクを完了する方法について独自のビジョンを持っていたため、トレーニングでエクササイズを実行することによって達成しなければならなかった状態です。 第二に、「標準」がある場合に評価する方がはるかに簡単です。作業単位は、すべてのチームメンバーにとって明確であり、特定の値を持ち、それに基づいて後続の作業を評価できます。 既にSCRUMチームの1つでこの手法を試し、優れた結果を得ました。以前にチームの推定値の精度が約70〜75％だった場合、手法を適用して「標準」を決定すると、わずかなスプリントで精度が90％に向上し成長する傾向があります。 もちろん、評価の品質を改善するために使用したツールはこれだけではありません。 しかし、最大の結果をもたらしたのはこの演習でした。

最後に、エクササイズに注目する価値があります。これは、管理者がすべての管理を実施するチームと比較して、自己組織化されたチームが生産的かつ調和的に機能する方法を非常によく示しています。 この演習は、チームビルディングでよく使用される「人間のノード」のバリエーションです。 この演習では、参加者は混chaとした方法で手を結合するように求められます。 次に、全員が手を結んだときに、結果の結び目を解く必要があります。 トレーニングで提示されたこの演習のバージョンは、2つのステージで構成されていました。 最初に、参加者の1人がマネージャーになり、チームに解決方法を伝えました。 第2段階では、チームはマネージャーなしで行動しました。 エクササイズの結果は驚くべきものでした。最初の段階では約4分、2番目の段階ではわずか17秒、14（！）時間もかかりませんでした。 したがって、これがシミュレーションであり、実際のケースではないという事実に合わせて調整しても、特定の条件下で専門家のチームはマネージャーの明確なガイダンスなしで作業を実行できると主張することができます。

コースの残りの部分は、さまざまな理論的側面、柔軟な方法論の基本的価値、SCRUMにおける役割とその能力、反復内の活動の種類などの研究に専念しました。 このコースは、SCRUMチームとの仕事を始めたばかりの初心者と、いくつかのチームを立ち上げて実践的なスキルを磨きたい人の両方に適しています。

認定スクラム製品所有者

前のトレーニングがチームとの連携を目的とした場合、認定スクラムプロダクトオーナートレーニングは、機能の優先順位付け、バージョン計画、顧客とユーザーの期待の管理などの側面で製品と連携するように設計されています。



前のトレーニングと同様に、グループは、トレーニング参加者の期待を特定し、作業契約を作成することから作業を開始しました。 次に、 スクラムペニーゲームの演習に進みました。 この演習では、4人の参加者が、20枚のシングルコインコインを裏返して次の従業員に転送するという非常に単純な仕事をしなければならない従業員の役割を果たしました。 最後の従業員に到達し、裏返しになった各コインは、完成した作業単位と見なされました。 20枚のコインすべてが設計作業の量と見なされました。 さらに4人のトレーニング参加者がマネージャーの役​​割を果たしました。 彼らは従業員の近くにいて、従業員が仕事の一部を行う時間、つまり 20枚すべてのコインを裏返します。 最後に、トレーニング参加者の1人が2つのポイントを記録しました。最初のコインと20枚目のコインが最後の従業員によって引き渡されたときです。 5回の反復の過程で、ルールは数回変更されました。最初は、各従業員が20枚すべてのコインを引き渡してから、2番目の従業員に渡す必要がありました。 その後、10、5、2、1枚のコインを転送する必要がありました。 その結果、次の従業員に転送されるロットサイズが小さくなるほど、個々の従業員の生産性が低下することが明らかになりましたが、全体的な生産性は向上しました。 チームが最初に完了した作業単位をわずか76秒後に顧客に提供した場合、すでに5回目の反復で、わずか6（！）秒で完了しています。 プロジェクトの合計実行時間も減少し、5回目の反復では25秒でしたが、最初の反復では86秒でした。これは、同じ品質レベルで3倍高速です。 もちろん、この結果は現実とはほど遠いです。 作業量の増加の可能性、欠陥の修正、機能の処理、受け入れの問題などは考慮されていません。 それにもかかわらず、この演習は、トレーニングのすべての参加者に、反復的なアプローチを製品開発に適用することの可能な利点と、そのアプローチが顧客に利益をもたらす速度を完全に実証しました。

その後、ビジネスケースで作業を開始しました。これは、トレーニングの残りの部分で注目の的になりました。 最初に、製品を考え出す必要がありました。 チームの1つは、コスト、旅行の期間、移動中の乗り換え回数などの条件に従って、旅行者がツアーに最適なオプションを選択できるようにするシステムを作成することを決定しました。 次に、チームメンバーは、いわゆる ビジネスドライバー-「ミッション」に似たもの。 議論の中で、次のドライバーが特定されました。

• 完璧なツアーを探すのに多くの時間を費やす機会がない人のために製品を作成したいので、旅行を選択するプロセスは可能な限り迅速でなければなりません。
• 私たちは、お客様の基準に応じて最適な一致をお客様に提供したいと考えています。
• お客様を幸せにしたい。

次に、チームは、開発されたドライバーをサポートするシステムのいくつかの重要な機能を考え出し、それらの機能をユーザーストーリーのレベルに分解する必要がありました。 重要と考えられるすべての機能から、少なくとも1つのドライバーを直接サポートしているため、重要な機能を特定するプロセスは非常に困難でした。

ユーザーストーリーのリストを受け取ったチームは、 ストーリーマッピング手法に切り替えました。

1. まず、ユーザーがアプリケーションで遭遇するはずの順序で主要な機能を配置することにより、アプリケーションフレームワークを作成しました。
2. 次に、対応する主要機能の下にユーザーストーリーを配置しました。 この時点で、参加者は、関数の初期分解中に見逃された重要なストーリーをいくつか追加しました。
3. 次のステップは、各機能のユーザーストーリーの優先順位付けでした。最も優先度の高いストーリーはより高く、最も重要度の低いストーリーはより低い位置にありました。
4. 最後に、すべてのユーザーストーリーが製品バージョンに分割されたため、各バージョンは論理的に完成し、リリースの準備ができました。 この場合、最初のバージョンには最小限の機能セット、つまり 外国文学で「 ウォーキングスケルトン 」と呼ばれるものであること。

そして、楽しみが始まりました。 チームは多くの時間を費やして、最初のバージョンの機能セットを定義し、ユーザーストーリーを次々に、またはバンドル全体をカットしました。 次第に、製品の最初のバージョンは旅行代理店の連絡先情報を含むランディングページに限定される可能性があることが明らかになりました。 この決定は当初意図されたものとは非常にかけ離れていたことが判明しましたが、そのための重要な議論がありました。

• 元のアイデアには、宿泊施設やチケットの予約システムとの統合、完璧な旅行を選択するためのアルゴリズムなど、多くの難しい機能が含まれていました。 このすべての機能を開発するには、かなりのリソースが必要です。
• 最初のバージョンで、計画されているすべての機能を導入することに決めた場合、チームは非常に遠い将来に利益を上げるでしょう。 絶えず変化する外部環境を考えると、長期投資のリスクは大きすぎました。
• すでに製品開発の過程で、アイデアは内部および外部環境のさまざまな要因の影響下で何度も変わる可能性があるため、小さなものから始めて結果を試すことは理にかなっています。

これらの議論を考えると、誰もがそうであるように、複数のエージェントを雇ってビジネスを運営するという決定は適切に思えた。 もちろん、この場合、チームは完全な旅行を選択するためのアルゴリズムの形で、意識的にメインの「チップ」を放棄します。 ただし、このアプローチは、市場全体をテストする機会を提供し、成功した場合、主要なアイデアを実装するのに十分な資金を調達します。 すべての読者は、このようなプロジェクトについて少なくとも一度聞いたことがあるか、それに参加したことがあると確信しています。 したがって、この手法を使用して、最初の段階で同様の状況を回避し、顧客に繰り返し製品を開発してもらうことをお勧めします。

最後に、バージョン計画中に機能の優先順位付けにも役立つ2つの手法を示します。

• 目的アラインメントモデル 。 潜在的なユーザーの重要度に応じて、機能を4つのグループに分割するために使用されます。 「差別化」象限に入る機能は、できるだけ早く開発する必要があります。 同時に、「誰も気にしない」機能がユーザーによって必要とされることはないため、優先順位を低くする必要があります。
• 狩野モデル 。 この手法は、すべての機能を基本的な必須のエキサイティングなものに分割します。 製品の最初のバージョンでは、すべての基本機能を含める必要がありますが、その一部は必須であり、1-2は驚くべき機能です。 何かを犠牲にする必要がある場合、最初は喜ぶ人を捨ててから、必要な人を捨てる価値がありますが、基本的な人は捨てません。

おわりに

両方のトレーニングは非常に役に立ちました。 4日間で次のことができました。

1. SCRUMに関する理論的知識のホワイトスポットを排除します。
2. 顧客やチームと連携するための多くの便利なツールを探ります。
3. 経験豊富なスクラムスペシャリストからの実践から、現在の質問に対する回答を入手してください。

あなたの何人かは、与えられた情報のほとんどがインターネットで見つけられると思うかもしれません。そして、あなたは正しいでしょうが、部分的にしかありません。なぜなら、コースはインターネット上では見つけることができないものを提供できるからです。素敵なボーナスとして-認定スクラムプロダクトオーナーまたは認定スクラムマスターになる機会。