敏捷开发经典案例
软件项目管理的敏捷开发实践案例
软件项目管理的敏捷开发实践案例敏捷开发是一种以迭代、快速反馈为核心的软件开发方法论，它强调团队成员之间的合作、用户的参与以及快速适应需求变化。
在软件项目管理中，敏捷开发已经成为许多企业普遍采用的方式。
本文将通过一个实际案例，介绍敏捷开发的实践，并讨论其在项目管理中的优势和挑战。
案例背景某互联网公司决定开发一款全新的移动应用程序，该应用程序旨在提供在线购物和支付功能。
由于市场竞争激烈，公司需要尽快推出这款应用程序。
为此，他们决定采用敏捷开发来加快产品上线速度，并确保产品的质量。
敏捷开发的实践1. 制定项目愿景和目标在项目开始之前，团队和利益相关者齐聚一堂，制定项目的愿景和目标。
他们共同讨论和确认产品的功能和需求，达成一致意见。
这个过程能够明确项目的方向，为团队提供明确的目标和动力。
2. 敏捷计划和迭代团队将整个项目划分为若干个迭代周期，并在每个迭代之前进行详细的规划。
每个迭代通常持续2到4周，团队会通过用户故事和任务列表来详细描述需求和工作内容。
并且，对于每个迭代的工作量，团队会根据预估时间和能力进行合理分配。
3. 自组织的团队团队成员可以根据他们的技能和兴趣自由选择任务，并通过交叉培训提高团队成员的技能。
这种自组织的团队结构增强了团队成员之间的合作和社交性，有效地提高了团队的生产力和工作质量。
4. 日常的短暂会议敏捷开发中有一个短暂的日常会议，叫做“站会”或“每日站会”。
这个会议通常持续15分钟，团队成员每天早上都参加。
在会议上，每个团队成员分享他们昨天完成的工作、今天计划要做的工作以及可能遇到的挑战。
这个会议帮助团队保持团结，并及时发现和解决问题。
5. 快速反馈和持续集成在敏捷开发中，团队通过持续集成的方式，将代码频繁地集成到主干版本中，并进行自动化的测试和检查。
这种方式可以让团队快速发现和解决问题，保证软件的质量。
同时，团队也会定期与用户进行沟通和反馈，以便及时调整产品的优先级。
敏捷开发的优势1. 迅速适应需求变化敏捷开发强调持续交付和快速反馈，使得团队能够更好地响应需求变化。
软件工程中的敏捷开发方法与实践案例分析
软件工程中的敏捷开发方法与实践案例分析随着信息技术的迅速发展，传统的软件开发生命周期模型已经无法满足多变的市场需求和快速的技术迭代。
为了更好地应对这些挑战，敏捷开发方法应运而生。
敏捷开发方法强调将软件开发划分为多个可迭代的小周期，以更快地交付有用的软件，并与客户紧密合作。
敏捷开发方法的核心理念之一是团队合作和交互，以及快速响应变化。
敏捷团队通常由开发人员、测试人员和业务代表组成。
这个多职能的团队通过日常站会、迭代计划会议和评审会议等活动保持高效的沟通和协作。
在敏捷开发方法中，Scrum是最常用的框架之一。
Scrum通过将软件开发过程划分为一系列的时间段，称为“Sprint”，来实现快速迭代。
每个Sprint通常持续1到4周。
在Sprint开始时，团队会制定一个可实现的目标，并在Sprint结束时交付一个可用的软件增量。
敏捷开发方法在实践中取得了许多成功的案例。
以下是一个实际案例的分析，以展示敏捷开发的优势和效果。
某汽车制造公司决定开发一款汽车销售管理系统以提高销售效率和客户满意度。
该项目采用敏捷开发方法，并采用Scrum框架进行实施。
在项目初期，团队首先进行了利益相关者的识别和需求梳理。
通过与销售部门、客户服务部门和财务部门的代表合作，团队明确了用户的需求和项目的目标。
然后，团队进行了产品规划会议，将需求转化为可迭代的用户故事，以便更好地组织和管理开发工作。
接下来，团队开始了第一个Sprint。
在Sprint计划会议上，团队协商确定了一个可实现的目标，并将将要实现的用户故事分解为更小的任务，以便更好地进行任务分配和跟踪。
每天的站会帮助团队成员了解彼此的进展，及时解决问题，确保项目按计划进行。
在Sprint过程中，团队采取持续集成和自动化测试的方法，以确保软件的质量和稳定性。
开发人员编写自动测试用例，并在每个代码更改后运行测试以及进行代码审查。
这些措施有助于减少缺陷的数量，并提高软件的交付速度和质量。
国内敏捷实践案例
国内敏捷实践案例1. 某互联网公司的敏捷实践某互联网公司在开展敏捷实践中，采用了Scrum框架作为项目管理方法。
团队按照Sprint周期进行工作，每个Sprint周期持续两周。
每个Sprint开始前，团队成员会进行Sprint Planning会议，确定本次Sprint的目标和计划。
然后按照计划进行工作，每天进行Daily Scrum会议，团队成员分享工作进展和遇到的问题。
Sprint 结束时，进行Sprint Review会议，回顾完成的工作并接受反馈。
通过这种敏捷实践，该公司项目的交付效率和质量得到了显著提升。
2. 某电商企业的敏捷实践某电商企业为了提高项目的交付速度和质量，引入了敏捷开发方法。
团队采用了Kanban方法进行项目管理。
他们将项目的需求和任务以卡片的形式放在看板上，通过推拉的方式进行工作流程的管理。
团队成员可以根据任务的优先级自主选择并开始工作，通过每日会议进行工作进展的交流和协调。
通过这种敏捷实践，该企业的项目团队更加高效和灵活地完成了项目。
3. 某金融机构的敏捷实践某金融机构在开展敏捷实践中，采用了Scaled Agile Framework （SAFe）作为项目管理方法。
他们将大型项目划分为多个敏捷团队，并通过PI（Program Increment）进行规划和协调。
每个PI周期持续8-12周，团队在这个周期内进行需求开发和测试工作。
每个PI结束时，进行PI Review会议，回顾完成的工作并进行项目规划的调整。
通过这种敏捷实践，该金融机构成功地应对了复杂的项目需求和变化。
4. 某制造业公司的敏捷实践某制造业公司为了提高产品开发效率，采用了敏捷开发方法。
团队采用了Scrum框架进行开发管理，每个Sprint周期持续4周。
他们使用Jira等工具进行需求管理和任务分配，通过每日站立会议进行工作的协调和沟通。
为了提高产品质量，他们还引入了持续集成和自动化测试的实践。
通过这种敏捷实践，该公司的产品研发周期明显缩短，同时产品的质量也得到了提升。
汽车敏捷开发案例
汽车敏捷开发案例汽车行业是一个竞争激烈的市场，要求企业能够迅速响应市场需求并快速推出具有竞争力的产品。
为了应对这一挑战，许多汽车制造商开始采用敏捷开发方法来提高开发效率和产品质量。
下面列举了十个汽车敏捷开发的案例。
1. 特斯拉 Model 3：特斯拉采用敏捷开发方法，快速迭代Model 3车型。
通过团队的跨职能合作和灵活的开发过程，特斯拉成功地在市场上推出了一款受欢迎的电动车型。
2. 丰田 TPS：丰田生产系统（Toyota Production System，简称TPS）是一种基于敏捷开发和精益生产的方法。
丰田通过持续改进和快速反馈，实现了高效的汽车生产和质量控制。
3. 宝马 Agile Transformation：宝马在整个组织范围内实施了敏捷转型，从而实现了更快的开发速度和更高的客户满意度。
通过敏捷开发，宝马能够更好地满足不断变化的市场需求。
4. 日产 Leaf：日产采用敏捷开发方法开发了全电动汽车Leaf。
通过快速迭代和持续改进，日产不断提高车辆的性能和续航里程，使Leaf成为市场上最受欢迎的电动车型之一。
5. 沃尔沃SPA 架构：沃尔沃采用敏捷开发方法开发了SPA （Scalable Product Architecture）架构，这种架构可以用于多个车型的开发。
通过敏捷开发，沃尔沃能够更快地推出新车型，并实现更高的生产效率。
6. 福特 SYNC 3：福特采用敏捷开发方法开发了车载娱乐系统SYNC 3。
通过快速迭代和用户反馈，福特不断改进系统的功能和用户体验，提高了产品的竞争力。
7. 雪佛兰 Agile Manufacturing：雪佛兰采用敏捷开发和精益生产的方法，实现了高效的汽车生产。
通过快速响应市场需求和持续改进，雪佛兰提高了生产效率和产品质量。
8. 奥迪 Q5：奥迪采用敏捷开发方法开发了SUV车型Q5。
通过跨职能团队的合作和敏捷的开发过程，奥迪成功地推出了一款畅销车型。
9. 现代 Agile Innovation Lab：现代汽车在韩国设立了敏捷创新实验室，用于快速开发新技术和产品。
敏捷开发实践案例
敏捷开发实践案例随着科技的迅猛发展，敏捷开发方法在软件开发领域越来越受欢迎。
它强调团队协作、快速反馈和快速交付，旨在提高软件开发的效率和质量。
下面将介绍一个敏捷开发的实践案例，以展示敏捷开发的优势和成功经验。
案例背景某公司决定开发一款新的电子商务网站以提升其在线销售业务的竞争力。
为了满足市场需求的快速变化，公司决定采用敏捷开发方法，并组建了一个跨职能的敏捷团队。
需求收集和优先级划分在敏捷开发的第一个阶段，产品负责人与项目利益相关者共同收集和识别了用户需求，并将这些需求根据优先级进行了划分，以便在整个开发过程中有针对性地分配资源。
Sprint规划和迭代开发基于划分的优先级需求，团队开始制定每个迭代周期的计划，并通过会议与产品负责人进行讨论和反馈。
根据Sprint计划，团队开始了每个迭代周期的开发工作。
持续集成和测试在敏捷开发中，持续集成和测试是至关重要的。
团队使用自动化工具来进行持续集成，确保每次代码提交都会通过自动化测试，减少潜在的错误和冲突。
同时，团队也会进行手动测试来验证产品的功能和质量。
迭代演进和需求变更在开发过程中，团队与产品负责人定期进行迭代评审，并根据实际情况进行调整和优化。
此外，如果市场需求发生变化，团队会灵活地处理需求变更，并根据实际情况重新规划下一个迭代周期的工作。
客户参与和反馈收集为了确保产品的质量和用户满意度，团队与客户保持紧密的沟通并鼓励他们参与到开发过程中。
客户可以通过不同的方式提供反馈和建议，如参加会议、提交bug报告等。
持续交付和发布在每个迭代周期结束时，团队会进行产品演示并收集利益相关者的反馈。
根据反馈和团队的内部评估，产品负责人可以决定是否发布产品或继续进行下一个迭代周期的开发工作。
案例成果通过敏捷开发的实践，该公司成功地推出了一款具有竞争力的电子商务网站。
采用敏捷开发的方法使得团队能够快速响应市场需求，并根据实际情况调整和优化产品。
同时，敏捷开发也促进了团队内部的协作和沟通，提高了开发效率和质量。
企业敏捷管理的实践案例有哪些
企业敏捷管理的实践案例有哪些在当今竞争激烈且充满变化的商业环境中，企业敏捷管理已成为众多企业追求高效运作和持续创新的关键策略。
敏捷管理强调快速响应市场变化、灵活调整业务流程、促进团队协作和持续改进，从而帮助企业更好地适应不确定性和实现业务目标。
下面，我们将探讨一些成功实施企业敏捷管理的实践案例。
一、某互联网科技公司这家互联网科技公司在面临快速变化的市场需求和激烈的竞争压力时，果断引入了敏捷管理方法。
他们首先打破了传统的部门壁垒，组建了跨职能的敏捷团队。
每个团队都包含了产品经理、开发人员、测试人员和设计师等，从而实现了从需求提出到产品上线的全流程协同工作。
在项目管理方面，他们采用了短周期的迭代开发模式，每个迭代周期通常为一到两周。
在每个迭代开始前，团队会共同制定明确的目标和任务，并在迭代过程中进行每日站立会议，及时沟通项目进展和遇到的问题。
这种短周期的迭代模式使得团队能够快速获得用户反馈，并根据反馈及时调整产品方向。
此外，他们还注重持续集成和持续部署，通过自动化的测试和部署工具，实现了代码的快速集成和产品的快速上线。
这不仅大大缩短了产品的上市时间，还提高了产品的质量和稳定性。
通过实施敏捷管理，这家互联网科技公司的产品创新能力得到了显著提升，能够更快地推出满足市场需求的新产品，从而在竞争激烈的市场中占据了一席之地。
二、某制造业企业某制造业企业面临着客户需求多样化、订单交付周期缩短和成本压力增大等挑战。
为了应对这些挑战，他们开始尝试敏捷管理。
在生产环节，他们引入了精益生产的理念，通过优化生产流程、减少库存和消除浪费，提高了生产效率和质量。
同时，他们建立了敏捷供应链体系，与供应商建立了紧密的合作关系，实现了原材料的快速供应和零部件的准时交付。
在产品研发方面，他们采用了并行工程的方法，将研发、设计、生产和销售等环节的人员组成跨部门团队，共同参与产品的开发过程。
通过这种方式，不仅缩短了产品研发周期，还提高了产品的市场适应性。
敏捷转型案例
敏捷转型案例
敏捷转型是指企业从传统的项目管理方式向敏捷项目管理方式的转变。
敏捷转型可以帮助企业更好地应对快速变化的市场需求和业务环境，提高项目的灵活性和应对能力。
以下是一些敏捷转型的案例：
1. 某知名互联网公司：该公司采用敏捷方法后，将产品开发周期从几个月缩短到几周，并且能够快速响应用户反馈，提高产品迭代速度和用户满意度。
2. 某大型制造业公司：该公司通过引入敏捷方法，提高了项目的质量和交付速度。
在敏捷转型后，项目按时交付率提高了30%，同时客户满意度也得
到了提升。
3. 某知名软件公司：该公司采用敏捷方法后，实现了跨部门协作和信息共享，提高了团队的协同效率。
通过敏捷转型，该公司成功开发了一系列高质量的软件产品，赢得了市场的认可。
4. 某医疗机构：该机构通过引入敏捷方法，加速了医疗设备的研发和上市时间。
在敏捷转型后，项目交付速度提高了50%，同时保证了医疗设备的安
全性和有效性。
5. 某金融机构：该机构采用敏捷方法后，提高了风险管理和质量控制的能力。
在敏捷转型过程中，该机构还加强了团队成员的培训和技能提升，提高了团队的综合素质和执行力。
这些案例表明，通过敏捷转型，企业可以更好地适应快速变化的市场环境，提高项目的成功率、客户满意度和团队协同效率。
敏捷创新在企业管理中的应用与案例(精选)
敏捷创新在企业管理中的应用与案例(精选)敏捷创新在企业管理中的应用与案例（精选）概述：敏捷创新是一种以快速迭代和持续改进为核心的管理方法，在当今日新月异的商业环境中具有重要意义。
本文将探讨敏捷创新在企业管理中的应用，并通过案例分析来说明其实际效果。
一、什么是敏捷创新敏捷创新是一种强调快速反应、适应变化的创新方法。
它强调小规模试错，在实践中不断调整和改进。
敏捷创新主要体现在以下几个方面：1. 快速迭代：通过快速迭代，企业能够更迅速地开发产品或服务，并基于客户反馈进行改进。
2. 开放式沟通：敏捷创新强调团队成员之间的开放式沟通，鼓励分享、反馈和协作。
3. 分阶段开发：通过将开发过程分解为多个独立的阶段，每个阶段都可交付价值，以支持快速迭代和改进。
4. 迭代学习：敏捷创新鼓励持续学习和不断改进，使企业能够快速适应市场变化。
二、敏捷创新的应用敏捷创新可应用于企业的多个层面和环节，包括产品开发、项目管理、团队协作等。
下面将从这些方面介绍敏捷创新的应用。
1. 产品开发在产品开发领域，敏捷创新提供了一种更加灵活的方法来满足客户需求。
与传统的瀑布模型相比，敏捷创新将开发过程分解为多个小的迭代周期，每个周期都可交付一定的功能。
这样，团队可以根据客户的反馈进行及时调整和改进。
敏捷创新还注重团队协作和跨职能合作，以促进高效的产品开发。
2. 项目管理敏捷创新在项目管理中的应用主要体现在灵活性和快速反应上。
传统的项目管理往往在项目启动前花费大量时间进行规划，而敏捷创新鼓励以较小的迭代周期开始项目，并在实践中进行持续改进。
这使得项目管理更加灵活，能够更好地应对快速变化的需求和环境。
3. 团队协作敏捷创新强调团队的协作和沟通，通过持续的反馈和分享来推动创新。
敏捷团队通常采用短期的迭代开发方式，每个迭代周期都要进行团队会议，以分享进展、讨论问题和制定下一步计划。
这种高效的团队协作能够更好地发挥团队成员的优势，加快问题解决和创新产出。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
敏捷开发经典案例背景荷兰铁路可以跻身于世界上使用量最大的铁路系统之列，每天要运送120万乘客。
该部门打造了一套全新的信息系统，为乘客提供更准确的列车信息，减少人为干预。
作为该系统的一部分，我们做了这个PUB发布系统，对所有车站中的信息显示和音频广播做集中控制。
有人之前试过完成这个PUB系统，但是他们当时用的是传统的瀑布方法。
客户把详细的需求文档规范交给了开发商，然后放任自流，等着完整的系统成形交付。
三年之后，这个项目被取消掉了，因为开发商没能开发出一个可以工作的系统来。
然后客户雇佣了我们公司从头做起，我们引入了敏捷开发方式，用上了 Scrum，跟客户紧密协作，开放交流，小步前进。
起步项目开始的时候，我们在第一个sprint开始前安排了一个启动阶段，耗时三周，准备好了sprint中所需的一切。
这个启动阶段由一个项目经理，一个架构师和一个Scrum master参与完成。
选择产品负责人是个很有难度的事情，我们找不到一个人能够有时间、具备领域知识、而且有权利设置需求优先级。
我们提名了两个业务分析师来一起承担产品负责人的职责。
他们能抽出时间来，而且他们从前也参与过构建PUB的工作，所以业务知识很丰富，足以担当起产品负责人的角色，为多组客户充当优秀的代理。
有关优先级的和范围的高级决策，是由客户委任的项目经理负责，但是他时间不够用，对于需求的理解也有所欠缺。
一般情况下大家的配合还可以，但偶尔项目经理也会对（他所缺席的）计划会议上制定的优先级进行调整，于是这个会议就得重新来过。
在理想状态中，对优先级有最终决策权的人应当每次都参加 sprint计划会议。
因为先前有人试着构建过PUB系统，所以有些部分的详细需求文档已经是现成的了。
它们遵守了MIL标准[1]，不过其形式不适于敏捷计划和估算 [2]，因为在敏捷开发中，需求应当被组织成小块的段落，每一块都可以在一个sprint中进行实现、测试和演示，但是现有的文档与此要求不符。
产品负责人也没有多少编写用户故事的经验，为了解决这个问题，Scrum master帮他们弄出了最原始的产品backlog，里面放着一些细粒度的、经过估算的用户故事，供前几个迭代使用。
我们所构建的软件只是某个大型软件系统的一部分，它还包括很多相关的软件系统，那些系统负责显示信息，还要在车站内安装相关显示设备。
我们得保证每件事情都可以按时完成，才能把复杂的系统理顺。
所以需要有一个整体的计划方案。
经历了几次迭代，我们对系统的各个功能都按照自己的最大能力做出估算，这个问题也解决掉了，而且也有了一个比较靠谱的生产率。
于是就可以用发布版本燃尽图来记录和沟通进度了。
这里我们学到的东西就是，即使是信息量很少的情况下，有估算也比没估算好。
扩展到分布式团队项目启动以后，一开始只有7个人，两星期一迭代。
项目从一开始就计划着要用到印度的一些人力，所以从第一个sprint开始就有两个印度开发人员进入了团队。
他们来到客户现场参与开发，用了六周时间熟悉领域知识、用户代表和团队其他成员。
建立团队伊始，就要决定如何协作。
我们跟所有团队成员一起——也包括印度同事——组织了一个“规范和章程”活动。
我们定下来一些实践方式，如怎样做结对、用哪些工具、质量目标、每天的核心工作时间等等。
然后在Wiki上记录下来。
整个团队有了共识，事情就好办多了。
一旦这些共识需要修改，比如在回顾会议上提出改进，这些实践就要在wiki上更新，这样有新人加入的时候，他们看到的总是最新内容。
在前几个迭代里面，团队成功地构建、测试、验证了组成系统核心的用户故事。
这让客户很满意，尤其是跟过去相比，我们的进度更快，而且客户对项目的方向也有掌控权。
几个迭代以后，我们就扩展了项目：印度的开发人员返回本国，然后我们在印度和荷兰都增加了资源，这样变成了两个Scrum团队，每个团队5个开发人员，共享同一个测试人员。
过后又变成了三个团队，一共三个测试人员。
每个团队都既有印度员工，又有荷兰员工。
这种方式让项目保持了很高的生产率和工作质量。
那我们是怎样异地协同工作的呢？首先，我们频繁使用Skype。
我们都有网络摄像头、耳机、麦克风，还有个大屏幕。
所以我们既能一对一开会，也能全体参会。
这些都用的是现成的东西和免费软件。
没多花多少钱，只是用UPS保证断电的时候也能继续开Skype会议，这样提高了印度那边的网络联系能力。
其次，只有在同一个地方的人才做结对。
也就是说印度的人跟印度的人结对，荷兰的人跟荷兰的人结对。
经验告诉我们，不管现在有了哪些工具，结对编程所需的交互协作还是需要两个人坐在一起的。
最后，我们用ScrumWorks记录谁在做什么事情，记录Sprint的进度。
因为我们是分布式团队，所以这个比白板要好得多。
在跟产品负责人讨论产品backlog的时候，ScrumWorks也起了很大作用。
在实施这种分布式模型的时候，我们也战胜了很多困难。
例如，产品负责人不习惯说英语。
按照Scrum的说法，计划会议分成两部分，在第一部分中，产品负责人给团队讲述用户故事，并且设置优先级。
因为这种语言障碍的存在，这一部分的会就只让荷兰团队参加了。
第二部分通常是大家讨论具体任务，做估算。
这部分是跟印度团队一起用Skype来完成的，说的是英语，产品负责人不参加。
我们还多花一些时间来沟通第一部分会议的内容。
Sprint演示也只在荷兰进行。
完成以后，荷兰团队再写封内部简报，告知印度团队——也包括公司其他人——演示的结果。
事实证明，这个内部简报深受欢迎。
拆出一个只关注架构的团队我们的项目只是整个应用链条中的一部分，必须要跟客户现有的IT基础架构无缝挂接。
虽然我们的产品负责人对核心功能需求非常熟悉，但是在安全、日志、可用性、性能等方面就所知甚少了。
要从客户的组织中了解这些需求难度很大，因为这得跟不同部门中的许多人沟通讨论。
这种调查工作给Scrum的迭代节奏拖了后腿。
为了解决这个问题，我们创建了一个独立团队，他们只关注架构方面的内容。
他们的工作就是弄清楚非功能性需求，好让我们把它们转换成backlog中的用户故事。
我们用“Scrum of Scrum”会议来跟特征团队沟通。
我们都喜欢这种方式，因为特征团队可以全速前进。
而且有些员工也喜欢在“架构团队”中工作。
文档客户要求大量的文档，而且还要符合MIL文档规范。
还要用荷兰语写。
很明显，这项工作只能由荷兰人来干。
而且开发跟测试都不熟悉MIL规范，写用户手册这样的文档也不是他们所擅长的。
所以我们决定雇一个曾经写过MIL文档的技术文案。
开发跟测试可以继续关注于各自职责。
这个做法也很成功，不过我们发现这也要求技术文案和其他团队成员之间也要有大量的沟通交流，这是需要引起注意的，因为开发人员只想“做他们该做的事情”。
需求管理我们的产品负责人是一些业务分析师，他们习惯于用荷兰语写出大量的需求文档。
而在我们的过程中，只要backlog中有用户故事，产品负责人也能在计划会议上做解释，这就足够了。
但是客户又要求有很多文档。
所以我们打算和产品负责人一起把需求翻译成用户故事。
结果就是需求被放在了两个地方：需求文档和 backlog。
当需求发生变化的时候就会导致问题。
我们做了大量的辅导工作，确保产品负责人不仅仅是关注需求文档，也要负责backlog。
有了一行文字表达的用户故事，再加上产品负责人的解释，我们的Scrum团队就可以构建和测试软件了。
不过需求文档对外部的测试团队做测试还是很有价值的，虽然在好些迭代里面，我们很难把实现的用户故事跟需求文档中的某些部分“映射”起来。
回顾从前，我们其实一直都没有一个理想的需求管理过程。
我们只是尽了最大努力，来应对这相互冲突的需求：我们需要用户故事，客户需要详细的需求文档。
测试我们在项目中做了自动化测试，保证在每个Sprint结尾的时候都可以交付经过测试的软件，不带有回归的bug。
即使随着系统扩展，我们还是做到了在8人的Scrum团队中只安排一个测试人员，而且保证了高质量：外部测试团队最多也就是能在每千行代码中发现一个缺陷。
我们的自动化测试包括两部分：单元测试和验收测试。
在前者中，我们用的是JUnit，用Clover度量测试覆盖率，我们的目标是服务器端代码的测试覆盖率达到80%。
验收测试用FitNesse作自动化。
每个完成的用户故事，都会在FitNesse上有一套验收测试。
有了庞大的测试套件，就能在 Sprint中找到并修复回归的bug。
这种做法还有另外一个好处，就是测试人员从一开始就可以积极参与，在用户故事实现之前编写测试用例。
有一个地方让我们苦恼了很久。
这个系统有一部分是一个用户界面很复杂的富客户端。
对这东西做自动化测试要比对服务端做测试难得多。
所以在UI方面的功能我们大部分还是依靠手工操作。
随着系统的增长，回顾测试所花的时间就越来越长，更糟的是，外部团队只在这部分系统中会发现回归bug。
如果有了自动化测试就能防止这一点。
我们由此学到了一点，即便是自动化测试很困难，为它付出些努力，迟早会获得回报，尤其是在项目晚期。
产出成果客户对我们的工作很满意。
说点马后炮的话，跟大多数项目一样，功能、时间、预算都会随着项目进度发生变化，所以“按时按预算”完成只是个很模糊的完成标准而已。
更为重要的是，我们在项目进程中常常跟客户讨论怎样把项目做好，他们都很满意。
不幸的是，因为其他系统中的问题，产品在全国范围内部署的时候出了麻烦。
客户找了外部的审核公司来审核这个软件。
他们的结论是：1.系统的可维护性非常好。
2.源码质量非常高。
在审核公司的报告中，他们说他们从来没有给过一个项目这么多正面评价。
总结下面是我们从这个项目中学到的最重要的几点：1.很难找到一个既有丰富的需求知识、又有权利设置优先级的产品负责人。
所以人们往往都要用几个人一起扮演产品负责人的角色，尤其是在大型项目里面。
2.如果一定要按期完成工作，那就得保证产品backlog的完整，也要做好估算。
对需求而言，即便信息量很小，有估算也比没估算的好。
把估算跟团队生产率合并以后，发布计划就有了必要的信息。
3.Scrum对多个分布式团队很适用。
我们每个Scrum团队都既有荷兰人又有印度人，这很好地发挥了团队精神，让我们注重有效沟通。
在沟通中，利用现成的硬件和免费软件能节省成本。
4.在启动分布式项目的时候，先把大家都聚到同一个地方，让大家对团队实践达成一致，这点效果很好。
5.对于不适合放到Scrum Sprint中的工作（比如寻找关键人员，跟其他客户部门交流），可以让一个单独的团队去做，这样效率更高。
特性团队可以集中精力开发软件。
有一个专职的技术文案也很好，即便这会增加沟通成本。
6.虽然软件开发过程不需要大量的需求文档，但客户可能需要。
不过在Scrum项目中，需求文档代替不了用户故事。