ラピッドプロトタイピングはどのようにアジャイル手法に適合しますか？
私はアジャイルプロセスの使用を指示する大企業で働いています。たとえば、私たちのプロジェクトでは、アジャイル開発の管理を特に目的としたクラウドベースのサービスを使用しています。
私が取り組んでいる特定のエンジニアリンググループは、伝統的に開発されたソフトウェアではありません（代わりに、はるかに鳥瞰的な視点からプロジェクトを推進するのに役立ちます）が、状況は変化しています。私たちは、主にデータ中心である次期/計画中のソフトウェアプロジェクトを幅広く持っています。たとえば、データの監視、収集、集計、一部のレポートを行います。その他のタスクには、専用ハードウェアとさまざまなタイプのクライアント/サーバー（多層）アーキテクチャーによる自動化が含まれます。私は数人を採用するプロセスを支援し、前進するための多くの計画を策定します。
私の質問は、ラピッドプロトタイピング（使い捨てコード）がアジャイルの哲学に適合するかどうかです。たとえば、Pythonとその幅広いパッケージが大好きです。Pythonベースのワークフローを使用すると、アイデアの多くを非常に迅速に実装できる可能性があります。しかし、 、Pythonは「エンタープライズ品質」ではないという認識がたくさんあると思います。この作業の多くはJava =またはC++。
ただし、Pythonプロトタイプを作成すると、実際の結果を迅速に提供できるようになるため、多額の投資が必要になります。
Python-でうまくいけば）エンタープライズ環境の堅実なアジャイルワークフローにラピッドプロトタイピングを組み込むことができましたか？
RADで意図されている「プロトタイピング」 の概念は、アジャイル開発には少し異質です。これは、実行できないという意味ではありませんが、異常なことです。
調査する必要があるさまざまなケースがあります。
プロトタイプは「空のシェル」、モックアップ、またはデモであり、製品がどのように見えるかについてのアイデアを提供するために構築されていますか？確かに1つ以上のストーリーでそれを行うことができますが、実際のフィードバックから製品を構築するのではなく、自分の想像力から何かを構築しています。人々は製品を評価するようにデモを評価しません。たとえば、 トップバーのプロトタイプ と実際の トップバーの実装 の比較をご覧ください。
プロトタイプは、問題の空間をよりよく理解するために構築する必要があるものですか？次に、それは spike としてカバーされ、その結果のみが保持されます（ソースコードは一時的です）。
プロトタイプはバージョン0.xですか？ A 実行可能な最小の製品 ？次に、選択したアジャイルプロセスを使用します。別の言語で再構築する必要がある場合は、別の製品を扱った方が良いでしょう。これは、仕様を書くショートカットとして扱われる場合があることに注意してください（「プロトタイプと同じようにする必要があります！」）。これは製品を文書化する方法としては非常に貧弱ですが、これはおそらく別の質問と回答として説明した方がよいでしょう:-)
迅速なプロトタイピング （つまり、反復的で段階的な開発）はアジャイルの要点ではありませんか？
組織で「知覚は現実」に問題を抱えているようです。アジャイルは「すべての計画を破棄する」ことを意味するのではなく、テスト駆動開発が「すべてのアーキテクチャを破棄する」ことを意味することをすべての人に思い出させることをお勧めします。
そしてPythonはおもちゃの言語ではありません（もしそうだったとしても） NASAとその請負業者はPythonを使用しています 、そしてそれが彼らにとって十分であれば、私にとって十分です。
スパイク と呼ばれる Extreme Programing には、かなり安定したプラクティスがあります。これは使い捨てのコードであることを意味します。特別なことは何もありません。これは、期待される結果が使い捨てコードに関する知識である単なるスプリントです。
上記のリンクには、グッドプラクティス、スパイクの落とし穴に関する十分な情報があります。
あなたの特定の使用例は良い例のようです：インターフェースを設計し、ユーティリティを検証し、一部のユーザーにそれを表示することは役に立ちます。
プロトタイプは学習にとって、またアジャイル精神においても重要であると付け加えておきます。プロトタイプを使用して、特により高速なフィードバックサイクル内で学習できる場合は、それを試してください。学習を最大化し、学習内容をチームと共有することがすべてです。
あなたはコードを捨てて本番環境に入れないでしょう（それを誰にでも完全に明確にしてください）ので、アジャイルであるかどうかは重要ではありません。プロトタイプの場合、アジャイルプラクティスはすべてオプションです。スプリント、バーンダウン、テスト、ペアプログラミングなど、使用する予定のあらゆるものです。
Python=）で主に機能モデルを構築して、製品の所有者や他の意思決定者がプロジェクトを概念化できるようにする場合は、エンタープライズ対応である必要はありません。ただし、プルーフオブコンセプトを再作成するか、特定のパフォーマンスレベルを処理できるかどうかを確認するには、おそらくプロダクション言語を使用する必要があります。
とにかく、あなたはコードを捨てるつもりですが、所有者が何を望んでいるかについてのより良い感覚とともに、これを機能させることができるという知識があります。これで、必要なメソッドを使用できます。
アジャイルの真の精神は、相互作用とコミュニケーションです。プロトタイプがコミュニケーションを助けるツールとしてうまく機能すれば、アジャイルの世界でそれを使用することは何の問題もありません。私たちのチーム（私たちは5年以上アジャイルを実践しています）では、それを時々使用しました。そしてそこから私が見ることができるいくつかの利点があります
1）コミュニケーションを支援する
2）ユーザーを ソリューションインタビュー に誘導し、早期のフィードバックを得る
警告：
UXとエンジニアの間の直接的な通信は、プロトタイピングアーティファクトに置き換えないでください。可能であれば、エンジニアとのペアリングは、メディエーター（プロトタイプ）を介した通信よりも優れています。
学習に関しては、プロトタイピングにより、より速く学習できるようになると付け加えておきます。そうすることで、解決しようとしている問題に人々が気を配っているかどうか、そしてあなたが考えている解決策が彼らが求めているものであるかどうかを検証することができます。結局のところ、痛みを伴う十分な問題を解決したり、正しい方法で解決したりしないでください。
他の人はすでにスパイクの学習目的について述べました。欠けているのは、その根本的なアジャイルの原則であるfail fastです。
アジャイル開発の柱の1つは、難しい部分を認識し、概念の実証を行うことです。それができるかどうかを確認してください。すべてのタスクを「論理的」な順序で処理する従来の方法は、プロジェクトの後半で何かを行うことができない場合、非常に費用がかかることがあります。これまでに行われたすべてのことは、無駄になる可能性があります。
それがその方法で終わる必要がある場合は、できるだけ早く知りたいです。次に、利害関係者は、まだ多くが燃やされていない間はお金を燃やすのをやめて、望んでいないことを実行できないようにするか、根本的に異なるアプローチで問題を解決するかを選択できます。プロトタイプがこの目的を果たしている場合、実際に最も俊敏です。