3. 实现故事。在软件框架上，实现一个故事，再实现一个故事，…项目管理者联盟
4. 实现变更。有时发现事情并没有想象的简单，于是就变更它，这就要求我们实现这些次变更。它象实现故事一样：实现一次变更，再实现一次变更，…项目管理者联盟
5. 部署软件。感觉软件已达到了可被接受的预想或合适的要求了，就发布这个软件。
上面所说的故事就是我们常说的用例（use case）。我们可以使用用例的形式来描述整个系统的计划内容，并计算它的工作量，为工作之间、项目之间的绩效提供一个统一的衡量标准。项目管理者联盟
这时，我们发现：项目管理者联盟
1. 由故事（有些项目可以用故事所包含的步骤）的数量可计算出开发的工作量项目管理者联盟
2. 我们实际开发工作过程的时间、成本、进度是可以被不了解项目实现技术的人所感知的
如果我们仔细查看项目的所有工作，会发现有些工作不是基于某个用例的，也与某些用例没有直接关系，如何拿用例来计算它的工作量呢？在项目的开发中确定存在这些工作，如项目开始时的“了解软件项目的故事”。但通过分析知道，在一个软件项目中顶层用例的数量是不难预测的，也是说在这个时期要向关键人了解的用例数是可以预测的。我们不难发现，要了解的用例数越多，需求了解的工作量就越大。在相同类型的应用软件开发中，需求了解的工作量与用例数量的比例是基本一致的。同理，了解系统隐喻，构造软件框架、部署软件的工作量与用例的量也是成比例的。
在没有不熟习技术的前提下，根据本人的经验，同类软件项目的工期与底层用例数或步骤数有着可计算的关系，如WEB应用软件中，一个底层故事的开发时间大约为1.5个人日。这个是经验数据，在不同的公司可能有所不同。网上也有文章证明不同规模的应用软件，故事与程序代码的行数有一定的计算关系。这样我们的不同项目，或同一项目的不同故事之间，在时间、成本、进度上就具有了可比性。talent.mypm.net
同时，我们发现：项目管理者联盟
3. 让项目的时间、成本、进度的估算可以通过简易的公式进行一次性计算得到项目管理者联盟
4. 让项目工作量的分配更具体、更客观，对成员的绩效表现显而易见项目管理者联盟
5. 使项目之间的工作绩效具有可比性
要注意的问题项目管理者联盟
项目管理者联盟
1. 在不同层次上的用例有着不一样的工作量比例，一定要分清。比如WEB应用软件的用例可以这样划分：blog.mypm.net
用例层次 对应系统的对象项目管理者联盟
顶层 项目，如网上商城项目经理博客
上层 子系统，如网上商城＼用户管理项目管理者联盟文章
中层 流程，如网上商城＼用户管理中＼注册流程项目管理者联盟
底层 页面，如网上商城＼用户管理中＼注册流程＼第一个页面training.mypm.net
2. 这种用例与工作量的比例关系，是建立一定量的基础之上的，比如20个以上才有这个比例关系。对于一般应用软件的计划及绩效的计算是合适的，但对于个例是不适用的，不能凭这个比例来衡量某几个用例的工作量。
总结项目管理者联盟
项目管理者联盟文章
好了，下面总结一下本文方法的实现步骤：项目管理者联盟
1. 了解软件项目的故事。从项目关键人物那了解到系统的主要故事有哪些，并力求描述清楚项目管理者联盟
2. 了解系统隐喻，构造软件框架项目管理者联盟
3. 实现故事。先实现顶层故事；再一个一个故事实现项目管理者联盟
4. 故事变更。实现一次变更，再实现一次变更，…项目管理者联盟
5. 部署软件项目管理者联盟
项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
