製品所有者はユーザーストーリーをスクラムで書くべきだと思います。
ユーザーストーリーは、エンドユーザーの機能を説明しています。
しかし、誰が技術的に開発する必要があるのか、それをどのように実装する必要があるのかを説明します
スクラムに関する情報はどこに保存されていますか？
それは本当に私に興味があるでしょう！
開発者がストーリーを実装し始めたとき、私たちの会社には知識が非常に不足していますが、実装する方法がわかりません！
たとえば、従来のCOM APIを処理する必要があり、その処理方法がわからない場合や、WPF / WEBなどの技術的なスキルがない場合です。
スクラムは、ユーザーがユーザーストーリーから始めるのにどのように役立ちますか？
回答:
ここに非アジャイル嫌い。実装の詳細を公開し、実行する必要のあるタスクを決定することは、スプリント計画会議中に行われ、ユーザーストーリーがスプリントの実際のタスク/要件に変わります。多くのアジャイルプロセスの失敗は、スプリント計画会議が実際に開発者によって主に行われることになっているということです...それが単なる製品所有者である場合、彼らは月を得ることに決めます。ここで、次のような（やや曖昧な）ユーザーストーリーを思いつきます。
As a non-technical user, I need to have a simpler interface with the API
プロダクトオーナーがどのユーザーストーリーを最も優先するかを定義しますが、プログラマーはそれらの優先順位を取得し、タスクのリスト（スプリントバックログと呼ばれる）に変換します。これは、あなたが物事をどのように実装するかについてのアイデアを得る場所です...スプリントのバックログは、あなたが好きなだけ技術的である場合があります。これは、「より簡単なAPIを実現するために、そのクレイジーなCOM APIをリファクタリングする必要があります。誰もそれを使用する方法を知っていますか？」を見つける場所です。答えが「Hell No」の場合、そのユーザーストーリーの範囲が予想よりも大きい可能性があることがわかります。そのため、ユーザーストーリーをタスクに分割する必要があります。
このことを考えると、ユーザーストーリーをネゴシエートして、それらを小さな変更に分割しても構いません。アジャイルな方法論とは、その人が望むものに段階的に近づくことを意味します。したがって、「ちょっと見てください。APIを1回の反復でオーバーホールすることはできません。それを「非技術的な顧客として、十分に文書化されたAPIが必要です」などに分けましょう。
開発チームは技術的なことを書きます。スクラムは、技術的ブレークダウンに関しては少しだけ役立ちますが、あまり役に立ちません。ユーザーストーリーを始めましょう。スクラムはほとんどWhat-Worldのみです。技術的な内訳はHow-Worldです。
スクラムが提供する内訳は次のとおりです。
これに加えて人々がよく使用する内訳は次のとおりです。
さらに、チームは、実行する必要があることがわかっている（プロジェクトの開始時にIntelliJ IDEAをインストールする）ものの、ビジネス価値のない技術タスクを作成する場合があります。
作業を分解する方法の詳細なガイダンスについては、XP（Extreme Programming）、Clean Code、Pragmatic Programming、Software Engineering、CRC-Cards、OOP / OOA / OOD、Design Patterns、Refactoring、Legative Codeで効果的に作業する、TDD（テスト駆動開発）、BDD（動作駆動開発）、ATDD（受入テスト駆動開発）。
ありますどのような世界とどのように世界。あなたは正しく感じたとおり、ユーザーストーリーのためであるユーザー生成、ビジネスバリュー別名セカンダリ価値にどのような世界。スクラムは主にWhat-Worldのみです。How-Worldについてはほとんど何も言わず、基本的には「How-Worldは開発チームの責任」にすぎません。
通常、How-World用のバックログアイテムは、ユーザーストーリーではなく、テクニカルタスクまたはサブタスクと呼ばれます。多くのツールは、破壊することができ、ユーザーストーリーから何-世界にサブタスクでどのように世界。
Scrum for the How-Worldのヘルプは、スプリントプランニングミーティングのいくつかの時点で終了します。
Backlog Refinementミーティングまたは少なくともスプリントプランニングミーティングの第2部（一部のチームSprint Planning 2ミーティング）で、ユーザーストーリーをサブタスクに分類すると役立つことがわかりました。
経験の浅いチームの場合、バックログの改良とスプリントプランニング中にアトミックユーザーストーリーに取り組むことは有益だと感じました。アトミックユーザーストーリーは、ビジネスバリューを完全に失うことなく、さらに小さなユーザーストーリーに分解できないユーザーストーリーです。一般に、ユーザーストーリーはアトミックである必要はありません。経験の浅いチームで役立つことがわかりました。
そして、ユーザーストーリーとして「フィーチャーXの（アーキテクチャ|設計|実装|テスト）」を実行しないでください。これをサブタスクとして回避することをお勧めします。
アトミックユーザーストーリーがあり、それらが実装される承認基準以外にさらに詳細な分析が必要と思われる場合、それは何かが最適なレベルで機能していないことを意味します。アーキテクチャが間違っている/複雑すぎる、つまりビジネス指向ではなく技術的です。または、チームは未経験です。または両方。いずれにせよ、知識を訓練し、広めることにより状況を改善するための行動が必要です。
今日、スクラムマスターはほとんど管理職の役割として理解されており、それはでたらめです。もともと、スクラムマスターだった、と私はこれを提唱、技術的な役割だけのような、ない経営役割、コーチでXP。
ScrumはHow-Worldについてほとんど何も述べていないため、ScrumとScrum Masterに依存することは非常に簡単であり、大きなギャップに陥ります。
理想的には、スクラムマスターは、チーム内の全員が心から深く「検査と適応」を行い、スクラムマスターが冗長になるまで、十分な管理スキルとコミュニケーションスキルを備えた経験豊富な開発者の間で交代します。誰もがスクラムマスターになることはありません。
ただし、スクラムマスタリーは料理のようなものであり、テーブルの掃除や皿洗いのようなものではありません。誰もができるように、テーブルを掃除して皿を洗う人を交替したいと思うかもしれません。しかし、料理ができない人や料理が嫌いな人がいて、おいしいものを食べたいので、みんなに料理を回転させたくありません。
エキスパート開発者間でスクラムマスターをローテーションすることの良い点は、チームがより多くのメソッドについて学習する可能性が高いことです。
スクラムの観点から、チームは、理想的にはスクラムマスターの助けを借りて自分自身を見つけなければなりません。
スクラムは開発チームのことも話します。アーキテクトやリードエンジニアのような役割はスクラムには存在しません。それは彼らが禁止されていることを意味するのではなく、スクラムが彼らについて何も言わないことを意味するだけです。スクラムは自己組織化チームを宣言します。つまり、チームがアーキテクトを宣言した場合、チームにはアーキテクトがいます。これはスクラムでは定義されていませんが、スクラムに準拠しています。私は専任のアーキテクトを宣言していません（私は何年も指定されたアーキテクトとして働いていましたが、私はそれが好きでしたが、基本的には指定されたアーキテクトのアイデアに反対です）。
ユーザーストーリーには承認基準があります。これらの受入基準は受入試験に変わります
ブレークダウンのためのその他のもののリストについては、プログラミングプロジェクトを他の開発者向けのタスクに分割する方法を参照してください。
お役に立てれば。
チームで最も適格な人は誰でも、製品所有者からの要件を実用的なユーザーストーリーに分解する必要があります。私の経験では、次のアプローチを使用しました。
開発者がストーリーの実装方法を知らない場合、これらのケースのいずれかが当てはまる可能性があります。
あなたが自由のためのUdemyでSCRUM上でこのコースを受講し、SCRUMプロセスの個々の側面について学ぶことができます- https://www.udemy.com/scrum-methodology/
簡単な答えは次のとおりです。製品所有者は、チームが提供しなければならないストーリーを作成する責任があります。ストーリーの配信方法を決定するのはチームです。配信の一部に技術的なストーリーが含まれる場合、それらのストーリーを作成するのはチームです。その後、チームは製品所有者と協力して優先順位を決定します。
繰り返しますが、POは何を構築するかを決定し、チームはそれらのストーリーを実装する方法を決定します。
これはアジャイルの問題ではありません。問題は、チームがユーザーストーリー（アジャイル）または要件（トラディショナル）を完了するための十分な技術知識を持っていないことです。この状況でアジャイルは役立ちますか？いいえ、チームが慎重に選択されず、チーム内の誰もタスクを実行するのに十分な技術的経験がない場合。はい、チームメンバーの一部が他のチームメンバーがタスクを実行するのを支援できる優れた技術知識を持っている場合。そのためには、チームは自己組織化する必要があり、その長所と短所を知る必要があります。
次のアジャイルの原則を覚えておいてください。
「最高のアーキテクチャ、要件、および設計は、自己組織化チームから生まれます」
これは、アジャイル環境ではチームの信頼が高く、チーム間で作業を委任しているために発生します。