CMMI 流程与敏捷方法在软件开发中的应用

Pradip Koli

4.94/5 (6投票s)

2015年3月31日

CPOL

28分钟阅读

21155

937

CMMI 流程与敏捷开发方法在软件开发中的应用 - 基于ASP.NET的实践方法

引言

你是否好奇为什么又有一篇关于CMMI和敏捷的新文章？这次，它将包含一个实际的例子。虽然互联网上已经有很多关于CMMI和敏捷的资料，但我之所以决定写这篇文章，是因为很多资料只有理论方法，这使得这两个主题都变成了“读完就忘”。因此，我决定通过一个实际的例子来分享我对CMMI和敏捷的理解。做一个实际的项目与阅读理论截然不同。当然，我将从一些实用理论开始，然后跟进一个示例项目。

CMMI

什么是CMMI？ 当然是能力成熟度模型集成，但CMMI到底是什么？通过解释缩写，我们能理解CMMI吗？或者说那只是唯一的定义？显而易见的答案是“不！” 所以让我们从头开始。首先，必须明确CMMI不是一个认证。任何组织都不能通过CMMI认证，而是一个组织被评估为符合CMMI。这意味着CMMI描述了一些规则和规定，并且通过比较组织如何最好地遵循这些规则和规定来评估CMMI，这很简单。现在，一些部分已经清楚了，让我们进一步深入。所以在讨论CMMI之前，我们先关注CMM，再之前关注MM。MM是成熟度模型（请注意，模型不是模块，模块是模型的一部分）。让我们看一个快速的历史例子。

我们都知道（我希望如此），奔驰专利汽车公司是第一家生产汽车的汽车公司，他们于1885年开始运营。这意味着他们制造了第一个汽车制造模型。这个模型非常成功，以至于其他公司研究它并开始制造自己的汽车品牌！请不要只关注汽车，而是要关注奔驰制造的“模型”。这个“模型”经过进一步研究和调查变得如此成熟，以至于其他公司开始效仿它来制造汽车。在这里，“模型”变成了“成熟模型”，而将“模型”变为“成熟模型”的过程就是“成熟度模型”（MM）。现在，我们清楚了CMMI中的MM，让我们继续以汽车的例子为例。

制造一辆完美的汽车并不是汽车制造业的终点，它进一步发展，旨在制造世界上最好的汽车！丰田汽车公司旗下的雷克萨斯品牌于1989年在美国推出了世界上最好的汽车。为了推出世界上最好的汽车，雷克萨斯于1983年在F1项目代号下启动了计划。等等，不要沉迷于历史，这里的“代号”、“计划”和“世界上最好的汽车”这个词，只是简单地让我们具备了不仅仅是更好，而是行业中最优秀的能力，雷克萨斯做到了！参与这项“能力”的人员将“成熟度模型”过程提升为“能力成熟度模型”，至今丰田汽车仍然坚持并被许多公司效仿。

此外，我们都知道今天的汽车技术越来越先进，这将使下一代汽车成为混合动力汽车，这意味着今天我们只是想象汽车在没有司机的情况下行驶，而自动驾驶汽车已经制造出来了！这是许多技术在汽车中的整合，明白了吗！不明白？我会解释，现在我们的能力成熟度模型变成了能力成熟度模型集成！

所以，简而言之，能力成熟度模型集成（CMMI）就是简单的初始化（制造一辆汽车），管理（让一辆汽车在路上行驶），定义（定义最好的汽车），定量管理（实现最好的汽车）和优化（制造最好的汽车）。太棒了，我们已经完成了CMMI！怎么完成的？

这五点

初始化
管理
定义
量化管理
优化

这五点就是CMMI的五个级别。让我们快速了解一下这五点是如何运作的，即它们是如何衡量的。在这里，请注意CMMI的5个级别适用于不同的目的（收购、开发和服务模型），但由于我们讨论的是用于软件的CMMI，以下措施适用于软件应用程序（项目）的开发过程以及开发该应用程序的组织，即CMMI用于软件开发模型。

