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