プロセス改善タスクに「ユーザーストーリー」を使用できますか？
現在、JIRAを使用して開発作業を追跡しています。私の経営陣は、ソフトウェア以外の開発関連のタスクを含め、すべてを「ユーザーストーリー」としてフォーマットおよび分類したいと考えています。例えば：
「テストマネージャーとして、自動テストのみを使用してアプリケーションのテストを実行し、手動テストを使用しないで、アプリケーションをできるだけ効率的にテストできますか？
承認基準：1. 50の既存の手動テストを完全に自動化されたテストに変換します2.テストは1時間未満で実行する必要があります
ソフトウェア開発プロセスをサポートする作業に「ユーザーストーリー」を使用することが理にかなっていて、プログラマーによって行われず、成果物コードが直接生成されない場合は、コミュニティから理解を得たいと思います。または、これを別の方法で処理/分類する必要がありますか（たとえば、JIRAで）？
2011年6月7日更新-「ユーザーストーリー」という用語に焦点を当てた質問に言い換え。
はい
あらゆる利害関係者、システムを改善するあらゆる機能
[純粋主義的な反対投票を始めましょう！]
「私の経営陣は、ソフトウェア以外の開発に関連するタスクを含め、すべてにアジャイルを使用したいと考えています。」
これはnotがすべての機能のユーザーストーリーを書くことを意味します。
すべての機能についてユーザーストーリーを記述したい場合、あなたは必然的にアジャイルではありません。すべての機能のユーザーストーリーを書いているだけです。
ユーザーストーリー！=アジャイル。
ユーザーストーリーは、要件を収集して理解する方法です。必要に応じて、完全に滝のように使用できます。一部の人々はこれを行います。
アジャイルはプロジェクトを管理する方法です。アジャイルプロジェクトでは、ユーザーストーリーを使用してもしなくてもかまいません。
技術的な負債と内部のタスクを管理するユーザーストーリーは、アジャイルであることとは何の関係もありません。
多くの人々は、純粋に内部的な、限定された付加価値のある非利害関係者向けの偽の「ユーザーストーリー」を書く時間を無駄にすることなく、「技術」または「サポート」機能をスプリントに追加することに完全に満足しています。
QAが彼らの話を理解しない場合、実際のビジネス損失はどのくらいありますか？
本当の利害関係者が彼らの話を理解しないならば、ビジネスは本当に苦しみます。
これは私には意味がありません。本質的に「ユーザーストーリー」とは、ユーザーストーリーであり、プロジェクトマネージャーストーリーではなく、開発者ストーリーでも、品質保証エンジニアストーリーでもありません。
そのノートでは、ソフトウェアは次のとおりです。
- 定義可能
- テスト可能
プロセスの改善は自由であり、通常は主観的です。
合格基準：1.テスト1の改善（x/yによる）
テストの改善をどのように測定しますか？そのための明確な契約はありません。
そして、無関係なメモで私はあなたの例が上に与えられたことを心から願っています、
テストマネージャーとして、自動テストのみを使用してアプリケーションのテストを実行し、手動テストは使用しないで、アプリケーションをできるだけ効率的にテストできますか？
...これはほんの一例です。これにはあまりにも多くの問題があるため、説明することすらできません。
Technical Debt はユーザーストーリーと同様の方法で処理できますが、場合によっては見苦しくなります。たとえば、「開発者として、他の変更が何かを壊すかどうかを検証するためのテストに自信を持つことができるように、ユニットテストを実行したい」というような話をするには、製品の所有者にとって大きな価値はありません。しかし、チームがスプリントでの作業の一部である独自のリファクタリングの一部として行うのは良い考えかもしれません。
タスクがシステムのエンドユーザーに表示されるものではなく、メンテナンスの改善とその所要時間に役立つ可能性があるため、ユーザーストーリーとは別のタスクを用意するのが好きですいくつかの新しい機能を開発します。一部のタスクは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がテストでテストの改善を示さない場合、誰も廃業することはありません。お金は失われません。
ユーザーがそもそもビジネスを行うことができない場合は、ビジネスから離れています。お金が失われます。操作全体が完全な失敗です。
内部（「鶏」）と実際の（「豚」）の利害関係者を混同しないでください。
「鶏と豚」のコメントは要点を逃している。内部の利害関係者は、開発中の製品の場合はニワトリですが（開発者向けに開発されている場合を除く）、開発プロセスの場合は豚です。
あなたが尋ねている質問は、文の式「として、私は_ができるようになりたいので、できます__ "は、改善のために新しいソフトウェアコードを記述する必要がないビジネスプロセスを定義および改善するのに役立ちます。同じことを考えてベストプラクティスを探しているため、このスレッドに出会いましたが、私の直感は、あなたの質問に対する答えが「はい」であるということです。文構造の目的は、ライターに、ユーザーがすでに考えているかもしれない解決策を抽象化し、ユーザー（この場合はプロセスユーザー）が実行できるようにしたいことに焦点を当てることを強制することです。ユーザーストーリーがプロセスに適用されたときに役に立たない理由はありません。
受け入れ基準に関するポイントは良いものですが、それについて独断的である必要はありません（とにかくアジャイルです）。 「プロセスの変更が目的を達成したかどうかをどのように知ることができますか？」その質問に答えるために常に自動テストを実行できるとは限らないのは事実ですが、それがユーザーストーリーをツールとして失格にする理由ではありません。