γ相事後分析
ビジョンと目標
1.当社のソフトウェアは、この問題を解決するには？明確に定義されたかどうか？典型的なユーザーと典型的なシナリオの明確な説明はありますか？
- 私たちが解決しなければならない問題：実験室の登録情報は、創造性で動作するようにして分離を達成するために散乱しにくいれます
- 典型的なユーザー：この段階では、学生や研究室用
- 典型的なシナリオ：
2 私たちは、（本来はそれを提供するために計画通りの機能はもともと？いくつかの配信を行うことを計画？もともとユーザー数がそれに達し到達するために計画された？）まだ目標に達しました
- 特長当初の計画：協力、信頼、創造性とフォーラムの基本的な機能を公開し、ラボステーション内委員会の手紙懸念のコレクションや他の機能に参加する後半デモの後に切断
- 配達時間は：開発の第一段階が配信を延期する障害がありますが、計画通りガンマは完全に終了しました
- ユーザー数：130以上予備希望の目標を達成
3. それを改善するためのソフトウェアエンジニアリングチームの品質に比べて、ステージ上の？改善されたもので、どのように測定するか、特定の数を増やしますか？
主に反映され、特定の改善があります。
- チームワーク：実行中の期間の後、みんなの協力が徐々に改善され、誰もが積極的にタスクを完了するために、自らの責任を認識しています
- 仕事の質：学習運動の最初の2つのステージでは、ほとんどの時間は、開発に割り当てられていると、新しいコンテンツを学ぶコードの品質を向上させる、（ダースのバグが5または6の単段の削減）のバグの数を減らすための時間を短縮することができます
4. ユーザーの量は、ユーザーが事前に重要な機能の受け入れに関する合意を何を期待していますし、それより近いから、私たち？私たちの目標？
予想内のユーザーが、重要な機能のユーザーの受け入れのと我々はいくつかの偏差を期待。ユーザーは、我々が目標と一貫性のあるユーザーを調整し、よりラボを、使用することを好みます。
5. レッスンは何ですか？また改めて歴史は、我々は改善するために何をするでしょうか？
- 教訓：総合計画を策定し、詳細な引数を実装するようにしてください。実装プロセスでの発見の前にいくつかのアイデアは、実装頻繁にそれを調整することは不可能です。
- 彼らは繰り返すことができる場合：マルチパーティの協力の発展を双晶の実装では、引数を達成することができ、詳細についての深い議論を達成するために
計画
1. 計画を行うのに十分な時間がありますか？
はい。あなたは、事前の計画との議論で週間半を思い付くことができます。
計画段階での2チームは、計画のための不一致の同僚を解決する方法ですか？
実際の不一致が多くを持っていなかった、我々は、開発者の意見を考慮するために注意を払います。
3.あなたは最終的に行われていれば、あなたが行っていない場合は？計画、そしてなぜ仕事しますか？
私たちは、完成されています。不要な部分を切り落とし、また、いくつかの新しいものを追加しました。
あなたには、いくつかの知恵を持っていない4.検索は必要ありませんでしたか、あまりのためにカウントされませんか？
そして、いや。実行する前に一部の機能（手数料）は、事前に切断し、その後、必要はありません発見しました。
5.各明確に定義されているタスクと、測定可能な成果ですか？
あまりにも特定の配信基準れることなく、二重基準の実用的な実装を検討し、ページの内容に特定の要件が、厳格なフォーマットを貼りません。
プロジェクトが計画に従って行った場合6.全体のプロセスは、プロジェクトがどのように起こりましたの？どのようなリスクを推定していない理由は、推定されていませんでしたか？
現像不良のアルファ段階の存在は、ベータ相は、いくつかの余分な機能を発見し、再学習新しい知識へ。プロジェクト担当者は、バックエンドの書き換えで、その結果、すべてのバックエンド技術者の移転をあまりにも重要に移動します。私はそれがリスクに対処するために苦労して非常にタイトな時間になります期待していませんでした。
7.計画、バッファの役割、それに残されたバッファがありませんか？
バッファを残すために二、三日があります。バッファは、いくつかのバグのフィードバック機能や小さな気まぐれの増加を固定するために使用されています。
8.今後は変わり何だろうか？
みんなの人事計画、タスクのより合理的な配分に組み込まれました。
9. 私たちは何を学びましたか？すべての上に再び歴史の場合、我々は改善するために何をしますか？
重合同じタスクは厳格に、割り当てのバランスをとるカップリングの品質を向上させるために固執しない、完全な人をお届け。
あなたは再びそれをすべて行う場合、我々は、動的なミッション計画もビジー待機現象を軽減します。
リソース
1.私たちは、タスク、それを満たすのに十分なリソースを持っていますか？
時間リソースの不足。十分なマシンリソース。
2.各タスクに必要な時間や他のリソースがどのように正確さを推定する方法ですか？
符号量と品質評価によれば、コード、良好な精度の最終段階。
3時間のテスト、人材とソフトウェア/ハードウェアリソースは、プログラミングのリソース（グラフィックデザイン/コピー）のない方のために？十分であるかどうか難しさを過小評価しますか？
少し緊張の時間をテストするだけでなく、少し緊張人員（5）。適切なハードウェアリソースは、あまりプログラミングのリソースを必要としない、難易度が素晴らしいではありません。
4.あなたは今まであなたが他の人が（より効率的に）やらせるために行うことができます感じたことがありますか？
タスクの一部は、同じ人々がより効率的で質を行うために配信することができます確かにあります。
5. レッスンは何ですか？また改めて歴史をした場合、我々は改善するために何をしますか？
人間と時間のリソースを大幅に進捗に影響を与えます。
オーバーRuoguo再び、我々はベータ段階の開始時に二つ以上のメンバーを募集します。
変更管理
メッセージが変更されたことをタイムリーに1.各関連の従業員？
はい。私たちは、通信し、労働者が実現の完了後にグループを引き継いだプッシュします。
2.どのような対策我々は「延期する」と「達成されなければならない」機能決断を採用していますか？
ユーザートラフィックとユーザーのフィードバック、体重調整によります。
3.輸出プロジェクト（終了基準 - どのような「完了」）の条件は、それの明確な定義がありますか？
美しく、実用的な、ないバグ：私たちは、3つの基準を持っています。
危機管理計画かどうかの可能な変更4.？
はい、それは問題を解決することに集中します。
5.従業員が効果的に予想外の作業要求に対処することができますか？
はい、チームメンバーがタイムリーで追加のタスク要求を処理することができ、以下の機能を実現するために自己啓発を達成するために。
6. 歴史はすべてやり直す場合は、我々は？学んだ、我々は改善するために何をしますか？
誰もがチームの担当で、自分自身のことを行う必要があります。
それは、再び、我々は小さないくつかのコメントを書く時間の量、および文書のカドガン開発の使用が必要になることができますが、私たちの時間の事実は十分ではない場合。
設計/実装
どのような時に、誰1.デザイン作業が行われていますか。右の時間は、右の人ですか？
冒頭で始まる達成するために、すべてのメンバーが共同で設計され、人々との適切な時期です。
2.デザインの仕事は、チームが解決されるか、あいまいな状況に遭遇していませんか？
コンテンツの一部を決定することができない、それは開発を選択しようとしたままにした、ビューを検討するために、開発者に焦点を当てました。
3.設計を支援し、実装するために、チームの使用単体テスト（ユニットテスト）、テスト駆動開発（TDD）、UML、または他のツールをしていますか？これらのツールは動作しますか？UMLドキュメントプロジェクトの開始時との違いは何である現在の状態を比較しますか？これらの違いはどのように発生するのですか？あなたはUMLのドキュメントを更新しますか？
一定の効果を達成するのを助けるために設計されたテストユニットを使用します。私たちはバックエンドを書き直しているため、書き換えするプロジェクトのUMLの基本的なプッシュの開始からの相対。
4.最も汎用性の高い生産バグ、そしてその理由は何ですか？出版は、何か重要なバグを発見した後、なぜ私たちは、設計/開発期間中にこれらのケースを考えていませんでしたか？
通信局アップバグは、チャネル繰り返し送信現象がステーション、欠失現象を生じます。主なテストは非常に包括的ではなく、テスト時間はテストするのが難しい機能の完全な実現のリリース前に、十分ではありません。
5.コードレビュー（コードレビュー）は、コード仕様の厳格な実施するかどうか、続行する方法ですか？
主にフロントとリアエンドの開発マネージャにより、コードレビューは、仕様は非常に厳密ではない、我々は改善する必要があります。
6. 私たちが学んだ何？もう一度歴史場合は、私たちが改善するだろうか？
アジャイルプロジェクトが完了するまでに事前に計画し、不測の事態のすべての種類に対処するために良いことがあります。
我々は再び、我々は十分なバッファの安定性試験を残し、全体の1〜2日前倒しで準備しますことができます。
テスト/リリース
1.チームは、テスト計画を持っていますか？なぜか？
チームはラフテスト計画を持っていた、テスト担当者は、詳細なテスト計画を持っています。
2.正式な受け入れテストするかどうか？
公式受け入れ、変更を反撃に失敗。
3.チームがテストを支援するテストツールを持っていますか？
使用Django coverage、私たちのユニットテストコードカバレッジを追跡し改善し、改善すること。
4. チームは、ソフトウェアの有効性を測定し、追跡する方法ですか？ソフトウェアの実際の動作の結果から、これらのテストは、便利な動作しますか？どのような改善を持っている必要がありますか？
主にテストを強調する。ビューのテストの観点から、いくつかの余分なコードを見つけることが、非常に有用ではない制限され、主要な改善が実装コードに依存します強化します。
5. のリリース時に予期しないどのような問題を発見しましたか？
パスワードの変更は、任意の形式に変更することができ、我々はテストを無視します。
6. 私たちは、あなたが再びそれをすべて行う場合は、我々は改善するために何をしますか？何を学びましたか？
私たちの経験：安定性を確保するためのテストに十分な数の必要性。
再びすべての場合：コードの改良された実装を示すために、追加的な加速を実現しています。
チーム管理、協力の役割
1. 各チームが役割を決定する方法を、最高の使用はないですか？
個人的な意見を考慮して、我々はすべての仕事をしたいん。
2. チームメンバーの間であり、それはお互いを助けますか？
いくつかは、ペアプログラミングの習慣は、開発プロセス全体を続けました。
3. 場合は、プロジェクト管理の出現、問題を解決するためにどのような協力の問題、チームメンバー？
方法を議論するために直面して、顔を、責任者を特定し議論し、再び修正することは非常に有効です。
概要
1. チームの現在の状態がでグレードCMM / CMMIに属しますと思いますか？
私たちは、全体的な開発プロセスの後、私たちのチームは基本的に「管理レベル」の要件に達している、と信じています。
2. あなたは、チームが現在あると思いますか つぼみ/ランニング/仕様/作成 段階のどの段階か？
私たちは、私たちのチームは、「標準」の基本的な要件フェーズに達したことを感じ、比較的高い意識と責任感となっている、協力はお互いの良い感じ、矛盾した表示されません。
3. あなたは側面を改善するために最も必要があるどう思いますか？
コードの仕様。この問題が繰り返し強調し、まだ頻繁に発生しており、異なるメンバーは、基準がいくつかの違いがあることを感じました。
4. 比較アジャイル原則、あなたはあなたのチームは何が最善かと思いますか？
最後に到達することは困難で予期しないイベントの数を扱います。
- バージョンを開発するための失敗があります
- バックエンドの開発者の転送
- パネルのメンバーの時間の制約（仕事、実験室、コンクール、審査）
しかし、我々は最終的に開発計画として完成します。
5. 次の段階で、我々は改善をしたいです
- 安定性：圧力負荷容量を増大させる、コードのアーキテクチャを最適化します
- コード規格：厳格な形式の要件、増加精査
- 広報活動の強化：ユーザーの数は非常に我々はより広範な宣伝する必要がありません
チームメンバーは描写します
（Mmは1週間帰ってクラスメート、ライン下の写真はありません）
