ソフトウェア開発プロジェクトの迅速な開発のためのまとめと要約

ソフトウェア開発プロジェクトの迅速な開発に関するまとめ#

プロジェクトの進行中に何が起ころうとも、すべての議論や会議はプロジェクトに関するものであり、個人には関係ありません。なぜなら、プロジェクトは一つの全体であり、一人の不足はプロジェクト全体の不足です。共に頑張りましょう〜

紹介#

この文書を書く目的は 2 つあります：

プロジェクト管理におけるプロセスと問題に注意を向けるために自分自身を整理すること
プロジェクト管理に転身したい人やソフトウェア開発プロジェクト管理の初心者に役立つ情報を提供すること

説明#

ソフトウェア開発プロジェクト（Android、iOS、Web など）のプロセスは基本的に共通しており、理解できない場合はまずこれを適用し、各ステップごとに各ポジションが何をすべきかを理解し、タスクの目標を明確にし、タスクを適切に割り当て、プロジェクトを迅速に提供することを目指します。

プロセス#

ソフトウェアプロジェクトの開発プロセスには、プロジェクトの立ち上げ、ビジネス機能の整理、製品のプロトタイプの定義、プロジェクトのテスト計画の定義、プロジェクトの開発計画の確定、開発プロセス、テストプロセス、品質検査、プロジェクトの納品が含まれます。これらはプロジェクト開発の主要な内容であり、詳細は後で説明します。一般的には、関連する役職（プロダクトマネージャー、プロダクトオーナー、UI、テストエンジニア、開発者、品質管理）が関与します。

立ち上げ#

外部委託プロジェクトまたは自社プロジェクトであっても、プロジェクトの要件は三者または自社の市場調査またはフィードバックによるものです。一旦確定したら、プロジェクトの内容、方向、関係者を決定するために立ち上げ会議を開催します。

私たちがプロジェクトに参加する場合、最初から参加するわけではないため、立ち上げは別途説明します。

その他#

フェーズ	内容	責任者	備考
機能リスト	プロダクトマネージャーが主導し、プロダクトオーナーが補助し、市場や三者の要件やフィードバックに基づいて関連する要件を整理し、プロジェクトの機能リストを確定します。	プロダクトマネージャー	プロダクトオーナーが補助
プロトタイプ	プロダクトマネージャーが担当し、機能リストに基づいて整理します。	プロダクトマネージャー
テスト計画	テストエンジニアが機能リストに基づいて、一部はプロトタイプを組み合わせてテスト計画を整理します。テストは全シナリオのカバレッジなどを考慮する必要があります。	テストエンジニア
開発計画	開発者がプロトタイプを評価し、作業タスクを評価し、各モジュールの開発責任者とタスクを確定し、開発計画を完成させます。	開発者
開発プロセス	プロジェクトの開発プロセスでは、開発とテストを同時に行います。開発は段階的に行われます。テストも段階的に行われます。すべての機能の開発が完了した後、全機能の開発が行われます。	チーム	開発プロセスの説明を参照してください
品質検査	プロジェクトオーナーが提出し、専門の品質管理者が品質を検査し、成果物が基準を満たしているかどうかを確認します。	品質管理者
プロジェクトのまとめ	プロジェクトの納品の品質が高いか低いに関係なく、後続のプロジェクトのまとめを行う必要があります。今回の開発プロセスでの利点と欠点をまとめます。	全員

例を挙げて説明します：#

例えば、私たちは現在、長期プロジェクトである全プラットフォーム（Android、iOS、Web）のショッピングプロジェクトを開発することになりました。立ち上げや市場などの要素をスキップし、直接プロジェクトの開発プロセスに入ります。具体的なタスクは次のとおりです：

現在の要件を整理し、第 1 段階の納品目標を議論して確定します（長期プロジェクトのため、各イテレーションは 2 ヶ月とします。簡単に言えば、2 ヶ月ごとにバージョンを定めます）。具体的なプロジェクトの機能リストを確定するために、納品目標に基づいて作業を進めます。
```
要件（1-2日で完了）：
	1. セール機能を追加する
	2. 代金支払い機能を追加する
	3. クーポン機能を追加する
```

機能リストが確定したら、会議を開催して以下の目的を達成します：

機能リストは上記の要件と同じです（1-2日で完了）

 * プロジェクト関係者がプロジェクトの内容を理解する
 * 要件が適切かどうか、機能などが実現可能かどうか、または実現には追加の条件が必要かなどを確認する
 * 各機能には統一的な認識が必要であり、認識が異なるとプロジェクトの機能方向がずれる可能性があるため、この要求は非常に重要です（高い要求ですので、ゆっくりと磨いていく必要があります）
 * このステップを繰り返し、機能リストが完全に確定し、関係者の認識がほぼ一致するようにします。

