アジャイル開発の効果【画像表示】
アジャイルはソフトウェア開発の法則により一致しています
ソフトウェアは生きている植物のようなものであり、ソフトウェア開発は
段階的かつ秩序ある成長のボトムアッププロセス
からのものであり、ソフトウェアの客観的な法則に従って機敏な
植物の自然な成長と同様に
、継続的に反復的な増分開発、顧客価値に沿った製品の最終的な配達
アジャイルソフトウェア開発とは何
ですか？
アジャイル開発は
概念的なフレームワーク
です。この概念的なフレームワークは
、アジャイルマニフェストの価値観と原則を
満たす一連の方法と実践で構成されています
。
アジャイル開発
は固定されていません[たとえば、固定された手順はありません
。たとえば、自分の家を自由に飾ることができます。気分]、それは異なる機能と自己管理を持つチームと協力することによってチーム自身の環境を満たす一連の実践と方法から徐々に進化しています。
1.アジャイル開発の波
アジャイル開発を使用している企業を見てください
アジャイルな開発プロセス：これは、数百人の大規模なチームであろうと、数人または2人の小規模なチームであろうと、ユーザーのニーズを完全に[ユーザーが望むソフトウェアをすばやく実現する]ことを可能にする開発モデルです。
- ISO 9000（09エディション）規格は、元の8つの原則に機敏な原則を追加します
- 2000年に、米軍のソフトウェア開発標準（DOD 5000.2）は、ソフトウェア開発の優先モードとして反復を推奨しました。
- 世界で最も影響力のあるAmericanBaldrige National Quality Awardは、敏捷性を11の主要原則の1つとしています。
2.アジャイル開発の歴史：[ソフトウェア開発は、重いプロセスから軽量のアジャイルまで、時代の変化に適応します]
| 1960年代の ソフトウェアワークショップ | ソフトウェアは小規模で、主にワークショップで開発されています[たとえば、2人でプロジェクトを開発する場合、プロジェクトが緊密に連携していれば、大きな変化があっても、ソフトウェアは比較的小さいので、書き直すのは大変です。可能な限り] |
| 1970年代の ソフトウェア危機 | ハードウェアの急速な開発とソフトウェアの規模と複雑さの急速な増加がソフトウェアの危機を引き起こしました[ワークショップスタイルの開発は時代遅れであり、ソフトウェアは適切なプロセス管理と科学的開発プロセスなしでより大きく、より要求が厳しくなっています非常に厄介。たとえば、戦争では軍隊が散らばり、戦争で全員が逃げ出したかもしれませんが、ここでも同様です。プログラマーはお互いの責任を怠ります。後で書かれた製品はユーザーが望んでいるものではないかもしれません] |
| 1980年代の ソフトウェアプロセス制御 | 製造業の成熟した製造管理手法を導入し、ある程度緩和された「プロセスを中心としたプロセス」（ウォーターフォールモデル[ラフプロセス：需要分析->設計->コーディング->テスト->製品]）で段階的にソフトウェア開発を管理します。ソフトウェアの危機[ソフトウェアを複数の段階に分割し、各段階の作業は異なりますが、ウォーターフォールモデルのプロセスはより複雑であり、それに応じてコストが高くなります（各プロセスは多くの制約や制限を増やす可能性があるため、制御が困難です））】 |
| 90年代の 重いプロセス | ソフトウェア障害の経験により、プロセスに対する制約や制限が増えています。ソフトウェア開発プロセスはますます「重く」なり、開発効率が低下し、応答速度が低下しています。 [ユーザーがニーズを変更したい場合、それは非常に困難になります。難しい、おそらく開発を待つ、ソフトウェアが古くなっているため、この方法はあまり柔軟ではありません] |
| 2001-アジャイルは今日人気があります | 情報時代の到来により、要件は急速に変化する可能性があり、配信サイクル[ソフトウェアが高速であるほど優れている]が企業のコア競争力になっています。変更により適応できる軽量で機敏な開発方法が一般的に認識され、変更されています。すぐに人気が出ました。 |
3.アジャイルマニフェストはより良いソフトウェア開発方法を明らかにします
私たちは、実践的な練習を通じてより良いソフトウェア開発方法を明らかにし、他の人が練習するのを助けています。この作業を通じて、私たちは次のことを信じています。
[アジャイルマニフェスト-値]
| 1.個別のやり取り[顧客と開発者&&開発者チーム間のコミュニケーション] |
ビート | プロセスとツール[アジャイルにもプロセスとツールがありますが、相互作用がより重要です] |
| 2.動作するソフトウェア[ドキュメントは完全に書かれていますが、私たちの目標はソフトウェアを作成し、ユーザーに使用可能なソフトウェアを提供することです。ユーザーは次のように述べています。これは私が望むものではありません。ソフトウェアを反復することで、最終的なソフトウェアはユーザーのニーズにより一致します] | ビート | 包括的なドキュメント |
| 3.顧客の協力[文書と顧客の要件の理解に違いがある場合は、ソフトウェアが出たり、破れたり、揺れたり、協力的な精神で顧客とコミュニケーションしたりしないようにします] | ビート | 契約交渉 |
| 4.変更への対応[ユーザーのニーズの変化に最短時間で対応し、計画通りの変更に追いつかないようにし、ユーザーはゴミを手に入れるために多額の費用を費やしたと感じます] | ビート | 計画に従ってください |
右の用語には価値がありますが、左の用語の方が価値があると思います
アジャイルマニフェスト（2001）は
、アジャイルの起源の基礎です
。これは、上記の4つの単純な値で構成されています。アジャイルマニフェストの署名は、アジャイル運動を促進します。
アジャイルマニフェストの本質は、ソフトウェア開発のより良い方法を明らかにし、ソフトウェア開発の価値とより良い仕事をする方法を人々に再考するように促すことです。
4.アジャイル開発の12の原則[指導原則、ただし静的ではない]
- 1. 私たちの最大の目標は、価値のあるソフトウェアをできるだけ早く継続的に提供することにより、顧客を満足させることです。[初期の段階で、最もコアな機能を実現するバージョンを作成し、ユーザーがそれを使用してユーザーの提案や意見を確認できるようにしました]
- 要件2.変更は歓迎されている-でも、プロジェクト開発の後期段階に。私たちは、顧客が競争上の優位性を獲得できるように、需要の変化をうまく利用する必要があります。[市場は非常に急速に変化しているため、他の顧客がこの同様のソフトウェアを入手する前に、このソフトウェアを使用する顧客の市場はそれほど大きくないと言われています。したがって、ユーザーは変更を提案できます]
- 3.使用可能なソフトウェアを継続的に提供するには、サイクルは数週間から数か月の範囲であり、短いほど良いです。[目的：ユーザーの提案やコメントに従ってソフトウェアを変更し、可能な限りユーザーを満足させます]
- 4.プロジェクト中、[要件を理解している]ビジネス担当者と開発者は協力する必要があります。[問題がある場合は、時間内に見つけて修正します]
- 5.プロジェクト担当者の動機付けに長け、必要な環境とサポートを提供し、タスクを完了できると信じます。[搾乳するだけ]
- 6.チーム内であろうとチーム間であろうと、最も効果的なコミュニケーション方法は対面での会話です。[文書交換、中国の文化は広範で深遠であり、同じ中国語の文字が誤解される可能性があることは誰もが知っています]
- 7.利用可能なソフトウェアは、進捗状況の主な指標です。[ソフトウェアの進行状況を測定するためにソフトウェアのドキュメントやモジュールを使用するのではなく、利用可能なソフトウェアを使用してください]
- 8.アジャイルプロセスは持続可能な開発を促進します。プロジェクトパーティ、開発者、およびユーザーは、一定の安定した進捗率を維持できる必要があります。[ユーザーに相談し、問題がないかすぐに確認して、すぐに変更してください]
- 9.テクノロジーの洗練とデザインの継続的な改善により、俊敏性が向上します[機能が増え、テクノロジーが増え、完璧なデザインで効率が向上します]。
- 10.簡潔にする、つまり、不要な作業を最小限に抑える。これは芸術です。[各モジュールは簡単な方法で実装されます]
- 11.最高のアーキテクチャ、要件、および設計は、自己組織化チームから提供されます。[誰もが自発的に、命令されたチームではなく、より意識的に物事を行うので、心の質は良くありません。ライブラリを直接削除して逃げるなど。]
- 12.チームは、それがより効果的になる方法を定期的に検討し、それに応じてチームの行動を調整する必要があります。[最善はありませんが、より良いだけです。たとえば、この方法で可能ですが、欠点と改善点は何ですか]
12の原則がチームのR＆D文化を導き、その原則を順守するには、チーム
による継続的な調整も必要です。
原則自体を守ることは非常に難しいことです、これは機敏なチーム調整の
目標です
5. Agileは、生産性、品質、満足度、およびコストを大幅に改善しました
