スクラムの測定単位がユーザー ストーリーの場合:
非機能要件をどのように考慮に入れますか? 私がもっと興味を持っているのは、インフラストラクチャですか?
私が選んだフレームワークでは、時間の約 50% がモジュールの構成、テンプレートの作成などに費やされています...
これらの要件はスクラムでどのように機能しますか? ユーザー ストーリーの言い方:
すべての条件下でのユーザーとして、出力が太字になることを期待しています?!? :)
複雑な Web アプリの各タイプの要件は、それぞれ異なる方法で計画および実行されると思います...
経験談や意見は？
ユーザー ストーリーとタスクを混同しています。
ユーザーストーリーは、開発される機能です。それを見積もるために使用されるストーリー ポイントは、1 つの測定単位を表し、機能間で見積もられた工数を比較する広範な手段です。ただし、機能を開発する段階になると、スプリント計画会議でタスクに分解されます。時間を使用して、スプリント バックログのタスク期間を見積もります。
したがって、ユーザー ストーリーは測定単位ではありません。これは機能であり、その機能を開発するためのすべてのタスクで構成されています。これらのタスクには、モジュールの構成、テンプレートの作成、コードの作成、単体テストの作成、機能のテストなどが含まれます。Done の定義にあるものは何でも。
「ユーザーとして、自分の株のティッカー シンボルと価格を強調して、他の株と区別できるようにしたい」というような話があるかもしれません。これは、ユーザーが何を望んでいるかを説明するためにユーザー用語で定義された機能です。
あなたが挙げた例はタスクなので、それをストーリーに変えることはありません。ただし、そのストーリーを展開するために実行する必要があるタスクの 1 つとして、それは完全に理にかなっています。
したがって、基本的に、ユーザー ストーリーは、ユーザーがアプリケーションで実行したいすべての機能を表し、ストーリー ポイントで見積もられます (プロジェクト全体で再見積される可能性があります)。そのユーザー ストーリーが開発されるスプリントの時期になると、それは必要なタスクに分解され、時間単位で見積もられます。
それが役立つことを願っています。