「テクニカルユーザーストーリー」はスクラムで許可されますか？
テクニカルユーザーストーリーはスクラムで許可されますか？もしそうなら、スクラムでテクニカルユーザーストーリーを書くための標準テンプレートは何ですか？同じAs a <user> I want to do <task> so that I can <goal> ??
私はいくつかのブログで as-a-developer-is-not-a-user-story を読んだことがありますが、スクラムはこれらを義務付けていないことも読んだことがあります。共有しているブログはほとんどありません システムをユーザーとして使用するユーザーストーリー 、as a <user who is not end user> i want to <system functionality> so that <some techinical thing>のようです。それで、どれが標準ですか？
たとえば、次のようなユーザーストーリーがあります。
レビュー担当者として、ホテルや食べ物の写真をアップロードして、他のユーザーがそれらを見て好きにできるようにしたい
ユーザーとして、自分の見解をよりよく説明できるように写真のコメントを追加したい
これらの両方のユーザーストーリーについて、大きな技術的な項目があります-画像の保存と取得
では、「画像の保存と取得のメカニズム」というタイトルのテクニカルストーリーを次の説明とともに追加できますか？
開発者として、ユーザーが必要に応じて画像を追加/表示できるように、画像を保存および取得するメカニズムを開発したいと考えています
テクニカルストーリーは許可されますが、できる限り回避することをお勧めします。
たとえば、画像を保存および取得するためのストーリーは、2つの通常のユーザーストーリーとして簡単に記述できます。
- レビュー担当者として、アップロードした写真を永続的に保存して、他のユーザーがいつでも表示できるようにしたいと考えています。
（これは、元のアップロードストーリーでは、アップロード後に画像が永続的に保存されないことを前提としています。これは奇妙に見えるかもしれませんが、ストーリーを分割して管理しやすくする有効な方法です。） - ユーザーとして、アップロードした画像を自分の都合のよいときに見たいです。
（これは、保存されたイメージを後で取得できることを意味します。）
テクニカルストーリーは、組織にとって重要な作業のために予約する必要がありますが、ユーザーに機能として直接表示することはできません。たとえば、負荷分散を追加して、より多くの数または要求を処理します。
特定の例を挙げれば、ユーザーが画像を追加または表示したくない場合を除き、ユーザーが必要に応じて画像を追加/表示できるように、開発者が画像を保存および取得するメカニズムを開発したいのはなぜでしょうか。
つまり、あなたの質問は良いものですが、例はそうではありません。これはユーザー機能であり、ユーザーストーリーが必要です。そして、ユーザーが本当にその機能を必要としないのであれば、開発者はそれをしたくないはずです。
テクニカルストーリーは、「開発者として、データアーカイブモジュールの重複を減らして、6か所すべてを変更する必要がないようにしたい」というものです。
これらをスプリントに含める必要があるかどうかは難しい問題であり、それはあなたが顧客であると考える人によって多少異なります。エンドユーザーですか、それともあなたを雇用している企業ですか、それともあなたを雇用している企業ですか？
業界の意見指導の多くは、コンサルタント会社で働く人々によって行われます。その観点から、開発者のストーリーは悪いという議論を見ることができます。それらは、日々の業務の一部であり、支払いをしている会社からは見えません。これらの会社は、請求書が高すぎると作業が乾燥することを確実にするため、すべての開発者は開発時間を改善する、またはバグのないソフトウェアをリリースする能力を改善する技術開発のみを行うという原則に取り組みます。
私の経験は、社内チームで働いて、私の賃金を支払う会社に直接ソフトウェアを提供することです。これらの企業の多くでは、ビジネスとビジネスの技術部門の間に信頼の壁があります。それらのすべてに、コストを減らすことは収入を増やすこととまったく同じだという異なる考え方があります。
それらの環境では、重要な開発者ストーリーを定義するのが良い場合があります。これにより、可視性が高まり、信頼が生まれ、開発者と管理者が同様に、そのようなタスクのビジネスに対する価値について考え、それに応じて優先順位を付けることができます。
最終的には、ぜひお試しください。そして、それが価値を提供しないなら、それをやめなさい。
しかし、私の本能は、もしあなたがこの開発のビジネスへの価値を考えていたら、あなたはそれを開発者の物語にしようとさえしなかったであろうと言います。エンドユーザーにとっては良いかそうでないかのどちらかです。そうでない場合、ビジネスに価値はありません。
これは良い質問です。私は公式な答えはありませんが、私が働く場所では、技術的なユーザーストーリーを追加して、技術的な負債と呼んでいます。それらが許可されていない場合は、私の仕事を記録してビジネスに伝達するためだけの目的でそれらを追加する別の方法を見つけます。同様に、このドキュメントがあると、将来のプロジェクトに何が必要かを思い出させてくれます。
例として、テクニカルストーリーを追加することが許可されていない場合の新しいアプリケーションの切断は、データベースモデルの作成のスプリントの開始後1週間、ハミングし、データモデラーの承認を待つことです。それらをモデラーと繰り返し、完了したらスクリプトをdbaに送信し、dbオブジェクトが作成されるのを待ちます。それまでの間、新しいコードプロジェクト、いくつかの基本的なORM機能、およびソース管理レイアウトを作成します。すべての説明が終わったら、1つの空白のランディングページを作成して展開する時間があります。
これが起こっている間、私が情報を記録しない場合、ビジネスは私たちのチームが実際にはプロジェクトに取り組んでいないのに慌ただしいです。ストーリーにこれらの項目があることは、作業を確認し、作業を文書化し、進捗状況をビジネスに伝えることができることを意味します。
これを行うためのより良いベストプラクティスがある場合、私はすべて耳です。
私の個人的な感想は、チームはスクラムが許すものにこだわりすぎてはならず、チームにとって何が有効かについてもっと心配すべきではないということです。スクラムが少し悪い評判を得た理由の一部は、実務家が プロセスに焦点を当てた になることができるということです。これは、アジャイルプロジェクト管理の背後にある考えとは正反対です。
私は今、私のsoapboxから降りるつもりですが、以下が本当に「スクラム」であるかどうか質問する場合は、上記を（再）読んでください。
ユーザーストーリーが定義する「機能」と、技術チームがこれらの機能をサポートするために提供する必要がある「成果物」を分離することが重要です。この場合、写真を保存および取得する必要があるのは、技術チームとして実装する必要がある技術的な成果物です。ほとんどすべてのストーリーには、技術的な成果物が必要です。
これが重要な理由は、技術的な成果物（それ自体）がユーザーの観点から価値を生み出すものではないためです。技術的な成果物をユーザーストーリーとして追跡し始めると、技術的な出力をビジネス価値を生み出すものとして扱うという罠に簡単に陥る可能性があります。この方法で水を濁すと、ビジネス目標（つまり、お金がかかるもの）をサポートする作業と実際のビジネス目標（つまり、お金を稼ぐもの）が混同されます。
上記の回答はすべて、スクラムフレームワークの信頼できるソースドキュメントを参照できません： The Scrum Guide 。
製品バックログには、将来のリリースで製品に加えられる変更を構成するすべての機能、機能、要件、拡張機能、修正が一覧表示されます。
価値を生み出すことに焦点を当てるべきです。その価値は、インフラストラクチャのアップグレードなどの技術的な作業からもたらされることもあります。それらのアイテムを除外しないでください！
user storyという用語は、The Scrum Guideには決して表示されません。
これは、さまざまなプロセスや技法を使用できるフレームワークです。
ユーザーストーリーの使用は、PBIを記録するための1つの可能な手法にすぎません。 「As a、I want、So that」フォーマットはよく見られますが、その 元の意図 に反する可能性があります。この厄介な形式は Agile 2017 でも対処されました。
垂直スライシング を理解して利用することは、製品バックログアイテム（PBI）のサイズを削減するのに役立ちます。その単一のsaveおよびRetrieveアイテムをsaveおよびretrieveitems。