书中提及，“One of the most obvious differences between stories and use cases is their scope.”“ stories are kept smaller in scope because we place constraints on their size (such as no more than ten days of development work) so that they may be used in scheduling work. A use case almost always covers a much larger scope than a story.”“ Each story is not necessarily equivalent to a main success scenario”。按照这样的理解，Use Cases是针对一个比较完整的用例，包含正常情况和各种非正常的情况。相对的，User Stories更像是把User Cases break down，并排列整合起来。

“Another important difference between use cases and stories is their longevity. Use cases are often permanent artifacts that continue to exist as long as the product is under active development or maintenance. Stories, on the other hand, are not intended to outlive the iteration in which they are added to the software. While it is possible to archive story cards, many teams simply rip them up.”对此，非常不理解，为何Stories就在迭代周期外不应存在呢？继续读下去。。。

“Another difference is that use cases and stories are written for different purposes (Davies 2001). Use cases are written in a format acceptable to both customers and developers so that each may read and agree to them. Their purpose is to document an agreement between the customer and the development team. Stories, on the other hand, are written to facilitate release and iteration planning, and to serve as placeholders for conversations about the users’ detailed needs.”感觉这该是一个非常重要的差异，因为其他一些区别是基于这个差异的。

“Finally, use cases are generally written as the result of an analysis activity, while user stories are written as notes that can be used to initiate analysis conversations.”

读完了这些，基本上对作者想要阐述的区别有了一个大致的了解。由于两者存在的目的不同，Use Cases是为了让Business方和Software方能有一种双方能够理解的沟通方式并达成一致，使以后的软件开发有个依据，以遵从Business方的需求。而相对应的，User Story是为了在一个迭代周期内制定计划的。所以，他们的内容也许很相似，但是本质却很不一样。Use Case更有些为Software一方服务，可说是一个类似architecture的工具，而User Story更站在用户角度，主要为了Schedule，可以说是一个类似Project Management的工具。鉴于以上的目的不一致，表现形式的不一致也就可以理解了。所以，虽然Use Case是一个比较概括的东西，但是却必须是非常Serious的，相对而言，User Story就比较随意些。

顺便翻了下《UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition》，正好也简短的说到了两者的差距，觉得说得比较到位。

“Features are a good way of chunking up a system for planning an iterative project, whereby each iteration delivers a number of features. Use cases provide a narrative of how the actors use the system. Hence, although both techniques describe requirements, their purposes are different.”

并且，提供了一种比较好的建议，很赞同。

“Although you can go directly to describing features, many people find it helpful to develop use cases first and then generate a list of features. A feature may be a whole use case, a scenario in a use case, a step in a use case, or some variant behavior, such as adding yet another depreciation method for your asset valuations, that doesn’t show up in a use case narrative. Usually, features end up being more fine grained than use cases.”

1 按照安装步骤，一切就绪以后，愣是无法重启apache Server。看了Apache的Test Configuration， 发现“LoadModule php5_module modules/php5apache2.dll ”有问题，load 没有成功。

解决方法：http://snaps.php.net/ 下载5.2.x dev版本的php，解压后将php5apache2_2.dll放到modules目录下面，并将config里面的php5apache2.dll改为php5apache2_2.dll。

2 简单的<? phpinfo() ?> 显示空白

解决方法：改为 <?php phpinfo() ?>

最后总算是看到了点界面。

公车有时候要等三分钟，有时等三十分钟；有时一辆挤得要命，有时三辆空车连在一起；路线的设置也有点问题，很多不同路线的公车在很长路段是重复的，不仅造成资源分配不合理，而且，在重复的这些站头，当高峰期间，司机竟然很难找到一个靠边停的地方。

如果参见国外的一些做法，可能会避免上述的很多问题。但是有一点是肯定的，就是简单的增加班次，增加路线，肯定不能解决人们碰到的不准时，上班迟到等问题。

软件开发也是如此，当项目进度落后的时候，为了能够按时发布或交付，最简单且容易想到的做法是增加人手，或者让现有的人延长工作时间。理论上说，这样似乎能成，但是，实际上似乎会带来更多的混乱，士气低落，产生不合格的产品，又疲于奔命般地亡羊补牢，不知何时才是尽头。

我们从小就被教育，做事要用功，但是，从来没有人说，做事要用力。学了最基本的物理知识，知道了功等于力乘以距离。接受了高级一点的物理知识以后，才知道，光增加力或距离，有时并不能增加功，还有一个角度在里面作怪。

加班或增加人手的确可能会解决问题，但是，那是初级物理。高级一点的，就要关注那个角度。想想，如果真的通过简单的加时或加人能解决问题，那还要软件工程干什么呢？还要项目管理干什么呢？

也许，调整一点小小的角度，会产生意想不到的效果，并且，不像以往那么费力。

做事要用功，而不是用力。