任何项目都始于项目本身的基本构想，理论上它只是一句阐述项目的简短陈述。（这是真的，不相信吗？想想谷歌是什么？答案是搜索引擎，对吧。一个一句话的项目！）在此基础上，我们开始进行建模，这意味着我们开始创建项目。这可以是级别1，它只是初始化一个项目。（制作一个软件应用程序，即汽车）
我们都知道，实际上一个项目绝非一言可尽，因此，利益相关者（项目为其所做）必须就其所需的服务、所有需求、这些需求的配置、配置如何分析和衡量、计划、控制、质量保证以及配置过程达成一致，所有这些管理方面的接受都属于CMMI的2级。（使软件应用程序可执行，就像让汽车跑起来一样）
正如我们所知，没有人是完美的，利益相关者（客户）和组织的资源也是如此。因此，可能需要不时地进行更改、修改或扩展，那么需求是如何收集和开发的呢？分析和解决方案是如何决定的？为利益相关者实现或提出了什么技术解决方案？潜在风险是否得到了管理？所有这些是如何与项目集成和管理的？组织是如何组织这些流程及其定义的？组织向其资源提供了哪些培训和指导？验证和确认是如何实现的？这些衡量标准属于CMMI的3级（定义每个接受点以达到最佳，思考最佳汽车）。
一个项目从来都不是由个人或团队或团队群体承担的，一个项目始终是组织与利益相关者之间的承诺，因此项目（群）的绩效过程和定量管理过程是什么？这在CMMI的4级下进行衡量（实现最佳的过程，实现最佳汽车）。
尽力而为，未必能取得最佳结果，那么为了确保最佳结果，在组织绩效管理方面进行了哪些优化？如何进行因果分析和解决？（已达到最佳，但通过迭代和确认，确保这就是最佳，制造并推出最佳汽车）

我想现在很多人对CMMI的许多要点都已清楚。如需进一步阐述，可以访问CMMI官方网站，了解更深入的课程。但就软件应用程序或项目及其理解而言，这已足够。请注意，CMMI 1级是默认的，不进行评估，CMMI评估从2级开始。现在让我们转到另一部分。

敏捷软件开发

敏捷概念：在深入探讨敏捷软件开发之前，必须明确敏捷软件开发过程中不涉及任何技术相关的步骤。因此，我们应该首先理解什么是敏捷方法论。回想一下，在理解CMMI时，我们以汽车工业为例，即汽车。让我们用同样的例子来理解什么是敏捷概念。所以，让我们再次回顾历史。准备好了吗？

所以，正如我们所知，是丰田汽车公司定义并推出了最好的汽车。但这并非一蹴而就，我甚至可以说不是几年就能实现的。它是基于很久以前就已经规划好的三个基本平台，现在让我们来谈谈它们。

许多人可能不知道，丰田最初并非汽车工业，而是一家由丰田佐吉拥有的纺织工业。在纺织工业中，当然有很多织布机！织布机的功能是制作成束的线。丰田佐吉发明了一种织布机，如果任何线断裂或破裂，它就会自动停止。这项发明不仅减少了浪费，还保证了质量。（永远当下解决问题，否则以后会带来更多麻烦。）
1930年，丰田集团设立了汽车工厂。由丰田佐吉之子丰田喜一郎领导。为了掌握汽车工业的基础知识，他访问了美国，研究亨利·福特公司。在那里他发现了传送带的概念。我们可以在机场看到传送带，行李在传送带上移动，乘客领取各自的行李。他深受启发，希望也能实现，但要增加自动化。从传送带中借鉴的部分被记录下来，以便再次制造。这意味着，零件一旦使用，就会再次被安排制造。通过这种方式，丰田喜一郎发明了“准时制”概念。物品一旦使用，就应该立即补充新的。（一旦一个主要模块完成，就应该向产品负责人或利益相关者展示。）
到了1940年，大野耐一在“准时制”生产中加入了更多自动化。他将每个传送带都视为前一个传送带的客户，从而使当前的传送带成为后续传送带的超市。这不仅缩短了生产时间，还提高了整体生产效率。这建立了一种“拉动系统”而非“推动系统”。这成为了“看板系统”，它提供了在流程内部和流程之间传递信息的功能。（当一个模块正在进行时，团队成员、产品负责人和利益相关者之间应该有定期的沟通。）
凭借上述三个系统，丰田汽车公司制定了一些基本原则。它们是：
1. 持续改进（不要固定任何规则，只需使其充满活力，使其更简单、更有用，检查A、B和C点，这是持续改进。）
2. 尊重人。（创造更愉快的环境，而不是专横跋扈。）
3. 长期哲学。（首先处理风险！简单的规则是如果风险从一开始就得到处理，它就会减少，而把它留到以后处理总是会增加风险。）
4. 选择正确的流程以获得正确的结果。（迭代以获得正确的流程，因此方向将自动以正确的方式开启。）
5. 对员工和合作伙伴进行入职培训。（不要以为所有人都无所不知！）
6. 持续解决根本问题，推动组织学习。

