現在、JIRAを使用して開発作業を追跡しています。私の経営陣は、ソフトウェア以外の開発関連のタスクを含め、すべてを「ユーザーストーリー」としてフォーマットおよび分類したいと考えています。例えば：

「テストマネージャーとして、自動テストのみを使用し、手動テストを使用せずにアプリケーションのテストを実行して、アプリケーションをできるだけ効率的にテストできますか？

承認基準：1. 50の既存の手動テストを完全に自動化されたテストに変換します2.テストは1時間未満で実行する必要があります

ソフトウェア開発プロセスをサポートする作業に「ユーザーストーリー」を使用することが理にかなっていて、プログラマーによって行われず、成果物コードが直接生成されない場合は、コミュニティから理解を得たいと思います。または、これを別の方法で処理/分類する必要がありますか（たとえば、JIRAで）？

2011年6月7日更新-「ユーザーストーリー」という用語に焦点を当てた質問に言い換え。

はい

システムを改善する利害関係者、機能

[純粋主義者の反対投票を始めましょう！]

「私の経営陣は、ソフトウェア以外の開発に関連するタスクを含め、すべてにアジャイルを使用したいと考えています。」

これは、すべての機能のユーザーストーリーを作成することを意味するものではありません。

すべての機能のユーザーストーリーを記述したい場合、必ずしもアジャイルである必要はありません。すべての機能のユーザーストーリーを書いているだけです。

ユーザーストーリー！=アジャイル。

ユーザーストーリーは、要件を収集して理解する方法です。必要に応じて、完全に滝のように使用できます。一部の人々はこれを行います。

アジャイルはプロジェクトを管理する方法です。アジャイルプロジェクトでは、ユーザーストーリーを使用してもしなくてもかまいません。

技術的な負債と内部タスクを管理するためのユーザーストーリーは、アジャイルであることとは何の関係もありません。

多くの人々は、純粋に内部的な、付加価値のある、利害関係のないユーザーのために偽の「ユーザーストーリー」を書く時間を無駄にすることなく、「テクニカル」または「サポート」機能をスプリントに追加することに完全に満足しています。

QAが彼らの話を理解しない場合、実際のビジネス損失はどのくらいありますか？

本当の利害関係者が彼らの話を得ないならば、ビジネスは本当に苦しみます。

これは私には意味がありません。基本的に「ユーザーストーリー」とは、ユーザーストーリーであり、プロジェクトマネージャーストーリーではなく、開発者ストーリーではなく、品質保証エンジニアストーリーです。

そのノートでは、ソフトウェアは次のとおりです。

1. 定義可能
2. テスト可能

プロセスの改善は自由で、通常は主観的です。

合格基準：1.テストの改善1（x / yによる）

テストの改善をどのように測定しますか？そのための明確な契約はありません。

そして無関係なメモで私はあなたの例が上に与えられたことを心から願っています、

テストマネージャーとして、自動テストのみを使用し、手動テストを使用せずにアプリケーションのテストを実行して、アプリケーションをできるだけ効率的にテストできますか？

...これは単なる例です。これには非常に多くの誤りがあり、説明することすらできません。

技術的負債は、ユーザーストーリーと同様の方法で処理できますが、場合によっては見苦しくなります。たとえば、「開発者として、他の変更が何かを壊すかどうかを検証するためのテストに自信を持つことができるように、開発者として機能する単体テストをしたい」という話をすることは、製品の所有者にとって大きな価値がありません。しかし、チームがスプリントの作業の一部である独自のリファクタリングの一部として実行するのは良い考えかもしれません。

タスクがシステムのエンドユーザーに表示されるものではなく、メンテナンスの改善とその所要時間に役立つ可能性があるため、ユーザーストーリーとは別のタスクを用意するのが好きですいくつかの新しい機能を開発します。一部のタスクは2分、他のタスクは2週間となる可能性があるため、全体的なポイントの合計に関して、タスクの数に応じて、これが蓄積され、チームがスプリントを取得して新しい機能を導入せずに機能するかどうかが決まります仕事で数回見たものを片付けるタスクについて

私の控えめな意見では、はい、プロセス改善タスクだけでなく、ソフトウェア以外の開発プロジェクトにもユーザーストーリーを使用できます。たとえば、3年前、私は友人の結婚式で最高の人物であり、結婚式の計画にはアジャイルの方法論とユーザーストーリーを使用しました。私たちが完了しなければならないすべてのタスクは、各ユーザーストーリーのペルソナ、意図、正当化、および成功基準を持つユーザーストーリーとして記述されました。関係者全員が毎日のスクラムに参加して、前日に何をしたのか、その日に何をするのかについて話し合いました。誰もが地理的に分散していたため、毎日のスクラムミーティング、スプリントプランニング、回顧、ストーリーライティング、見積もりセッションのための電話会議を開催しました。合計6か所（3か月）のスプリントがあり、結婚式は途方もない成功を収めました。

内部の「ユーザーストーリー」を実際のユーザーストーリーと組み合わせると、深刻な問題が発生します。

「ステークホルダー」の定義をできる限り読み直してください。

http://en.wikipedia.org/wiki/Scrum_(development）

http://wiki.openbravo.com/wiki/Scrum/Pigs_and_Chicken

http://www.testertroubles.com/2009/04/scrum-pigs-and-chickens.html

鶏と豚の違いがわかるように、注意深く読んでください。

内部の「ユーザーストーリー」は鶏によって書かれています。

実際のユーザーストーリーは豚によって書かれています。

「チキン志向」のユーザーストーリーはそれほど重要ではありません。管理者がどれほど実際の価値のある実際のユーザーストーリーであるかのように追跡したい場合でも、それらは実際のユーザーストーリーではなく、同じ方法で価値を生み出すわけではありません。

議論のぼやけた端にあるのはQA問題です。QAは重要であり、それなしでは何も機能しません。

それは魔法のように突然QAを豚にすることはありません。それは彼らをまだ非利害関係者にしている。サポート、インフラストラクチャ、残りの作業に不可欠な基盤を提供します。しかし、それらは「ユーザーストーリー」であり、実際のユーザーの実際のユーザーストーリーとは本質的に異なります。

QAがテストでテストの改善を示さない場合、誰も廃業することはありません。お金は失われません。

ユーザーがそもそもビジネスを行うことができない場合は、ビジネスから離れています。お金が失われます。操作全体が完全な失敗です。

内部（「鶏」）と実際の（「豚」）の利害関係者を混同しないでください。

「鶏と豚」のコメントは要点を逃している。内部の利害関係者は、開発中の製品の場合はニワトリですが（開発中の場合を除く）、開発プロセスの場合は豚です。

あなたが質問しているのは、「式として 、できるようになりたい _、できるように__ "は、改善が新しいソフトウェアコードの記述を必要としないビジネスプロセスを定義および改善するのに役立ちます。同じことを考えてベストプラクティスを探しているので、このスレッドに出会いましたが、私の強い直感は、あなたの質問に対する答えが「はい」であるということです。文構造の目的は、ライターに、ユーザーがすでに考えているかもしれない解決策を抽象化してユーザーに焦点を当てることです。場合、プロセスのユーザー-できるようになりたいです。

受け入れ基準に関するポイントは良いものですが、それについて独断的である必要はありません（とにかくアジャイルです）。「プロセスの変更が私の目標を達成したかどうかをどのように知ることができますか？」と尋ねるビジネスプロセスを設計するときは、良い練習です。その質問に答えるために常に自動テストを実行できるとは限らないことは事実ですが、それがユーザーストーリーをツールとして失格にする理由ではありません。