スクラムは柔軟なフレームワークであり、本格的な方法論ではないため、説明されている問題のほとんどが現れます。 これは、同時にその短所と利点です。 「バニラ」または「コーシャ」スクラムについては、サザーランドとシュワバーの公式の正式ガイドで簡単に説明されています。 「コーシャ」スクラムとは、ルールに従ってすべてを実行することですが、それはあまり美味しくなく、プロセス自体は喜びを与えません。 このような球形スクラムは理想的な真空でのみ機能しますが、適応させることは可能であり、そうすべきです。そのため、このフレームワーク自体が優れています。
バックログはどこから来ますか
製品のバックログは実際にはスクラムの主要な成果物ですが、実際には魔法のように表示されます。「要件を小さなユーザーストーリーに分割し、優先度順に並べ替える」とみんなが幸せになります。 実際には、2つのオプションがあります。プロジェクトによると、要件の完全なコレクションを実行する必要があるか、大規模でわかりにくいTKドキュメント（TK = HZ）があります。
どちらの場合も、要件を分析する必要があります。そのためには、次のプラクティスを使用すると非常に便利です。
- 人の分析（「ペルソナ」）
- 収納
個人分析の実践は、ユーザーエクスペリエンスの実践から製品管理にもたらされました。 作成された製品のユーザーを、特定の価値と目標を備えた実際のキャラクターとして説明することにあります。
ストーリーマッピングは、機能を視覚化して要件の完全性と検証を確認するための非常に便利な方法です。 視覚化はボード上で行われ、特定された人々の高レベルの活動から始まります。
アクティビティはタスクに分割され、タスクはサブタスクに分解されます。
サブタスクの最上層は、機能の可能な限り単純な実装であり、通常、最初のリリースに含まれています。 以下のサブタスクは、追加機能の実装です。 サブタスクに進むほど、重要度は低くなります。
ストーリーマッピング後（およびストーリー中）には、完全なバックログを実行してリリースを計画できます。 詳細については、 filippov のプレゼンテーションをご覧ください。
レガシーコードの変更を計画する方法
問題は、各開発者が自分のコードを知っており、通常、この知識をできるだけ深く持っている技術者がいることです。 通常、ソリューションは、個々のチームメンバー間の機能横断性を高めることです。
ここで最も簡単なツールは、チームメンバー間で知識を広めるのに役立つ次のエンジニアリングプラクティスです。
- コーディング標準
- コード共有
- ペアプログラミング/正式なコード検査
繰り返しますが、この問題に真正面から取り組む価値があります。まず、個々のメンバーではなく、チームのクロス機能性が重要です。
何がいい
開発者は、必要な機能から逸脱して、自分の観点からより高品質のシステムを提供する傾向があります。 ただし、開発者の品質基準は、ユーザーまたは顧客の品質基準と一致しない場合があります。
問題の説明を理解している限り、正式な品質パラメーターを規定する（規定するのではなく規定する）ユーザーストーリー（完了の定義）の完全性の基準を作成する必要があります：合格と単体テストの合格、テストのカバレッジ率、コード標準の遵守、正式なコード検査に合格する/ペアでコードを書くなど
等号の最初
開発者の生産性は本当に異なります...最悪なのは、それが時々ではなく、桁違いに異なることです。 この問題について簡単に説明すると、仕事の整理の問題と星の動機付けを解決するための次のオプションを提供できます（これはそれほど大きな問題ではないと思いますが）。
- キャリアアップ
- 同僚向けのトレーニング：メンタリングから社内イベントでの講演まで
- 会議への出席とスピーチ
- 野心的なタスク（時間、作業量、複雑さ、柔軟性の観点から）
注：私は究極の真実であるふりをしません。