タグ付けされた質問 「user-story」

ユーザーストーリーは、アジャイルソフトウェア開発の中心的な概念の1つです。

15
ユーザーストーリーを推定する際に、マンデイではなくストーリーポイントを使用するのはなぜですか?
アジャイル手法(SCRUMなど)では、ユーザーストーリーに必要な複雑さ/労力はストーリーポイントで測定されます。ストーリーポイントは、チームが反復で取得できるユーザーストーリーの数を計算するために使用されます。 推定工数のように、具体的な測定値を使用できる抽象的な概念(ストーリーポイント)を導入する利点は何ですか?推定工数を使用して、速度を計算したり、反復のカバレッジを推定したりすることもできます。 対照的に、ストーリーポイントは使用するのが難しく(概念が抽象的であるため)、関係者に説明するのも困難です。どのような利点がありますか?

8
バグ修正タスクのストーリーポイント:スクラムに適していますか?
ストーリーポイントをバグ修正タスクに割り当てる必要があるかどうかだけを考えています。私たちの問題追跡ソフトウェアであるJIRAには、バグタイプの問題のストーリーポイントフィールドがありません(StoryおよびEpic専用です)。 ストーリーポイントフィールドの該当する問題タイプにバグ問題タイプを追加する必要がありますか?長所と短所は何ですか?スクラムに適しているでしょうか?
50 agile  scrum  bug  user-story 

8
ユーザーストーリーと要件
ユーザーストーリーは、ユーザーがシステムで何をしたいのかを高レベルでキャプチャします。ユーザーストーリーがさらに多くの低レベル要件を推進することを理解しています。ユーザーストーリーはシステムの高レベル要件と同じですか?

5
機能を共有するストーリーに対処する方法
私は2つの物語を持っています(私は彼らが利益部分を欠いていることを知っています) 与信管理ユーザーとして、Officeの現在と以前の給与の差異を表示できます。 与信管理ユーザーとして、Officeの現在と以前の給与の差異のPDFを含む電子メールを受信できます。 2つは、同じクエリ/フィルター基準を持つという点で関連しています。唯一の違いは、「表示」ストーリーでは結果がユーザーに表示され、「メール」ストーリーでは結果がPDFに書き込まれ、ユーザーにメールで送信されることです。 これらの2つのストーリーの共通の側面の分離に苦労しています。 たとえば、どちらも同じクエリを使用しますが、結果に対する処理は異なります。 クエリを純粋に技術的な別のストーリーに分離する必要がありますか? PDFの作成と電子メールの送信はオフラインで行う必要がありますが、それは技術的な話になりますか? これらの2つのストーリーを2つの機能的なストーリーと2つの技術的なストーリーに分けることができました。 システムとして、Officeの現在の給与と以前の給与の差を計算できます。 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いを確認できます。 システムとして、Officeの現在の給与と以前の給与の違いのPDFドキュメントを作成できます。 与信管理ユーザーとして、Officeの現在の給与と以前の給与の違いのPDFを含む電子メールの受信をリクエストできます。 私が戻ってくる問題は、4つのストーリーが独立しておらず、「ケーキをスライス」しないことです。 したがって、これら2つをどのように扱うかはよくわかりません。

8
スクラムでは、開発環境のセットアップや機能開発などのタスクを実際のユーザーストーリー内のサブタスクとして管理する必要がありますか?
プロジェクトでは、次のようなタスクに時間を費やす必要がある場合があります。 代替のフレームワークとツールの調査 プロジェクト用に選択されたフレームワークとツールの学習 サーバーとプロジェクトインフラストラクチャ(バージョン管理、ビルド環境、データベースなど)のセットアップ ユーザーストーリーを使用している場合、この作業はどこに行けばいいですか? 1つのオプションは、それらすべてを最初のユーザーストーリーの一部にすることです(たとえば、アプリケーションのホームページを作成します)。別のオプションは、これらのタスクを急増させることです。3番目のオプションは、タスクをユーザーストーリーではなく問題 / 障害(たとえば、まだ選択されていない開発環境)の一部にすることです。

5
アジャイルチームの要件ドキュメントをどのように追跡しますか?
ユーザーストーリーがアジャイルの世界を支配していることは理解していますが、これらのアーティファクトはどのように保存されるので、チームに参加する新しい開発者が要件に追いつくことができますか? ユーザーストーリーが後で変更された場合、どのように更新され、アーティファクトとして保持されますか?多くのチームが、元のストーリーを追跡するのではなく、新しいチケット/機能のリクエスト/バグレポートを開くだけを見てきました。

