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

正式なユーザーストーリースタイルに従います。 として<user>、私は<goal>そうしたいです<benefit>。 私たちのチームは、システムの所有者がユーザーにマイナスの影響を与える何かをしたいという要望がある場合、表現することに困難を感じました。 任意の例として、所有者がメールをチェックするたびにシステムが顧客に請求することを望んでいるとしましょう。 ユーザーストーリーの正式なスタイルに従って、次のように記述します。 顧客として、システム所有者が収入を増やすことができるように、メールをチェックするたびに請求されたいと思います。 明らかに、顧客は請求されることを望んでいません。物語は読みにくくなり、言語は事実を妨げています。 要件はどのように異なる形で記述できますか？

9 user-story 

私は、アジャイルソフトウェア開発アプローチを使用して、基本的な数独ゲームのユーザーストーリーを作成しようとしています。 ユーザーストーリーの背後にある概念を理解しましたが、理解を深めるための例を得ることができるのかと思っていました。 言うでしょう 私は数独の熱心なプレイヤーとして、さまざまな難易度で複数のレベルを持ちたいと思っています。 新しいプレーヤーとして、私は基本を教えてくれるゲームの紹介レベルが欲しいです。 ユーザーストーリーとしてカウントしますか？

8 agile  software  user-story 

私のチームは、次のプロジェクトでVisual Studio Team Servicesを使用します。アジャイルツールを使用すると、次のようにユーザーストーリーとタスクを階層的に整理できます。 エピック>機能>ユーザーストーリー>タスク/バグ 高校生とアドバイザーのためのStudent Org（クラブ）管理システムを設計しているとしましょう。学生とアドバイザーはクラブに参加したり、役員になったり、イベントを企画したり、お知らせを送信したりできます。 アナウンス機能を例に見てみましょう： ユーザーストーリー： 学生として、自分が所属しているクラブのお知らせを読んで、スケジュールの変更を認識したいと思っています。 アドバイザーとして、自分が所属しているクラブの告知を読んで、スケジュールの変更を認識したいと思っています。 アドバイザーとして、所属するクラブに通知を送信して、生徒がスケジュールの変更を認識できるようにしたい 管理者として、すべての学校のクラブにアナウンスを送信して、スケジュールの矛盾を認識させることができます。 等 これらが適切に記述されたユーザーストーリー（そうではない可能性があります）であると想定すると、開発チームとこれらの項目を開発タスクに分割するために座るときに混乱します。複数のユーザーストーリーの一部を単一の開発タスクでカバーできます。たとえば、お知らせのプロパティを定義するだけで、UIからDBまでのすべてのレイヤーのCRUDアクションを生成するツールがあります。したがって、いくつかの「送信」および「読み取り」ユーザーストーリーの部分は、単一の開発ステップで完了します。 私が読んだことから、各ユーザーストーリーは他のユーザーストーリーから独立している必要があり、それは理にかなっています。ただし、ユーザーストーリーのそれぞれが「UIとDBを生成する」タスクを共有しています。これは、この方法で（カスタマイズする前に）ベ​​ースレベルのUIを作成するためです。ユーザーストーリーごとに「UIとDBを生成する」タスクを書くべきではありません。冗長性が高すぎます。しかし、ユーザーストーリーを開始する前に完了する必要がある「UIとDBを生成する」タスクの記述方法がわかりません。 私の許可システムにも同様の混乱があります。Student、Adviser、Adminなどのさまざまなアカウントタイプがあり、すべて[お知らせ]ページにアクセスできますが、ページ内の機能は異なります（このアイデアは上記のユーザーストーリーでキャプチャしました）。アクセス許可システムを他の機能で使用できるようにモジュール化することもできますが、「モジュール化されたアクセス許可システム」を作成するタスクをどこに書き込むかわかりません。 このユーザーストーリー全体が混乱しているようです。はい、それはシステムの機能をキャプチャするのに最適ですが、開発タスクを通して考えるとなると、私はそれに頭を抱えているようには見えません。どんなアドバイスでもいいでしょう。 TL; DR：あるユーザーストーリーで行うプログラミングの一部は、他のユーザーストーリー（アクセス許可システムなど）のプロジェクトの他の場所で使用できます。この可能性を説明するために、ユーザーストーリーのタスクを作成/整理するにはどうすればよいですか？

