推介好书：敏捷软件开发：原则、模式与实践

作者：Robert C.Martin是Object Mentor公司总裁。他和他的软件咨询队伍使用面向对象设计、模式、UML、敏捷方法学和极限编程，在世界各地都有他们的客户。他还著有《Designing Object-Orient C++ Applications Using the Booch Method》等多部畅销书······

主要内容：
#论述在预算和时间的要求下，软件开发人员和项目经理如何使用敏捷开发完成项目
#使用真实案例讲解如何用极限编程来设计、测试、重构和结对编程
#包含了极具价值的可多次使用的C++和Java源代码
#重点论述如何使用UML和设计模式解决面向客户系统的问题

期待各位同学发表读书笔记，结合实际进行探讨！我将对优秀的帖子给予PUB￥、日鱼徽章奖励:rose: :)

敏捷软件开发：原则、模式与实践

1

敏捷软件开发：原则、模式与实践

2

敏捷软件开发：原则、模式与实践

3

敏捷软件开发：原则、模式与实践

4

敏捷软件开发：原则、模式与实践

5

敏捷软件开发：原则、模式与实践

6

敏捷软件开发：原则、模式与实践

7

敏捷软件开发：原则、模式与实践

8

敏捷软件开发：原则、模式与实践

9

敏捷软件开发：原则、模式与实践

10

敏捷软件开发：原则、模式与实践

11

敏捷软件开发：原则、模式与实践

12

敏捷软件开发：原则、模式与实践

13

over,有问题PM:)

支持一下，好东东！

[QUOTE][i]最初由 yulongan007 发布[/i]
[B]支持一下，好东东！ [/B][/QUOTE]

过年一直在网上工作，辛苦:rose:
常来聊聊:)

下面这篇文章也许有助于对敏捷软件过程的全面了解--

敏捷软件过程的局限性
作者：Dan Turk　　来源：《非程序员》
摘要：软件开发人员和项目经理努力地评估敏捷过程对他们的开发环境的适应性。本文指出许多已公布的敏捷过程对不同的项目类型来说存在的局限性，敏捷过程应用在这些项目中可能会存在问题。

　　绪论：当越来越多的组织要求通过及时部署基于Internet的服务来寻求获得竞争优势时，开发人员就承受不断增长的压力以尽快实现新的、增强的服务。敏捷软件开发过程主要针对这个问题发展起来的，即在“网络时代”开发软件的问题。敏捷方法采用技术上和管理上的过程，这些过程能持续地适应。

　　(1)源自开发过程中获取的经验而进行的变更
　　(2)软件需求的变更
　　(3)开发环境的变更。

　　敏捷过程特别支持尽早尽快地交付可工作代码的产品，这通过迭代的开发过程完成的，其中每次迭代都注重提交可工作的代码以及其他制品（artifacts）以供客户评估，同时也供项目评估。敏捷过程的支持者和批评者都强调在这些过程中注重代码。支持者经常争论说代码是唯一重要的可交付的产品，可以忽视分析和设计模型、文档在软件开发、演化过程中的角色。敏捷过程批评者指出，强调代码能带来全体记忆丢失（corporate memory loss），因为没有重视编写良好的文档和模型来支持庞大、复杂软件系统的创造和演化。 敏捷支持者和批评者提出的声明引出这样的问题：在当今快速变化的开发环境中，什么样的实践、技术和基础结构适合软件开发过程？特别是，对有关特定应用程序领域和开发环境的敏捷过程适应性的问题的回答通常是根据轶闻报导。

　　本文，我们基于对已发表有关敏捷过程的作品的分析介绍了我们所认识到的敏捷过程的局限性。许多自称为“敏捷”的过程在价值上、实践上和应用领域有很大的差别。因此评估所有敏捷过程和识别适应于所有敏捷过程的局限性不是一件容易的事情。我们的分析是根据对假设采用极限编程（XP）, Scrum , 敏捷统一过程，敏捷建模以及敏捷联盟提出的宣言的研究。这主要是一个分析性研究，由作
者指导的几个XP项目经验作支持。

