一般的に言って、すべての機能部分を作成するか、UIを最初に機能させるのが良いですか、それとも2つを組み合わせた方がいいですか？
一般的に言って、すべての機能部分を作成するか、UIを最初に機能させるのが良いですか、それとも2つを組み合わせた方がいいですか？
あなたが何か大きなものに取り組んでいると仮定すると、UIの前にすべての機能データハーベスティングBLOBを機能させること、すべてのUIを一度に1つずつ機能させること、または途中で何かを行うことは一般的に受け入れられているプラクティスですか？
私たちは皆、作業を管理可能な部分に分解することを知っていますが、問題は、UIが私が想定する管理可能な部分に含まれているかどうかです。
この例の場合、1つのルートウィンドウを持つGUIアプリケーションを考えますが、さまざまなデータコンポーネントを分離するために、さまざまなドックに12を超えるタブがあります。個々のタブには、機能ユニットの観点から見ると、その背後に比較的複雑な可動パーツのセットがあります。
この特定の質問のサンプルアプリケーションは here に付随する blog および オリジナルの商用製品 です。
多くのビジネスユーザーとクライアントの間には、見た目が完了すると、ほぼ完全であるという一般的な概念があります。ご存知のように、これは真実とはかけ離れています。見栄えはいいですが、バックエンドがなく、見栄えを良くすることは20％ではなく作業の80％であると考えるユーザーもいます（ または他の80％ ）。
数え切れないほどの開発者が、ホラーストーリーを語ることができます。他のツールのスクリーンショットを使用してMicrosoft Wordでページのモックアップを作成し、クライアントは「それで、ほぼ完了しましたか？」
すべてのパーツが完了したときに完了するように、ペースを調整する必要があります。最初にすべてのバックエンドを実行し、次にすべてのフロントエンドを実行しようとすると、何もしていないとエンドユーザーが考え、表示するものがないときに支払いを受ける理由を尋ねます。一方、フロントエンドを最初にすると、エンドユーザーが微妙な変更を行い、すべての時間を費やしていることがわかります。
「一方が他方で」という最悪のケースは、もう一方の部分に到達したときに、デザインにまったく適合しないことです。
したがって、両方をビルドします。フロントエンドで進行状況を表示し、バックエンドをビルドしているもので機能させます。多くの場合、増分ビルドを提供し、クライアントが望むものを作成していることを確認することをお勧めします（これはアジャイルに組み込まれます）。 「目に見える進歩」がない状態で長すぎると、クライアントとの関係が損なわれる可能性があります（これはの場合「すべてが早いように見える」場合と「何も行われない場合」の両方の場合終わりまで」-作成中のフレームワーク、ユニットテスト、またはデータのサニタイズが進行しているのをクライアントが見るのは困難です）。
ジョエルはこれについて The Iceberg Secret , Revealed ：
重要な結果2。プログラマーではないユーザーに、100％美しいユーザーインターフェースを備えた画面を表示すると、プログラムはほぼ完了したと見なされます。
プログラマーではない人は、画面を見ているだけでいくつかのピクセルが見えます。そして、ピクセルが何かを行うプログラムを構成しているように見える場合、彼らは「ああ、まあ、それを実際に機能させるのにどれほど難しいだろうか？」と考えます。
ここでの大きなリスクは、おそらくUIを最初にモックアップすると、おそらく顧客と会話ができるようになり、それで誰もがほぼ完了していると考えるでしょう。そして、来年「裏をかく」仕事をするとき、いわば、誰もあなたが何をしているかを実際に見ることはなく、彼らはそれを何もないと考えます。
これは、ブログ記事で再度繰り返されます デモを完成させないでください これは、この有用なグラフを持っています：
ここで、2つのオプションは一般に「UIを完了させる」（そして、すぐに完了することが予想される）と「バックエンドを完了させる」（そして顧客は締め切りを見逃していることを顧客が心配している）を反映していることに注意してください。
どのように「完了」したかは、「完了」したものと一致するはずです。
すべてのソフトウェア開発者は、キャリアの中でこれを何度も経験しています。しかし、デスクトップパブリッシングツールは、テックライターにとって同じ悩みの種です。完璧なフォントとフォーマットの大まかなドラフトを誰かに見せると、彼らはそれがあなたが望むよりも多く行われているように見えます。私たちがどこにいるのか、他の人がどこにいるのかを理解する必要があります。
この記事では、ユーザーインターフェイスのさまざまなレベルで得られるフィードバックのtypeについての重要なポイントも取り上げます。完全に見えるものがあれば、「このレイアウトは機能しません-タブが多すぎます」よりも「フォントを変更できますか」についてのフィードバックを得る可能性が高くなります。
Java Swingの世界でこれと戦っている人のために、 look and feel と呼ばれる Napkin があり、UIが（完全であっても）完全に見えません。
ここで重要なのは、lookが実行されないようにすることです。 UIが完全に見えるようにすることは、アプリケーションが完了したことを示す多くのビジネスユーザーへの合図です（たとえその背後にロジックがない、またはインターフェースビルダーで構築されたものがない静的ページがいくつかある場合でも）。
さらに読む（そして記事からのリンク）：
それは依存します：あなたの最も重要な機能部分の周りにタイトなフィードバックループが必要です
あなたがしていることの中核となる、危険で怖い部分が何らかの内部エンジンである場合は、その中核部分をコンソールやユニットテストなどで機能させます。たとえば、プロトコルパーサーは、UIが正しく動作しているかどうかを知る必要はありません。
クールなものにインタラクティブ機能（常にトラブルシューティング、破棄、再発見を行う必要があるインタラクティブ機能）が含まれる場合、UIを優先するアプローチが重要です。たとえば、ユーザーがデータの視覚化を操作できるようにするアプリを構築したいと考えています。私が理解する必要がある最も重要なことは、視覚化が意味があるかどうかです。そのため、半ダースのアプローチを捨ててから、それに着手するでしょう。単体テストを作成する前に、これをすべて行います。
あいまいな灰色の領域があり、コードを適切に操作して検証する方法（自動テスト？実験用のUI？）の最適な組み合わせを決定できます。私は個人的に極端なものとその間のすべてのことの両方を行いました。そのスペクトルの適切な場所を決定することは、私が決定しなければならない最も難しいことの1つであり、私が構築しているもののタイプに100％依存しています。
アジャイル環境では、「歩くスケルトン」または「薄い垂直スライス」についての議論を聞くかもしれません。実用的なソフトウェアはユーザーにとって重要なので、ソフトウェアを1つずつ実用的な方法で構築していくという考え方です。
前述のサンプルアプリケーションでは、ウィンドウとおそらく1つのタブから始めて、すべてを何らかの方法で前面から背面へと動作させます。その後、時間の経過とともに機能を追加し、ケースごとにタブを追加して、各機能を作成しながら機能させるようにします。これは、頻繁な顧客デモンストレーションが提供するものの一部です。新しい機能を示し、即座にフィードバックを得るチャンスです。
要するに、はい、UIがあれば、UI作業は機能的な作業の単位の一部であり、全体です。
機能する小さなものから始め、その機能を繰り返して、完全なソフトウェアを提供します。
機能とUIの両方を混在させることをお勧めします（できるだけ早くフィードバックやテストの経験を得る）。
ところで、ほとんどの大きなGUIソフトウェアが開発される方法ではないでしょうか。たとえば Firefox ブラウザを見てください。あるバージョンから次のバージョンへと、機能とユーザーインターフェイスの両方が進化しています。
私がしがちなことはくだらないUIで開始：変数データを画面にダンプするだけのものです。長い間、フォント、配置、実際のグラフィックはありません。 「Welcome user x」と「load pic」などと呼ばれるボタンだけです。これの良いところは、バックエンドの何かが壊れているかどうかがわかることです。
開発が進むにつれ、続行する必要のある項目が増えるか、少なくなります。しかし、ある段階で、バックエンドがほぼ完成すると判断します。これで、必要なすべての添付ファイルを含むUIができました。すべてのグラフィック関連の作業に多くの時間を費やすことができます。
しかし、注意してください、それは絶対確実ではありません。特定の問題の発生を確認するには、少し先見の明が必要です。たとえば、データを適切に表示するために、UIコンポーネントを調査する必要がある場合があります。
私が取り組んでいる大規模な（PHP Webベースの）アプリケーションでは、まずクラスとメソッドを配置しようとしますダミー値を返す。これは、他の開発者がUIの実装に使用できる疑似契約を確立するためです。
このメソッドの2番目の利点は、すべてのコードが作成されて配信される前でも、コントラクト/インターフェイスをI要件の変更（そして常に変更される）に調整できることです。
優れたマイルストーンと問題追跡システムを使用すると、一目で管理者が自分の生産性を確認できるため、これらの問題の一部を回避できます。彼らは、あなたが80％バックエンドを終了し、UIが次のマイルストーンであることを確認できます。彼らは、特定の機能のマイルストーンのために完了する一連のUIおよびバックエンドタスクがあることを確認できます。しかし、すべてはプロジェクトの要件から始まり、Doug Tの答えは、システム設計のその側面についていくつかの良い点を提起します。
ユーザー/クライアントの視点で考えます。ソフトウェアシステムは、このユーザー/クライアントにいくつかの価値を与える機能の集まりです。もちろん、これらの機能にはそれぞれ、UI、バックエンドなどの機能があります。
常に機能ごとにシステムを構築し、非常に小さな機能に分割してみてください。このようにして、常に顧客に提供するものをもっと近くに持っています。ソフトウェア開発はバージョン1.0をビルドすることではなく、バージョン1.0.1から1.0.2に行くことなどを覚えておいてください...
場合によります。要件はどの程度明確に定義されていますか？システムのどの程度がUIに対応していますか？
私の経験から、ほとんどの顧客は自分の前に何かを見るまで、何が欲しいかわからない。したがって、私は通常、主要なUIアスペクトのワイヤーフレームをいくつか提供するか、UIの大部分を提供します（機能しない）。これにより、データベースの設計とコード構造はまだ設計段階にあるだけなので、設計に修正を加えるのは簡単なので、顧客は機能や機能についてあまり影響を与えることなく考えを変えることができます。プロジェクトの早い段階で設計を変更し、後で変更する方が桁違いに簡単/迅速です。
アジャイルでは、最も難しい項目と最も重要な項目についても最初に取り組む必要があると述べています。 失敗する。したがって、お客様がUIを確認したら、完全に機能する小さなコンポーネントの構築に焦点を当て、最初に実装することが最も重要で最も難しいため、ハードルに遭遇するかどうかをできるだけ早く知ることができます。
次に、スプリントを取得し、いつかUIと機能の両方の側面を開発している顧客と常に連絡を取ります。