凭借上述知识和原则，丰田汽车公司于1983年以雷克萨斯之名开始实现世界上最好的汽车，并于1989年实现了！现在以这个例子为例，如果我们用产品来代替“汽车”，或者我应该说用项目来代替，同样的原则将驱动我们的项目取得最佳结果，并为利益相关者提供合适的产品。而同样的方法论就变成了敏捷方法论。

困惑？意思是汽车模型如何能取代软件项目模型？所以让我们走出历史，明白它们不可能完全相同，因此我们有了敏捷软件开发。它基于上述原则，但为了软件开发目的，增加了一些内容。让我们看看非敏捷方法和敏捷方法分别是什么。

非敏捷方法：（瀑布方法）软件开发过程具有应用程序生命周期管理（ALM）。这是大多数组织遵循的例行工作。主要概念是收集需求并将其文档化。这由业务分析师或产品经理完成。然后由工程师和架构师根据流程图或用例图（取决于哪种适合技术团队阅读）来制定功能需求。接下来开始开发，开发人员编写软件代码。然后是测试阶段，编写测试用例以验证规范并进行测试，如果发现缺陷，则将错误分配回开发团队，直到产品完成。在我看来，这难道不是更理论化而不是一个真实世界的例子吗？我之所以这样想，是因为当测试完成时，许多功能可能已经改变或不再需要，而且需求可能与最初制定的有所不同！现在，整个团队和利益相关者之间开始出现混乱。嗯，这种情况确实会发生！

敏捷方法：在敏捷方法论中，也采用相同的应用程序生命周期管理（ALM）。但它是以小块的形式进行的。需求不仅由业务分析师或产品经理收集，还包括开发团队和测试团队。制作所需文档，文档当然会很小，并且在制作任何技术或功能文档时，如果需求收集存在差距，会再次与利益相关者讨论。明确的需求并行开发，测试开始，如果需求发生变化，则将其整合并执行测试。如果验证和核查通过，则交付该需求。收集下一个块或需求，并重复该过程，直到项目完成。所以基本上，敏捷软件开发是一个持续集成过程，直到产品或项目完成。

正如我们从上面看到的，后者更实用，更可行。让我们进一步详细了解敏捷方法论。如上所述，整个项目的小块在敏捷方法论中被称为“Scrum”。而驱动力不是“推”，而是“拉”，这意味着它实现了我们“最佳汽车”示例中描述的“看板系统”。

Scrum：它是项目在现实世界中的进展，不基于最佳猜测、想象或未知的预测，而是真实的计划和发布日程。Scrum可以是一个模块、一组模块或一个项目。Scrum中的每个任务都可以被称为Sprint，使其运行一到两周，当所有Sprint完成时，Scrum会被测试并交付给利益相关者，利益相关者查看项目的进展。因此，Scrum允许项目根据已完成的工作进行调整或重新定位。在这里，我们可以看到没有想象、猜测、假设、预测或一个人领导，它只是一个真实情况的场景。让我们看看Scrum的角色是什么。

