「テクニカルユーザーストーリー」はスクラムで許可されていますか？

技術的なユーザーストーリーはスクラムで許可されていますか？もしそうなら、技術的なユーザーストーリーをスクラムで書くための標準テンプレートは何ですか？同じAs a <user> I want to do <task> so that I can <goal>ですか？

私はいくつかのブログでas-a- de -veloper-is-not-a-user-storyを読んだことがありますが、スクラムはこれらを義務付けていないことも読んでいます。彼らは共有しているいくつかのブログがあるユーザーとしてシステムにユーザーストーリーを、そのようにas a <user who is not end user> i want to <system functionality> so that <some techinical thing>。それで、どれが標準ですか？

たとえば、次のようなユーザーストーリーがあります。

レビュー担当者として、ホテルや食べ物の写真をアップロードして、他のユーザーが見たり気に入ったりできるようにします

ユーザーとして、写真のコメントを追加して、自分の意見をよりよく説明できるようにします

これら両方のユーザーストーリーには、大きな技術項目があります-画像の保存と取得

次の説明とともに、「画像の保存と取得のメカニズム」というタイトルの技術的なストーリーを追加できますか？

開発者として、ユーザーが必要に応じて画像を追加/表示できるように、画像を保存および取得するメカニズムを開発したい

技術的なストーリーは許可されますが、できる限り避けることをお勧めします。

たとえば、画像を保存および取得するためのストーリーは、2つの通常のユーザーストーリーとして簡単に記述できます。

1. レビュー担当者として、アップロードした写真を永続的に保存して、他のユーザーがいつでもそれらを表示できるようにします。
   （これは、元のアップロードストーリーでは、アップロード後に画像が永続的に保存されないことを前提としていることに注意してください。
2. ユーザーとして、アップロードした画像を自分にとって都合の良い瞬間に表示したいです。
   （これは、保存された画像を後で取得できることを意味します。）

技術的なストーリーは、組織にとって重要な作業のために予約する必要がありますが、ユーザーに機能/機能として直接表示されることはありません。たとえば、負荷分散を追加して、より多くの数または要求を処理します。

あなたの特定の例を考えると、ユーザーが画像を追加または表示したくない限り、ユーザーが必要な場所で画像を追加/表示できるように、開発者が画像を保存および取得するメカニズムを開発したいのはなぜでしょうか？

つまり、あなたの質問は良い質問ですが、例はそうではありません。これはユーザー機能であり、ユーザーストーリーが必要です。そして、ユーザーが本当にその機能を必要としない場合、開発者はそれを望んではなりません。

技術的な話は、「開発者として、6か所ですべての変更を行う必要がないように、データアーカイブモジュールの重複を減らしたい」ということです。

これらをスプリントに含めるべきかどうかの質問は難しいものであり、それはあなたが顧客だと誰が考えるかによります。それはエンドユーザーですか、それともあなたを雇用しているビジネスですか、それともあなたを雇用しているビジネスを雇用しているビジネスですか？

多くの業界の意見は、コンサルタント会社で働く人々によって行われます。その観点から、私は開発者のストーリーが悪いという議論を見ることができます。彼らはあなたが何をしているのかの一部であり、日々、支払いを行っている会社には見えないはずです。これらの企業は、請求額を高くしすぎると作業が枯渇することを本能的に知っているため、すべての開発者は、開発時間を短縮するか、バグのないソフトウェアをリリースする能力を向上させる技術開発のみを行うという原則に基づいています。

私の経験は、社内のチームで働き、賃金を支払う会社に直接ソフトウェアを提供することです。これらの企業の多くでは、ビジネスとビジネスの技術部門との間に信頼の障壁があります。それらのすべてにおいて、異なる精神があり、そこではコストの減少は収入の増加とまったく同じです。

これらの環境では、重要な開発者ストーリーを定義するのがよい場合があります。可視性を高め、信頼を生み出し、開発者と管理者がビジネスに対するそのようなタスクの価値を考え、それに応じて優先順位を付けることを奨励します。

