問題タブ [project-planning]

仕様書を書いているときは多くの時間を浪費しているのに気づいたのですが、後でアプリを書くときは無視でき、いくつかの重要なことを忘れてしまいます。
私は、(私にとっては) 概念実証アプリケーションを作成し (適切なエラー ハンドラーやセキュリティ機能がない、スタイルにマイナーな問題があるなど)、それを参加者の仕様として使用する方が高速であることを発見しました。

それでも、私はこの方法でも時間を無駄にしていると感じています。これをどのように行うべきかについて何か良いアイデアはありますか?

おそらくその質問に対する最良の言い回しではありませんが...

プロジェクト内のタスクを管理するための MS Project のようなものがあることは理解していますが、1 つ上のレベルのものを探しています。プロジェクト内のタスクだけでなく、プロジェクトと利用可能なリソース自体を管理できる必要があります。

例えば

つまり、基本的には、新しいプロジェクトを追加し、利用可能なリソースを確認し、いつ開始できるかを見積もり、ソフトウェアを見てすべてを完了することができます。（その後、経営陣に、さらに人を雇わないのであれば、2099年まで待っていることを示すことができます.;））

何かご意見は？

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

• 計画がほとんどまたはまったく行われなかったため、メンテナンスの悪夢になるプロジェクト。
• 永続的に計画段階にあり、そこから移動しないプロジェクト。

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

立ち上げに十分な機能をどのように判断しますか? グッズなしで「裸の機能」で起動する必要がありますか? それとも「ベルとホイッスル」を追加する必要がありますか？

どのように決定しますか？突然の露出で「やけど」する可能性があるのは本当ですか、それとも突然の露出は神話ではなく、露出はゆっくりと段階的です.

あなたの提案は大歓迎です。

私は職場で、さまざまな人が構築した最大のソフトウェア システムはどれかという議論に参加していました。この場合の最大の問題は、システムの複雑さと実装の難しさの組み合わせです。

経験豊富なプログラマーはプロジェクトの規模を直感的に把握している傾向があるので、たとえそれを書面にしないとしても、SO に質問することにしました。

議論中のシステムは次のとおりです。

• 通信課金システム。4つの主な機能:
  • 60 秒ごとにデータベースからコール クレジットが予約されるリアルタイム コール コントロール、
  • カスタマイズ可能な通話プラン、最小コストのルーティング、ユーザーあたりのカスタム料金、
  • 課金サーバーあたり 1000 の同時通話の容量、
  • 365x24x7 と 99.999% の信頼性。
• レース業界向けのコア賭けシステム。4つの主な機能:
  • 約をサポートするクライアント/サーバー アプリケーション。1000 のキャッシュ アウトレットと 200 席のコール センター、
  • 固定オッズ システムではなく、コミッションを差し引いて勝者間でプールを共有することに基づいてペイアウトが計算されます。
  • 約 20 の異なるベット タイプ、最大コンビネーション ベットは最初の 4 位、
  • 350x20x7 で 99.9% の信頼性。
• 顧客関係管理システム。4つの主な機能:
  • AJAX ユーザー インターフェイス、
  • 受信者アドレスに基づいてさまざまなキューに配信する電子メール統合、
  • 請求、
  • サードパーティの統合が許可された Web サービス API。

欠落している詳細はたくさんありますが、問題の要点は、「大きさ」の降順でシステムをランク付けすることです (定義については上記を参照してください)。スケールは任意ですが、関連性を持たせるために以下のスケールをお勧めします。

• 100 スペースシャトル生命維持装置、
• ?? アプリケーションX
• 1 つの Hello World コンソール。

上記の 3 つのシステムに加えて、人々がスロットインで作業した他の大きなシステムのランキングを見て、展望を示すことに興味があります.

データ収集 Web アプリケーションのフロントエンドを作成しています。データ収集アプリケーションを使用するオペレーターは、12 の異なるプロジェクトのデータをログに記録し、各プロジェクトには異なるフィールドが必要です。いくつかの一般的なフィールド (名前、住所など) がありますが、各プロジェクトには、収集する必要がある追加データ用のカスタム フィールドもあります。プロジェクトによっては、数十の追加フィールドが必要な場合もあれば、1 つまたは 2 つのフィールドのみが必要なプロジェクトもあります。この状況を処理する「クリーンな」方法を考えられる人はいますか? 私はプロジェクトごとに入力ページを作成したくありません。また、UI テンプレートを XML で作成するというアイデアを検討している人もいます。どんなガイダンスでも大歓迎です。

私は新しいソフトウェアアーキテクト/リーダーであり、ソフトウェア開発者のチームのためのソフトウェア設計を考え出します。要件仕様、インターフェイスヘッダーファイル、Visioソフトウェアの設計ドキュメント、ビルドプランなどを考えています。

私の質問は、この期間中にチームの他のメンバーは何をするのかということです。私は確かに彼らをデザインに携わっていますが、チーム全体が私がいつもやっていることに積極的に取り組んでいる必要はありません。

新しいソフトウェアアーキテクトのための良い本はありますか？

現在、製品の開発者向け API機能に取り組んでいます。

最初のバージョンがリリースされ、現時点では少数のユーザーしか使用していません。2 番目のバージョンの開発を開始して以来、API をよりエレガントで明確にするために、いくつかの部分が作り直され、いくつかの部分が削除されました。

ただし、2 番目のバージョンの展開は、古いバージョンのユーザーにとっては苦痛になる可能性があります。当社のマーケティング部門は、API 製品を大幅に強化し、機能を追加することを計画しています。

1)
新しい興味深い機能を追加するために「古いバージョン」に制約されないようにするには、どのようにシステムを構築すればよいでしょうか?変更された API

それとも、仕様に大幅な変更がないように、公開リリース前にかなり長い期間、サンドボックスで API 製品をテストする必要がありますか?