ラピッドプロトタイピングはアジャイル手法にどのように適合しますか？

私は大企業で働いており、アジャイルプロセスの使用を指示しています。たとえば、プロジェクトでは、アジャイル開発の管理を特に対象としたクラウドベースのサービスを使用しています。

私が働いている特定のエンジニアリンググループは、従来ソフトウェアを開発していませんでした（代わりに、より多くの鳥瞰的な観点からプロジェクトを推進しています）が、それは変化しています。私たちには、主にデータ中心の広範囲の今後/計画中のソフトウェアプロジェクトがあります。たとえば、データの監視、収集、集計、およびいくつかのレポート作成を行います。その他のタスクには、特殊なハードウェアとさまざまなタイプのクライアント/サーバー（多層）アーキテクチャによる自動化が含まれます。私は、複数の人を採用し、前進するための多くの計画を策定するプロセスを支援します。

私の質問は、ラピッドプロトタイピング（スローアウェイコード）を行うことがアジャイル哲学に適合するかどうかです。たとえば、Pythonとその幅広いパッケージが大好きです。Pythonベースのワークフローを使用して、多くのアイデアを非常に迅速に実装できる可能性があると思います。ただし、Pythonは「エンタープライズ品質」ではないという認識が多くあり、この作業の多くはJavaまたはC ++で書き直す必要があると思います。

ただし、Pythonプロトタイプを作成することで、実際の結果を迅速に提供できるようにするための費用を大幅に削減できます。

ラピッドプロトタイピングを（できればPythonで）エンタープライズ環境の堅牢なアジャイルワークフローに組み込むことができましたか？

RADで意図されている「プロトタイピング」の概念は、アジャイル開発にとっては少し異質です。これは、実行できないという意味ではありませんが、異常なことです。

調査する必要があるさまざまなケースがあります。

1. プロトタイプは、「空のシェル」、モックアップ、またはデモであり、製品がどのように見えるかについてのアイデアを与えるために構築されていますか？確かに1つ以上のストーリーでそれを行うことができますが、実際のフィードバックから製品を構築するのではなく、自分の想像力から何かを構築しています。人々は製品を評価するようにデモを評価しません。たとえば、トップバーのプロトタイプと実際のトップバーの実装に関するフィードバックを参照してください。

2. プロトタイプは、問題空間をよりよく理解するために構築する必要があるものですか？その後、スパイクとしてカバーされ、その結果のみが保持されます（ソースコードは一時的なものです）。

3. プロトタイプはバージョン0.xですか？mininimum実行可能な製品？次に、選択したアジャイルプロセスを使用します。別の言語で再構築する必要がある場合は、その別の製品を扱うとよいでしょう。これは、仕様を記述するショートカットの方法として扱われる場合があることに注意してください（「プロトタイプと同じことをする必要があります！」）。それは製品を文書化する方法としては本当に貧弱ですが、これはおそらく別の質問と回答として説明した方が良いでしょう:-)

ありませんラピッドプロトタイピング（すなわち反復型開発）ソートのアジャイルの全体のポイントは？

組織で「認識は現実」という問題を抱えているようです。テスト駆動開発が「すべてのアーキテクチャを捨てる」ことを意味するのではなく、アジャイルは「すべての計画を捨てる」ことを意味しないことを皆さんに思い出させてください。

そしてPythonは（もしあったとしても）おもちゃの言語ではありません。 NASAとその請負業者はPythonを使用しており、彼らにとって十分であれば、私にとっても十分です。

エクストリームプログラミングには、スパイクと呼ばれる非常に安定したプラクティスがあります。これは、使い捨てコードであることを意味します。特別なことは何もありません。予想される結果がスローアウェイコードに関する知識である単なるスプリントです。

上記のリンクには、良い習慣、スパイクの落とし穴に関する十分な情報があります。

あなたの特定の使用例は良い例のようです：インターフェースを設計し、ユーティリティを検証し、それを一部のユーザーに見せることは有用です。

コードを捨てて、本番環境に入れない（誰にでも完全に明確にする）ため、アジャイルであってもなくてもかまいません。スプリント、バーンダウン、テスト、ペアプログラミングなど、使用を計画しているものであれば、プロトタイプのアジャイルプラクティスは完全にオプションです。

主にPythonで機能モデルを構築して、製品所有者やその他の意思決定者がプロジェクトを概念化できるようにする場合は、エンタープライズに対応する必要はありません。ただし、概念実証を作成している場合、または特定のパフォーマンスレベルを処理できるかどうかを確認しようとしている場合は、実稼働言語に固執する必要があります。だからといって、Pythonで試すことができないわけではありません。

とにかく、あなたはコードを捨てるつもりですが、所有者が望んでいるもののより良い感覚と一緒にこの仕事をすることができるという知識を持っています。これで、必要な方法論を使用できます。

プロトタイプは学習に不可欠であり、アジャイルの精神でも重要だと付け加えます。プロトタイプで、特により速いフィードバックサイクル内で学習できる場合は、試してください。それはすべて、学習を最大化し、学習をチームと共有することです。

学習に関しては、プロトタイピングを使用すると、より速く学習できます。そうすれば、解決しようとしている問題を人々が気にかけているかどうか、そしてあなたが考えている解決策が彼らが探しているものであるかどうかを検証することができます。 、最終的には、痛みを伴う問題を解決したり、正しい方法で解決したりしないでください。

アジャイルの真の精神は、相互作用とコミュニケーションです。プロトタイプがコミュニケーションを支援するツールとしてうまく機能すれば、アジャイルの世界でそれを使用することは何も悪いことではないと思います。私たちのチーム（私たちは5年以上にわたってアジャイルを実践してきました）で時々それを使用しました。そして、そこからわかるいくつかの利点があります

1）アシストコミュニケーション

2）ユーザーをソリューションインタビューに参加させる、早期のフィードバックを得る

警告：

UXとエンジニア間の直接通信は、プロトタイピングアーティファクトに決して置き換えないでください。可能であれば、エンジニアとのペアリングは、メディエーター（プロトタイプ）を介した通信よりもうまく機能します。

他の人は、スパイクの学習目的についてすでに言及しています。不足しているのは、高速で失敗する基本的なアジャイルの原則です。

アジャイル開発の柱の1つは、難しい部分を認識し、概念の証明を求めて、それができるかどうかを確認することです。プロジェクトの後半で何かを行うことができないとわかった場合、何らかの「論理的」順序ですべてのタスクを実行する古典的な方法は、非常に高価になる可能性があります。これまでに行われたすべてが無駄になる可能性があります。

そのようにする必要がある場合は、できるだけ早く知りたいです。その後、利害関係者は、まだ多くが燃やされていない間にお金を燃やすのをやめて、彼らが望むものを受け入れられないことを受け入れるか、または成功する新たなチャンスを持つ問題に対して根本的に異なるアプローチを試みることを選択できます。プロトタイプがこの目的を果たしている場合、実際に最も機敏です。