最終的には、試してみることをお勧めします。そして、それが価値を提供しない場合、それをやめる。

しかし、私の本能は、この開発の価値をビジネスに考慮していれば、開発者のストーリーにしようとしてさえいなかったと言います。エンドユーザーに適しているかそうでないかのどちらかです。そうでなければ、ビジネスに価値はありません。

これはいい質問です。公式の回答はありませんが、私が作業している場所では、技術的なユーザーストーリーを追加し、技術的な負債と呼びます。それらが許可されていない場合は、私の仕事を記録してビジネスに伝えるという単なる目的のために追加する他の方法を見つけるでしょう。同様に、このドキュメントを持つことは、将来のプロジェクトに必要なものを思い出させます。

例として、新しいアプリケーションの切断は、技術的なストーリーの追加が許可されていない場合、スプリントの開始から1週間、データベースモデルの作成とデータモデラーの承認を待ってハミングするということです。それらをモデラーで繰り返し、完了したらスクリプトをdbaに送信し、dbオブジェクトを作成するのを待ちます。それまでの間、新しいコードプロジェクト、いくつかの基本ORM機能、およびソース管理レイアウトを作成し、すべてが完了したら、1つの空白のランディングページを作成して展開する時間を取ります。

これが日々行われている間、私が情報を記録しないと、ビジネスは私たちのチームが実際にはプロジェクトに取り組んでいないのに邪魔をしています。これらのアイテムをストーリーに含めることは、作業を確認し、作業を文書化し、ビジネスに進捗を伝えていることを意味します。

これを行うためのより良いベストプラクティスがあれば、私はすべて耳にします。

私の個人的な感じは、スクラムが許すものにチームがあまりにも固執してはならず、チームにとって何がうまくいくかについてもっと心配するべきではないということです。スクラムが少し評判が悪くなった理由の一部は、実務家がアジャイルプロジェクト管理の背後にあるアイデアと相反するプロセスに集中できるようになることです。

私は今、私の石鹸箱から降りますが、以下が本当に「スクラム」であるかどうか疑問がある場合は、上記を（再）読んでください。

ユーザーストーリーが定義する「機能」と、それらの機能をサポートするために技術チームが提供する必要がある「成果物」を分離することが重要です。この場合、写真を保存および取得する必要があるのは、技術チームとして実装する必要がある技術的な成果物です。ほとんどすべてのストーリーには、技術的な成果物が必要になります。

これが重要である理由は、技術的な成果物が（単独で）ユーザーの観点から価値を生み出すものではないためです。技術的な成果物をユーザーストーリーとして追跡し始めると、技術的な出力をビジネス価値を生み出すものとして扱うというtrapに陥りやすくなります。このように水域を濁らせると、ビジネス目標（つまりお金がかかるもの）をサポートする作業と実際のビジネス目標（つまりお金を稼ぐもの）が混同されます。

上記の答えはすべて、スクラムフレームワークの信頼できるソースドキュメント：The Scrum Guideを参照できません。

製品バックログには、将来のリリースで製品に加えられる変更を構成するすべての機能、機能、要件、拡張機能、および修正がリストされます。

価値を生み出すことに焦点を当てるべきです。その価値は、インフラストラクチャのアップグレードなどの技術的な作業から得られる場合があります。それらのアイテムを除外しないでください！

ユーザーストーリーという用語は、スクラムガイドに表示されません。

これは、さまざまなプロセスと手法を使用できるフレームワークです。

ユーザーストーリーを使用することは、PBIを記録するための1つの可能なテクニックにすぎません。「このように」という形式を見るのは一般的ですが、元の意図に反する可能性があります。この面倒なフォーマットは、アジャイル2017でも対処されました。

製品のバックログアイテム（PBI）のサイズを小さくするには、垂直方向のスライスを理解して活用すると役立ちます。その単一の保存および取得項目を保存および取得項目sにスライスすることを検討してください。