「機能しない」ユーザーストーリーとしての建築原則[閉じた

Question

ユーザーストーリーの使用など、アジャイルプラクティスを導入するために、当社でパイロットプロジェクトを開始しようとしています。 Mike Cohnの2冊の本を読んだ後、特にアジャイルの推定と計画、ユーザーストーリーが適用された後、私は今、どのように進むべきかをより明確に考えています。私は、練習とともに私たちのテクニックを改良することに自信があります。

しかし、私を納得させないことが1つあります。 このブログ投稿で Mike Cohnは、特定のタイプのユーザーストーリーを定義します。これは制約と呼ばれ、いわゆる非機能要件を定義するために使用できます。個人的に私は言葉が好きではありません 制約 そして、「...、私は...、それを...」という古典的なテンプレートの使用でさえ。

むしろ、私は顧客に常にカードに書いてもらい、おそらく上記のテンプレートで、ニック・ロザンスキーとエオイン・ウッズが幻想的な本で呼んだものを書いてみます ソフトウェアシステムアーキテクチャ, 建築原則:

「建築原則は、建築の定義を導く信念、アプローチ、または意図の声明です。」

（彼らはまた、これらの原則を分割します ビジネス原則 と テクノロジーの原則, 、私たちが気にするべきではないと思う差別化。）

これらでやりたいこと 原則 カードは、ユーザーストーリーの定義と計画活動の間に常に存在させるために、バックログカードボードの隣に配置することです。また、顧客と開発者に、カードがチームのリマインダーとして役立つと考えるたびに、顧客と開発者が反復ボードの隣に置くことをお勧めします。

同様のアプローチを試したことはありますか？何らかの理由で落胆しますか？この問題について何か提案はありますか？

Answer 1

同様のアプローチを試したことはありますか？私はまったく似たようなことを試していませんが、私がチームのスクラムマスターだったとき、私たちはさまざまな検査ポイントと適応ポイント中に、私たちが思い出させたプロジェクトの広い建築ガイドラインとビジョン（すべてのチームが参加していました）を持っていました。スプリントとスクラムプロジェクトの、振り返り、スプリントの計画会議、さらには毎日のスクラム会議のように。私たちが思い出させるために使用したいくつかの方法は、建築ガイドラインに従うための1つの原則を含むタスクの完了基準を追加することであり、また、バックログに小さなメモとして追加される可能性があります。以下の私の提案では、これが本当に高いレベルからどのように見られたかについて言及しました。

何らかの理由で落胆しますか？まったくありません。私はあなたの提案が良いと言います、そしてあなたは計画会議のためにそれを試してみるべきです。そして、彼らのスクラムガイドでケン・シュワバーとジェフ・サザーランドが示唆したように、あなたはスプリントの3つのポイントの間に検査して適応する必要があります - 「スクラムでの検査と適応のために3つのポイントがあります。毎日のスクラム会議は、その進捗を検査するために使用されます。スプリントの目標、および翌勤務日の価値を最適化する適応を行うこと。さらに、スプリントのレビューと計画会議は、リリース目標に向けて進捗を検査し、次のスプリントの価値を最適化する適応を行うために使用されます。 Sprint Retrospectionは、過去のスプリントをレビューし、次のスプリントをより生産的で充実した、楽しいものにする適応を決定するために使用されます。」

この問題について何か提案はありますか？あなたの会社のこの「アジャイル」プロジェクトが始まったばかりであり、あなたはまだプロジェクトの堅実なビジョンセットを持っていないと仮定するのは安全ですか？はいの場合、2週間のプロジェクトワイドリリース計画ワークショップを手配することをお勧めします。このワークショップの目的は、すべての利害関係者、POS、SMS、プロジェクトマネージャーを単一の場所で獲得し、スーパーユーザーのストーリーとビジョンを開発することです。プロジェクトの目標の高レベルのビジョン。すでにこれを行っている場合は、この提案を無視してくださいが、これを持ち出す私のポイントは、高レベルのビジョンまたはスーパーユーザーストーリーがあなたの会社で設定された建築原則に従うことに言及する部分を持つことができる/すべきであるということです。

これの利点は？それは、ビジネスと技術的な側面の間のビジョンを十分に理解するのに役立つスーパーユーザーストーリーから、製品の建築的および技術的な側面に関与する利害関係者を獲得します。

私は自分のアイデアについてもフィードバックを得ることができるように、質問の範囲を超えて答えを拡張しようとしたかもしれません。

ありがとう、シド。

Answer 2

私はあなたが説明した方法でそれをやっています。カード（その他の色）に定義された制約があります。制約は、ユーザーストーリー形式ではなく、次のような単純な文として記述されます。

• システムは、30人のユーザーのピーク使用をサポートします。
• 輸入は毎日実行する必要があります。
• すべてのフィルターと検索結果は同じページにある必要があります。

顧客には、直接単一のユーザーストーリーではなく、より広範な効果がある特別な要件がある場合は、制約としてそれらを書きます。これらの制約は推定されておらず、製品バックログの一部ではありません。それらを使用して、実際のユーザーストーリーのいくつかの実装要件を思い出させます。

Answer 3

それが、今年1月に建築家工場で見た講演の主題でした。私はそれを追跡しました。それはリー・イングラムの「ビジネス駆動型のアーキテクチャ：現在のスタートアップからの例」でした。私はスライドを見つけることができませんが、彼は要件がどのように満たされるかを導く包括的な原則のアイデアについて話しました。

彼はマルチテナンシーや白録画のようなものを持っていました。マルチテナントWebサービスを使用すると、ユーザーの分離/分離を最初から計画する必要があります。同様に、サービスをホワイトラベルにしたい場合は、さらに多くのことを構成可能にする必要があります（スタイル、ラベルなど）。どちらもほぼすべての話に影響を与えます。

Answer 4

強くお勧めします ユーザーストーリーマッピングに関するジェフパットンのプレゼンテーション.

彼は、目的物語がどのようなもの（またはあなたが呼びたいものは何でも）の正確なメイクを明確にするだけでなく、ストーリー間の関係や依存関係を構築する方法、そしてそれらに対処する方法を明確にするだけではありません。

Answer 5

「原則」（または制約）のこの一般的な考え方は良いもののようです。私はこのクラスに本当にあるべきもの - 「システムはある程度の定量化されたレベルのパフォーマンスを達成する必要がある」 - バックログに投げ込まれ、他のすべての「特徴」ストーリーの中で失われたときに何が起こるかを見てきました。パフォーマンス（「大丈夫だ...どこかでストーリーがある」から）そして最終的に誰かがそれを拾うとき（奇妙なことに、これらのことは常に顧客に高い価値があるにもかかわらず）数日間は不可能なタスクが取得されると予想されており、おそらく、はるかに早く行われ、現在は大規模な再補充コストがあるはずのシステムの深刻な研究でのみ実際に達成できる可能性があります。