8 agile  user-story  task-organization  task 

スプリントの真ん中にある毎日のスタンドアップミーティング中に、デファクトプロジェクトマネージャー/スクラムマスターは通常、開発者に次のバージョンを尋ねます。 「それで、これはいつ行われるのですか？」 「では、今日の午後4時までにこのタスクを完了させることはできますか？」 「このサブタスクには何時間残っていますか？」 これは率直に言って非常に迷惑であり、物事をより速く終わらせません。その結果、開発者は多くのプレッシャーにさらされていると感じることが多く、スタンドアップはコラボレーションよりも戦場のように感じることがよくあります。 開発者として、これを処理する確かな方法は何ですか？

8 agile  scrum  user-story  sdlc 

ユースケース（図ではなく説明について話している）と、要件を収集してより適切に整理するために使用されるユーザーストーリーの両方について聞いたことがあります。 私は一人で仕事をしているので、要件を整理し、開発で何をすべきかを理解するための最良の方法を見つけようとしています。巨大なドキュメントなどを扱う正式な方法論はありませんし、必要もありません。 私が製品バックログを作成するために使用されているように見えるユーザーストーリーには、開発で実行する必要があるすべてのものが含まれています。 一方、ユースケースは、システムでの処理方法、外部のアクターとシステム間の相互作用のフローの説明を提供します。 1つのユースケースに複数のユーザーストーリーがあるように思えます。 これは私に次の質問を導きます：要件を見つけるとき、最初に何をすべきですか？ユーザーストーリーを見つけて書いたり、ユースケースを見つけて書いたりしますか？それとも、何とかして「同時に」行う必要がありますか？ 私は実際にはかなり混乱しています。ユースケースとユーザーストーリーに関して、単独で作業する開発者にとって、より良い開発を行うためにこれらの方法論を正しく使用するには、良いワークフローとは何ですか？

8 agile  requirements  user-story  use-case 

ユーザーストーリーのバックログがあり、それぞれにストーリーポイントの推定数があるとします。今、スプリント計画を実行しています。 これで、ストーリーはタスクに分解されるはずであり、多くのスクラムリソースは、各タスクを人時間で推定する必要があることを示唆しています。この時点ではすべての質問についてチームが話し合っているため、タスクの見積もりに1分以上かかることはありません。ただし、タスクは1日より長くすべきではないため、8人の開発者による3週間のスプリントを想定すると、120タスクを意味し、見積もりにのみ2時間かかることは、私には少し多く思えます。 経験豊富なチームがタスクの見積もりをスキップまたはショートカットできることは知っていますが、まだその段階ではないとしましょう。 あなたの経験では、スプリントにはいくつのタスクがあり、それらすべてを推定するのにどれくらいの時間がかかりますか？（それらの半分だけを見積もることはあまり意味がありませんか？） 明確化： 答えはスプリントの長さとチームのサイズに依存するので、8人の開発者と3週間と仮定します。 言及された数値は経験則である可能性がありますが、それらがオフの場合（たとえば、より多くのタスク、それぞれを推定するために必要な時間の短縮）でも、推定には約2時間かかります。それで、おそらく質問は「計画会議の何パーセントが純粋なタスク推定のために予約されるべきであり、そして私たちがより良いことをすべきではないのか」であろう。

8 scrum  planning  user-story 

