並行開発プロジェクトのスケジュール

1 回のリリースですべてのアップグレードが行われる従来のソフトウェア開発とは異なり、オンラインアプリケーションはいつでもアップグレードできます。開発の容易な機能強化であればテストは少なくてすみ、優先度が高い場合はすぐにエンドユーザにリリースできます。そのため、リリース管理では開発作業のスケジューリングが重要なステップになります。IT 組織の場合、これは開発プロジェクトを短期、中期、長期などのカテゴリに分けることを意味します。これらのカテゴリは多くの場合、開発を行う環境、必要なテスト量、新機能のリリース期限によって定義されます。

カテゴリは必要な数だけ使用できますが、最初は 3 階層から始めるとよいでしょう。プロジェクト期間の他に、次のような方法で開発作業をカテゴリ化できます。

開発を行う環境:

• 本番のみ — 機能の開発とテストをすべて本番 Web インターフェースで行える場合、開発サイクルを速めて、ユーザに早く機能を提供できます。
• メタデータ API コンポーネント — 必要なコンポーネントがすべてメタデータ API で使用できる場合、各環境の変更を追跡してマージする作業がはるかに容易になります。
• 1 つの Sandbox — 機能を 1 つの Sandbox で開発してすぐに本番組織にリリースできる場合、開発サイクルには統合環境やステージング環境は必要ありません。
• 複数の環境 — 開発プロジェクトが複数の Sandbox で行われることがあります。この場合、コード行の統合がより複雑になります。複雑なプロジェクトによって、単純なプロジェクトのロールアウトが止まらないようにします。

開発者の数:

• 1 人 — 1 人の開発者が機能を作成、テスト、およびリリースできる場合、変更のマージの問題やその他の時間のかかる問題が発生する可能性は非常に低くなります。
• 小規模なチーム — 小規模な開発チームの場合、大規模なプロジェクトを扱いやすい単位に分割すれば、迅速な開発が可能です。このようなプロジェクトは、開発者 1 人のプロジェクトと簡単に統合でき、すぐにロールアウトできます。
• 大規模なチーム — 大規模な開発プロジェクトには、大規模な開発チームが必要です。このようなプロジェクトには、さまざまなコードブランチで行われた変更の追跡とマージ、受け入れテスト、その他の関連プロセスが必要になり、開発プロセスのスピードが低下する可能性があります。