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

アジャイル開発プロセスでは通常、主な焦点はユーザーストーリーにありますが、1つの要件が複数のユーザーストーリーにまたがることもあります。 たとえば、クライアントはフォーラム内のすべてのユーザーの検索ページを要求する場合があり、ユーザーの禁止、ユーザーの削除、パスワードのリセットなど、ユーザーごとに実行できるアクションがいくつかあります。 この機能は、少なくとも4つのユーザーストーリーに分割できます。 ユーザーを検索 ユーザーを禁止 ユーザーを削除 パスワードを再設定する ユーザーインターフェイスデザイナーは、このようなユーザーインターフェイスをどのように実装しますか？彼/彼女は最初のユーザーストーリーに取り組み、それからUIへのより多くの機能を増やし始めるべきですか？ただし、最終的なUIは台無しになると思います！ 彼が機能全体（検索+アクション）で作業することに決めた場合、アクションの優先順位が低く、検索機能が実行された後に複数の反復が実装されるとしたらどうでしょうか。

11 web-development  agile  user-interface  user-story  user-experience 

私たちは、新しいプロジェクトを開始しようとしている5人の小さなグループです。これは、スクラムでオールインする最初のプロジェクトです。 プロジェクト（フレームワークなど）のベースをどのように確立するかについて、少し苦労しています。このようなタスクは、ユーザーが直接恩恵を受けるものではないため、ユーザーストーリーをどのように書くかを考えるのに苦労しています。 それで、一般に、フレームワークもベースライブラリも配置されていない状態でプロジェクトをゼロから開始する場合、スクラムをどのように使用しますか？

11 scrum  user-story  sprint 

ユーザーストーリーの迅速で汚い定義： "As a <role>, I want <goal/desire> so that <benefit>" この一般に受け入れられている定義では、ビジネスルール、制約、またはユーザー入力を定義するためのスペースがほとんどありません。 説明のための簡単な例： "As a <librarian>, I want to <register new books> so that <students can find their availability online>" このばかげた例では、本を登録するときに必要なフィールドをどこで定義しますか？どこにでも書かれるべきですか？または、必要なビジネスルールをプロダクトオーナーから口コミとして渡す必要がありますか？

11 business-rules  user-story 

私は、XPを実行するという真の意図を持つ非常に優れた会社で働いています。コミュニケーションは良好で、経営陣は建設的な議論を受け入れることができますが、差し迫った時間の制約があるため、RUPで議論することができないものもあると見なされています。 現時点では、ストーリーの実装中に必要となる変更の量に少し悩んでいます。これらの発見の多く（もちろん時間と労力がかかります）は、ストーリー作成者（顧客、エンドユーザー、製品所有者）の責任であり、開発者の責任ではないかと思います。簡単に言うと、ユーザーストーリーは概念的すぎて、根本的な意図を伝えているだけですが、十分な詳細（特に、前提条件と事後条件、他のストーリーとの関連性、依存関係など）が不足しています。開発者は、XPの開発者がデザイナーとアナリストを兼ねているため、独自の裁量で空白を埋めることが期待されています。問題は、これらの空白の多くが、最初の予想よりも複雑さが増していることに気付いてから、いくつかの誤った仮定が評価時間とコードに組み込まれた後に発見されることです。それでも適切な項目を見つけるには時間がかかります。これは、さまざまな程度で、初期の見積もりからの逸脱と見なされます。 私は、これらの影響を経営陣に伝える建設的な方法を探しています。不必要に物事を複雑にしようとしている人として私を装うような方法ではありません。私は新しいですが、まだ信頼性を確立していません。 あなたの洞察は大歓迎です。 密接に関連し、どういうわけか答えを与える：開発者はユーザーストーリーの詳細をどのくらい期待できますか？

10 user-story  extreme-programming  estimation 

