著者：柯Zicong / eamoiアジア旬テクノロジー・ソフトウェア・エンジニア、に特化したWeb アプリケーションの開発、注意OA 、ポータル、電子政府、電子商取引、RIA 、の著者「Ajaxの開発エッセンシャル- 概念、ケースとフレーム、」ブックそして、「Ajaxの開発ブリーフ」、「Liferayのポータル二次開発者ガイド」およびその他のオープンソースドキュメント。
個人ブログ：http://www.blogjava.net/eamoi
本文：
ソフトウェアプロジェクトは、プロジェクトからの典型的な需要主導型のプロジェクトで、開発は、納品までテストし、需要の繰り返しの変化は通常のものであり、これは大規模なプロジェクトのために特に明らかです。需要反復制御が良くない場合は、プロジェクトの失敗で、その結果、プロジェクトのリスクを高めることは容易です。また、著者のプロジェクトに類似しており、国内の多くのソフトウェア企業問題の需要の繰り返し。本論文では、反復を命じた要件を投射することを期待して、需要の反復と、プロジェクトのリスクコントロールとの間の関係を探るために、実際のプロジェクトと組み合わせる需要反復、から始まります。
需要の反復、必然的なサイクル
市場の需要の調査を通じて、市場や顧客のニーズからソフトウェアプログラムを起動し、ターゲット顧客の典型的なニーズは、抽象的要求仕様にアクセスして、プロトタイプシステムの評価は、実際のシステムを起動した後に、プロトタイプシステムを設計し始めました設計と開発。
プロトタイプシステムの設計段階では、このようなずれがあります理解して実際のニーズ、またはビジネスアナリストのニーズを明確にしない顧客など、様々な要因に起因し、それに応じてプロトタイプシステムを市場に関連している可能性が設計し、顧客の需要は真実ではありませんそれが構築されたプロトタイプシステムの深化と、それは必然的に反復ニーズをトリガーする、一致しています。
実際のシステム設計・開発プロセスでは、システムの理解の深化と、要求することができる顧客は、深め拡張または変更することであった、反復ニーズをトリガーするR＆Dエンジニア消化の需要。
でも、実際のシステム・デリバリー場合、事業開発で、顧客のニーズが変更されることがあり、その過程でシステムを使用して、顧客は、システム要件への更なる改善を行うためにバインドされ、オリジナルの特徴の動作モードを変更し、新しい機能を追加これらは、さらなる反復の需要が必要になります。
よく反復プロセス、反復のコスト見積もりを、制御されない場合は、このシリーズの反復プロセスでは、需要の効果的な管理をイテレーション、需要無限の反復の錯覚、各反復のニーズに圧倒プロジェクトチームを形成することが容易です、ハイテンション、予見可能な将来の内、リリース日のプロジェクトの開発は、それが確実にプロジェクトに高いリスクをもたらすでしょう。
おむつのプロジェクトは、北米市場向けの電子商取引サイトであることは三年間のために実行されています。最近の顧客は上の決定おむつアップグレードするプロジェクト。顧客の通信を担当するプロジェクトマネージャーやエンジニアは、分析、顧客の真のニーズの抽象的分析を必要とし、要求仕様を書いた、ソフトウェアエンジニアは、要求仕様に応じて技術的なソリューションを開発し、コーディングを続行するために、テストエンジニアは、要求仕様とテストケースに合わせてプロジェクトをテスト、プロジェクトを管理者は、最終的なプロジェクトのプレゼンテーション能力を確認し、必要なときに反復プロセスの要件を開始するためにユーザーを誘導します。
のでおむつは北米からのプロジェクトをアウトソーシングしている、2時間差の間の通信があり、プロジェクトチームや顧客と通信するための条件が直面して。反復回数の後に需要の偏差を理解するため、コミュニケーション不足やビジネスに、プロジェクト全体のアップグレードプロセスでは、時間を必要とする、チームのメンバーは、各繰り返しの面倒な手動ニーズの束に直面する必要があります。以来おむつすでに完全に動作サイト、顧客の市場からの圧力だけでなく、プロジェクトチームに渡さ体、プロジェクトが圧力リリースチームのメンバーを悩ませてきました。おむつビューのプロジェクトポイントの進捗状況、需要が反復の無限のサイクルです。
アクティブトリガー需要反復消化するのに十分な時間が与えられ、
その結果おむつプロジェクトの状況の主な理由は、受動的なニーズの反復、反復顧客からのフィードバックによってトリガ受動的です。すべてのチームが反復が、より大きな圧力解放をもたらすために、プロジェクトのリリースチームのインパクトを開発計画を中断することが必要です。したがって、我々は主導の需要の繰り返しを制御する方法を見つける必要があります。
各反復の需要は効果的な方法を消化するのに十分な時間を与えています。おむつビューのプロジェクトポイント、需要が処理を消化していない最後の時間は、新しい反復の需要が再び始まりました。プロジェクトでは、需要の反復、新たな需要を段階的に進めてきたに追いつくことができないだけで、反復速度をリリース。この場合、テストエンジニアは、単純に包括的なテストを実施するためのプロジェクトのために十分ではない時間を持っています。
問題の性質が確認され、おむつのプロジェクトチームは、リリースのリズムを調整する人材への投資を増やし、消化ニーズをスピードアップするために始めた、不十分なコミュニケーションの問題のため、プロジェクトマネージャは、顧客とのコミュニケーションに焦点を当て、疑問で可能な限りの時間断面の両方に我々は明らかに通信する必要があります。調整出版リズムの後、顧客がテストを実行するために、プロジェクトチームと同期する時間を持って、バグはまた、最初の時間を処理することができ。調整後、プロジェクトチームは、需要の各反復を消化するのに十分な時間を持っていますが、またプロジェクトをテストするのに十分な時間を持っています。
早期リリースイニシアチブのプロトタイプシステムは、需要の反復をトリガする別の効果的な方法です。素早くプロトタイプシステムを構築するには通常、実際のシステムのデータの操作の仮想シミュレーションを通じて、アナログ・インターフェースと機能のプレゼンテーションに焦点を当てています。これはかなりの程度にコミュニケーションの効果的な媒体として、将来の顧客需要の短い抽象的で明らかに実際のシステムのプレゼンテーション、および顧客をシミュレートすることができます。顧客はできるだけ早く実際のシステムとそのニーズとのギャップを見つけることが容易になり、抽象文書の束に関して、プロトタイプシステムを使用して、で、将来は反復回数を削減する必要があります。
したがって、抽象化プロセスの需要は、プロトタイプシステムは、当事者とメディアの間の通信ブリッジとして採用されるべきで、双方は、プロトタイプシステムのプレゼンテーションの最初の議論すべきです。また、プロトタイプシステムのリリース時には、プロトタイプシステムをできるだけ早く公表する必要があるプロジェクトの開始後に、より重要です。
クレームプロジェクトは、商用プラットフォームの事故の保険金請求、北米のお客様はオンライン報告のため、市販の傷害保険でサービスを主張します。プロジェクトの早期開始では、プロジェクトチームは、抽象の基礎を理解する必要があり、最初の時間は、仮想現実システムを提供する仮想データ・インタフェースを使用したプロトタイプシステムをリリースしました。このプロジェクトは、顧客自身の雇わアナリスト、ビジネスニーズの理解の最高度、顧客ニーズの正確な表現に比較的有利であり、詳細なプロトタイプのインタフェースを描き、これは二つの側面との間の通信及びシステム開発プロセスで再生しますより重要な役割。以下のために主張需要も反復回数あったが、すべての後、まだ管理可能範囲内にいるが、プロジェクトのリズムの需要の反復は、プロジェクトチームの許容範囲内であったが、このプロジェクトは、整然とした進歩しています。
各反復のコストとリスクを評価します
これは、各反復は、このようにコストをもたらし評価するために必要なプロジェクトへの影響の程度が異なる、要求することを予見している可能性があります。だけでなく、プロジェクトマネージャと分析エンジニア、ソフトウェアエンジニアとテストエンジニアを必要とするが、この繰り返しがポイントを備え、既存の技術的なアーキテクチャは、影響を受ける可能性があり、かつそのシステムのモジュールを変更する必要がある、テストケースそれが必要かどうかに影響するかどうかを評価するために、このプロセスに参加すべきですリライトは、チームはこの繰り返しの時間コストを支払うために余分に多くを必要とするので、上のプロジェクトの延長につながるとします。
プロジェクトの進捗状況の繰り返し需要が重大な影響を引き起こす可能性があれば評価の後、プロジェクトマネージャとクライアントは、特に時間コスト、反復のコストのニーズを知らせるために効果的なコミュニケーションでなければなりません。
また、各反復の需要は、技術的なリスクおよび発行リスクを含め、プロジェクトにいくつかのリスクをもたらすためにバインドされています。反復後の需要は、特にコアビジネスロジックの変更で、オリジナルの技術的な解決策に影響を与える可能性があります。技術的な解決策は、このソリューションは、まだ本来の目的を達成できるかどうかを確認するために、整理するためにチームを再します。需要の反復の後、ソフトウェアエンジニアは開発の調整に時間がかかりますし、テストエンジニアは、必然的にプロジェクトのリリースサイクルに影響する再試験に基づいて、システム上の新たな需要を必要とし、プロジェクトマネージャーとしてこれを予想しなければなりません。
GSのプロジェクトは、できるだけ早く、その競合他社が同様の製品の新バージョンをリリースする準備をしている、その製品をアップグレードしながら、研究開発会社は、対象製品として政府機関行政審査と承認サービスに焦点を当てた製品の市場圧力の要件でありますアップグレード版を完了します。新製品は、統合テスト・フェーズに入ろうとしたときしかし、会社が突然、製品の主要な調整のインターフェースを比較することにしました。この調整は、製品のリリース時には、2ヶ月遅れて徐々に新製品への期待が低下してきたセールス、マーケティング、顧客の黄金期を逃したリワークにコードを主導し、テストし、製品の売上高の結果が予想よりはるかに少ないです。会社の前に反復はコストとリスクのインターフェース要件の明確な評価を持っている場合、それはそう性急なトリガ反復すべきではありません。
おむつプロジェクトチームを意識おむつの需要の反復ごとに、ソフトウェアエンジニアとテストエンジニアが仕事のすべての必要な量を消化するための要件とテストを決定するための共同プロジェクトマネージャを評価しますので、プロジェクトの反復サイクルのニーズが比較的短いです、したがって、時間とコストや技術的なリスクをもたらす可能性があり、チームメンバーは心の需要反復の恐怖から自由に壊れています。
プロジェクトがリリースさ明確な境界を必要とします
ソフトウェアは、反復需要は無限大です、完璧ではありません。イテレーションサイクルの需要は、明示的に各小バージョンの境界を求め、それが最終版では、この期間のいくつかの小さなバージョンの間に放出される可能性が、その要件のすべてを含め、不確定です。これは、各マイルストーンを越え、長距離が途中でいくつかのマイルストーンを実行しているようなものだに集中して一歩前進を意味します。
それぞれが制限された機能要件の小さなバージョンを含む、テストエンジニアは、早期トリガーこれらの機能の要件をテスト同時に起動することができるバグを、テスト時間のために努力しています。お客様は、事前にこれらの小さなバージョンからの実際のプロトタイプシステムを見ることができ、エスカレーションのバージョンで、リリース日からプロジェクトが近づいている、と需要のギャップがますます小さくなってきています。
私たちは、最初にその利益の必要があります。私たちは、国境やトラックの需要を管理するために、いくつかの既製のツールを使用することができますバグなど、JIRAを。JIRAは、プロジェクト計画、タスク割り当て、需要管理、経営課題の追跡を提供し、商用ソフトウェア、のいずれかで、バグ追跡、状況分析とフォローアップ、プロジェクトカテゴリ管理、構成要素である/ モジュールのリーダー、プロジェクトの電子メールアドレスおよびその他の機能。多くのよく知られたオープンソースプロジェクトが使用しているJIRAを。
することでJIRA 、あなたは、顧客を統合するプロジェクトマネージャ、開発者、テスター、その役割の様々なチーム内でその職務を行うことができますすぐに、事前に潜在的な問題への暴露を情報とフィードバックを交換し、制御項目を促進することができます。
図に示すように、1 及び図2 に示す、とJIRAの支援事業、各プロジェクトのような種類のさまざまなタスクをサポートするために、新機能、バグ、タスクおよび改善は、またカスタマイズすることができます。
図1 JIRAのサポート、複数のプロジェクト
図2 JIRAは、複数のタスクの種類をサポートしています
JIRA プロジェクト管理、タスク管理および欠陥管理の考え方のイデオロギーワークフローの統合、および項目を設定し、モジュールのバージョンを許可し、各需要、タスクを処理するために、指定された人のための目標期日を設定します。図3 、図。
図3 JIRAの人に割り当てられたタスク
JIRAは等、各項目の優先度を設定することができブロッカー、クリティカル、メジャー、マイナー、トリビアルに示すように、各タスクの重要性を識別する、4 図。
図4 JIRAのサポートの優先順位付け
如图5所示，如果任务定义了优先级，那么在每个人的桌面上，任务会自动排列。这点对于多任务的项目尤其重要。
图5 JIRA中的任务会自动排序
预见到需求迭代的被动性后，Diapers项目团队在Diapers项目上全面启动了JIRA进行项目管理，将需求分解细化后进入JIRA，排定任务的优先级并指定到人，确定每次小版本发布的需求编号，不定期的发布小版本。结合SVN等版本控制工具，Diapers项目团队能够将功能需求迭代的粒度控制到最小，项目逐步推进，客户对项目的进度有充分的了解，项目经理也能够准确把握项目的进度，团队中充满了乐观的情绪。
安抚团队成员的情绪
工程师对于冗长的需求说明书有天生的恐惧感，开发周期拉得太长，似乎需求迭代无穷无尽。如果需求的迭代周期不在可控范围之内，项目的发布边界模糊不清，项目发布的日期自然也遥遥无期。由此带来的结果是团队每天紧赶慢赶的跟踪需求迭代，消化处理新的需求，工作气氛也是高度紧张。每一次需求迭代，都会进一步增加这种紧张情绪。
项目经理应该把握项目的进展情况以及客户的真实需求，也要知悉客户的需求底线，更要在必要的时候安抚团队成员的情绪。
当原始需求第一次被抽象出来的时候，团队的第一要务是快速构建原型系统作为和客户沟通的主要媒介和依据，项目经理应该引导团队把握这一点。
之后的每一次需求迭代，项目经理要将需求分解细化，控制需求的粒度，并且确定优先级，消除团队成员的焦急情绪，按照先后顺序逐步的处理每一个粒度的需求，以发布每阶段的小版本为阶段性的目标。
在这个过程中，需求细化到最小粒度，还需要注意到每个需求之间的关联关系，关联的需求要优先集中处理，是降低每个小版本之间的耦合度。
Diapers项目自从将需求细化成一个个任务并进入JIRA控制之后，软件工程师每天的只需要按照顺序处理JIRA上面的任务，并及时将代码以最小粒度的形式通过SVN工具提交；测试人员根据发布边界所指定的版本号从SVN下载最新代码测试，确认并关闭相应的任务；项目经理引导团队成员遵循规范的需求迭代程序，有条不紊的处理需求，轻松应对需求迭代。
'' 〜 ``
（OO）
+ ------------------エスパニョール- 。（_） - OOOO .------------ --------- +
| ジミー|
| Eメール： [email protected] |
| Suryaniテック。株式会社 http://www.suryani.cn |
| 厦門、中国（）|
+ --------------------- \（----（）-------------------- + ---
\ _））/
（_ /
ます。https：//www.cnblogs.com/suryani/archive/2007/08/15/856310.htmlで再現