機能要件の欠如は俊敏ですか？
今日、誰もが機敏になりたいと思っています。私が一緒に働いたすべてのチームで、アジャイルの形は異なっていました。いくつかのことは一般的です-毎日のスタンドアップや計画のようですが、他の部分は大幅に異なります。
私の現在のチームには、私が気になると思う詳細が1つあります。それは機能要件の欠如です。書面による期待が存在しないだけでなく、タスクでは、何をする必要があるかが漠然と定義されています。
プロジェクトの目標は、新しいテクノロジーを使用して古いシステムを書き換えることです。古いシステムにも適切なドキュメントはありません。確かに最新のものは存在しません。事業主の要件の説明は、古い実装と同じように新しい実装で実行しましょう。それは合理的に思えますが、そうではありません。古いシステムはスパゲッティコードの一種であり、ビジネス要件をそこから抽出するにはコストがかかります。状況は計画に悪影響を及ぼしているようです。確かに、新しい実装では間違いやバグが発生しやすい（詳細は省略）。
したがって、私は考えています-古いシステムを書き換える場合にビジネス要件がないことは本当に俊敏ですか？
機能要件の欠如が機敏であるかどうかにかかわらず、それは災害のレシピです。そのシステムがどのように機能するかわからない場合、システムを再構築することはできません。
古いシステムの仕組みがわからないことを事業主に伝える必要があります。
最善のオプションは、ビジネスオーナーまたは数人の経験豊富なユーザーと協力して、現場でのビジネスプロセスを理解し、独自の受け入れテストを開発することです。一部のエンドユーザーと連携できる場合は、古いシステムのしくみに関するフィードバックが増える可能性があります。
それができない場合は、独自の要件を収集するために、非実稼働環境でいくつかの探索的テストを行う必要があります。多くの場合、ビジネスオーナーが「古いもののように機能させる」と言うと、時間どおりに制約され、ビジネスオーナーのように手助けすることができません。古いシステムがどのように機能するかを理解するには、一部の熟練したユーザーの専門知識、または完全な多数の手動テストが必要です。
要件の欠如と古いシステムの理解により、システムの再構築にかかる時間が大幅に増加することを事業主に知らせてください—約3倍以上の時間です。タイムラインとコストの増加に直面して、ビジネスオーナーは、要件をより迅速に収集するために必要な専門知識を提供するか、現時点では書き換えを経済的に実行できないと判断します。
次のいずれかが表示されます。
- 適切な要件とより速い開発サイクル
- 要件を収集してソフトウェアを再構築する時間
- キャリアのブラックマークにならない新しいプロジェクト
アジャイルは機能要件の必要性を変更しませんが、一般的にはどのようにgatherそれらを変更するかを変更します。非アジャイルな方法は、誰かが長いプロセスを経て、システムのすべての要件を含む何らかのドキュメントを提供することです。
要件を収集するための俊敏な方法は、一緒に作業してシステムの小さな増分の要件を指定し、それを構築してからフィードバックを得て、次の増分を行うことです。ビジネスオーナーにプロセスを開始させるのに問題がある場合は、まず半日かけて、次に作業する古いシステムの部分を調査し、要件に関する質問のリストを生成します。
次に、ビジネスオーナーと一緒に座って質問します。簡単に答えられる質問もあれば、コードを見れば簡単に答えられる質問もあれば、どちらにしても答えにくい質問もあります。解ける何かに到達するまで、難しい質問をどんどん小さくしていきます。
目標は、何かを構築し、フィードバックを得て、プロセスを再開するために、十分な数の質問に答えることです。変更が小さく、フィードバックサイクルが短いほど、間違ったものを構築した場合の大したことは少なくなります。
要件の取得は、（成功した）ソフトウェアプロジェクトの重要な部分です。しかし、要求仕様を書くことはそうではありません。
ドキュメント中心のアプローチは、中国のささやきのゲームのように終わる可能性があります。対象の専門家が要件を発声し、アナリストがそれを書き留め、開発者がアナリストの説明と一致するものを書き込もうとすると、ソフトウェアが原因でエンドユーザーが混乱する彼らの問題を解決しない。
アジャイル技術は、開発者が主題の専門家、通常はエンドユーザーから直接要件を収集することを提案しています。これを行うには、さまざまな手法があります。たとえば、SMEとシナリオ例を話し合うことです。開発者はEdgeのケースを見つけ、SME=に尋ねて、ソフトウェアがそのEdgeケースでどのように動作するかを明確にするように依頼します。
アジャイルチームは、すべての要件を事前に収集するのではなく（したがって、大きな誤解を招くおそれがあります）、要件の小さなスライスから始めて、プロトタイプを作成し、それを使用して次の反復のフィードバックを収集します。
要件の理解が時間とともに変化するため、静的な要件の仕様は古くなります。これをどのように防ぐことができますか？
要件を実行可能なテストとして表現する。 「読み取り可能な仕様」と「実行可能なテスト」は、排他的な概念ではなく、同一のドキュメントになる可能性があることがわかりました。例えば。ここでは、BDDスペースからのキュウリやその他のアイデアが非常に役立ちます。
古いシステムを書き換える場合、元のシステムが要件の大きなソースになる可能性があります。しかし、どの側面が関連していますか？そのニッチな機能も使用されていますか？互換性のためにどのバグを再実装する必要がありますか？通常、エンドユーザーと対話するための回避策はありません。
稼働中のシステムが横になっていることも、新しいソフトウェアのテストに非常に役立ちますが、それはアジャイルのような懸念とは無関係です。
締め切りが迫っている固定範囲、固定時間のプロジェクトはアジャイルの正反対であることに注意してください。通常のアジャイルアプローチは、機能の一部を選択し、最初にそれを提供し、次に反復することです。最も重要なものが最初に実行され、それほど重要でないものは後で実行されます（または実行されません）。すべてが重要であり、できるだけ早く実行する必要がある場合、何も重要ではなく、プロジェクトは何も提供しない可能性があります。
あなたの状況では、要件の欠如は俊敏な機能ではなく、組織の機能障害の平均的なケースです。プロジェクトを成功させるには、この機能不全を切り抜ける方法を見つける必要があります。例えば。事業主に完全な要件文書を書くのではなく、最も重要な機能の要件を説明するミーティングを設定するように促してください。詳細については、古いシステムをご覧ください。次に、その機能を実装し、繰り返します。
これが私たちのやり方です。オーナー様にお話を伺いました。私たちはマネージャーと話をしました。作業をしているユーザーと話しました。ユーザーの机に座って見て（そして質問して）見つけたものは、驚くほど役に立ちました。マネージャーは、一緒に座るべきユーザーを知っていました。
システムの一部が実際に非常にうまく機能していて、設計、コーディング、テストケースなどを開始するのに十分な要件を簡単に記述できることを発見しましたが、他の部分には、床のユーザーが使用していた厄介な回避策がありました。マネージャーとオーナーは知らなかった。古いシステムのこれらの部分については、ビジネスに戻り、ワークフローとプロセスについて少し話してから、より小さなタスクを特定し、それにより、アジャイルメソッドが必要とするユニットに分割することができました。
そのため、アジャイルはシステムの一部をすぐに開始できましたが、開始する前に、もう少し考えて文書化する必要がありました。
この質問は、アジャイル運動の何が問題だったかを示唆しています。質問をする人の責任ではありません。長年の企業生活が私を訓練してきたので、私はいつもこの罠に陥ります。
私が話している罠は、物事を行うための規定された正しいアジャイルな方法があると思っていることです。これは、アジャイルが存在すると人々が考えるためかもしれません。 doできる以上にアジャイルにすることはできませんdo Pragmatic。
「機能仕様」など何もないので気になりますが、そうではないかもしれません。開始するためにどのくらいの詳細が必要ですか？セキュリティとパフォーマンスは、前もって知られていて、ずっと適用されている明らかなものです。それ以外の場合、それはオプション価格設定エンジンですか、それとも時計アプリですか？
ソフトウェアの継続的なリリース、ディスカッション、学習、遡り、変更はありますか？ softウェアまたはハードウェアを構築していますか？
ウォーターフォールプロセスで作業する開発者は、後の段階まで関与しないことが多く、これは問題です。彼らを早い段階または最初から関与させることは、不明確、未定義、中途半端なものに精通していることを意味します。これは、実際の仕事の一部が「これから構築するこの機能要件は？」
計画の穴を特定することは、障害を見つけることではなく、単なるソフトウェア開発です。
このため、ガイの答えが大好きです。
アジャイルフレームワークで要件を収集し、誰もユーザーストーリーについて言及していませんか？ユーザーストーリーとは、基本的に、ソフトウェアが実行できる機能の高レベルの定義です。通常、ビジネスまたはエンドユーザーからのフィードバックやリクエストは、ユーザーストーリーとして記述できます。 ...受け入れ基準は、ユーザーストーリーをサポートする機能要件と考えることができます。