5

私はXPのバックグラウンドを持っています。私はそのプロセスをよく知っており、確かな実務経験があります。私はそれがソフトウェアを開発するための最良の方法であることに気づきました。

私はある種のプロセスドクターの立場にいることに気づき、これは私自身の理解の多くの自己検査と再評価を生み出します。

私がよく耳にするのは、一部の作品はストーリーにできないということです。私は個人的にこれを信じていません。言い訳には以下が含まれます

  1. 大きすぎます(開発者は5週間の終わりまで何も表示されません)。
  2. これは複雑なアルゴリズムまたは抽象的な概念です(作成には5週間かかり、表示には何もかかりません)。

この質問は、ヒント、ヒント、または提案を取得することです。

私は、これらおよび同様の認識された問題に対処する方法に関するヒント、ヒント、および提案を探しています(そしてあなたがそれらについて考えることができればもっと)。

ストーリーを書かないユーザー/開発者を回避する方法について最も多くの情報を持っている答えをマークし、その理由について多くの言い訳に対処します(私はほんの数例をリストしましたが、もっとたくさんあります)。

4

7 に答える 7

13

以下は、私が時間をかけて収集したいくつかのリソースであり、役立つ可能性があります。

大きすぎたり複雑すぎたりする場合でも、ストーリーをダイエットに取り入れる方法は常にあります (1 回の繰り返しで最終結果が得られない場合もありますが、できないというわけではありません。繰り返し)。

于 2009-11-11T15:57:38.527 に答える
10

基本的に、あなたの質問は「ユーザー ストーリーに対してタスクが大きすぎて分割できないと人々が主張する場合、どうすればよいですか。

私の経験では、ほとんどすべての問題を分割できます。簡略化されたバージョンを実装できるかどうか、高度な機能を省略できるかどうか、場合によってはデフォルト値を使用できるかどうかを尋ねます。基本的に、1 回の反復で意味のある (つまり、テスト可能な) 結果が得られるものを生成するためのものです。

覚えておいてください: 反復のポイントは、完全な機能を提供することではなく、有用でテスト可能な機能を提供することです。

この分割は難しい場合がありますが、最初に本当に必要なものを検討する必要があり、非常に価値があります。開発者はそれについて愚痴をこぼすかもしれません (私自身もしばしばそうします :-)) が、それは本当に必要なことです。大きなタスクを管理可能なユーザー ストーリーに分割することは、すべてのアジャイル手法の中心です。

とはいえ、タスクが本当に、本当に、本当に分解できない場合 (基礎を理解するのに数週間かかる研究環境の複雑な数学的アルゴリズムを考えてみてください)、反復は短すぎます。反復は、意味のある結果を生成するのに十分な長さである必要があります。そして、問題のほとんどが非常に難しく、何かを成し遂げるのに 2 ~ 3 か月かかる場合、それがイテレーションの長さになります。しかし、それが本当に当てはまるプロジェクトを見たことがありません...

于 2009-11-11T12:44:26.180 に答える
3

ストーリーを書かないユーザー/開発者

ユーザーはユーザー ストーリーを書くべきではありません。ユーザーストーリーを伝えることは想定されていません。彼らがどのように働いているか、彼らを悩ませている問題、そして日々の仕事を容易にするために何が欲しいかについて話すことを期待できます.

あなたは順番に、彼らの話を聞いてメモを取ることになっています。許可されている場合は、テープレコーダーまたはカメラを使用してください。次に、収集した情報を再生して再生し、ユーザー ストーリーと呼ぶものを識別します。それらについてチームと話し合い、合意が得られたら、開発で対象とするユースケースがあります。

開発者がどのような役割を果たすかは、あなた次第です。彼らが単なるコーダーである場合、彼らはプロセスに参加しません。彼らがコンサルタントとしての役割を果たしている場合は、ユーザー ストーリーの定義を支援します。

于 2009-11-11T11:26:23.133 に答える
3

通常、「大きすぎる」と言われた場合、彼らが実際に言っているのは「これがどのように機能するのか漠然とした考えしか持っていない」ということです。より簡単に管理できる論理的な部分に分割できるようになるまで、より適切に定義するために彼らと協力する必要があります。

于 2009-11-11T11:27:08.577 に答える
1

「アルゴリズム仕様」の問題はよくあることです。

多くの人はコードを書くことを好み、ユーザーが誰で何をするかはあまり気にしません。

これらの質問をすることで、彼らに集中してもらうようにしています。

  1. その人はどのような行動を取ることができますか?彼らはその情報で何ができるでしょうか? 何らかの責任がある場合は、拒否、承認、保留、拒否、再処理、停止、開始などのアクションを実行できます。ユーザーが何もできない場合は、本当に関係者かどうかを尋ねる必要があります。
  2. 彼らはどのような決定を下す必要がありますか? 実行するアクション (ある場合) をどのように決定しますか? その決定を自動化することはできませ
  3. この人物が行動を起こす決定を下すために必要な情報は何か。

情報決定アクション。

私たちは、人々が行動を起こすことができるように意思決定を行うための情報を準備するためのソフトウェアを作成するだけです。

それが焦点でない場合、ストーリーは制御不能になります。

于 2009-11-11T11:24:59.343 に答える
0

開発チームが、ストーリーが大きすぎてスプリントに収まらないと主張した場合は、彼らのフィードバックを受けて、ストーリーを必須タスクと素敵なタスクに分割し、それに基づいて分割してみてください。

このフローチャートを確認してください..参考になることがあります: http://www.agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

于 2014-01-17T19:42:18.283 に答える