ただ、新しい学生を普及するために、いくつかのプロジェクト全体のプロセスの経験とgitLabの規範で、プロジェクトを終了し、ライン上の厳しい取得します。
最初の製品は、要件文書を書くことになり、私たちは一緒に議論のフロントエンドと、UI、その後、バックエンドの製品を叫ぶ、一般的な理解を持っているプロジェクトの要件の文書を見ている - 議論の場合のプロジェクトについて、プロジェクトでは、明確な理解を持っています私たちは、研究が必要で、機能時に行っていません。変わらないのは、地元の何ロジックとUI感じることができないプロジェクトの全体の相互作用フロー図を考える。図未完成のUIを見てみましょう、製品ヘッド一緒に、私は、バックエンドに呼び出すことを覚えているとき、あなたはバックエンドの人々の良い議論を持っていない議論しますあなたはそれが起こっているのかを知っています。あなたが不快な厄介なレイアウトのいくつかを見て、しかし、あなたに話すことができるとUI UIベース場合は、すべての後、人々は、このだけでなく、同社は最初、我々は確かにあなたは量を調整することはできませんPSDダイアグラムが発生しただけでなく、条件を遵守する必要はありませんでした来たんあなたはUI PSD図を頼む方法のうちの3つは、「ウェブ側の相互作用の規範を」ルックアップし、UIは地図上の距離のピクセルを識別できるようにそこにあります。第三は、一般的ですが、我々はコンポーネントライブラリを持っているので、通常の距離を測定していません。
明確な意識を持つプロジェクトでは、あなたが開いているこのリンクとの接続点を詳しく説明しているものを識別するために、クラス関係をクラス図を描画するために始めることができます https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html 描き、そうでありませんか関係は彼らの教師を頼むことができます理解していないクラスは、クラス図は、実際に最優先で行うにはクラス図を維持するためにコードを書き始めるまでの時間です。この時点でモックもバックグラウンドで開発することができます。
その後、UIマップが完了した後、私たちは業務プロセスとユーザーの双方向性を反映するための対話、対話型のタイミング図のタイミング図を描画するために始めることができ、インタラクティブなタイミングは、エリアが問題だろうなUIを持つ相互作用の全体像のUIの外観を与えるためにあなたが言いました。
プレビューと見なさ完全な画像チェックのマスターまたは頭部いるので、その後、あなたは相互作用の特にタイミング図、チームの残りの部分に説明するのは、これらの2つの数字を取り、チームメンバーがアイデアに同意する必要があることをリハーサル、リハーサルを開始することができ、成功。彼らのプロジェクトはgitLabに問題を分割する必要が通じリハーサルの後、
リハーサルの説明の発達：もちろん、最初の問題は、プロジェクトのタイトルがあるような：試験v1.0のプロジェクトのマイルストーン、結果をプレビュー - 図やクラス図をタイミング対話するコメントを送って図やインタラクティブな要素を、タイミングクラス図を含め、開発者プレビューを問題、およびコメントの頭をプレビューの問題を開発するために閉じることができます。
あなたは/見積2Hとして推定時間でこの問題を検討する必要がある問題、H Hを作成すると、dは日数です。
実際の時間が長い理由を超えて検討する推定時間を超えた場合にレビューの問題を完了するために必要な実際の時間は、/ 2H過ごします。
プロセスの完全な問題：
---- ----問題の予想完了時間は、完全な変動問題のマークを作成し、問題をプッシュすることを選択した上図の問題のコメントを作成するときに、コードの完成のための分岐目標期限----- ----問題リアルタイムのコメント - 問題へのコメントはタイムアウト理由でタイムアウトが--- DEVに合流している場合
見つけるために問題が無ければ問題は、それぞれの問題の説明は、各質問に書かれ、その後、別の問題を作成しているの外に検討する場合には、試験の前にコードレビューの必要性に言及し、すべての準備ができて言及したテスト問題を完了し、コードは、問題を作成するために、レビュー審査の担当者はコメントで行われ、その後のdevのリリースをマージ
DEVは、サービス・テスト・アドレスをバックエンドのためにバックエンドには、プロジェクトの運営・維持管理をテストしたいアドレスに、リリース良いWebPACKのをマージする前に設定する必要があります。
あなたはあなたの問題は、バックエンドのテストであり、彼が任命しましょうと言うことを見つけた場合、あなたは彼のためにバグテストは、テストの問題中に作成され、問題があなたに割り当てられている見つけた場合、成功は言及して測定された場合でも、解放し、プロジェクトを実行するためにマージバックエンドに、コメントが発行問題推定時間を受け取った後、終了時刻を変更、我々は以下のチャートに従って作成する支店名が完了した後に、実際の終了時間を確認する必要があります。
そして、あなたはのdevのリリースにマージし、テストに割り当てられ、その後、問題を閉じるためにマージあなたの修正/ XXX支店を置きます。
試験の後、試験は内部の事前オンライン問題で、我々はフロントエンドのチェックを事前にオンライン通知を作成し、チェック項目を確認し、relaseが製品に割り当てられたマスターにマージテスト、バグを発見した場合の行に、合併オンライン通知問題の後に製品をオフにしますRCのマイルストーンは、RCのマイルストーンオンラインバグの問題を指して、masterブランチでブランチを作成するときに作成した製品を作成するには、バグがマスターに直接分岐ホットフィックス/ XXXの合併DEV、DEVマージを完了しました。
プロジェクトの最後の行は問題ありませんした後、インクルードが戻っDEVとリリースにマージ習得。最後に、このプロジェクトは、いくつかのポイントを要約し、最終的にプロジェクトの概要書かれたプロジェクトのwikiを書くとき覚えてラップアップミーティングを開きます。
