私の以前の記事はここにあります：
パート1
パート2
パート3
パート4
パート5
開発アプローチ
市場とプレイヤーは更新の頻度を非常に要求しています。 したがって、3週間に1回リリースされます。 もちろん、より頻繁に-より良いですが、すべての開発プロセスはあなたによってデバッグされるべきです。 さらに、リリースに十分な機能を蓄積する必要があります。 機能コマンドのおかげで、このペースを構築しました。
プロジェクトの開発を開始したとき、クライアント開発者があらゆるタスクを引き受けることができるように努めました。 それから、各従業員がいくつかのタスクをより良く実行し、他のタスクをより悪く実行することに気付きました。 主任開発者は、専門化のためにタスクを割り当て始めました。 このアプローチはQAチームによって採用されました。
そのような作業の1年半後、チームは次のようになり始めました。
15人のプログラマ。
9人のテスター;
3人のテクニカルアーティスト。
このアプローチにも欠点があることに気付き始めました。 開発者は同じタスクを実行したため、プロジェクトへの影響を感じなくなりました。 専門能力の開発も遅くなりました-まれなタスクを行う必要はほとんどありませんでした。 「それらの」コードにはいくつかのセクションがあり、別の開発者がサポートしているコードに変更を加えることを恐れています。 チームリーダーは、タスクの分散、レビュー、およびコンサルティングに多くの時間を費やしました。
開発へのアプローチを根本的に変えることにしました。 複雑な問題を解決できるサブコマンドを作成しました。 これにより、開発サイクルが閉じられました。
開発者の専門分野を分析した後、次の領域を特定しました。
- サーバー部分とクライアントモデルのプログラミング。
- コア開発-ゲーム機能とUIの実装。
- サードパーティのライブラリとサービスの統合、iOS / Androidプラットフォームおよびさまざまな支払いシステムとの連携。
- Unityで開発をレンダリングする-たとえば、シェーダーを作成する。
その後、開発チームを3つの機能チームに均等に分割しました。 それぞれ1人のテクニカルアーティストが同量のQAを追加し、Jiraのワークフローを変更し、このアプローチを使用するためのルールを説明しました。
プロジェクトマネージャーは、プロジェクトコーディネーターによって既に分析および記述されている機能チーム間でタスクを分散します。 それらはすでに開発者の要件を満たしています。 この後、マネージャーは次のリリースに必要なタスクに注意する必要があります。 次に-期限までに要件を明確にし、優先順位に従って手配し、各チームが何かすることを確認します。
チーム自身が、タスクの実装に誰を割り当てるかを決定します。 チームアクティビティの必要性を自ら判断し、テストとコードレビューを実施して、完成したテスト済みタスクを出力として提供します。
アプローチの利点：
- 開発者は新しい挑戦に挑戦することができます。 これらは、これらのコンポーネントを専門とする人に助けられています。
- プログラマーはテスターとより密接に対話し、プロジェクトへの影響をよりよく感じます。
- リードは、Jiraではなくチームと連携する時間を確保できます。
短所：
- チーム全体の有効性の低下。
- Jiraで作業を整理し、各開発者の個々の貢献と有効性を評価することは困難です。
Gitflow開発
以前はSVNを使用していました。 彼は問題を起こさず、通常の流れに違反せず、誰もが常識を守っていれば、すべてを整理しました。 定期的に、失われたリビジョンに関連するマージに問題がありました。 それらを解決するには、かなりの時間がかかりました。
機能コマンドの作成と並行して、gitに切り替えてGitFlowを導入しました。 イノベーションの本質は、ブランチを扱うための厳格なルールにあります。
- 安定したコードを持つブランチ。
- リリースのみが該当するブランチ。
- バージョンごとに新しい機能とホットフィックスを開発するためのいくつかのブランチ。
このアプローチの詳細については、 こちらをご覧ください。
Unityには、シリアル化されたリソースのマージに問題があります。 私たちと一緒に、PrefabEvolutionが広く使用されるようになりました。 残念ながら、良い解決策は見つかりませんでした。 競合する可能性のあるリソースには取り組みません。 たとえば、NGUIアトラスはすぐに安定した開発ブランチにコミットされ、すべてのブランチ間で分岐します。 このため、機能ブランチが凍結されるまで、ビルドに未使用のグラフィックが存在する場合があります。