language-agnostic - 計画の完全な欠如と分析の麻痺の境界線はどこにありますか？

Question

プログラミング分野での非常に短い時間の中で、私は2つの極端な状況を見てきました。

後者は前者への反応としてしばしば起こるようです。ハッピーミディアムはどこにありますか？さらに重要なことに、プロジェクトがこれらの方向の1つに進んでいる場合、プロジェクトを前述の幸せな媒体に向けて動かすための最良の方法は何ですか？

score 6 · Accepted Answer

私自身の個人的な経験では、「意思決定」が私のボトルネックであることがわかりました。

この場合、次のようになります。

「概念実証」は、何かを証明するための最小限のアプリです。（私の場合は通常1〜6時間です）

2 つ以上のオプションが等しい状況にある場合は、時間制限 (2 か月ではなく 5 分など) を自分に与えて決定を下します...どんな決定でも、振り返ってはいけません。

また、設計時に考慮に入れなかった問題に対処できることを信じてください。

score 3 · Accepted Answer

分析の麻痺には多くの症状があります。私が気づいたことの1つは、同じ質問が各会議で行われ、解決策に到達しないことです。計画プロセスが停滞していることを認めるのを助けることができるかもしれない人々にこれを指摘することができれば。

可能であれば、プロジェクトの開始時に、計画段階で要件の特定の割合、たとえば80〜90％をカバーすることを表明します。このように明確な目標があり、あなたは完璧を目指しているのではありません。後で計画と分析を再検討することができますが、それが物事を妨げないようにしてください。

score 3 · Accepted Answer

初期計画は、およそ O(log n) である必要があります。ここで、n は予想される総開発時間です。

1 週間頑張らなければならない場合は、ナプキンに何かをスケッチします。月がある場合、初日は初期設計です。1年あれば1週間。

これは、計画を繰り返し再検討することを前提としており、大人の監督なしで、コードベースですべてのコマンドスタイルを実行するだけではありません:-)。

score 2 · Accepted Answer

私はそれが2つの要因に依存していると思います：

プロジェクトの長さ
- 1週間のプロジェクトですか？
- 1年間のプロジェクトですか？
- それともその間のどこか？
プロジェクトに変更が導入されるリスク
- それらは本質的にアーキテクチャであり、元のコードの多くに影響を与える可能性がありますか?
- それとも単に新しい機能を追加するだけですか?

明らかに、それは上記の 2 つの要因の組み合わせです。実装に 2 日かかり、アーキテクチャへのリスクがほとんどない機能の設計に 1 か月を費やすのは、まったく意味がありません。ここでは、長さ/リスク/設計時間のトレードオフのマトリックスを描いています。

私が現在読んでいる Code Complete 2 には、いくつかの興味深いアドバイスがありました。正確な言葉遣いを思い出せないので、ここでは言い換えていますが、次のような内容が書かれていました。

設計で犯しがちな 2 つの最大の間違いは次のとおりです。

1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation

これら 2 つの中間点を見つけることが、設計と計画を成功させるための鍵です。

score 1 · Accepted Answer

素晴らしい質問 - 絶対的な答えはありません - これが経験を有意義なものにします。以下を含む経験：

大きな要因は、開発中のシステムです。「生命」が重要であるほど、より多くの詳細が必要になります (Web ページと比較した心臓モニター)。

より複雑で、コスト/時間の制約があり、命に関わるほど、前もっての作業が増えます - 作業を行う際に詳細にできることは少なくなります (プロトタイプから生産まで)。

5 に答える 5