各アプリケーション-Redmine形式の1つのプロジェクト
たとえば、モバイルアプリケーション「焼きたてのパンを検索するには」。 ほとんどの場合、アプリケーションにはWeb、Android、およびiOの3つの側面があり、プロジェクトの構造は次のようになります。
- プライマリ-ウェブ（すべての組織的な問題もあります）
- サブプロジェクト1-iO
- サブプロジェクト2-Android
プロジェクト内のタスク
タスクステータスの標準プロセス（M.-マネージャー、P。-プログラマー）：M. Sozdana→P. In work→P. Reshena→M. Zakryta。 （ M.必要に応じて、K-clientに変更します ）
タスクパラメーターの改良：M.作成済み→P.フィードバック→M.フィードバック→P.作業中。
タスクのタイプ：エラー-バグ修正、サポート-スケジュールされた作業、改善-元の計画に含まれない作業。
小さいながらもWikiでは容量が大きい。
例：FTPアクセス、チームメンバーの連絡先など。 言い換えれば、本質的に管理上の情報です。 Redmine-チームの各メンバーが必要なすべての情報にアクセスできる単一の情報スペースを構築したいという要望。
Git
必須の靭帯コミットタスク。 可能であれば、完了した1つのタスク（コミットされたコミット）のルールに従います。 したがって、それどころか、各コミットにタスクが付加されます。 コミットを記述するとき（commit -m）、タスクID-"refs #Issue ID"を指定します。
データベース移行
プログラマーは、プロジェクトのルートにmigration.sqlファイルを作成します。このファイルには、データベースを作成するための指示が含まれています。
ファイルストレージ
ファイル-プロジェクトディレクトリ内にファイルを保存します。 プライマリプロジェクト（デザインおよびUI）内の適切なフォルダー内のPSDおよびPDF。 したがって、描画の履歴は保持され、hddの場所は残念ではありません）。
テストケースの説明。
プロジェクトが進行するにつれて、マネージャーとプログラマーは、アプリケーションのテストシナリオを説明します。 各マイクロリリースの終わり、スプリントの終わりに、プロジェクトの回帰テストが実行されます。 リリースで完了したタスクに基づいて、ドキュメントが補足されます。
マイルストーン
プロジェクトの開始時に、プロジェクトマネージャーがプロジェクトの開発の重要な段階を評価する、継続的な統合のイデオロギーをサポートします。 そして運用計画にそれらをマークします。 たとえば、5月15日の「ユーザー登録は可能です」。 したがって、プロジェクトの長さ、専門家のコストと負荷を概算できます。
実際にはテストされていません
各プロジェクトのスプリント期間は3〜5営業日で異なり、各チームごとに個別に設定されます。 スプリントの開始時に、チームは次の反復のタスクを共同で選択します（タスクに対する設定された優先度と個人的な関心が考慮されます）。 スプリントの最後に、チームは以前のスプリントのコースを議論する「回顧展」で会合します。原則として20分以上かかりません。 そのため、入力にタスクがあり、スプリントプロセスでそれらが解決され、結果として作業インターフェイスが得られます。 スプリント中に問題が解決しない場合、コメントのプログラマーが理由を説明します。 各スプリントの終わりに、チームは回帰テストを実施します。
プロジェクト実装アルゴリズム
- Redmineでのプロジェクトの初期化。
- UIの開発。 「プロジェクトフォーラム」でUIブランチが開きます。 PDFファイルは、フォーラムのメッセージに直接添付されます。フォーラムでのUIのディスカッションは、オフィスでの会議をキャンセルしないことに注意してください。 UIが完成して同意されるとすぐに、ファイル「Final UI.pdf」が「ファイル」セクションに表示されます。
- プロジェクトマネージャーは、並列プロセスの設計とプログラミングで最初のスプリントを開始します。 運用計画に貢献：スプリント完了日、バージョン0.1。 設計を議論するために、フォーラムでスレッドが形成されます。議論には、マネージャー、デザイナー、UIスペシャリストが含まれます。 UIの場合のように、フォーラムはライブ会議をキャンセルしません。 結果には一貫性があり、「ファイル」セクションに「最終設計」ファイルが表示されます。
- レイアウトとプログラミングの段階は、別の記事に値します。
PSだから、％ユーザー名％、私はあなたに連絡しています。 すべてのアイテムは実際にテストされ、