私が現在働いている会社では、スクラムプロジェクトを始めました。管理者に滝からスクラムに移行するよう説得することはそれほど難しくありませんでした。プラットフォームをゼロから再構築するプロジェクトを行っています。（ほとんどの）機能は既知であり、ほとんどの改善はかなり技術的です。
これでは、ユーザーストーリーではなく技術的なタスクを持つことを正当化できます。バックログには、次のようなあらゆる種類の技術的なタスクがあります。
スタンドアップ中に出てくるものには、長い「研究タスク」が必要であるが、決して実行されないことが含まれます。また、チームメンバーは、スプリントの途中で、計画外のタスクを追加する必要があると主張します。
スクラムマスターはこれにどのように対処する必要がありますか？この種のプロジェクトにとって、スクラムは進むべき道ではないのでしょうか？
回答:
スクラムは、ユーザーストーリーの使用を義務付けていません。それらは単に便利なアジャイルプラクティスです。プロダクトオーナーは、ユーザーストーリーの代わりに技術仕様を使用してプロダクトバックログを構築できますが、他のプロセスの問題のほとんどは、効果的なスクラムおよびアジャイルプラクティスを採用できないことに起因します。
スクラムは、次のようなさまざまな方法で破損しているように見えます。
スクラムは必ずしもすべてのプロジェクトに適しているわけではありませんが、この場合、チームが実際にスクラムを行っていないためスクラムが機能していないと言う方が正確です。ユーザーストーリーに関するあなたの質問は、チームが直面する大きなプロセスの問題のほんの一部です。
技術仕様は、要件を伝えるための根本的に壊れた方法です。ある観点から取り残されていない要件は、開発者にとって有用なガイダンスを提供しません。投稿された例を使用：
開発者の観点から見ると、これらの種類の質問に答えられないことは、まさにあなたが説明するプロセスの問題の種類につながります。それがユーザーストーリーの役割です。必要なコンテキストを提供し、特定の機能についての利害関係者またはエンドユーザーとの追加の会話のプレースホルダーとして機能します。
ユーザーストーリーはフレームワークの要件であると考えているため、または広く受け入れられているアジャイルプラクティスであるため、ユーザーストーリーを使用しないでください。代わりに、プログラミングタスクを簡単にし、プログラミングの仕事をより楽しくするため、効果的に作成および使用する必要があります。もちろん、走行距離は異なる場合があります。
ここでの問題はスクラムそのものではないと思います。問題は、明確に定義されたプロジェクト成果物がなく、（これを何度も経験した）明確な方向性がないことだと思います。
あなたの技術的な仕事は大丈夫だと思いますが、大部分は測定可能かつ定義可能であるため、ストーリーとしては絶対に問題ありません。
スクラムでは、研究タスクは目に見える利点をほとんど提供せず、膨大な範囲のクリープを作成する可能性があるため、私にとって大きな危険です。スプリントでこれらの先行投資を制限することを推奨します。追加すべきではなく、コミットされた目標を犠牲にして追加すべきではありません。合意されたスプリントタスクを完了する必要がある場合、その依存関係は計画時に明確になっているはずです（そうでなければ、彼らは何を見積もっていましたか？）。
私の経験では、多くの「調査スパイク」を伴うプロジェクトは、実際に多くのことをしておらず、ビジネス価値を生み出すのではなく、新しい光沢のあるクールなものを見つけることに時間を費やしたい開発者のカバーです。あなたのチームがこれを行っていることをお勧めするわけではありませんが、プロジェクトには明確な目標が必要です。開発者に「研究」の自由が与えられた場合、許可する限り、彼らはそれを行い、それを続けます。
スクラムは、顧客に成果物を提供した方が良いと言います。ただし、ここでのポイントは、成果物と顧客を指定しないということです。
つまり、特定のケースでは、成果物をコードの改善、プラットフォームの変更、書き直し、再設計などとして定義し、テクニカルマネージャーを顧客と見なすことができます。
それは100％理にかなっています。あなたはあなたの製品のユーザーの物語を伝えるバックログを作成し、そのユーザーは誰ですか？技術管理者。したがって、次のようなアイテム：
また、顧客（技術マネージャー）に提供するのはロギングシステムです。
ただし、あなたが話したR＆Dタスクに関しては、スクラムのスパイクについて読むことをお勧めします。これらは基本的には時間ボックス化されたミニタスクであり、より大きななじみのないタスクを実行するために必要な時間を決定するのに役立ちます。
スクラムマスターとして、作業の性質上、より長いスプリントを検討することをお勧めします。これにより、「研究」タスク用のバッファが少し増えます。ただし、タスクがコードで何らかの作業成果物/概念実証を生成することを確認する必要があると思います。プログラマに何を期待していますか？動作するものを入手して、この情報を使用して、A：必要なことを実行するかどうかを判断しますB：パフォーマンスが向上しますC：より高速になり、アイデアが得られるまでにどれくらい時間がかかりますか何かを作ります。
現在の書き換えについて考えたことがわからない場合は、スプリントサイクルを短くすることができます。あなたが進むにつれてそれらを調整することを恐れないでください。これがアジャイルであることの意味です。あなたの研究の後、あなたはまた、新しいテクノロジーを採用することに決めるかもしれません。これは、制御不能になる前にスプリントを短くするもう1つの理由です。スプリントの途中で、新しいものが機能しないことがわかります。スプリントを停止し、古いテクノロジーで調整します。結局のところ、開発者は古いメソッドと新しいメソッドを比較して対比できるはずです。
開発者のニーズをジャグリングしていて、この場合はアプリケーションを書き直しています。私は、このプロジェクトを後よりも早く完成させ、長期的な言い訳として「研究」の必要性を受け入れないプロダクトオーナーがいると思います。
以下の戦略のいくつかが役立つかもしれません、
はい、テクニカルストーリーでバックログを作成できます。
ユーザーストーリーのように、これもエンドユーザーにもたらすメリットに焦点を当てたテクニカルストーリーにする必要があります。ここにいくつかのヒントがあります。これらは、より良いバックエンドに移行したいなど、製品に本質的な価値をもたらすストーリーです。
調査（研究）タスクでスパイクを使用する
スパイクとは、開発者がユーザーストーリーで未知のもの、たとえば新しいテクノロジについて十分に学習して、そのユーザーストーリーを推定できるようにする実験です。スパイクはタイムボックス化する必要があります。これは、学習に費やされる最大時間を定義し、スパイクの推定値を修正します。