要件がない場合にソフトウェアを作成することは、所有するスキルまたは回避すべき状況ですか？
一部のソフトウェア開発者はこれに長けていて、抽象的な要件を備えた実用的なコンセプトを提供できることで賞賛されることがよくあります。率直に言って、これは私を夢中にさせるものであり、私は「作り上げる」のが好きではありません。以前はこれが問題だと思っていましたが、シフトを感じ始め、非常に小さな指示が与えられたときに自分の思考（およびプログラミング）プロセスを調整する必要があるかどうか疑問に思っています。この能力をスキルとして習得し始めるべきですか、それとも要件の収集とビジネスルールが最優先であるという考えに固執する必要がありますか？
スキルは、要件なしでソフトウェアを書くことではありません。代わりに、正式な要件ドキュメントがあるかどうかに関係なく、プロジェクトオーナーから要件を引き出すことです。
要件の収集は間違いなく最優先事項ですが、必ずしも顧客のすべてのニーズを事前に把握する必要はありません。もちろん、リスクとは、顧客との適切な会話ができなければ、システムアーキテクチャが役に立たなくなるような重要な情報を見逃してしまう可能性があることですが、製品を定義して入手することも珍しくありません。開発の大部分を邪魔することなく、主要なシステムアーキテクチャの決定を最後の可能な瞬間まで延期します。これは無駄のない開発アプローチであり、互換性のない可能性のあるアーキテクチャを、製品開発の早い段階で確固とした情報が得られるまでコミットしないようにすることを目的としています。 OPが彼の質問で述べた状況では、この無駄のないアプローチは、後で大規模なやり直しやコストのブローアウトを回避するために非常に重要なIMHOになります。
はい、お客様が実際に求めているものの中心に到達するために、時々水晶玉を凝視する必要があります。プロトタイピングの急上昇と遅い-そしてはい、時々痛みを伴う-要件からの漸進的な描画が必要ですあなたは本当に優れた顧客関係スキルを開発し、複雑なソフトウェアのアイデアでは、最初は顧客がソフトウェアが実際に何をする必要があるかについてあなたよりもはるかに多くを知っているわけではないことを理解する忍耐力を持っています。ほとんどの場合、顧客はソフトウェア開発プロセスの必要な専門知識や知識を常に持っているわけではないため、顧客は早い段階で専門知識に頼って要件を定義するように求めてきます。
これは非常にあいまいです...
私が言える2つのこと：
彼らは完璧な要件を待つためにキャリアが停止される非常に才能のある技術者がたくさんいます。または、「申し訳ありませんが、できません。要件に含まれていませんでした。」実際のところ、要件の記述は非常に困難です。適切な要件に必要な精度は、ほとんどのビジネスマンがこれまでに作成したものとは異なります。テクノロジーとビジネスの間に架け橋があり、他の人と出会う方法を100％実現する人々は、通常、失うことになります。
顧客と同じかそれ以上にドメインを学ぶソフトウェアの人々がいます。これらの人々は、彼らが100％最高の開発者でなくても、金の価値があります。ソフトウェアの人々が国内で最高のブランド管理者の定量的なマーケティングのニーズを予測するのを見てきました。彼らはすべてのソリューションをコーディングするのは得意ではありませんでしたが、彼らは橋を渡ることができたので、ヒーローでした。
人生は黒と白ではありません。自分の周りに狭いボックスを描くと、自分を制限することになります。反対に、テクノロジーを作成するために必要なものを却下する組織も限られています。あなたはグレーのどこになりたいのかを確認する必要があります。
要件は旅のステップであり、ビジョンは方向です
多くのアプリケーションにとって、非常に詳細な技術仕様は、あまりにも先行しすぎています。代わりに、ビジョンから始めます。全員が全体像を理解している場合、要件は議論の途中で満たすことができます。
開発者は、これらのディスカッションを使用して要件のトロールを学習する必要があります。これは、今日の決定が全体的なビジョンにどのように適合するかについて顧客に主導する質問をすることを意味します。早い段階でこれらのより詳細な議論が行われ、全体的なビジョンが一貫性のある設計に早く固まるでしょう。
元のディスカッションを見逃した場合に他のユーザーがコメントできるように、これらのディスカッションの結果をある種の課題トラッカーで追跡する必要があります。そして、あなたやあなたのチームの他のメンバーがあなたが明確にする必要がある場合に戻って参照できるようにあなたが記録を持っているように。
そのため、ビジョンに反してコーディングすることを学びますが、その時が来たら、それらの要件に対応する準備をしてください。
Steve Jobsは、顧客が将来の製品をどのように見せたいかを正確に説明することはできないと信じていたため、それらを提供するのはあなたの仕事です。そのため、常にカスタムソフトウェアを提供する場合を除き、正式な仕様を忘れて、プロトタイプを作成して、顧客に試してもらい、彼らが考えていることを伝えるようにします。あなたはプロトタイピングを行う適切な人を配置する必要があり、彼らは助けを必要としています。私はこれを経験から言っています-私は直感的なインターフェイスを作成するのが大好きなプロトタイピングモンキーであり、クライアントが何を求めているのかを理解し、紙またはExcelを使用して説明できる製品の誰かとチームを組みました。
どちらも天才ではありませんが、私たちは同じように考えています。化学反応があり、どのようなものをどのように構築するかに大きな影響を与えたと言っても過言ではありません。現在、中規模から大規模のチームだけが、プロトタイプ作成者と非開発者が製品を独占的に開発する余裕がありますが、それだけの価値があります。プロトタイピングはソフトウェア開発の最も安価な段階なので、UIと見かけの動作を正しくすることだけが理にかなっています。私はコードコンプリートを読んだことはありませんが、その本にそのようなものが書かれていると思います。
スペックはいいですが、完璧ではありません。それについての定理があります。仕様が完全であること、およびツールにバグがないこと、またはツールが停止することを証明することはできません。
しかし、ソフトウェア会社は、プロセスのこれらの欠陥にもかかわらず、常にソフトウェアを出荷しています。スペックが完璧になることは決してありません。仕様も自然で時代遅れです。プロトタイプへの仕様は、対数表が単一のグラフに対するもののようなものです。仕様は、本質的に印刷するための退屈なパンフレットですが、代わりにツール/グラフを操作することができます。 http://www.i-programmer.info/news/112-theory/3900-a-better-way-to-program.html からインスピレーションを得てください。
今、あなたのお尻をカバーする契約をしている必要がある場合は、スペックは良いです。しかし、仕様はまだプロトタイプの前ではなく後に来るはずです。プロトタイプを安価にする方法を見つけるのはあなたの仕事です。
スタートアップでソフトウェア開発者として働きたいのなら、それは持っているスキルです。
コンサルティング会社で働きたいなら、絶対に避けたい状況です。これは、顧客が問題をどれだけうまく解決したかではなく、仕様/要件をどの程度適切に実装したかに応じて会社が支払いを受けるためです。
あなたが余暇に楽しみのためにコーディングしているなら、それはあなたの呼び出しです。暇な時間のプロジェクトを依頼する資格がないと感じた場合は、それぞれにいくつかの方法を試して、何が機能するかを確認してください。また、すべてに対応する必要はありません。プロジェクトによっては、どちらか一方のアプローチを必要とする場合があります。通常、これらのプロジェクトの1つで間違ったものを選択すると、かなり速くそれがわかります。
私はしばしば、ビジネスアナリストとして行動する必要がある状況で、ビジネスが現在どのように機能しているか、人々がどのように機能しているかthinkが機能していること（多くの場合、非常に異なることが多い）、およびその方法- like動作します。
私は、ソフトウェアをビルドするために私が強制されている決定について常に明確にすることによって成功を見つけました。私は私の推論を説明し、私が発見したものに関する文書を書き、グラフを作成し、それらをすべての人に配布します。
完全な要件が引き渡されるまで作業を拒否することで、おそらくあまり印象に残りません。しかし、（実際に注意を引くことなく）自分で良質の要件を収集することで、質の高いソフトウェアの同じ目標を達成できます。
そして、そうです、他のコメンターが言ったように、常に変化することを想定してソフトウェアをビルドします。変化はあなたが信頼できる一つの定数です。新しい要件が突然現れたときにソフトウェアを更新するのが面倒にならないように、常にソフトウェアを十分に柔軟でモジュール式に構築してください。
両方のビット。クライアントを満足させる必要があります。つまり、クライアントが何を望んでいるかを知る必要があります。一方で、クライアントは本当に欲しいものを伝えるのが悪いことで有名です。
したがって、クライアントが何を求めているのかわからないシナリオは避けたいですが、要件がせいぜい「ふさふさ」で、最悪の場合は欺瞞的なシナリオに必ず遭遇します。優れた現実世界のプログラマーには、適応性が必要です。
要件なしでプログラムを書くことはできません。 「Hello World」でさえ、出力を生成するという要件があります。したがって、UMLのような何かの大きなスタックの形で、正式な要件について質問していると思います。そして、それらに関して、私は2種類の人々に会いました：
1）正式な要件を必要とする人々。彼らは、何をすべきか、そしてせいぜいどのようにそれを行うべきかを正確に伝えられる必要があります。彼らは引数Bをとる手続きAはCを出力するのような文を愛し、それらを嫌います：プログラムは私たちの部門の仕事をより効果的にするはずです。彼らは通常、企業の動物です。
2）反対側の人々1.彼らは何をすべきか、どのようにすべきかを教えられることを嫌い、何が達成されるべきかを教えられることを愛する。彼らはクライアントと話をし、彼らが言うことを分析してから、独自のソリューションを開発するのが好きです。彼らは通常フリーランサーであり、企業に適していません。
どちらが良いかは言いません。どちらにも長所と短所があります。それらは、他の条件に対しては単純で十分です。
[〜＃〜]できない[〜＃〜]要件を知らなくてもoperationalソフトウェアを開発できます。しかし、あなたの経験があなたに教えてくれるものを開発するのに、おもしろい良い試みをすることができます要件はlikelyであるべきです。アジャイル開発では、80：20ルールやプロトタイピングによる要件の「発見」など、「直感的な」手法を組み合わせて使用します。つまり、経験豊富な開発チームが何が必要であるかを最もよく推測し、ソフトウェアのプロトタイプを作成します。 80:20ルールでは、80％正解になるとされています。次にプロジェクトの利害関係者は具体的なプロトタイプをレビューします。彼らのフィードバックは、要件の理解における20％のギャップを埋め始めます。つまり、アジャイルは実質的に、要件なしでソフトウェアを作成することではなく、以前の経験を使って「このようなものを望んでいるのか」と言うことです。これにより、80％のケースで、従来の要件プロセスを駆使するよりも早く、本当に必要なものをすばやく確認できます。