　　敏捷联盟  

　　最近几年的文献中，提出许多种称为“敏捷”的过程。为了避免在什么样的过程是“敏捷”的这个问题上引起混淆，17位业界专家在2001年召开的研讨软件过程未来发展趋势的一次会议上，就什么是“敏捷”达成一致意见。这次会议的一个成果是成立了“敏捷联盟”并发布了联盟敏捷宣言(参考[url]http://www.agilealliance.org/principles.html[/url])。这份联盟敏捷宣言是“敏捷软件开发”价值和目标的浓缩定义，并通过许多共同的原则进行了细化。这些原则如下所示。  

　　1. 我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。

　　2. 在项目的整个开发期间，业务人员和开发人员必须天天在一起工作。  

　　3. 即使到了开发后期，也欢迎需求变化。  

　　4. 经常性地交付可以工作的软件。  

　　5. 可以工作的软件是主要的进度度量标准。  
6. 围绕被激励起的个体来构建项目。为他们提供所需的环境和支持，并信任他们能胜任工作。  

　　7. 最好的架构、需求和设计来自于自组织的团队。  

　　8. 在团队内部，最有效果和最有效率的传递信息的方法是面对面地交流。  

　　9. 敏捷过程提倡可持续的开发速度。

　　10. 不断地关注最优秀的技术和良好的设计能增强敏捷能力。  

　　11. 简单是根本的。  

　　12. 开发团队每隔一定时间，都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整。

　　敏捷过程分析


　　这一节我们在分析敏捷联盟原则和敏捷过程潜在的假定的基础上，讨论了敏捷过程的局限性。下一小节列出了在我们研究中识别出的管理上和技术上的假定，随后的一小节讨论了由这些假定推导出的局限性。 潜在的假定 敏捷过程声明的比传统说明性过程的优点是建立在这些假定正确有效的基础上。

　　这些假定在另外一篇论文中进行了更详细地讨论。

　　假定1：客户要和开发团队协同工作，随时作好和开发人员交流的准备。而且，面对面的交流需要开发人员彼此位于很近的位置。

　　假定2：文档和软件模型在软件开发中不充当重要的角色。

　　假定3：软件需求和软件开发环境随着软件开发的发展而发展。

　　假定4：动态适应不断变化的项目和产品特征的开发过程，更有可能开发出高质量的产品。

　　假定5：开发人员具有正确地定义和适应过程的经验。换句话说，一个组织能建立由有丰富经验的问题

　　解决者组成的团队，他们在执行过程期间，能有效地改进过程。

　　假定6：项目的可见性能主要通过增量和一些度量的传递来获取。

　　假定7：软件制品（产品和过程）严格的评估仅限于经常非正式的审查和代码测试。

　　假定8：重用性和通用性不应该是面向应用程序软件开发过程的目标。

　　假定9：变更的成本不随着时间的变化而显著增加。

　　假定10：软件可以被增量开发。

　　假定11：无需为变更作设计，因为任何变更能通过重构代码有效地处理

　　敏捷过程的局限性

　　上述的假定通常不是所有的软件开发环境都支持，尤其是也不是被所有的“敏捷”过程支持。这无需惊讶，任何一个敏捷过程都不是银弹（尽管有支持者热情地声明）。在这部分我们将描述敏捷过程通常不适应的情况。可能一些敏捷过程能更好地符合这些假定，而其他的敏捷过程能通过扩展解决这儿讨论的局限性。类似的扩展能合并通常与更多预言性开发实践有关的原则和实践到敏捷过程中。

1.缺乏对分布式开发环境的支持：

　　 敏捷过程提倡的强调在实践中协作，不能很好地适应推动一些行业实现全球化分布式软件开发环境。团队成员和客户在地理上分布的开发环境可能无法支持敏捷过程提倡的面对面的交流。在这种情况下，人们至少可能通过诸如视频会议的技术手段进行面对面地交流，不过这些技术太昂贵，而且不一定达到预期效果。

　　面对面的交流在分布式的开发环境和在非分布式的开发环境中同等重要，但是不会经常发生，而且必须事先计划好以保证所有的相关人员都能参加。可以利用这种面对面的会议作为主要的同步事件，地理上分布的开发者

　　(1)可以了解其他人的进度

　　(2)讨论产品下一步开发的计划。

　　两次会议之间，文档（在代码之上）成为主要的交流方式。及时地创建和维护良好的需求和设计文档，对于保证分布式的开发成员对开发的产品保持一致的观点具有重要的作用。这不应该认为是需要对软件的所有方面都要写文档或建模，文档和模型仅是在对项目和项目有关人员有价值的时候才创建和维护。

　　2. 缺乏对转包合同的支持

　　承包商的软件开发任务经常是根据合同中对承包商需要做什么的精确规定而制定的。在承包商必须投标签订合同的情况下，必须精确地定义承包任务。承包商在制定标书时，通常会制定足够详细的计划，计划包括一个规定了里程碑和可交付产品的过程，以进行成本评估。这个过程可能采用一个迭代的、增量的方法，但是为了能完成，承包商必须通过详细说明迭代的次数和每次迭代的交付产品使过程可预言。合同可能允许承包商在时间和成本的限制内对如何开发产品拥有一定程度的灵活性。如果承包商有良好的跟踪记录，并且合同单位相信承包商能开发出满足自己需求的产品，这当然是可能。一个合同若支持在承包商环境的敏捷开发，应该由两部分组成：  

　　• 固定部分：

　　这部分定义了
　　(1)框架，框架限制合同中承包商将如何合并变化到产品中（例如，接受和拒绝可变部分（参见下面）变更的成本和时间标准）
　　(2) 承包商必须执行的行为（如质量保证行为）
　　(3)认为是不可变的需求和必须提交的产品。  

　　• 可变部分：

　　这部分定义了在固定部分定义的范围内可变的需求和提交产品。这部分能在固定部分定义的约束下变化。合同签订的时候，应该包括交付产品和需求的优先级。

　　3. 缺乏对创建可复用制品的支持

　　类似极限编程的敏捷过程聚焦在创建解决特定问题的软件产品。在“网络时代”开发经常排除通用性的解决方案，即使这很清楚会带来长期的效益。在这种开发环境中，通用解决方案和其他形式的可重用软件（如设计框架）的开发最好在主要开发可重用软件制品的项目中解决。这种特定产品开发环境和可复用软件制品开发环境的分离是位于学院公园的马里兰大学的研究人员开发的称为Experience
Factory的可复用框架的主要特征。

　　可复用产品广泛的适应性要求其创建的过程要注重质量控制，因为低质量（尤其是严重的错误）的影响将会和重用该产品的应用程序的数量一样广泛。另一方面，及时开发可重用制品也是需要的。看起来好像有应用敏捷过程来开发可复用软件制品的案例，但是敏捷过程如何很好地适应这个过程仍然不是很清楚。

4. 缺乏对大型团队开发的支持： 敏捷过程支持“小规模管理”的过程，其中采用的协调、控制、交流机制适应于小型到中等规模的团队。对于更大的团队，必须维护的交流线索会降低诸如面对面交流和评审会议等实践所带来的效果。大团队很少需要敏捷方法来处理针对“大规模管理”的问题，传统的强调控制文档变化和以架构为中心的开发更适应这种情况。这并不是说敏捷实践不适应这种环境，团队可能有使用敏捷实践的机会，但是敏捷程度可能会比在小项目中使用小得多。

　　5. 缺乏对开发有严格安全性要求的软件的支持

　　有严格安全性要求的软件是指一旦失败会导致对人类造成直接伤害或是引起重大经济损失的软件。当前敏捷过程支持的质量控制机制（非正式的审查，结对编程）并没有证明来说服使用者软件是安全的。实际上，单独这些技术是否是足够的还有些值得怀疑。软件工程中的正式的规格说明书，严格的测试覆盖，以及其他正式的分析和评估技术能提供更好但更昂贵的机制来解决有严格安全性要求或是严
格商业要求的软件的开发。一些敏捷实践也能对此类软件开发有益。例如：

　　(1)测试为先（Test-first）的方法需要在写代码之前定义单元测试

　　(2)敏捷过程增量迭代过程支持的早期可工作代码的产品支持重要性软件探测性开发，这些开发的需求没有很好地定义

　　(3)结对编程能作为正式审查的有效的补充。

　　因此，可以想象，敏捷和正式软件开发并非不兼容，而是在需要的时候可以结合：正规的技术可以应用在敏捷方法中来处理软件中重要的部分，以提高质量和增加信任度。

　　6. 缺乏对开发大型、复杂的软件的支持：  

　　假设代码重构就不需要设计来处理变更对特别大型、复杂的系统是不够的。在这类软件中，可能一些重要的架构方面因为在系统核心服务中起重要作用而很难进行变更。这种情况，变更这些方面的代价会很高，因此需要早期花费精力预期此类变更。依赖代码重构对这类系统也是有问题的。这类软件的复杂性和规模会导致严格的代码重构代价过高而且容易出错。模型能起重要的作用，尤其是有工具能从模型中产生代码的重要部分。以模型为中心制品演化系统的观点是对象管理组织（OMG）的模型驱动架构(MDA)方法的核心思想(参见[url]http://www.omg.org/mda[/url])。

　　还有一些系统，其功能紧密耦合和集成，不太可能增量地开发。在这种情况下，每次迭代产生代码的迭代方法仍然可以使用，只不过每次迭代产生的代码会包括所有的部分，每部分都出于各种各样的不完整状态。

　　结论：尽管看起来有许多软件开发基于敏捷过程获得成功，到目前为止大多数成功的故事都仅仅是逸闻。对比敏捷方法和非敏捷方法的效果和局限性将极大地促进我们理解敏捷过程真正的优点和局限性。本文我们根据对部分称为“敏捷”的过程的原则和假设的研究列举了一系列局限性。并不是所有的假定适应所有这些过程，例如，仍然未发表的“Crystal Blue”，亦即 “Crystal Clear”的兄弟 [7]，就很好地支持大型软件的开发，但可能并不很“敏捷”。很显然，有些领域更需要敏捷开发过程，其中有Internet应用领域，这些应用面临着显著的尽快推向市场的压力和下一个版本更新的成本尽可能小。然而，同样很明显，开发长期规划、大型复杂系统的公司在目前形式下不太可能采用敏捷过程。

　　通常，一个软件开发项目的某些方面能从敏捷方法获益，而另外一些方面可能从不是很敏捷的或是预言性的方法获益。从这个方面看，实际的软件开发过程可以根据其“敏捷性”程度沿着频谱分类。在频谱的一个极端是纯粹的预言性开发，这些开发中的步骤都是在项目的早期详细地定义好，项目的目标在整个项目的执行过程中保持相对稳定。在频谱的另一个极端是纯粹的敏捷过程，在这些过程中，
步骤和目标是根据以下分析动态决定的：

　　(1)执行先前过程步骤获取的经验

　　(2)在本项目之外获取的类似经验

　　(3)需求和开发环境的变化

从这方面看，一个过程的敏捷性是项目团队根据环境变化动态调整过程的程度和开发人员集体的经验决定的。

　　实际过程处于频谱中纯粹的敏捷和纯粹的预言性两个极端之间。目前的敏捷过程靠近频谱中纯粹的敏捷端，但并不是纯粹的敏捷，因为他们提供了一个过程框架限制开发人员必须遵守的过程形式。例如，大多数发布的在敏捷过程上的作品规定迭代的、增量的过程，并且提倡诸如先编写测试代码、结对编程和每日审查会议等特殊形式的实践。

　　致谢：Bernhard Rumpe的工作部分得到Bayerisches Staatsministerium für Wissenschaft，Forschung und Kunst through the Bavarian Habilitation Fellowship and the German Bundesministerium für Bildung und Forschung through the VirtualSoftwaereengineering Competence Center (ViSEK)的支持。Robert France and Dan Turk的工作得到Colorado Advanced Software Institute (CASI) and
Qwest (CASI Project 5-30186)的授权方式的支持。

我需要敏捷吗：不必关心敏捷的六大理由 -zt
理由1：项目需求？ 客户即上帝！
我们的需求来自对客户目标的仔细分析和准确理解， 并严格的将其付之实现，通过签订合同的方式，可以在一开始的时候就明确项目范围，这样也避免了不必要的责任，鉴于我们对待客户要求的严肃态度， 这将是我们不关心敏捷的第1个理由。

通常，软件开发者需要的是精确理解客户需求，并且以合同的方式明晰这些需求，而敏捷项目使用QuickStart来进行这一过程， QuickStart是一个建立对于业务目标共同理解的过程， 其不仅仅是让需求制定者明白客户需求， 也是让客户明白什么是自身需求的过程。 即使是客户，对现有业务过程的理解也并不完全一致，从而带来不同的需求。 然而非常普遍的一种情况是，由于各种因素的制约(文化，理解度， 时间)用户的需求并未完全展露， QuickStart正是一个利用一种行之有效的方法发掘客户需求，将客户利益最大化的过程，而非简单的遵循客户要求。

理由2：项目回报？ 我们的客户很有耐心!
客户制定了项目期限，我们需要的只是按期交付，我们的客户总是会耐心等待最后的交付时刻。鉴于我们的客户深谙没有钱不搞信息化的道理，这将是我们不关心敏捷的第2个理由。  

敏捷项目的初始需求是投资回报的基线，通过开发过程中频繁的客户反馈，敏捷使客户来掌舵项目，利用对项目新的认识，对外部环境变化的及时响应来构建更好的系统，以改善投资回报。并且通过尽可能早的交付，敏捷项目使早期部署和早期投资回报变成可能。

理由3：市场变化？ 超出我们的考虑范围！
总而言之，我们是开发者，我们的客户在需求完成的时候就从人变成了具有法律效力的合同，不管市场怎样，合同确保了我们一方的收益。客户应当为自己的失误决策买单。这将是我们不关心敏捷的第3个理由。

通常，项目80%的工作会按计划完成，在这种情况下，项目的负责人面临着一个艰难的决策，如果在花费了80%的预算后，环境发生变化，项目进入一 个进退两难的境地，我们是否要抱着最后一丝希望来继续开发？ 敏捷项目通过渐进开发方式和使用交付情况估算项目进度的方法避免了这样的情况，这些方式提供了真实可靠的反馈而非字面上的进度，过度乐观的商业计划在敏捷 项目中将变得十分明显，这样项目负责人可以有机会更早的重新审视项目的成本和收益，尽早在未陷入投资泥潭的时候抽身而退。

理由4：项目质量？ 功能才是用户价值所在！
我 们需要面对的是客户制定的最终期限，以及在此期限内需要完成的功能，这才是最头疼的根源。通常我们和客户会因为缺少的功能而产生纠纷，对于某些质量问题我 们和客户都认为可以通过fix bug的形式消除，鉴于项目质量并非我们亟待解决的问题，这将是我们不关心敏捷的第4个理由。  

软件开发之中需要控制的4个变数是成本，时间，范围和质量， 大多数的敏捷项目选择控制范围。 所有的敏捷项目都强调交付高质量的软件，而敏捷项目使用的极限编程确保了这一点地实现。

理由5: 项目管理？ 一切尽在掌握！
我们有严密制定的计划，并且项目经理会监督并确保计划中的每一项可以按时完成，而且我们也同时认为公司的知识产权就存在于设计文档和代码中，定当控制能接 触到这信息的人群，避免无形资产的流失。 鉴于我们同样能够很好的控制项目以及对无形资产的良好控制，这将是我们不关心敏捷的第5个理由。

敏捷项目从不制造表面假象，通过进行短小的迭代以及时刻面对迭代完成后运行中的软件来开展工作，敏捷项目给予项目负责人和客户持续增加的项目能见 度和控制度。 紧密合作以及训练有素的团队更加强了这一点。在敏捷的团队中，增加信息的透明度，共享这些信息是例行公事一般的行为。 即使为此付出额外的努力，敏捷团队也认为是值得的。

理由6：我们的开发者？他们是最佳人选！
我们有很好的开发者，项目也已经经过仔细划分，每一部分的设计者、开发者都是这个位置最佳人选，我们希望用正确的人做正确的事，否则就是浪费资源，这些开 发者的工作合同也确保了他们在项目结束前不会离开，鉴于我们项目小组经过了仔细组织，这将是我们不关心敏捷的第6个理由。  

敏捷项目强调信息共享，并且依赖以团队方式进行的分析，设计和编码而非某个设计者，这将预防开发过于依赖于某个人，这也意味着预防开发瓶颈的出 现，在一个敏捷项目中，任何一个人在任何一个领域工作都是可能的，每个人工作领域的变化取决于业务上的优先级，而不是他所熟练掌握的部分。

敏捷开发带领项目提速
作者：黄昆　　来源：eNet　　
IT项目不仅投资较大，而且项目的实施过程很长，拿ERP来说，一般的项目都是分阶段去实施，每个阶段的实施过程少则几个月，而且存在项目风险。因此，很多企业在项目决策上都存在一个顾虑，企业上项目需要解决企业存在的问题，但实施的过程和风险又让企业进退两难，真的不能二者兼得吗？   
  
　　敏捷开发关键在于，能够“敏捷”地适应项目的变化，而不是在开发阶段去适应需求变化。  

　　IT项目不仅投资较大，而且项目的实施过程很长，拿ERP来说，一般的项目都是分阶段去实施，每个阶段的实施过程少则几个月，而且存在项目风险。  

　　因此，很多企业在项目决策上都存在一个顾虑，企业上项目需要解决企业存在的问题，但实施的过程和风险又让企业进退两难，真的不能二者兼得吗？  

　　软件价值的兑现  

　　现在的软件业有个现象，就是软件的功能就等于价值，软件功能越多，系统越复杂、解决问题越多价值就最大。但是实际上很多功能最终用户根本不会用，造成功能浪费。  

　　第二个现象是很多用户并不清楚软件的价值究竟在哪里，所有的IT部门和厂商都是追求软件按需求开发完成，认为软件只要开发完成上线后就实现了价值。  

　　但实际上软件上线仅仅是一个软件生命周期最早期的阶段，软件的价值是在使用中体现出来的。

　　比如说投资回报率的计算方法：  

　　投资回报率=软件单位时间内实现的价值×时间－开发成本  

　　在这里面时间的因素是很重要的。很多国内企业都是为了降低开发成本，忽略了怎么样延长软件的使用寿命从而提高它的最大价值。  

　　国内企业IT投资有80％是用在新产品开发上，20％用在现有系统扩展上。国外这个数字正好相反。如果对现有系统进行投资控制，用户得到的价值要比开发一个新系统大得多。  

　　敏捷开发的价值  

　　从中国前几年ERP上线的平均速度来看，项目的交付时间都比较长，这让用户产生了顾虑。  

　　从某些角度来讲这是很正常的现象。因为中国的企业可以利用自己的后发优势，从西方软件开发过程中学到了很多经验，可以避免很多犯过的错误。  

但是也有一些不正常的因素存在：一些项目因为业绩的需求，希望项目能尽快上线，可如果是传统的软件开发方法，它的自然规律是速度、成本和质量三个互相制约的因素。一味追求速度必然的结果就是成本的提高，系统的灵活性、可扩展性和可使用性都会下降。

　　在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。  

　　简单说，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。  

　　敏捷开发很多方面就是为了解决问题：一个就是什么样的功能提供给客户，应该产生最大的价值？什么样的功能不要提供给客户，因为它产生不了价值。产品系统的灵活性和可扩展性，以及适应性是怎么样实现等。  

　　软件开发不能被认为是一个既定的进程，因为在一个团队里开发一个软件时会有太多的变化出现，任何一个既定的程序设置都能达到一个合适的预想结果是不可能的。因为需求在变化，技术在更新，还有人员流动等问题的存在。  

　　敏捷开发最重要的就是怎么样使业务人员、技术人员和最终用户能够尽可能地沟通。因为只有过程的沟通，大家才能意识到什么样的功能是可以做的，什么样的功能是能给用户提供最大价值的。  

　　敏捷开发使团队依靠变化来获取活力。因此，不需要一个成熟的初始设计。他们更愿意保持设计尽可能的干净、简单，并使用许多单元测试和验收测试作为支援。这保持了设计的灵活性、易于理解性。  

　　团队利用这种灵活性，持续地改进设计，以便于每次迭代结束生成的系统都具有最适合于那次迭代中需求的设计。  
  
　　敏捷开发技术应用分析  

　　电子商务软件开发存在的问题

　　开宏公司是国内某汽车零部件贸易企业，其业务形式大部分采用期货订货，客户群基本上覆盖了全国各地，公司制定的订货时间一般集中在月底的10天左右。  

　　该企业原来开发了一套适合自己企业运作的贸易企业ERP系统，但ERP的核心是实现企业内部资源的优化配置，是实现企业内部供应链管理。仅仅是在公司内部使用。  

　　由于企业没有外部信息管理机制，所以不能够很好的和客户进行信息交流，这样一来就造成客户在集中订货的时候，因为订货量巨大，而时间集中在供货的那几天，造成该企业的业务人员平时很轻松，在那几天却很忙碌，而且经常会发生排队订货的现象。  

同时由于是期货订货，所以该企业还得向上游供应商订货，这样一来，给工作带来极大的不便，也容易造成混乱和漏洞。  

　　因此，经过多方面考虑，公司决定根据企业特点开发一套网上期货订货系统，将订货的整个环节都打通，通过和几个系统之间的集成，做到实时的信息流通。

　　但是因为国内没有相关成熟的案例和模型，所以实施存在极大地风险性。而为了尽快地解决业务流程中的问题，要求尽早建立网上订货系统，根据以上情况，决定采用敏捷开发技术来实施这个项目。  

　　实施计划  

　　建立联合实施团队，由电子商务公司的项目实施人员和客户方的关键用户一起构成，统一受客户方的常务副总指挥。  

　　工作方式：在客户现场办公，在调研的同时做需求，根据系统架构和功能划分，边做设计边做开发。  

　　沟通方式：所有项目组成员对每天的工作进行总结和经验交流。每周召开一次推进和培训会议，在不断开发的过程中进行对用户的业务知识，系统知识，和操作的培训，为将来系统的运行维护打下更好的基础。  

　　项目实施过程  

　　第一轮循环实施周期两个月，不但搭建了整个应用的整体框架，还实现了两大品种的单向期货订货流程。  

　　第二轮循环实施周期两个月，打通了向供应商的期货订货环节，并且实现了另外两个品种的订货。同时逐步将前期做好的系统向用户做推广使用，在不断完善的过程中，对本阶段的项目开发实施做修正。  

　　第三轮循环实施周期三个月。由开发人员和客户方的关键用户对期货订货系统进行完善和优化。  

项目实施效果  

　　通过网上信息的快速传递，再也没有排队订货的状况，同时由于采用了敏捷开发技术，降低了开发成本，开发效率得以提高。尽管在整个项目实施过程中存在大量的变更和修正，但是这样的开发方式可以很有效的避免带来更多负面的扯皮现象。