受け入れ基準に関するこのブログの投稿で、著者は適切な受け入れ基準は次のようでなければならないことを説明しています。 解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」） 実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは​​同じです） 比較的高いレベルである（すべての詳細が書面である必要はない） 次のような詳細： 列見出しは「バランス」です ローリングバランスの形式は99,999,999,999.9 D / CRです。 チェックボックスではなくドロップダウンを使用する必要があります チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります ただし、GUIテストを実行するためにCucumberまたは同様のフレームワークを使用することについて眉をひそめる人々をよく耳にします。さらに、内部ドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。 私はまだ、お客様との会話中にそのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。

8 agile  development-process  scrum  requirements  user-story 

私は、システムを介したユーザーワークフローなど、大きなユーザーストーリーを役立つ方法で分割するためのさまざまな手法を読んでいます。私が苦労しているのは、これらの小さなストーリーを実現するために次のステップを促進する場合、どのようにこれらの小さなストーリーを表現するかです。プロセスとユーザーへのアプリケーションの主な利点を提供していません。 たとえば、私の新しいシステムが3つの小さなストーリーに分割されている場合、 オンラインで新しいアカウントを作成する 新しいオンラインアカウントに対して特定のエンティティを作成する 私のモバイルデバイスにこれらのエンティティを私のアカウントに対してクエリさせ、それらに作用させる システムは、すべてのストーリーが完成したときにのみ、エンドユーザーに本当に役立つ機能を提供します。したがって、従来の「[ユーザーとして] [機能]で[メリット]を実現したい」とする場合、最初と2番目のストーリーのメリットは、後続のストーリーを促進するだけであり、ユーザーに主要な機能（叙事詩）。これはこれを行う正しい方法ですか？

8 agile  user-story 

私たちはスクラムワークフローを実装しており、ユーザーストーリー、つまり完了したとき、イテレーションなどに頭を回そうとしています。私たちがよく行うことの1つは、初期のイテレーション中にストーリーに取り組み、それを完全に機能させることですが、 "醜い"。プレーンなボタンを使用し、画像は使用せず、テキストのみを使用して、ボタンが適切に機能していることを示します。私たちはお客様を紹介し、その動作に満足していることを確認してから、通常は提供された画像を使用して、機能の設計を完成させ、完成させます。 この例では、機能的に完成したときにユーザーストーリーを完成させ、「ユーザーとしてxyzを視覚的に魅力的にしたい」という効果を示す2番目のユーザーストーリーを作成して、設計フェーズを処理しますか？または、設計要素を取得して完了できたら、ユーザーストーリーをプロジェクトの最初の反復から後の方に移動するだけでしょうか。その場合、最初の数回の反復で1つか2つのストーリーしか完了せず、最後の数回の反復でTONのストーリーを完了していることがわかります。 このシナリオをどのように処理しますか？

8 development-process  scrum  user-story 

構築したばかりの新しいプロジェクトバックログから2つのユーザーストーリーを達成しました（いい言葉ですか？）。これらはユーザー登録とパスワードのリセットで、どちらもメールが必要です。私が最初に選択したもの、および通常は信頼できるものが機能しなかったため、代替メールコンポーネントを実装する必要があります。メールコンポーネントのデバッグではなく、ユーザーストーリーの配信に重点を置いていたため、スプリントの最後に機能するコードを配信するためにそれを交換しました。メーラーの新しいサポート問題をログに記録しますか、それともこれらのストーリーをバックログに「再挿入」しますか？後者を実行する場合、ユーザーストーリーに技術の詳細をあまり紹介していませんか？

8 agile  development-process  scrum  user-story 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 6年前休業。 この図に遭遇し、これらの数値を確認するのに役立つ別のよく知られたソースがあるかどうか疑問に思いました。 正常に完了したスプリントについて分析したデータに基づいて、チームは1人のスプリントにつき1人のユーザーストーリー（実際にはあらゆる種類の製品バックログアイテム）を平均1〜1-1 / 2にする必要があると判断しました。 出典：Mike Cohnのブログ「毎日のスタンドアップは1人ずつですか、それとも1枚ずつですか？」

8 scrum  estimation  user-story