产品负责人：此角色由业务分析师或产品经理担任。此角色介于利益相关者（客户）和团队成员之间。此角色负责理解客户兴趣和开发团队的理解。此角色的职责是完整分析需求并确定优先级，这作为启动第一个Scrum的起点。
Scrum主管：此角色充当产品负责人和开发团队之间的协调者。请注意，Scrum主管既不是项目经理，也不是团队负责人，也不管理团队。Scrum主管致力于消除团队在实现Sprint目标时遇到的任何瓶颈。Scrum主管还会建议产品负责人如何最大化团队的投资回报率（ROI）。这直接提高了开发团队的创造力、生产力和质量。
开发团队/团队成员：对于软件开发，敏捷方法论建议一个团队由软件开发人员（程序员）、UI设计师、架构师、分析师、QA专家和QC测试人员组成。

我们可以看到，一个项目以真实生活实例为导向，赋予团队成员自主权，类似于产品负责人，两者都拥有自由和对项目的责任。最好的部分是没有项目经理、团队负责人或任何一个人承担全部责任，而是一个由团队驱动的项目，利益相关者也参与其中。

看板：正如我们在“最佳汽车”示例中看到的，为了理解敏捷方法论，看板是即时生产和最受欢迎产品的生产，通过在流程内部和流程之间传递信息。最关键的部分是看板可以消除瓶颈（如果发生），以实现产品目标，敏捷软件开发通过以下基本步骤实现相同目标：

在收集需求时，分析师、架构师、程序员和测试人员都参与其中。每个大脑并行工作以实现相同的目标。
文档以用户故事的形式完成，敏捷认为只需要在短时间内记录所需信息，只需考虑谁？什么？为什么？和何时？简单明了。
每天工作前后进行15分钟会议。因此，更多沟通，更少文档。记录下来以了解正在运行的利益相关者，并沟通要开始什么任务，工作开始前有哪些积压，什么已经完成，以及一天结束时明天将做什么。
首先创建原型，可以是草图形式，也可以是可以在冲刺中直接实现的工作模型。
计划尽早并更频繁地进行测试，这使得产品没有遗漏一些重要配置变得真正有意义。
更频繁地交付，这使产品负责人能够赢得利益相关者的信任，同时利益相关者也了解项目的全部进展。

上面给出的例子和要点足以理解什么是敏捷软件开发。如果我们结合CMMI级别和敏捷，我们可以看到两者很容易共存。这意味着如果我们采用敏捷方式，我们的文档会很简短，但在每个Scrum结束时，我们都会有完整的文档。神奇之处在于文档和项目相互补充。CMMI级别中列出了相同的规则集。因此，大多数通过CMMI评估的组织都依赖敏捷方法论来实现产品成功。

但CMMI和敏捷方法都不是项目成功的关键，项目仍然可能失败。在这种情况下，从团队成员、Scrum主管、产品负责人到利益相关者，所有人都要负责。在敏捷方法中，或多或少没有沟通障碍，每个用户故事（任务）、Sprint和Scrum都有文档记录，下一个Scrum只有在前一个Scrum成功后才会启动，最终产品与已沟通的文档相似，所以我们可以清楚地看到，没有违反CMMI描述和设定的任何规则。

随着对CMMI和敏捷软件开发方法有了清晰的认识，我们可以假设现在是时候用一个更实际的例子来实施了。所以，让我们从一个示例项目开始。在开始之前，最好再阅读一遍文章的顶部，因为我将尝试在示例项目中涵盖CMMI和敏捷方法的方方面面。

基于敏捷方式的ASP.NET示例项目