現在、私の現在のプロジェクトではアジャイルメソッドを使用しており、次のような大量のストーリーがあります。 アシスタントとして、お客様に払い戻しを請求し、リクエスト時にお金をもらうことができるようにしたい 顧客として、私はアイテムを受け取ることができるように購入の代金を支払いたいです。 これまでに行った方法は、すべてのスプリントで最も重要なストーリーを選択し、それをいくつかの正式な要件仕様にまとめます（同じ仕様で似ているストーリーのいくつかをグループ化します）。ストーリーによっては、画面上のボタンまたはワークフロー全体の場合もあります。 問題は、ストーリーが多すぎるため、システムのどの部分にストーリーが関連しているかがすぐには明らかにならないことです。 それは開発者の時に機能し、すべてのスプリントは開発者が何をする必要があるか、そして彼らが行う必要がある変更を概説するスペックを取得します。しかし、このストーリーリストの維持とテストに関しては、バグの追跡が非常に難しくなり、一般的には仕様のみを維持することになります。これは、画面の機能の一部がさまざまな場所で文書化されているためです。ストーリーで分割。 ストーリーに基づいた仕様を書くことは良い考えですか？ストーリーを間違った方法で書きましたか？

10 agile  documentation  requirements  user-story 

ユーザーストーリーは次のような文で定義できます。 As a <type of user> I want <some goal> so that <some reason> 「ユーザーストーリーの公式」のGoogleと最初のリンクはすべて、この公式を提案しています。 私の質問はの目的が何であるか、であるので、その句？マネージャー向けですか？プロジェクト管理者と利害関係者がアイテムの優先順位をよりよく理解できるようにするためにありますか？なぜそこにあるのですか？ 注：私はas a <type of user> I want <some goal>数式を使用してきましたが、うまく機能します。より簡潔なこのフォーマットを実装しても、私の作業には問題がありません。

10 user-story 

バックエンド開発をユーザーストーリーに垂直に分割することを計画しました。しかし、私たちのチームのバックエンドの男は、これにより彼らの仕事が見えなくなると不平を言い始めました。 私の答えは スプリントの計画とレビューのミーティングでは、関係者の前でバックエンドのタスクについて話し合い、それが見えるようにします。 プロジェクト中に高品質を維持すると、他のチームよりも起動のペースが遅くなりますが、プロジェクト中は速度が安定します。そして、速度は利害関係者に非常によく見えます。 「開発者として、ビジネスロジックをカプセル化できるように、ドメインレイヤーを用意する必要があります。」 チームを汚染する前に問題を解決するにはどうすればよいですか？ 問題の根本は、私たちの経営陣が体系的にバックエンドの仕事を目に見えないものと見なし、支援された開発者の鉱夫やその他の軽蔑的な言葉を呼ぶことです。

10 agile  scrum  team  user-story 

スクラムでの役割は、プロダクトオーナー、スクラムマスター、およびスクラムチームです。ユーザーストーリーは、タスクと呼ばれる小さな部分に分解する必要もあります。タスクには、定義、割り当て、実装、フォローという4つのフェーズがあるようです。 タスクについてスクラムで誰が何をすべきか？タスクの残り時間を更新するのはスクラムマスターの責任ですか、それとも開発者（スクラムチーム）の責任ですか？開発者は自分にタスクを割り当てる必要がありますか、それとも製品の所有者が伴うスクラムマスターの責任ですか？

10 scrum  scrum-master  user-story  task 

