篇一：一个真实的敏捷开发案例
一个真实的敏捷开发案例
摘要：Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，将会介绍如何成功地完成
Scrum为项目执行提供了可靠的、已被证实的基础。但是，在每个项目中，Scrum都必须根据具体需求和环境进行调整，这是项目成败的决定性因素。在这篇文章中，将会介绍如何成功地完成了一个大型的（20人年，超过十万行代码）、分布式（开发人员位于印度和荷兰）Scrum项目，而这个项目曾经在传统开发方式下被废弃过。为了帮助读者顺利运作大规模项目，在这里我也会历数我们的经验教训，包括：项目启动、找到合适的产品负责人、估算的重要性、有效沟通、测试、文档。
背景
荷兰铁路可以跻身于世界上使用量最大的铁路系统之列，每天要运送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。 有了一行文字表达的用户故事，再加上产品(本文来自：wwW.xIAocAofaNwEn.com 小 草范 文 网:用户故事与敏捷方法,评论)负责人的解释，我们的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项目中，需求文档代替不了用户故事。如果既有需求文档，又有用户故事，那就得在做计划的时候，就要考虑到在两个地方协调需求的额外开销。
7. 在增量式交付软件的过程中，自动化测试发挥着关键性作用，它可以排除回归bug的干扰。在项目结束之前，投资回报会高过成本的。
篇二：敏捷项目管理系列之：用户故事
敏捷项目管理系列之：用户故事（1） 摘要:
一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。本文描述了敏捷开发的技巧：如何以用户故事管理项目.
什么是用户故事(user story)
假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。
因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的 钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”
上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说，上面我们的客户所说的话，就是在描述一个用户故事（user story）。
(我解释一下为什么用故事这个词，没兴趣也可以忽略。在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。)
如果我们想要记下这段用户故事，我们可能会用这样的格式：
名称：卖饮料
事件：
1. 用户投入一些钱。
2. 售货机显示用户已经投了多少钱。
3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。
4. 用户按了某个亮了的按钮。
5. 售货机卖出一罐饮料给他。
6. 售货机找零钱给他。
注意到，一个用户故事里面的事件可以这样描述：
1. 用户做XX。
2. 系统做YY。
3. 用户做ZZ。
4. 系统做TT。
5. ...
用户故事只是描述系统的外在行为
一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面有下划线的那些文字，就属于不应该出现在用户故事中的系统内部动作：
1. 用户投入一些钱。
2. 售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。
3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。
4. 用户按下一个亮起来的按钮。
5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1。
6. 售货机找零钱给用户。
不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。
评估发布时间
用户故事是用来干嘛的？假定客户希望在50天内递交这个系统。我们做得了吗？为了解答这个问题，我们就要在项目开始的阶段，试着找出所有的用户故事，然后评估一下，每一项历程需要多长的开发时间。可是，怎么评估呢？
比如，我们现在收集了下面这些用户故事：
卖饮料：如上面所说的。
取消购买：在投入了一些钱后，用户可以取消购买。
输入管理密码：授权的人可以输入管理密码，然后增加存货，设定价格，拿走里面的钱等等。
补充饮料：授权的人可以在输入管理密码后增加存货。
取出钱箱里的钱：授权的人在输入管理密码后，可以取出钱箱里的钱箱里面的钱。 安全警报：有些事情经常发生的话，系统会自动打开安全警报。
打印月销售报表：授权的人可以打印出月销售报表。
然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短）。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如，我 们觉得“输入管理密码”是最简单的用户故事。然后我们判断说，这个用户故事算1个“故事点（story point）”。
用户故事故事点
卖饮料
取消购买
输入管理密码 1
补充饮料
取出钱箱里的钱
安全警报
打印月销售报表
不过一般我们不会列出清单，而是做出一堆卡片贴在墙上，每张卡片记录一个用户故事，然后将故事点写在卡片上面：
敏捷项目管理系列之：用户故事（2）
然后开始考虑其他用户故事。比如，对于“取出钱箱里的钱”这个故事，我们认为它跟“输入管理密码”这个故事一样简单，所以它应该也是算1个故事点。我们在列表里面标上。当然，实际操作的时候，我们是在“取出钱箱里的钱”的故事卡上填上故事点。
用户故事 故事点
卖饮料
取消购买
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表
对于“取消购买”，我们认为它应该是“取出钱箱里的钱”的两倍的工作量，所以它算2个故事点。
用户故事 故事点
卖饮料
取消购买2
输入管理密码1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表
对于“卖饮料”，我们认为它应该是“取消购买”两倍的复杂度，所以它应该算4个故事点。 用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表
对于“补充饮料”，我们又认为它比“取出钱箱里的钱”复杂，但又比“卖饮料”简单，然后它又应该比“取消购买（２个故事点）”复杂，所以我们认为它应该是3个故事点： 用户故事故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报
打印月销售报表
类似的，我们认为“安全警报”应该比“补充饮料”简单一些，所以应该是2个故事点： 用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
打印月销售报表
“打印月销售报表”应该跟“卖饮料”一样复杂，所以应该是算4个故事点，这样的话，我们总共有17个故事点：
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
打印月销售报表 4
总计 17
现在挑出任意一个用户故事，估计一下它要花（你一个人）多少时间来完成。假设我们之前做过跟“取出钱箱里的钱”类似的功能，所以我们就挑这个来计算，估计 它要花5天的时间。也就是说，一个故事点要花5天的时间来完成。现在我们有17个故事点，也就是说，我们需要17×5＝85天来完成这个项目（如果只是一 个开发人员来做的话）。假设现在我们的团队里面有两个开发人员，所以我们就需要85÷2＝43天来完成。
从目前的估计来看，我们可以在50天的期限里面做完这个项目。但现在说这个还太早了！这样的评估，更多的是猜测。通常开发人员在工作量上的估算都很差。事实上，人们经常会低估了工作量。那我们应该怎么估计得更准？
我们实际的开发速度是多少
为了做到更准的估计，我们就让客户先给我们两周的时间做一些实际的开发，来测量一下我们在这两周里面可以做多少的用户故事。我们叫这两周的时间为“迭代周期”。
哪些用户故事应该放在第一个迭代周期里面做？这可能完全是客户决定的，也可能是大家讨论以后决定的。不过挑出的这些用户故事的故事点不应该超过这两周的承 受能力。因为一个迭代周期有10天（假设我们周末不工作），然后我们估计一个开发人员5天可以完成一个故事点。现在我们有两个开发人员，所以我们应该可以 在这个迭代周期中完成（10÷5）×2＝4个故事点。
然后客户可以在总故事点不超过４的前提下，挑出一些用户故事在这个迭代周期里实现。他们可能会尽量挑选他们觉得最重要的故事。比如，对他们来说，销售报表跟找零钱最重要，所以他们就挑出这两个：
用户故事 故事点
取出钱箱里的钱 1
打印月销售报表 2
总计 3
假设两周的迭代周期过去了，我们完成了“取出钱箱里的钱”，不过“打印月销售报表”没有完成，还剩0.5个故事点没有完成。也就是说，我们在这个迭代周期内完成了3-0.5＝2.5个故事点（比原来的预计要差一些）。
2.5个故事点这样的数值，就是我们现在的参考值。也就是说，这个团队每个迭代周期可以完成2.5个故事点。这个参考值对我们很有用。它有两个用处：
首先，我们可以假定我们在下个迭代周期也可以完成2.5个故事点，然后客户选择的用户故事的故事点总和不能超过2.5。
其次，在从第一个迭代周期取得参考值以后，我们可以重新估算我们的发布时间了。
篇三：敏捷开发用户故事系列之三：用户建模
敏捷开发用户故事系列之三：用户建模
作者: cheny_com 发布时间: 2011-09-16 23:10
用户建模的目的，是为了更好地分析用户行为和用户价值，并因此获得商机。 用户建模四部曲
有一次培训中，分组建模的时候，一位学员就自言自语地说了一句话：“真的啊……我好像不知道谁会使用我的产品……”这其实是一种常见的现象。
比如前文所说的敏捷开发管理软件，如果想把一个用户故事描述为“作为一个用户，可以登录“我的空间”，以查看我我在的所有项目的进展以及自己的任务”，就会遇到这个麻烦。所谓领导，肯定想浅层次低能看到多少项目，就看到多少项目，而且最好能汇总一下显示；作为普通程序员，则肯定不止是想知道自己在哪些项目中有任务，而是想知道自己有哪几个任务是急需完成的（领导肯定也有着急的事情比如要审批，但肯定不如把控大局更重要）；作为项目经理，又介于其间。
分析到这一步，就已经做了用户建模的第1步：列出尽可能多的用户。
第2步则是：识别关键用户。
按刚才的划分，还是很难确定谁是关键用户，因为“项目进展”的关键用户是领导和项目经理，而“我的任务”的关键用户则是普通程序员更常用。
这说明这个故事太大了，应该予以分拆，直到能识别出关键用户为止。后面还会提到另外一种更科学的判断故事颗粒度过大是否应该分拆的方法，这里先用这个方法。 第3步则是：面向关键用户，描述故事
假设我们先研究普通程序员的“我的任务”的功能，那么问题就简单一些了。故事可以描述为：“作为一个程序员，可以登录“我的空间”，以查看自己的开发任务中有哪些需要处理。” 为何要写上“那些需要处理”这句话？因为一般没有人会无缘无故面对自己的任务列表发呆的，他肯定来了就有它的目的。比如我们描述了这个“哪些需要处理”的价值观，眼前就能浮现出这些任务肯定不是一视同仁地列在那里，至于要突出“延期的任务”还是“亟待解决的任务”还是“领导关注的任务”，都是具体需求了，不难实现。
可惜经常不是这么简单的三种角色，而是上来一堆程序员、脚本设计师、测试人员、黑盒测试人员等等，不可能给他们每人写一个故事，这时候要做的是第2.5步：合并次要用户。 在上面的例子里边，我们发现刚才列举的几种人可能在使用其他功能上有所不同，但在“我的空间”里边，还是基本相同的，所以把它们合并为一个“开发人员”，并把故事描述为：“作为一个开发人员，可以登录“我的空间”，以查看自己的任务中有哪些需要处理。”
总结
重新排序总结一下用户建模四部曲：
第1步：列出尽可能多的用户
第2步：识别关键用户
第3步：合并次要用户
第4步：面向关键用户，描述故事
灵活应变
本来写到这里就万事大吉了，国外书上也是这么说的，之前有几次课也是这么讲的，大家也听得挺开心的。
但自己在项目中实践了一段时间后，发现自己经常有一些“过度合并”的倾向。比如在那个敏捷开发管理系统中，角色设置是非常自由的，“添加用户”这个操作，任何授权的用户都可以做，而不一定是“系统管理员”，所以开始就写成“作为被授权的用户，可以添加用户，以便……”。但这种“授权的用户”越来越多了，就感觉其实逐渐坠入最开始的一股脑“作为一个用户”的情况，又都改成“作为一个系统管理员，……”。宁可放弃实际功能，而模拟用户可能的使用场景。
一会说要分清用户，一会又说太多了要合并，一会又说合并过头了不行，到底应该怎样？
这里借用《金刚经》里边的一句话，来稳定心法：“菩萨为利益一切众生故，不着于法。”就是菩萨的出发点是众生的利益，因此怎样做好他们就会怎样做，而不会纠缠于方法（比如韦陀菩萨经常杀生）。在如何用户建模这件事情上，出发点是“更清晰更有价值地描述故事”，而不是符合什么建模方法，因此实际使用时，应固守心法，而灵活掌握技法。
本系列乃至本博客其他所有文章所描述的方法，都是即是非法，又是非非法，要本着对开发团队是否有价值，如何更有价值的心法来加以采纳或调整。