ソフトウェア工学の分野では、このようなウォーターフォールモデル、ラピッドプロトタイピングモデル、インクリメンタルモデル、スパイラルモデル、進化のモデル、噴水モデル、RADモデル、アジャイルソフトウェア開発モデル、XPの極端なモデルとして多くのソフトウェア開発モデルは、あります。それぞれが自分のシナリオを持っているので、多くのモデルは、それぞれが独自のスコープを持っているが、私が最も実用的な開発モデルやアジャイルソフトウェア開発を考えます。
中国のソフトウェア開発のアイデア何それ？基本的には一つの共通点持って、私が遭遇している観点から、ほとんどのソフトウェアプロジェクト、 - 高速である必要があり、顧客は短気です、私はあなたに製品を考え出す明日、今日のプロジェクトのために待つことができません。
会社の顔と、顧客の要件は、私たちが行うための手段を持っていることを、テンポの速いですか？人々は、生産から出てくるし、効率的かつ高品質な開発モデルであるセットのうち住むいる - アジャイルソフトウェア開発。
それはアジャイルソフトウェア開発とは何ですか？
アジャイル開発は、ユーザーのニーズに基づいてソフトウェア開発のためのコア、反復的、漸進的なアプローチとして進化します。アジャイル開発では、ソフトウェアプロジェクトが早期ビルド複数のサブプロジェクトにカットされ、各サブプロジェクトの結果は、目に見える統合され、動作特性と、テストされています。言い換えれば、それが相互に複数に大規模なプロジェクトにあるが、急速な発展の目的を達成するためには、それぞれ、独立して小規模なプロジェクトの実行および完了することができます。
または特にアジャイル開発が達成される方法では？
図1に示すように、システムは、大部分に分割されます。
私たちはこのプロジェクトのアイデアは、研究、分析、調査研究報告の後と要求仕様の様々な要求に最初で受信する前に、戻って取得する必要があり、その後、アウトライン設計（UEデザイン、UIデザイン、インタラクションデザイン、データベース設計、フレームデザイン問題がある場合、次のステージへの進行、ステージは、それがプロジェクトのプロセスのすべての段階に影響するとき）、概要設計、詳細設計前に完了している......サイクルダウンなどAは、時間がかかりすぎます。
アジャイルはそれぞれ、我々はグループの複数のグループに分けることができるように、サブプロジェクトであること、及び、サブサブモジュールに分割し、モジュール間の結合を最小限にするために、その増加凝集性であろう大規模システムに分割されグループが同時に動作することができます。モジュールを変更する必要があるとき加えて、他のモジュールへの影響は難しいの開発を削減するという目標を達成するために多くのではありません。
前述の不動産情報ネットワークプラットフォームの構築では、我々はそれぞれ、独自の取引、証券会社の取引、ユーザー権限の管理、建設委員会や他の外部インタフェース、資産の大部分、トランザクション管理、プラットフォーム管理の背景、Webサイトのフロントエンド・モジュール、にシステムを分割します需要の議論は、議論は、次にモジュールは個々のオブジェクトに分割要求する、オブジェクトは、単に外部のオブジェクトとの関係の発生を最小限に抑える、公共を通じてオブジェクトと可変情報との間を通過します。
概要：落下1までの分割
2、チームと顧客との滞在
通信コストを削減するために、私たちのチームは、顧客とのコミュニケーションする準備ができてお客様のサイトへの直接のすべての担当者は、顔の通信に直面して理解する上での違いを減らします。プロジェクトの様々な段階では、我々は通信、通信気軽に、クローズアップお客様と維持しています。このように、私たちは、初めての需要、問題を解決し、エラーの可能性を減らす、開発効率を向上させ、高品質の開発を確保するための最初の時間を得ることができます。また、それが顧客の信頼を得るために、この方法で容易になるだろう、顧客がプロジェクトの作業状況、作業の進捗状況の通知を保つことができます。ときはお互いに信頼関係は、残りの作業はリラックスして幸せになります。
不動産プロジェクトでは、我々は、顧客サイトで仕事をいくつかの小さな不確実性がある場合には、ニーズやデザインを議論するために定期的に開催、チームメンバーが直接顧客関連の検証があります。過度の需要は、プロジェクトサイクルを通して変化しませんでした。
概要：顔通信への顧客の顔をして、相互信頼を促進し、取引コストを削減します。
図3は、モデリングと通信します
むしろ、大量の文書によるよりも、ユーザーのニーズを取得するモデルと、顧客と通信するためにモデルを使用して、時間がかかり、非効率的に文書化します。実際に、私たちのほとんどのためのテキストとさまざまなパラメータを確認するために多くの時間を過ごすために好きではない、とモデルは、より直感的でステレオになります。私はこのモデルが使用して、ユースケース図、クラス図、展開図、状態図、アクティビティ図、パッケージ図、オブジェクト図、プロトタイプ図面、E-R図を含み、当社の通常の設計プロトタイプ、を参照していないと言います異なるグラフィックスは、製品、豊富な三次元製品の異なる寸法を発現します。
不動産事業では、当社は、対象物を表現するクラス図で、データベース設計を伝えるERで、顧客の需要にプロトタイプを議論し、情報交換プロセスを説明するためのアクティビティ図で、展開図、ハードウェアの導入環境とネットワーク構造によって決定されますタイムライン内のオブジェクト間の相互作用を表現するタイミング図。より直感的になり、この方法を使用して、チャートの様々なを通じて産物を発現し、エラーを検出したとき、それは維持が困難文書、変更の不便の使用とは異なり、変更することも容易であるために、読解力を助長されていません。
概要：代わりに、モデルの文書交換を使用します。
4、変化を受け入れる勇気
市場環境は、私たちが目の市場を維持する必要があり、ベンチマーク製品です。市場を満たすために、製品はいつでも変更する必要があります。需要の変化、設計変更......の様々な変化レッツ・打撲とボロボロますが、私たちの製品はまた、変更、製品の唯一の急速な変化を受け入れなければならないとして、将来のために良いことができます。私たちは、それは開発段階であっても、需要がありそうな変化にもある限り、それが合理的であるとして、変更を歓迎します。アジャイル開発は変更を通じて顧客に大きな競争力をもたらすために変更することができます。アジャイルレコードがチャートを使用する必要がある、すべてのコードモジュール設計の、異なる機能は、相関を減らすために、可能な限り分割されます。それはそれは、変化の理由を満たすためにあえてことができるものです。
提到了敏捷的一个很重要思想就是“勇于迎接变化”。就有人说了，你一定不是技术出身的吧。做技术的就讨论变化，最不允许的就是确定的需求再修改。当产品经理与技术人员沟通时，当谈的一个复杂性操作时，经常说：“你确定不会修改了吧，如果你确定需求不变，我就做！”，你要答应了，再找技术修改时哪就等于堵死了自己的后路。实际，哪能一定有不修改的需求呢？我们做产品不也是时刻在迎接市场的考验吗？在大海上航行，当风向变化，我们的大船不也得时刻准备掉头，准备调整。变化，本身就是为了适应，没有变化，就等于没有进步。但作为产品经理的我们，能做的应该是利用自己的智慧和敏锐的市场洞察力，尽量的去感知风向，尽量的控制需求，在需求发现初期就做好充足的调研。怕变化，不是办法，在项目初期就要做好灵活可调整的方案，如果需求真的变化了，我们应该怎么办，这才是敏捷的思想，需求的变化，我们谁能阻拦得了呢？5、実行することができます初期の結果の早期かつ継続的デリバリー
私たちは、顧客の信頼を失っている主な理由は、技術的な理由のために、一般的に、前のプロジェクトの失敗をないと述べています。私たちは、お客様が私たちの熱を感じるようにすることを、継続する必要があり、顧客に信頼感を与え続ける、1は、顧客サイトでの当社の一定の通信で、通信。同様に、あなたはまた、対応する結果であったと私たちの能力を確認することができ、（製品を実行するために）顧客を顧客に提供し続け、できるだけ早く必要です。もちろん、これは別の利点は、早期に問題を公開する機能であり、後の露出を解決するために、より困難それ以前の問題点を解決するために、のみ、事前に公開、人々を見ることを恐れて、少し女性のよう敬遠しないでください。
コンテンツのコンパイルは問題ありません日後に完了不動産プロジェクトでは、プロジェクトの進捗状況を把握するために、顧客はいつでも変更を見ることができるように、サーバープラットフォーム上で展開機能を変更します。質問があれば、その後、できるだけ早く露出させることができます。
概要：プロジェクトのリスクを軽減するためには、早期の配信がプログラムを実行することができます
図6に示すように、顔の通信に顔
通信の最速の形態は、直接通信するための最も迅速な方法で、この冗長な、非効率的な通信を削減する方法を促進する大部分の顔の通信、アジャイル開発の面です。技術者、設計者、クライアントやチームメンバー全員がその通信がスムーズになるように、情報交換回路を削減するために協力しましょう。
交換する必要が私に直接しているときに問題があるが、理解していないとき不動産プロジェクトでは、私は顧客に直接知りません。私はありません場合は、私の同僚は、誰もが直接需要を得ることができ、顧客と直接通信します。
概要：直接通信、中間リンクを減らします
7、ワーキングソフトウェアは、最も重要な尺度であります
文書のいかなる量、中間製品のノー量は、より現実の結果ではないではありません。ほとんどのお客様は、心臓の中間のビューではありませんが、結果が得られました。アジャイルソフトウェア開発のために、ソフトウェア缶の仕事は、開発の進捗状況を評価する最も重要な尺度です。歌うはどんなに良い、良いをやって、あなたはスタイルとノー物質をプレイしていない、本物の、アジャイル開発の感覚はコアがあり、落下していないされていません。
概要：メイクソフトウェア・デリバリーは、プロジェクトの中核であります
8、開発の一定の速度を維持するために、
プロジェクトの開発は、短期の長距離ランニング、急加速され、長距離走、我々はチームメンバーが最後まで主張されていることを確認するように、実行中の連続、統一的な方法であるべき方法ではありません。アジャイル開発は、持続可能な開発の速度を提供するので、チームメンバーだけでなく、疲労だろうが、開発サイクルのプロジェクト開発の開発、および制御にも資します。
概要：プロジェクトの開発プロセスはマラソンではなく、スプリントスタートです
9、定期的に最適化チーム
当社は、定期的に個人とチーム開発の仕事に影響を与える問題やボトルネックを特定し、批判と自己批判を行って、チーム作りを行います。交換を通じて、コミュニケーションとチームのメンバー間の問題を特定し、その後、継続的な最適化により、自己調整、独自のチームをアップグレードし、戦闘が可能なチームを構築します。
10、アジャイル開発ツールを使用しました
CORNERSTONEは、大手企業がインテリジェントにR＆Dプロジェクト管理の痛みのポイントを解決するために管理するために大規模なアジャイル開発チームのためのワンストッププロジェクト管理コラボレーションプラットフォームに適している、それは継続的な配信と統合をサポートし、我々は様々な寸法を通じて、プロジェクトの進捗状況を追跡することができます、補完対象で簡単にチームに役立ちます。
より多くのガントチャート、看板、マインドマッピング;これは、プロジェクト管理のニーズのチームワークとアジャイル開発を完了し、ヘルプの企業にアジャイルチーム、タスク、要件、欠陥、テスト管理、WIKI、共有ファイルやカレンダー機能モジュールを提供しますヘルプ企業に、バーンダウンや他の多次元ビュー、状況を制御するための包括的なプロジェクト。
一方、CORNERSTONEはまた、ファイルストレージと共有、ドキュメントコラボレーション機能が付属しており、チーム間のリアルタイム通信を実現することができます。言い換えれば、選択CORNERSTONEは、文書コラボレーションツール、ファイルストレージと共有ツール、社内チームのコミュニケーションツールを選択する必要がないかもしれません。
また、製品の開発、販売、運用だけでなく、行政審査と承認を使用することも可能でCORNERSTONEの管理。間違いなく大幅に管理コストを削減している企業向け統合管理プラットフォームを使用してください。
总结：プロジェクトマネージャはアジャイル開発を使用することをお勧めすることができた場合は、ゲームの世界で使用される楽器を持つことと等価であるグルメの世界では、マスターの道を調理します。そのような「開発テスト駆動」などがあり、他の多くのアイデアがありますが、いくつかの考えと私は同意しないアジャイル開発では、中国では外国で、外国CMMIで、テスト要件が非常に高いとは異なり、実際のテストは品質です検査部門、品質管理部門は、テスターの非常に高い権威がより尊重と認識されています。国内では、同社が開発し、複数の光テストは、同社のテスターと開発者からあなたの給料はもっと注意が誰であるかを、見ることができます。テスターが開発を推進しましょう、現在の現状を行うことがやや困難です。時々私は先人たちがより多くの多目的利用を参照してください、本当に学ぶべき、非常に多くの良いアイデアをまとめ、必ずしもすべての適用可能なアイデアを持っていないされている、それぞれのアイデアは、独自の成長の土壌を持っていると思いますない限り、より多くの肥料として、より多くの水が良い作物を栽培することができるようになります。時には、我々はそれがより多くの私たちの環境に適応しているかどうか、植物の習慣を見なければなりません。CORNERSTONEは今、無料でできる20人以下のチームのために適用されます。
