アジャイルの原則、特にスクラムの原則と XP のようなユーザー ストーリーを開発プロセスに適用しようとしているときに、アーキテクチャに関する問題に直面しました。
私たちはまだアーキテクチャ中心の開発に結び付きすぎているかもしれませんが、アジャイル モデリングの原則と組み合わせて、強力なコンポーネント ベースの開発を維持しようとしています。私たちの目標は、開発中に進化しやすい小さなデザインを前もって用意することです。
私が探しているのは、私のアーキテクチャとその内部のコンポーネントに関するバックログのストーリーに入れることができるものです: 使用の話だけでなく、開発の話です。システム ストーリーは別の種類のユーザー ストーリーである可能性があります。これは、厳密にはビジネス価値に関連するものではなく、システムのアーキテクチャと品質の問題に関連するものです。
編集： 「開発者の話」に関するオールボー大学のこの研究 を見つけました。
経験、アイデア、または反対はありますか?
前もって感謝します！(これは私の最初の質問です! :D)
IMOのバックログには、開発者のストーリーを含めるべきではありません。プロダクトオーナーがビジネス機能と一緒にこれらを賢明に優先する方法はありません。そして、プロダクトオーナーがそれらの1つを重要でないと見なし、それをバックログから引き出した場合はどうなりますか？その後、チームがストーリーを維持することを主張すると、バックログの所有権が不明確になる状況になります。
ただし、チームはプロジェクトの早い段階でアーキテクチャを構築する必要があると確信しています。私のプロジェクトの問題の1つは、最初の数スプリントの機能に重点を置きすぎたことです。
「建築債務」（技術的債務と同様）を、インフラストラクチャとアーキテクチャの構築に費やす必要のある時間として考えてみましょう。技術的負債（ゼロから始まり、チームが適切なリファクタリングなしで機能を生成するにつれて蓄積する）とは異なり、チームはアーキテクチャ上の負債から始めて、それを減らすために取り組む必要があります。アーキテクチャの負債を減らすために費やされる時間は、機能の作成に費やされる時間が少なくなることを意味します。つまり、チームの速度が低下し、スプリントの出力が減少します。このように、建築債務は技術的債務に似ています。現在のアーキテクチャに適合しない要件が発生した場合、アーキテクチャの負債のレベルは増加します。
チームは、時間をどのように使うかを決定する（そしてプロダクトオーナーに正当化できる）必要があることを覚えておいてください。そして、彼らは自分たちの努力を機能性、技術的負債、建築的負債の間で適切と思われるように分割することができます。
ただし、アーキテクチャの作業は機能によって推進される必要があります。言い換えれば、チームは特定のユーザーストーリーをサポートおよび有効化するためのインフラストラクチャを構築する必要があります。彼らがそれが将来役立つと思っているという理由だけではありません。YAGNIの原則はそのようなアプローチに適用されます。
ここでの私の答えが当てはまります。
アーキテクチャに関する作業と、より機能に特化した作業とのバランスは非常に難しいものです。技術的にはどちらも有効なアプローチであり機能しますが、ある程度の使用可能な製品 (スプリントの結果) を遅らせるほど、適切な製品 (ユーザー要件、パフォーマンス要件など) を構築していないというリスクが大きくなります。システムレベルのテストを実行して製品が機能することを証明し、製品の価値と方向性を利害関係者に示すことができるようになるまで、できるだけ早く到達してください。
私たちのチームでは、これを「IT カード」と呼んでいます。これは、「開発者として、xyz コンポーネントをリファクタリングしたくありません。メンテナンス コストを削減し、柔軟性を高めるためです。」という形式のカードです。
チーム メンバーは、優先順位付けされたバックログから「機能カード」を取り出すのではなく、重要と思われる IT カードを自由に選択できます。
このアプローチは、技術的負債を許容レベルに維持し、健全なペースでイノベーションを実現するために、かなりうまく機能すると思います。
ただし、システムを再構築する手段としては、やや欠けていることがわかりました。フィーチャー作成フローからの長い逸脱を正当化するのは困難です。
これを書いているとき、ストーリーをテーマにすることで建築にアプローチできるのではないかと考えています。エピックでアーキテクチャの目標を特定し、焦点を当てるべきテーマに分解します。
他のすべてのコンポーネントの「ユーザー」ストーリーからプラグを抜いてメンバーシップ コンポーネントをテストできることを確認するのと同じくらい簡単です。そのような実装。
これは通常、「ドメイン モデルは負荷分散下の別のデータセンターで実行する必要がある」などのように、機能以外の要件をバックログに入れる方法です。
開発者のストーリーを取り上げるのに役立つレンズの 1 つは、特定のストーリーの「ユーザー」が誰であるかを考えることです。社外の人が見るような機能を書いていないからといって、その作業のユーザーがいないわけではありません。廊下でチームのためにコードを書いているかもしれません。場合によっては、ユーザーはあなた自身です。これは、開発者のストーリーの場合によくあります。「私は開発者として、新しい機能を簡単に追加できるスケーラブルなアーキテクチャを持っている」と考えてください。特定のユーザーを呼び出すことで、製品の所有者は誰がストーリーの価値を理解するかについての洞察を得ることができます。また、「なぜ」を指摘することも、ストーリーが達成しようとしているメリットを伝えるのに役立ちます。他の人が述べたように、バックログの管理は、プロダクト オーナーとチーム間の交渉に帰着します。そしていつものように、プロセスのドグマに関係なく、チームにとって何が最善かを考え出す必要があります。すべてのチームには異なる状況があり、あるチームでうまく機能するアイデアが別のチームに反映されるとは限りません。