機能要件の欠如は俊敏ですか？

今日、誰もが機敏になりたいと思っています。私が一緒に働いたすべてのチームで、アジャイルの形は異なっていました。いくつかのことは一般的です-毎日のスタンドアップや計画などですが、他の部分は大幅に異なります。

私の現在のチームには、気になることが1つあります。それは機能要件の欠如です。書面による期待が存在しないだけでなく、タスクでは、何を実行する必要があるかが漠然と定義されています。

プロジェクトの目標は、新しいテクノロジーを使用して古いシステムを書き換えることです。古いシステムにも適切なドキュメントはありません。確かに最新のものは存在しません。事業主の要件の説明は、以前と同じように新しい実装で実行しましょう。それは合理的に思えますが、そうではありません。古いシステムは一種のスパゲッティコードであり、そこからビジネス要件を抽出するにはコストがかかります。状況は計画に悪影響を及ぼしているようです。確かに、新しい実装では間違いやバグが発生しやすい（詳細は省略）。

したがって、私は考えています-古いシステムを書き換える場合にビジネス要件がないことは本当に俊敏ですか？

機能要件の欠如が機敏であるかどうかにかかわらず、それは災害のレシピです。そのシステムがどのように機能するかわからない場合、システムを再構築することはできません。

古いシステムがどのように機能するかわからないことを事業主に伝える必要があります。

最善のオプションは、ビジネスオーナーまたは数人の経験豊富なユーザーと協力して、現場でのビジネスプロセスを理解し、独自の受け入れテストを開発することです。一部のエンドユーザーと協力できる場合は、古いシステムのしくみに関するフィードバックが増える可能性があります。

それができない場合は、独自の要件を収集するために、非実稼働環境でいくつかの探索的テストを行う必要があります。多くの場合、ビジネスオーナーが「古いもののように機能させる」と言うと、時間どおりに制約され、ビジネスオーナーのように手助けすることができません。古いシステムがどのように機能するかを理解するには、一部の熟練したユーザーの専門知識、または完全な多数の手動テストが必要です。

要件の欠如と古いシステムの理解により、システムの再構築にかかる時間が大幅に増加することを事業主に知らせてください—約3倍以上の時間です。タイムラインとコストの増加に直面して、ビジネスオーナーは、要件をより迅速に収集するために必要な専門知識を提供するか、現時点では書き換えを経済的に実行できないと判断します。

次のいずれかが表示されます。

• 適切な要件とより速い開発サイクル
• 要件を収集してソフトウェアを再構築する時間
• キャリアのブラックマークにならない新しいプロジェクト

アジャイルは機能要件の必要性を変更しませんが、一般的にそれらを収集する方法を変更します。非アジャイルな方法は、誰かが長いプロセスを経て、システムのすべての要件を含む何らかのドキュメントを提供することです。

要件を収集するための俊敏な方法は、一緒に作業してシステムの小さな増分の要件を指定し、それを構築してからフィードバックを得て、次の増分を実行することです。ビジネスオーナーにプロセスを開始させるのに問題がある場合、まず半日かけて、次に作業する古いシステムの部分を調査し、要件に関する質問のリストを生成します。

次に、ビジネスオーナーと一緒に座って質問します。簡単に答えられる質問もあれば、コードを見れば簡単に答えられる質問もあれば、どちらにしても答えにくい質問もあります。解くことができる何かに到達するまで、難しい質問をどんどん小さくしてください。

目標は、何かを構築し、フィードバックを得て、プロセスを再開するために、十分な質問に答えることです。変更が小さく、フィードバックサイクルが短いほど、間違ったものを構築した場合の大したことは少なくなります。

要件の取得は、（成功した）ソフトウェアプロジェクトの重要な部分です。しかし、要求仕様を書くことはそうではありません。

• ドキュメント中心のアプローチは、中国のささやきのゲームのように終わる可能性があります：専門家が要件を表明し、アナリストがそれを書き留め、開発者がアナリストの説明と一致するものを書き込もうとすると、ソフトウェアが原因でエンドユーザーが混乱する彼らの問題を解決しない。

  アジャイル技術は、開発者が主題の専門家、通常はエンドユーザーから直接要件を収集することを提案しています。これを行うには、さまざまな手法があります。たとえば、SMEとシナリオ例を話し合うことです。開発者は、エッジケースを特定し、そのエッジケースでのソフトウェアの動作を明確にするようSMEに依頼するのが得意です。

