要件のないソフトウェアの作成は、所有するスキルまたは避けるべき状況ですか？

一部のソフトウェア開発者はこれに非常に熟達しており、抽象的な要件を備えた実用的なコンセプトを提供できることで称賛されることがよくあります。率直に言って、これは私を夢中にさせ、私は行くにつれて「作り上げる」のが好きではありません。以前はこれが問題だと思っていましたが、変化を感じ始めました。そして、方向性がほとんど与えられていないときに思考（およびプログラミング）プロセスを調整する必要があるかどうか疑問に思っています。この能力をスキルとして習得し始める必要がありますか、それとも要件の収集とビジネスルールが最優先事項であるという考えに固執する必要がありますか？

スキルは、要件なしでソフトウェアを書くことではありません。代わりに、正式な要件のドキュメントがあるかどうかに関係なく、プロジェクトオーナーから要件を引き出します。

要件の収集は間違いなく最優先事項ですが、必ずしも顧客のニーズのすべてを前もって指摘する必要はありません。リスクはもちろん、顧客との正しい種類の会話ができなかった場合、システムアーキテクチャが役に立たない重要な情報を見逃す可能性があることですが、製品を定義して取得することも珍しくありません主要なシステムアーキテクチャの決定を可能な限り最後まで延期しながら、開発の大部分を邪魔にならないようにします。これは無駄のない開発アプローチであり、より堅実な情報が得られるまで、製品開発の早い段階で潜在的に互換性のないアーキテクチャにコミットしないようにすることを目的としています。OPが彼の質問で説明した状況では、

はい、顧客が実際に求めているものの中心に到達するために、時々水晶玉を注視する必要があります。これは、プロトタイピングのスパイクと遅い-そして時には痛みを伴う-要件の漸進的な引き出しが必要な場所です優れた顧客関係スキルを本当に身に付け、また、複雑なソフトウェアのアイデアでは、最初はソフトウェアが実際に何をする必要があるかを顧客があまり知らないことを理解する忍耐力を身に付けます。ほとんどの場合、顧客はソフトウェア開発プロセスの必要な専門知識や知識を常に持っているとは限らないため、顧客から早期に電話をかけて専門知識に頼って要件を定義します。

これは非常に曖昧です…

私が言うことができる2つのこと：

1. 完璧な要件を待っているためにキャリアが停止する、非常に才能のある技術者がたくさんいます。または、「申し訳ありませんが、できません。要件に含まれていませんでした」と再生します。現実には、要件の記述は非常に困難です。優れた要件に必要な精度は、ほとんどのビジネスマンがこれまでに作成したものとは異なります。テクノロジーとビジネスの間には橋があり、他の人を作る方法の100％が彼らに会う人は通常負けます。

2. ドメインは顧客よりも優れているか、優れていることを学習するソフトウェアの人々がいます。これらの人々は、100％の最高の開発者でなくても、金の重さの価値があります。私は、ソフトウェアの人々が国内の最高のブランドマネージャーの定量的マーケティングニーズを予測しているのを見てきました。彼らはすべてのソリューションをコーディングするのにベストではありませんでしたが、彼らは橋を渡ることができるのでヒーローでした。

人生は黒と白ではありません。自分の周りに狭いボックスを描くと、自分自身を制限します。一方、テクノロジーを作成するために必要なものを却下する組織も限られています。グレーのどこになりたいかを確認する必要があります。

要件は旅のステップであり、ビジョンは方向です

多くのアプリケーションでは、すばやく議論すると慎重にタイプセットされたドキュメントが役に立たなくなる可能性があるため、非常に詳細な技術仕様は前倒しすぎます。代わりに、ビジョンから始めます。全員が全体像を理解していれば、議論の途中で要件が満たされます。

開発者は、これらのディスカッションを使用して要件をトロールすることを学ぶ必要があります。これは、今日の意思決定が全体的なビジョンにどのように適合するかについて顧客に考えさせる質問を顧客に尋ねることを意味します。これらのより詳細な議論が早く行われると、全体的なビジョンがより迅速に一貫したデザインに固まります。

ある種の問題トラッカーでこれらのディスカッションの結果を追跡し、元のディスカッションに参加できなかった場合に他の人がコメントできるようにする必要があります。そして、あなたやあなたのチームの他のメンバーが、明確化が必要な場合に参照できるように、記録を残します。

そのため、ビジョンに照らしてコーディングすることを学びますが、時間が来たらそれらの要件を探しましょう。

スティーブジョブズは、顧客が将来の製品をどのように見せたいかを正確に説明することはできないと考えていたため、それらを提供するのはあなたの仕事です。そのため、常にカスタムソフトウェアを提供する場合を除き、正式な仕様を忘れて、プロトタイプを作成し、顧客に試してもらい、考えを伝えてください。プロトタイピングを行う適切な人を配置する必要があり、彼らには助けが必要です。私は経験からこう言います-私は直感的なインターフェースを作成するのが大好きなプロトタイピングモンキーであり、クライアントが望むものを理解し、紙またはExcelを使用して説明できる製品の誰かとチームを組みました。

私たちのどちらも天才ではありませんが、私たちは同じように考えています-私たちは化学を持ち、どのようなものがどのように構築されているかに大きな影響を与えたとほぼ言えるでしょう。現在、中規模から大規模のチームだけが、プロトタイパーと製品を独占的に開発する非コーダーを持つ余裕がありますが、それだけの価値はあります。プロトタイピングはソフトウェア開発の中で最も安価な段階であるため、UIと見かけの動作を正しくすることだけが理にかなっています。私はCode Completeを読んでいませんが、その本に書かれているようなものがあると思います。