（请注意：对于敏捷开发，有许多工具可用于跟踪沟通、创建Scrum、Sprint、文档等。但我将由您决定是否选择这些工具。无论如何，对于记录沟通，Word Pad就足够了；对于创建Scrum和Sprint、跟踪待办事项等，Excel是个不错的选择。我不会使用草图，而是使用虚拟模块，这样它就可以集成到我们的项目中。当然，您无需说明需要Visual Studio 4.0或更高版本，我的代码语言是C#，您可以选择您喜欢的.NET语言。需要ASP.NET编程的中级或专家水平，期望在泛型、设计模式和逻辑思维方面高于平均水平，了解一点JavaScript、HTML和CSS将是加分项。项目中需要的任何其他技术，都是对敏捷方法的挑战和测试，以了解如何处理这些瓶颈，这就是为什么选择一个示例项目的原因。）

为了实施一个项目，我们必须对一些常见概念进行假设。我们将直接创建一个项目，其中不包括客户的初始获取和营销，也不考虑完成服务模型后的情况。而是假设客户已经获取，并且组织内部的产品负责人或产品经理已分配给客户。

我们假设利益相关者（客户）和产品负责人之间正在进行第一次对话。利益相关者简要介绍了项目和他正在寻找的解决方案。

客户在寻找什么？客户与产品负责人之间的首次沟通

客户：我们有许多正在运行的门户网站，所有门户网站都基于ASP.NET。由于门户网站正在运行，其中包含许多配置元素。因此，web.config文件完全混乱。我们正在寻找的解决方案是将ASP.NET的默认配置和门户配置分离到单独的配置文件中。这应该这样实现：我们的配置文件应在应用程序启动时读取，并将元素保留在内存中，供整个应用程序生命周期使用。开发人员可以在任何时候读取配置，并且应该易于搜索。我们拥有.NET框架提供的全局文件访问权限，因此一次读取和处置不会是问题。我们正在寻找的解决方案应该是通用的，适用于任何配置文件（当然，这将是基于XML的），并且易于在各种门户网站中实现和使用。

产品负责人（项目经理）：当然，这意味着我们只需要读取配置文件并将其保存在内存中，以便随时搜索。我从需求中了解到，您正在寻找一个插件，可以在您的任何门户中使用，这样web.config就能保持简单，并且您的所有配置详细信息都转移到单独的配置文件中。由于您已明确表示对您的门户和托管环境拥有完全访问权限，添加DLL文件不会是配置问题。我们可以为您提供一个插件和简单的实现步骤。我们请求您提供您在.NET中使用的语言，以及用于测试和提供模拟运行项目的示例配置文件。

客户：好的，我们很快就会提供配置文件，我们大致使用.NET 4.5框架，并且正如已经建议的那样，插件将采用DLL的形式，我们建议您选择开发语言，这最终不会成为插件的障碍。但实现部分应该是通用的，并且易于配置，而不会在web配置文件中带来任何进一步的复杂性。

产品负责人：当然，我们会坚持这一点，并向您展示一个模拟的虚拟项目。此外，我们正在等待示例配置文件。

正如我们所见，客户需要一个可以读取XML文件并将读取到的数据以可搜索的形式保存在内存中的插件。同时，可以是任何需要读取并保存在内存中的有效XML文件。因此，现在让我们开始Scrum和Sprint过程，并制定任务列表。Scrum文档应在架构师、开发团队负责人和质量控制团队负责人在场的情况下制定。这将确保开发什么以及需要控制什么以确保质量和质量测试。

只需下载“AgileProject”文件夹并解压。其中包含三个文件夹。

Documentation：此文件夹将供所有人使用，用于维护问题日志（待办事项）、Scrum和Sprint（用户故事）以及燃尽图。
Project：此文件夹是满足需求的实际工作项目。在这里，它已经按天维护。当然，将有版本控制，应使用VSS、Team Foundation Server等，任何您选择的工具来维护。
Sample XML：这个文件夹包含了客户提供的配置文件，这些文件将用于我们的项目。

A. 打开“Documentation=>Day1_7”文件夹和“Project_Tracking”Excel文件。有三个工作表，让我们逐一查看它们提供了什么。