ここで私は、比較的小さな新しいソフトウェア開発プロジェクトの範囲を定め、見積もっている最中です。私は、お客様から提案されたユーザーストーリーに目を通し、それぞれに対してタスクを配置しました。見積もりと、タスクがどのように達成されるかについての簡単なメモを付けました。受け入れ基準があります。すべては世界と良くなるべきです。 予定していた作品を見ていると、何か足りない部分があることに気づきました。機能を追加できるものをセットアップするだけの初期費用がかかります。特定の1つのユーザーストーリーではなく、すべてのユーザーストーリーに属するもの。 たとえば、このアプリケーションの一部は、XMLを解析するサービスです。ユーザーの観点から見ると、XMLの内容に応じてさまざまな処理を行う必要がある特定のストーリーがあります。実際にXMLパーサー（ファイルを探し、それを読み取り、内容をどうするかを決定する前に関連データを取り出すビット）を書くことは、これらすべてのストーリーの一部です。インストーラーなどを使用してWindowsサービスにラップする場合と同様です。これは、ユーザーに直接関係のない開発者中心のタスクです。 この特定のアプリケーションのもう1つの関連する例は、このアプリの機能に役立つ貧弱なレガシーコードのブロックを取得して書き換えることです。繰り返しますが、これはユーザーに直接の結果はありませんが、必要な作業です。ユーザーストーリーに焦点を当てたプロジェクト計画の中で、この作業の計画と実行はどこで「ライブ」ですか？ 「開発者として、私はしたい...」というユーザーストーリーを書いて人々がこれを解決するのを見てきましたが、他の場所で議論されているように、これはユーザーストーリーではありません。それは開発者のものです。 私（および他の人）がオンラインでTFSのような厳密な管理フレームワークを使用してプロジェクトを計画するのを助けるために、これに対する具体的な答えを探しています。これらは、「利害関係者の物語」や、計画会議でのスクラムチームによるインフラストラクチャタスクの説明への回答で言及されている他のあいまいなメタソリューションを作成する機能を備えていない傾向があります。

9 agile  team-foundation-server  planning  user-story 

当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定の種類のプロジェクトに特定の種類のソフトウェア（またはハードウェア）を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。Jiraプロジェクトを使用して特定のプロジェクトの問題をホストし、Jiraボードを使用して異なるチームのスプリントを実行します。 私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。 したがって、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング（週に1回）でレビュー、優先順位付け、推定され、将来のスプリントでは（プロジェクト固有の問題と共に）優先順位に従って取り組みます。 優先順位付けは問題を並べ替えることで行われ、並べ替えられた問題にsortedラベルを付けます（並べ替えられていない問題を検索できるようにするため）。次に、コアコンポーネントごとに1つの課題をバックログの先頭に手動で配置して、それらを最初に処理します。一部のチームがそのような問題をスプリントに入れる場合、代わりに別のアイテムをバックログの上部に手動でドラッグする必要があります。 これはかなりエラーが発生しやすいです。基本的に、私たちが持っているのは、「未解決」と「進行中」の間の「ソート済み」と「推定済み」の追加の問題ステータスです。これをsortedラベルとボード内での位置で反映することは、かなり面倒でエラーが発生しやすくなります。（たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、数週間前の広範なディスカッションでチームが決定した可能性がある問題の順序を静かにスクランブルします。） これを実装するより良い方法は何でしょうか？

9 agile  project-management  user-story  requirements-management  jira 

アジャイルアプローチはに仕事を構築することである垂直ユーザーストーリーと焦点を当てたが、完全にからのアプリケーションの一部を機能実現エンドツーエンド。これはソフトウェアを構築するための新しいアプローチなので、なぜこれが横長のストーリーよりも優れているかについて多くの文献を読みましたが、このアプローチの欠点についてはあまり知りません。 私はすでにアジャイルクールエイドを飲みましたが、ケーキを垂直にスライスすることは水平なスライスよりもはるかに優れていることに同意します。ここに私が思いつくかもしれない欠点の短いリストがあります： 開発者はストーリーの開発に必要なすべてのテクノロジー（UI +サービスレイヤー+データアクセス+ネットワーキングなど）を理解する必要があるため、最初は機能の実装に時間がかかる場合があります。 全体的なアーキテクチャ設計（アプリケーションのバックボーンをクレーティングする）はこのマントラに実際には適合しません（ただし、全体的なアーキテクチャを開発/変更することはユーザーストーリーの一部であると主張する人もいます） ユーザーストーリーを垂直にスライスすることのその他の欠点は何ですか？ 注：この質問をする理由は、チームに「垂直方向」のストーリーを書き始めるよう説得しようとするためであり、可能なトレードオフを事前に提示して、彼らが勝つことができるようにしたいのです。彼らが欠点に直面しているとき、アプローチを失敗とは考えないでください。