7
どのような電子的なユーザーストーリーマッピングツールをお勧めしますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 アジャイルソフトウェア開発は、ユーザーストーリーと呼ばれるワークアイテムタイプに大きく依存しています。たとえば、ユーザーストーリーでいっぱいのバックログがあり、それらのいくつかを選択して次のスプリントで作業することができます。 しかし、バックログに入れるユーザーストーリーをどこでどのように見つけますか?ストーリーマッピングと呼ばれる一般的な手法があります。ジェフパットンがそれを発明しました、そして、ここにそれをする方法に関する決定的なガイドがあります。 問題は、Pattonのストーリーマッピング手法をサポートする電子ツールは何ですか? 私は少し調査を行ったところ、Pivo​​talおよびRallyプラグインが見つかりましたが(どちらの顧客でもありません)、現在SilverStoriesを試しています。 他にどんなツールがありますか?何を使いましたか?あなたは何をお勧めしますか(しません)?どうして? 更新:コメントを書いた人の中には、この手法を電子ツールで適用することは単に不可能であるという答えに傾いているようであり、それを受け入れるべきです。誰かが答えとしてそれを書くことはできませんか? 更新(Alex Feinmanのコメントを踏まえて質問を明確にするため):質問は、ストーリーマッピングのオプションを識別することです。ジェフ・パットンのテクニックは、明らかにスティッキー付きのホワイトボードで実行できるため、質問は電子ツールで提供される可能性のある追加オプションに焦点を当てています。(未熟な)特定のツールまたはツールのクラスに対するコミットメントは、この質問のポイントではありません。

6
平均スプリントよりも50%悪い状況をどのように処理しますか?
スクラムを正しく理解していれば、次のスプリントでチームが引き受けることができる仕事を決定する方法は次のとおりです。 過去数回のスプリントで完了したポイントの数を平均します。 この量は平均速度です。次のスプリントでは、多くのストーリーポイントを取り上げます。 これは平均であるため、履歴が繰り返される場合、このスプリントは、ストーリーポイントが少なすぎる可能性が50%あり、ストーリーポイントが多すぎる可能性が50%あります。 50%のケースでは、できる限り多くのストーリーポイントを使用しました。 スプリントを完了できません。これは、スプリントのコミットメントを半分の時間で満たさないことを意味します。 追いつくために余分に働く。問題は、これが一方向にしかラチェットしないことです。スプリントを達成し、完了したストーリーポイントの数はそれを反映します。私たちは常に時間をかけて終了するので、私たちの平均は常に多くのストーリーポイントを達成し、遅れている点まで上昇傾向にあります。 平均速度とスプリントのコミットメントについての私の理解は正しいですか? もしそうなら、平均より遅れているスプリントの50%に対して何をすべきでしょうか? そうでない場合、何が間違っていますか?

5
スクラムは、ユーザーストーリーではなく製品バックログで技術仕様を使用できますか?
私が現在働いている会社では、スクラムプロジェクトを始めました。管理者に滝からスクラムに移行するよう説得することはそれほど難しくありませんでした。プラットフォームをゼロから再構築するプロジェクトを行っています。(ほとんどの)機能は既知であり、ほとんどの改善はかなり技術的です。 これでは、ユーザーストーリーではなく技術的なタスクを持つことを正当化できます。バックログには、次のようなあらゆる種類の技術的なタスクがあります。 MySQLからPostgreSQLにDBクラスを書き換えます。 システムロギングを実装します。 オブジェクトキャッシュを書き換えます。 スタンドアップ中に出てくるものには、長い「研究タスク」が必要であるが、決して実行されないことが含まれます。また、チームメンバーは、スプリントの途中で、計画外のタスクを追加する必要があると主張します。 スクラムマスターはこれにどのように対処する必要がありますか?この種のプロジェクトにとって、スクラムは進むべき道ではないのでしょうか?