工作表1（问题日志）：“用户故事”列简要介绍了任务内容。“任务描述”列提供了用户故事的简要说明。“任务负责人”列提供了执行任务的人员信息。“估算”列提供了完成任务所需的时间（以天为单位）。“优先级”列指明了任务的执行顺序。（这也被称为依赖关系）。“任务状态”列描述了任务的状态，“注释”列提供了关于任务的注释。

在第一个工作表中，我们定义任务，以便我们可以向客户进行演示。同时，还会输入影响或需要进一步完成的任务，或者需要客户确认的任务。由于我们只需要提供一个演示，客户可以观看，甚至可以在我们的测试托管环境中从他/她的桌面运行演示。因此，我们需要这个演示没有错误或错误最少，所以我们也把QA和QC纳入了同一个演示中。在这里，我们可以看到任务索引不是按顺序排列的，这是有原因的，因为我们在讨论需求时会遇到不同的事情，然后这些事情会根据优先级进行排序。

工作表2（迭代1）：此工作表需要深入解释。理解它是在敏捷方式下运行或遵守工作的核心概念。左侧有两个表格，与工作表一（问题日志）相同。我们可以注意到，我们只选取了演示所需的任务ID。其余的，我们将保留到下次迭代或在与客户讨论后考虑。左侧表格下方是制作演示或发布版本1.0.0.1的总天数。（我们有6天）。在进入“计算可用或分配时间”之前，我们需要查看右侧的表格。

右侧表格包含一些关于估算的计算，以下是对其的澄清。

不支持。		天数	解释
1	开始日期	3/2/2015	填写您的项目开始日期。
2	工作天数	6	演示发布的时间估算（天）。
3	开发人员和质检人员数量	3	我们有2名开发人员，他们也充当QA，还有1名QC负责测试，因此团队有3人。
4	开发和质检天数	18	“天数”列中的第2项 * 第3项，即（6*3）
5	效率系数	0.69	如果我们一天工作8或9小时，我们不能假设100%的工作时间。通常0.7是标准值。
6	实际开发和质检天数	12.42	“天数”列中的第4项 * 第5项，即18*0.69。
7	结束日期	3/8/2015
8	根据效率计算的积压工作。	-2.07	这一个有点棘手。它假设在实际工作开始的第一天就有积压工作，然后逐渐减少。其计算方法是（实际开发和质量控制天数）/（工作天数）* -1。我们乘以-1是为了创建需要清除的积压工作。
9	用于积压工作的天数	3	由于我们假设积压为-2.07天，因此用于此目的的天数为（开发和质量控制天数）/（工作天数）

现在让我们定义“计算可用或分配时间”，它在左下角的表格中。这是平均可用时间。它的计算方法是“实际开发和质量控制天数”（来自右表）– “总发布天数”（来自左表的估算时间总和），即12.42 – 6 = 6.42。

工作表3（迭代1燃尽图）：这张表格有点复杂，但当我们逐一解释每列时，它会变得更清晰。在这张工作表中，我们输入每个开发人员、QA和QC的实际数据。那么，让我们看看它提供了什么。