プロダクトは機能リストに基づいてプロトタイプを設計します。会議で以下を議論します：

プロトタイプは省略します。タスク量に基づいて完了予定日を確定します（通常、2ヶ月のプロジェクトサイクルで、プロトタイプは2日でほぼ完了します）

 * プロトタイプの設計が適切かどうか（インタラクションなど）
 * 実現可能かどうか（認識のずれなどの要因があるか）
 * このステップを繰り返し、プロトタイプが完全に確定し、関係者の認識がほぼ一致するようにします。

テスト大纲（1-2 日で完了）は、プロトタイプと並行して、機能リストに基づいて作成します。プロダクトと開発者との間で詳細を議論することもできます。主に機能リストに基づいてテスト大纲を作成します。会議で以下を議論します：

 * テスト大纲が適切かどうかを確認する
 * テストシナリオが十分にカバーされているかを確認する
 * テストのステージとテストの時間を明確にする
 * このステップを繰り返し、テスト大纲が完全に確定し、関係者の認識がほぼ一致するようにします。

開発計画（1-2 日で完了）（4 つのプラットフォーム：Android、iOS、Web、バックエンド）は、テスト大纲と並行して作成されます。機能リスト、プロトタイプ、テスト大纲、および自己の機能分割に基づいて作業内容と時間を評価し、開発計画を完成させます。会議で以下を議論します：
```
 * タスクの分担を確定する
 * タスクの時間軸を明確にする
 * 機能の分割はできるだけ細かく行い、開発の進行に応じて調整することが望ましいです。通常の機能は2日ほどで提出し、困難なタスクは評価に基づいて提出します。提出後、テストがすぐに行われるようにします。
```
開発プロセス：
- 計画に基づいて、開発の機能を定期的に提出します。
- 計画に基づいて、テストを定期的に実施します。
- 開発の主な内容：機能ごとの開発、テスト、および機能ごとのバグ修正（通常、次の段階の開発時にバグ修正を行うように要求しています。特定のバグ（時間がかかり、影響範囲が小さい）は後で処理することもできます。）
- テストの内容：プロジェクト全体でテストタスクが非常に重要であり、ほぼプロジェクト全体の開発プロセス中にテストが行われます。問題を発見し、解決し、プロジェクトの品質を向上させることが目的です。
  - 機能ごとのテスト（プロジェクトの時間に基づいて回数を決定します。2 ヶ月のプロジェクトサイクルでは、3 回の機能ごとのテストを推奨します。）、バグの提出、バグの受け入れ
  - すべての機能が開発された後、全機能のテストに入ります（開発の提出時間は約 3 日で、実際の状況に応じて調整します）、テスト時間は 2-3 日です。
  - 全機能のテスト後、プロジェクトの品質を評価し、システムテストに入ります。
  - システムテスト（通常 2 回以内で、プロジェクトに大きな変更がないことを求めます）が合格した場合、成果物が合格したかどうかを確認します。合格しない場合は、合格しない機能を削除して、タスクの時間軸を守り、品質検査をスムーズに合格させます。
  - システムテストが合格したら、プロダクトの品質を確認します。
  - プロダクトの受け入れ：テストレポートとテスト大纲に基づいてプロジェクトの成果物を受け入れます。
1. プロジェクトのまとめ
  - プロジェクトの進行中に発生した問題をまとめる
  - 各人がプロジェクトの進行中に発見した問題や不足点を発表する
  - 問題の解決策について議論する
  - プロジェクトの進行中に発見された利点を発表する
  - プロジェクトの利点と欠点をまとめるために、プロジェクトの責任者がまとめる。
2. その他の注意事項：
  - プロジェクトの進行中に臨時の要件が追加された場合はどうすればよいですか？
現在のプロジェクトの時間軸、機能、要件の優先順位を評価し、優先順位に基づいて調整します。原則として、時間ボックスは変わらず、プロジェクトの開発機能を置き換えるか、削除することになります。

まとめ#

プロジェクトの開発プロセスでは、何が起ころうとも、すべては人が行うものであり、人が行うということは間違いを com する可能性があるということです。したがって、PO（プロジェクトオーナー）としては、プロジェクトの異常な状況に常に注意を払い、状況に応じて話し合いや調整を行う必要があります。プロジェクトの進行中に何が起ころうとも、すべての議論や会議はプロジェクトに関するものであり、個人には関係ありません。なぜなら、プロジェクトは一つの全体であり、一人の不足はプロジェクト全体の不足です。共に頑張りましょう〜

注：

文章の書き方が苦手で、個人的な経験です。嫌なら批判しないでください。