ドキュメントはユーザーストーリーですか？
過去数回のスプリントのために取り組んできた製品について、ユーザードキュメントを作成する必要があります。現在、次のスプリントで新しいプロジェクトを開始しており、POは以前に作成された製品のドキュメントをこのスプリントのユーザーストーリーにしています。
私はこのアプローチについてのあなたの意見を考えているところです。個人的には、ドキュメントがコードを生成しないため、ドキュメントがスクラム内のユーザーストーリーであることに同意しません。
編集：ご意見ありがとうございます。スプリントが機能するソフトウェアの増分を実装することであることが頭の後ろにありましたが、あなたの見方は私のOutlookを変えました。たくさんのご回答ありがとうございます。
「Xのユーザーとして、私はXがどのように機能するかを知る必要があります」というのは、私にとっては正当なユーザーストーリーのようです。これにより、文書やオンラインヘルプが作成される場合があります。
ポイントは単なるコードではなく、ユーザーの要件を満たしています。
理想的には、ドキュメントはすべてのユーザーストーリーの一部であり、蓄積されることはありません。しかし、現実の世界では、それはしばしば起こりません。その場合、特定の不足しているドキュメントに追いつくためのユーザーストーリーを作成する必要があります。
そうです、コードは生成されません。ただし、これはユーザーの要件を満たしているため、他のユーザーの要件よりも優先する必要があります。
これが決して行われないことを意味する場合、これとその機能が処理されているため、おそらくそれほど必要なドキュメントは必要なかったでしょう。
要件、技術文書、またはプロジェクト文書に関するpdrの文書評価に同意します。理想的には、スプリント作業に組み込む必要があります。
製品ドキュメントは実際のユーザーが要求した成果物であり、ユーザーに直接価値を提供するため、非常に異なると感じます。もちろん、これは製品ドキュメントは本質的に技術的タスクであるnotであり、機能的タスクであり、プロジェクトの技術リソースにとって適切なアクティビティである場合とそうでない場合があることを理解する必要があります。
ユーザーストーリーと思いますが、これらのタスクには、ビジネス要件、ユーザーの視点、優れたテクニカルライティングスキルを十分に理解しているプロジェクトリソースを割り当てるべきだと思います。理想的には、これが利用可能な場合はビジネスアナリスト、または要件、ユーザーストーリー、優れたテクニカルライティングスキルを十分に理解している高次QAテスターであることが理想的です。これも開発者である可能性がありますが、開発者が作成した製品ドキュメントは、通常、開発者が技術的な詳細に近すぎるため、高品質または有用であるとは言えません。
私たちの組織では、継続的インテグレーションシステムの維持と強化を担当するツールチームが、スクラムを使用して作業の管理を支援しています。彼らはコードを書いていませんが、それでもスクラムを実践しています。
具体的にお客様の質問にお答えするために、ドキュメントが「完了の定義」の一部であるとチームが考えるかどうかを尋ねます。
ドキュメントが「完了の定義」の一部であるとチームが考える場合、追加のストーリーは必要なく、ドキュメントが書かれて検証されない限り、ストーリーは受け入れられません。
ドキュメントが「完了の定義」の一部ではないとチームが考える場合、プロダクトオーナーが作業を管理できるように、別のストーリーを作成します。