工作日（A列）	它是组织中的实际工作日。当然，节假日和周末休息需要排除在外。
工作天数（B列）	项目开发中的递增天数。这应该始终从零开始。
理想剩余工作量（C列）	我们已计算出积压为-2.07天，可用实际工作天数为12.42天。因此剩余工作量为（计算出的积压 * 当前工作天数）+ 可用工作天数。即（-2.07 * 0）+ 12.42 = 12.42，以及（-2.07 * 1）+ 12.42 = 10.4，依此类推，适用于每个递增天数。
D列	我们将在末尾定义这个。*
E和F列	我们有2名开发人员。每个人在一天结束时输入他们对每个任务的时间消耗。它应该是他们在“迭代1”工作表左侧表格中分配的任务估算（以天为单位）的总和，即任务ID 1、2和3的总和。这些任务ID是实际的开发工作。
G和H列	我们有2名QA人员。每位QA人员在一天结束时输入其在每项任务上的时间消耗。这应该是他们在“迭代1”工作表左侧表格中分配的任务估算（以天为单位）的总和，即任务ID 7、8和9的总和。这些任务ID是实际的QA任务，用于相互交叉检查工作。
I和J列	这里，QC检查发现的bug，并立即提出，由开发人员同时修复，或单独处理。任务ID为11、12和13。
已完成任务总数（L列）	工作日完成后，计算当天的已完成任务总数。显然，它是E、F、G、H、I和J列的总和。
实际剩余任务（M列）	这从总预计完成天数中减去一天内已完成的估计量来计算。我们总共有6天，并且L列中已完成的总和。我们可以在第2行看到相同的值：第0天是6 - 0 = 6。
已用工时（N列）	= 积压天数（3） * 当前递增天数。对于第2行，我们有：3 * 0 = 0。
计算效率系数（O列）	= 已完成任务总数 / 已用工时，如果已用工时为零，我们在excel中将效率设为零，否则使用公式。

*D列只是M列的副本，从标题中我们可以看到。D列用于将B、C和D列包含在excel图表中，以创建“燃尽图”。D列以浅粉色标记，表示在理解时可以忽略，但要包含在图表中。

从上面的“Project_Tracking”文档中，我们对如何估算一个模块（Scrum）并利用它来控制项目并在“问题日志”中定义项目的每个方面有了一个粗略的理想。因此，每天都使用相同的方法。每个故事都成为一个Sprint，可以交付的Sprint集合成为Scrum，并且持续集成一直进行，直到我们完成项目的需求。“燃尽图”告诉我们是否按时完成或滞后，如果是，则采取必要措施将开发时间控制在预期之内。

（每个Scrum都采用相同的Excel样式和计算方法，并使用相同的计算方法来完成项目的需求。）

B. 现在打开“Project_Day1_7”。我们有一个.NET网站项目。它包含default.aspx。您可以直接下载它。其功能如下：

用户可以浏览任何XML文件。
提供一个按钮来验证文件是否为有效的XML文件。
另一个按钮读取并显示文件内容，并将其保存在内存中。

演示已向客户展示。现在客户关心的是数据在内存中保存的能力、搜索任何属性或XML元素。此外，根据最初的讨论，客户需要一个API，以便上述模拟代码可以在其任何门户中运行和实现。在与客户讨论时，还要求客户创建单独的日志实用程序。日志实用程序的配置应保留在主web配置文件中。

现在打开文件夹“Documentation->Day9_14”。我们再次拥有project_tracking Excel文件，其中包含更多用户故事。这些用户故事的实现用于开发代码。

打开文件夹“Project->Day9_14”。其中包含两个项目，它们是：

ReadXML：它实现了读取配置文件的所有必要代码，并将配置内容以层次结构和简单泛型列表的形式保存，以便可以搜索所需的XML元素、键和属性。该网站演示了一些搜索功能的用法。
ReadXML.Logger：它实现了日志记录错误的代码，并且需要在网站的web.config 中设置配置。（如果在Windows项目中实现，配置则在app.config 文件中设置。）

每个用户故事都在上述项目中实现，并且每个用户故事完成的天数都输入到“project_tracking”的迭代工作表中。

最后一部分“Documentation->Day16”文件夹，我只是将其留空。您可以填写估算和开发/QA/QC。只需填写迭代工作表，燃尽图就会根据每天的完成情况做出响应。在Project->Day16中，我保留了插件的完整实现代码。请查看web.config 文件以获取配置。插件设置在global.asax 中启动，使用实现在default.aspx.cs中。您可以评估过程并填写project_tracking Excel。其余文档我未包含，将跟踪保留在开发部分本身。

关注点

嗯，我的文章有很多要点。学习和实践敏捷非常棒。这是一个整个团队的努力，同时在合理的时间内发挥出最佳效果。我没有涵盖所有要点，但尝试对CMMI级别以及CMMI如何与敏捷方法论一起发挥作用进行了一些介绍。