3
ユニットテストを使用してストーリーを伝えるのは良い考えですか?
だから、私は少し前に書いた認証モジュールを持っています。今、私は自分のやり方のエラーを見、それのための単体テストを書いています。単体テストを書いている間、私は良い名前とテストする良い領域を思いつくのに苦労しています。例えば、私は次のようなものを持っています RequiresLogin_should_redirect_when_not_logged_in RequiresLogin_should_pass_through_when_logged_in Login_should_work_when_given_proper_credentials 個人的には、「適切」に見えても、少しthoughいと思います。また、テストをスキャンするだけでテストを区別するのに苦労しています(失敗したものを知るには、メソッド名を少なくとも2回読む必要があります) だから、機能を純粋にテストするテストを書く代わりに、シナリオをカバーするテストのセットを書くかもしれないと思った。 たとえば、これは私が思いついたテストスタブです: public class Authentication_Bill { public void Bill_has_no_account() { //assert username "bill" not in UserStore } public void Bill_attempts_to_post_comment_but_is_redirected_to_login() { //Calls RequiredLogin and should redirect to login page } public void Bill_creates_account() { //pretend the login page doubled as registration and he made an …


4
ドキュメントはユーザーストーリーですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 過去数回のスプリントで取り組んできた製品のユーザーマニュアルを作成する必要があります。現在、私たちは次のスプリントで新しいプロジェクトを開始しており、POは以前に作成された製品のドキュメントをこのスプリントのユーザーストーリーにしています。 このアプローチについてのあなたの意見を知りたいだけです。個人的には、ドキュメントはコードを生成しないため、スクラム内のユーザーストーリーであることに同意しません。 編集:ご意見ありがとうございます。私は頭の後ろで、スプリントが作業ソフトウェアの増分を実装することであると思っていましたが、あなたの意見は私の見通しを変えました。答えてくれてありがとう。
13 scrum  user-story 

5
複雑な処理を伴うアプリケーションにアジャイルをどのように適用できますか?
アジャイルに関する文献のほとんどは、ユーザーが舞台裏で何が起こっているかをかなり認識しているCRUDタイプのビジネスアプリケーションに偏っているようです。(書かれているコードのほとんどはおそらくこのクラスに属しているため、それは問題ありません。) このタイプのアプリケーションでは、ユーザーストーリー(要件)と開発タスクの関係はほとんど単純です。ユーザーストーリーをいくつかのタスクに分割するだけです。 しかし、ほとんどのコードがユーザーに直接見えない複雑な処理を処理しなければならない別のタイプのアプリケーションがあります。例は次のとおりです。 コンパイラー 自動運転車の画像解析システム 流体シミュレーションシステム ここでは、タスクとユーザーストーリーを関連付けるのが非常に難しくなる可能性があります。この問題を克服するためのテクニックはありますか、それを受け入れてそれを最大限に活用しなければならないのでしょうか?

5
プロジェクト開始時のアジャイルメソッドとデータベース
アジャイルは初めてで、どのように始めればいいのかわかりません。アイデアは、スプリントでプロジェクトの小さな部分を作成することです。しかし、私が取り組んでいるプロジェクトにはデータベースが必要であり、データベースはプロジェクトで何でもできるようにほぼ機能している必要があります。 それでは、アジャイルプロジェクトはこれをどのように処理しますか、データベースを作成することから始めますか? たとえば、Scrumを使用している場合、ユーザーストーリーをどのように行い、データベースをテストしますか。 コードを必要とするストーリーの中で、dbの一部を実行したいですか。 「ユーザーとして登録する必要があります...」というストーリーがあるとします。このストーリーの一部としてデータベースにユーザーテーブルを作成しますか? アジャイルは、データベースの設計にどのように役立ちますか?

5
「テクニカルユーザーストーリー」はスクラムで許可されていますか?
技術的なユーザーストーリーはスクラムで許可されていますか?もしそうなら、技術的なユーザーストーリーをスクラムで書くための標準テンプレートは何ですか?同じ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>。それで、どれが標準ですか? たとえば、次のようなユーザーストーリーがあります。 レビュー担当者として、ホテルや食べ物の写真をアップロードして、他のユーザーが見たり気に入ったりできるようにします ユーザーとして、写真のコメントを追加して、自分の意見をよりよく説明できるようにします これら両方のユーザーストーリーには、大きな技術項目があります-画像の保存と取得 次の説明とともに、「画像の保存と取得のメカニズム」というタイトルの技術的なストーリーを追加できますか? 開発者として、ユーザーが必要に応じて画像を追加/表示できるように、画像を保存および取得するメカニズムを開発したい

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.