プロジェクトのドキュメント?という質問への回答では? 、Chris Ballance さんは、"ユーザー ストーリー" と "バーンダウン チャート" が、開発者にとって最も役立つ 2 つのタイプのプロジェクト ドキュメントであると答えました。
私の質問は、これらの種類のドキュメントの良い例を知っていますか (たとえば、インターネットや本で)。
可能であれば、次のような多くの例をご覧いただければ幸いです。
これは Google にとって簡単なトピックではないと思います。それについて書かれていることはたくさんありますが、それを示すデモはほとんどありません。
これらの質問の両方について、Alistair Cockburn の Web サイトをスキャンするよりもはるかに悪い結果になる可能性があると思います。特に、彼はバーンダウン チャートとそれらを生成するいくつかの異なる方法に関する素晴らしい記事を持っています。
http://alistair.cockburn.us/Earned-value+and+burn+charts
（ただし、マイク・コーンの作品に対する以前のポスターの推奨事項を繰り返します）。
秘訣の 1 つは、プロジェクトに適したドキュメントの種類を決定することです。多くの開発者が時間と空間に分散していますか? より大きく、より重く、より詳細なストーリーが必要になります。1 人か 2 人の開発者が同じ場所で働いていますか? 軽いもので逃げることができます。チームはそのシステム (レガシーの場合) で長い間働いていますか? 軽い話はおそらくうまくいきます。チームはそのシステムを初めて使用しますか?それともビジネス要件が複雑ですか? これにより、より詳細な方向に進むことができます。
あなたが小規模の多くの定義のいずれかによる「小規模」プロジェクトに参加している場合は、非常に軽いストーリーで問題ないかもしれません。コックバーンのサイトからの例を次に示します。
http://alistair.cockburn.us/Examples+of+ultra-light+use+cases
数か月前、機能の開発と同時にユーザー ドキュメントの作成を開始しました。テクニカル ライターは、各スクラム チームに割り当てられます。
開発中にユーザー ドキュメントを作成しなければならないことは、設計の検証に役立ちます。テクニカルライターもアプリの設計に参加。
これは、リリース バーンダウンとスプリント バーンダウンに追加されます。
プロダクト オーナーとのコミュニケーションが有用であるとチームが判断した場合、追加のドキュメントがチームによって作成されます。より良いユーザー ストーリーを書く方法を学んでいるので、これはあまり重要ではなくなりました。