不作為または不正確な場所、会社でアジャイル開発手法で歓迎の批判がある場合は、この概要は、記録された、私の要約から来ています。
いわゆるアジャイル開発は、ウォーターフォール開発の点で伝統的なウォーターフォール開発厳しいコンプライアンス要件事前計画分析と等価である、各ステージは、対応する文書を行う設計、コーディング、試験手順のすべての段階を有します。主な問題は、困難または高価な調整の後半の変化に減少要求リードに自由厳密階層度です。
開発するコア、反復インクリメンタル、漸進的なアプローチとして、ユーザーニーズへのアジャイル開発、早い段階でプロジェクトをビルドするが、いくつかのサブプロジェクトに分割された、各サブプロジェクトは、独立して動作し、この過程で相互作用することができるソフトウェアでされている実行することができます状態;各サブプロジェクト等の設計、コーディング、テスト、いくつかの段階を経る必要があり、別々に開発するために、いくつかのサブプロジェクトに大規模なプロジェクトを分割することと等価である、ことを確認するために、リスクを軽減し、各サブプロジェクトの成功を確保大規模なプロジェクトの最終的な成功全体、大規模なプロジェクトは、しばしば、複雑なサブプロジェクトの複数に分割し、後部を制御することは困難であり、各サブの複雑性が低くなり、プロジェクトはより成功するように、
以下は、アジャイル開発を行うための様々な段階あり、アジャイル開発は終了して実行する方法ということです。
1、チームビルディングの段階：
このチームの分布が固定されていないことを意味しますが、クロスファンクショナルチーム、同じ大きさが、小さな安定した滝の開発チーム、などのアジャイル開発チームの機能モジュールで作られた構造の組み合わせに基づいて、任意の時点で、例えば、開発の最初の反復における6つのサブプロジェクトにプロジェクト分割、5つのサブ機能モジュールへの最初のサブプロジェクトの開発における更なる分割は、小さなチームの5つの大グループに分割することができる、各チームディストリビューションの開発、ニーズやテスターに対応し、それぞれが小さなチーム責任者を必要とし、この人は、サブ機能モジュールの責任であることが必要進捗と品質を担当し、各反復で、スタッフや流通部門の小さなチームや担当者指定は固定されていません。
2、分析フェーズを必要とします：
プロジェクトは、いくつかのサブプロジェクトに分割され、各サブプロジェクトが複数のサブタスクのモジュールに分割され、各モジュールは、アナリストのための対応する需要があり、需要が需要で、要件文書を作成し、テストを行って、このサブタスクモジュールの需要にする必要がありますシステム全体へのサブタスクモジュールの相対は、難易度が大幅に削減されているが、そこに開発され、テストは、参加して、テスターや顧客を開発提示し、議論し、それぞれの最終案は、文書のニーズから分岐する必要があるとき、テスターや顧客一緒通信員、需要の正確さを保証することが可能です。
3、設計段階。
各サブタスクモジュール開発者は、現在の反復、タスク分割および見積り、以上の分割粒度によって開発されたタスクプログラムのために設計する必要が 2 時間と、タスクを超えた場合に、適切で2 時間、さらに分割をお勧めします。設計グループの完了は、古い開発者の設計レビューを認定した後、一つは、第二に、不合理なデザインで見つけることができ、タスク分割のサイズにガイダンスを提供するために、かどうかを評価した場合、サブタスクが合理的である判断します不足しているタスクの項目があります。
サブタスクのに入る分割する必要性により、デザインレビューの後 JIRAを指導者たちは常に開発プロセスの開発の現在の進行状況を表示することができますので、行きます。
4、実施段階をコードします。
通勤、朝と夕方には長すぎない時間になります前に、開発フェーズは、毎朝開かれて、朝と夕方に開きます 10 ダオ15 分が適切である、会議はプロセスで、自分のペースの下で皆を報告し、主でしたスケジュールへの影響は、評価の下で影響力の範囲が他のメンバーに2時間の夜間クラス、またはリクエストを追加することにより、例えば、制御の範囲内であれば発生しませんでした何の進展に影響を与える問題や課題があり、サポートは解決することができ、通常はそれが制御可能な範囲内で解決されて、覚えて作ることができます。大きすぎる場合、それはデザインやタスクの分割の前に重大な問題があることを示し、この時間をタイムリーに調整プログラム戦略のリーダーシップの必要性についてなど他の上司をサポートする会社に依頼。
5、テストフェーズ：
2つの段階でのテスト段階、一つは開発はすでに完了の時間であるとき、開発作業がまだ完了していないです。前者の場合は、テストは、テストのための開発環境である場合には、早期にこの時間は通常となります。早く、毎日朝の会議時間をキャンセルされる時、開発者は、テストの進行状況だけでなく、アジャイルチームのグループに遭遇するリスクについて行わテスターを開発しました。
アウトテストテストバグは、毎日残り、時間の変化に開発されるバグの一定範囲内のコントロールの数、および最終的には制御不能を回避するために進行、および他の比較的大きな変化は、あなたがコードを実行するためにグループ内の経験豊富な開発者に依頼する必要があることに留意すべきです破壊を避けるために見直し、バグリードの結果、複数のバグ現象を、
図6に示すように、反復反射要約ステージ：
各反復の反復がラップアップミーティングを開くために必要とされるが完了した後、会議は改善するためのソリューション、次の反復を見つけるために、発生した問題を議論することを提案し、これらの問題の理由の核心を要約したもの;場合反復の複数の方法が有効であることが確認され、それは制度の方法で固定することができます。