7

私はより組織化された方法で作業しようとしており、ユーザー ストーリーの採用を開始しました。

技術的なものにユーザー ストーリーをどのように使用すればよいかについて、私は誤解していると思います。

Google で特定のキーワードに対するサイトのランキングを表示するアプリをコーディングしているとします。

ユーザーストーリーは次のようになります。

インターネット マーケターとして、
自分の Web サイトがキーワードのどこにランク付けされて
いるかを知りたいので、自分の SEO の取り組みが効果的かどうかを知りたい

これは非常に簡単で、ユーザー中心です...しかし、プロキシをループに導入する必要がある場合はどうなりますか。

一方では、プロキシは技術的な実装の詳細であり、他方では、プロキシはインターネット マーケティング担当者のドメインの一部です。

そのような物語をどのように作成すればよいですか?

インターネット マーケティング担当者として、
Google で検索するときにプロキシを使用したいので、
Google にブロックされることなく、多くのキーワードをチェックできます。

上記のシナリオは私には適切に聞こえません...次のように書き直すことができるかもしれません:

インターネット マーケターとして、
一度に多くのキーワードをチェックできるようにしたいので、時間の
節約になります

これはより正しいように聞こえますが、どのような受け入れ基準を与えることができますか? Google を 1 分間に 100 回スクレイピングしてみませんか? 時間の無駄じゃない?

これが別のシナリオです。30 秒に 1 回プロキシを使用できる機能を実装したい場合、ユーザー ストーリーはどのように作成すればよいですか? ユーザー中心の観点からこの問題にアプローチする方法がわかりません...

私がやろうと思ったもう一つのことは、別のものを提示することRoleです. を中心とするのではInternet Marketerなく、 という役割があると言えますGoogle ScraperInternet Marketerと関係していると言えGoogle Scraperます。

これで、次のようなユーザー ストーリーを書くことができます。

Google Scraper として
、検索ごとにプロキシを変更したい
ので、Google に禁止されません

上記のような技術的な実装の詳細にアプローチすることについてどう思いますか? また、システムをモジュールに分割するのにも役立ちます...

4

2 に答える 2

2

ユーザー ストーリーには、技術的な詳細を含めないでください。スプリント計画中、技術的な詳細は、ユーザー ストーリーの下にネストされたデリバリー チームのタスクとして追加する必要があります。これらのタスクは、配信チームによる議論を通じて作成する必要があります。すべての実装の詳細を太陽の下で文書化しようとするべきではありません。詳細はコーディングの開始時に変更される可能性があるため、各ユーザー ストーリーの実装の詳細 (タスク) の 60 ~ 75% をカバーすることを目指します。コーディング中に開発者が発見した追加の詳細は、毎日のスタンドアップ中に簡単に共有および文書化できます。デリバリー / 開発チームがストーリーの詳細をネストされたタスクとして具体化する一方で、ユーザー ストーリーは単純で非技術的なものにすることができます。これらのタスクは、統合開発環境 (IDE) を通じて開発者に表示される必要があります。

于 2017-01-08T07:59:44.220 に答える