仕様は素晴らしいのですが、決して完璧ではありません。それについて定理があります。仕様が完全であることを証明することはできませんし、ツールにバグがないことや停止することを証明することもできません:)

しかし、ソフトウェア企業は、こうしたプロセスの欠陥にもかかわらず、常にソフトウェアを出荷しています。仕様が完璧になることはありません。仕様も非自然で古くなっています。プロトタイプの仕様は、対数表が単一のグラフであるようなものです。仕様は基本的に印刷することを意図した退屈なパンフレットですが、代わりにツール/グラフを操作できます。チェックアウトhttp://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.htmlをインスピレーションを得るため。

今、あなたはあなたのお尻をカバーするために契約をしなければならない場合、仕様は良いです。ただし、仕様はプロトタイプの前ではなく、後でなければなりません。プロトタイプを安価にする方法を見つけるのはあなたの仕事です。

私は、多くの場合、いくつかの状況で、私は、人々がどのように、ビジネスは現在動作します正確にどのように発見し、ビジネスアナリストとして機能する必要があることを発見したと思う、それは（多くの場合、非常に異なるものを）作品、およびそれらがどのようになりたいとの仕事にそれを。

私は、ソフトウェアを構築するために私がしなければならない決定について常に明確であることによって成功を見つけました。推論を説明し、発見したことに関するドキュメントを書き、グラフを作成し、全員に配布します。

おそらく、完全な要件が引き渡されるまで作業を拒否することで、あまり良い印象を与えることはないでしょう。しかし、（必ずしも事実に注意を払わずに）自分で良質の要件を収集することにより、品質の高いソフトウェアという同じ目標を達成できます。

そして、はい、他のコメンターが言ったように、常にそれが変わると仮定してソフトウェアをビルドします。変更は、信頼できる1つの定数です。いくつかの新しい要件が突然現れたときに更新するのが苦痛にならないように、常に柔軟でモジュール式のソフトウェアを構築してください。

スタートアップでソフトウェア開発者として働きたいなら、それは持っているスキルです。

あなたがコンサルティング会社で働きたいなら、それはすべての費用で避けるべき状況です。これは、顧客の問題をどれだけうまく解決したかではなく、仕様/要件をどの程度うまく実装したかに応じて会社が支払いを受けるためです。

暇なときにコーディングを楽しんでいるのなら、それはあなたの呼び出しです。空き時間のプロジェクトに電話をかける資格がないと感じた場合は、それぞれの方法でいくつか試して、何が機能するかを確認してください。また、万能なものである必要はありません。プロジェクトによっては、いずれかのタイプのアプローチが必要です。通常、これらのプロジェクトの1つで間違ったものを選択した場合、それは非常に迅速にわかります。

両方のビット。クライアントを満足させる必要があります。つまり、クライアントが何を望んでいるかを知る必要があります。一方、クライアントは本当に欲しいものを伝えるのが悪名高い。

そのため、クライアントが何を望んでいるかわからないシナリオを避けたいのですが、必然的に、要件がせいぜい「ぐにゃぐにゃ」で、最悪の場合は欺cept的なシナリオに陥ります。優れた実世界のプログラマーには適応性が必要です。

要件なしでプログラムを作成することはできません。「Hello World」でさえ、出力を生成するという要件があります。ですから、UMLのような大きなスタックの形で、正式な要件について質問していると思います。そして、それらに関して、私は2種類の人々に会いました：

1）正式な要件を必要とする人々。彼らは何をすべきか、せいぜいそれを行う方法を正確に伝える必要があります。彼らはのような文章が大好き引数B意志の出力Cを取る手順Aを、そして彼らはそれらを憎む：プログラムは、私たちのdeparmentの仕事をより効果的に行う必要があります。彼らは通常、企業の動物です。

2）1の正反対の人々。何をすべきか、どのようにすべきかを言われるのが嫌いで、達成すべきことを言われるのが大好きです。彼らはクライアントと話し、彼らの言うことを分析し、それから彼ら自身のソリューションを開発するのが好きです。彼らは通常、フリーランサーであり、企業に適していません。

どちらが良いかは言いません。どちらにも長所と短所があります。これらは、他の条件に適した単純なものです。

要件を知らずに運用ソフトウェアを開発することはできません。しかし、あなたの経験があなたに要件がそうであるかもしれないことを伝えるものを開発するのにとても良い刺しを持つことができますすることが。アジャイル開発では、80：20ルールやプロトタイピングによる要件の「発見」など、「直感的な」技術の組み合わせを使用します。つまり、経験豊富な開発チームが、必要なものを最大限に推測して、ソフトウェアのプロトタイプを作成します。80:20ルールでは、80％が正しいとされています。次に、プロジェクトの利害関係者は、具体的なプロトタイプを確認します。彼らのフィードバックは、要件の理解における20％のギャップを埋め始めます。したがって、実質的に、アジャイルは要件のないソフトウェアを書くことではなく、以前の経験を使って「このようなものが欲しいですか？」と言うことです。これにより、80％のケースで、従来の要件プロセスを駆け抜けるよりも早く飛躍し、本当に必要なものを確認することができます。

要件がない場合にアジャイルがコードを書いていると言ったのは誰ですか？マニフェストがこのように解釈された人もいることは知っています...しかし、それは正しくありません。