• アジャイルチームは、すべての要件を事前に収集するのではなく（したがって、大きな誤解を招くおそれがあります）、要件の小さなスライスから始めて、プロトタイプを作成し、それを使用して次の反復のフィードバックを収集します。

• 要件の理解が時間とともに変化するため、静的な要件の仕様は古くなります。これをどのように防ぐことができますか？

  要件を実行可能なテストとして表現する。「読み取り可能な仕様」と「実行可能なテスト」は排他的な概念ではありませんが、最終的には同じドキュメントになる可能性があることがわかります。たとえば、BDDスペースからのキュウリやその他のアイデアは、ここで非常に役立ちます。

古いシステムを書き換える場合、元のシステムが要件の大きなソースになる可能性があります。しかし、どの側面が関連していますか？そのニッチな機能も使用されていますか？互換性のためにどのバグを再実装する必要がありますか？通常、エンドユーザーと対話するための回避策はありません。

稼働中のシステムが横になっていることも、新しいソフトウェアのテストに非常に役立ちますが、それはアジャイルのような懸念とは無関係です。

期限が迫っている固定スコープ、固定時間のプロジェクトは、アジャイルの正反対です。通常のアジャイルアプローチは、機能の断片を選択して、最初にそれを提供し、次に反復することです。最も重要なものが最初に実行され、それほど重要でないものは後で実行されます（または実行されません）。すべてが重要であり、できるだけ早く実行しなければならない場合、何も重要ではなく、プロジェクトは何も提供しない可能性があります。

あなたの状況では、要件の欠如は俊敏な機能ではなく、組織の機能障害の平均的なケースです。プロジェクトを成功させるには、この機能不全を切り抜ける方法を見つける必要があります。たとえば、ビジネスオーナーに完全な要件ドキュメントを書くのではなく、最も重要な機能の要件を説明するミーティングを設定してみてください。詳細については、古いシステムをご覧ください。次に、その機能を実装し、繰り返します。

以下がその方法です。オーナー様にお話を伺いました。私たちはマネージャーと話をしました。作業をしているユーザーと話しました。ユーザーの机に座って見て（そして質問して）見つけたものは、驚くほど役に立ちました。マネージャーは、一緒に座るべきユーザーを知っていました。

システムの一部が実際に非常にうまく機能しており、設計、コーディング、テストケースなどを開始するのに十分な要件を簡単に記述できることを発見しましたが、他の部分には、床のユーザーが使用していた厄介な回避策がありました。マネージャーとオーナーは気づかなかった。古いシステムのこれらの部分については、ビジネスに戻り、ワークフローとプロセスについて少し話してから、より小さなタスクを具体化し、それにより、アジャイルメソッドが必要とするユニットにそれらを分割できるようにしました。

そのため、アジャイルはシステムの一部をすぐに始めることができましたが、開始する前に、もう少し考えて文書化する必要がありました。

アジャイルフレームワークで要件を収集し、誰もユーザーストーリーに言及していませんか？ユーザーストーリーは、基本的に、ソフトウェアが実行できる機能の高レベルの定義です。通常、ビジネスまたはエンドユーザーからのフィードバックやリクエストは、ユーザーストーリーとして記述できます。...受け入れ基準は、ユーザーストーリーをサポートする機能要件と考えることができます。

この質問は、アジャイルムーブメントの何が問題だったかを示唆しています。質問する人の責任ではありません。長年の企業生活が私を訓練してきたので、私はいつもこの罠に陥ります。

私が話している罠は、物事を行うための規定された正しいアジャイルな方法があると思っていることです。これは、アジャイルが存在すると人々が考えるためかもしれません。あなたはできません行う任意のより多くのあなたができるよりもアジャイルを行う実践的。

「機能仕様」など何もないので気になりますが、ないかもしれません。開始するためにどのくらいの詳細が必要ですか？セキュリティとパフォーマンスは、前もってわかっていて、ずっと適用されている明らかなものです。それ以外の場合、それはオプション価格設定エンジンですか、それとも時計アプリですか？

ソフトウェアの継続的なリリース、ディスカッション、学習、遡り、変更はありますか？あなたは構築しているソフトウエアやハードウエアを？

ウォーターフォールプロセスで作業する開発者は、後の段階になるまで関与しないことが多く、これは問題です。それらを早い段階または最初から関与させることは、不明確、未定義、中途半端なものに精通していることを意味します。これは、実際の仕事の一部が「これから構築する機能の要件は？」

計画の穴を特定することは、障害を見つけることではなく、単なるソフトウェア開発です。

このため、ガイの答えが大好きです。