9 agile  user-story 

プロトタイプのネイティブモバイルアプリ（最初はiOSとAndroid）、およびこれらのアプリが通信するためのWebベースの管理インターフェイスとAPIの開発を伴うプロジェクトに着手しようとしています。既に作成されたストーリーのリストがありますが、それらの多くは次の形式になっています。 As a mobile user I want to be able to view a login screen so that I can sign into the app これが単一のプラットフォームを対象にしている場合、問題は発生しません。ただし、複数のプラットフォームを対象としているため、これらを「Androidユーザーとして」などに複製する必要があるかどうかは不明です。これは重複のように見えますが、プラットフォームごとに個別に完了する必要がある作業です。 これは、私たちがネイティブに行った最初のモバイルプロジェクトです。以前はPhonegapで、すべてのストーリーを「モバイルユーザーとして」にまとめました。これは本質的にネイティブコードでラップされたWebベースのアプリだったので、それほど問題にはなりませんでしたが、完全にネイティブなアプリは別の球技だと私は意識しています。

9 agile  mobile  user-story 

ユーザーストーリーを採用して、重いSRS（ソフトウェア要件の仕様）ではなく、軽量な方法で利害関係者の「意図」を捉えることを計画しています。ただし、彼らはストーリーの価値を理解していますが、すべての属性、優先度、入力、出力、ソース、宛先などを備えたSRSのような言語にストーリーを「変換」したいという要望がまだあるようです。 ユーザーストーリーは、アーティファクトのような正式なSRSの必要性を "排除"するため、SRSを持つことのポイントは何ですか？システムの機能要件を取得するためにユーザーストーリーを採用した場合、SRSは「排除」されることを私のチーム（ちなみに、教育と実践の両方で非常に有能なCSスタッフ）にどのように説得する必要がありますか？（NFRなどもキャプチャできますが、それは質問の意図ではありません）。 だからここに私の「ワークフロー」の引数があります：ユーザーストーリーとして初期要件をキャプチャし、後でユースケースにそれらを詳しく説明します（これは低レベルでドキュメント化する必要がある、つまりUIプロトタイプ/モックアップとの相互作用を説明し、成果物です）展開）。したがって、ユーザーストーリーからユースケースへと移行するのではなく、ユーザーストーリーからSRSへと移行します。 現在、職場でユーザーストーリーをキャプチャしている場合（ある場合）、ユーザーストーリーが存在する場合にSRSが存在しないことを「主張する」ことをどのように提案しますか？

9 agile  requirements  user-story  requirements-management 

最初のスプリントのストーリーを発見したときに、執筆を中止して前に進むタイミングをどのようにして知っていますか？ 私は知っている数人に尋ねましたが、基本的に私が得た反応は、プロジェクトが存在するコンテキストとプロジェクト全体のタイムボックス化の方法にも依存します。 ユーザーストーリーの作成をいつ停止するかを知るための標準的な方法はありますか。その場合、その根拠は何ですか。また、それは将来のスプリントにどのように適用されますか？

9 scrum  user-story 

私のマネージャーがチームに「今から成功したユーザーストーリーは評価の対象となるでしょう！」 と言ったとき 私たちはショックを受けてそこに座っていましたが、それは彼が私たちに与えたいくつかのあごを落とす瞬間の1つでした:-) これはアジャイル開発方法論のすべての概念と目標を台無しにするので、それは愚かな考えだと感じました。 みなさんの考えを教えてください。そして、どうすれば彼を説得できますか？

9 agile  scrum  productivity  user-story