|
但在功能点分析(Function Point Analysis)中是一个基本概念。FPA通过对软件中的“业务数据”以及对其进行的“业务操作”为基本单元建立了颗粒度的概念，进而建立了规模的概念。这些概念的应用成熟度、推广程度、数据积累量(公开的在10000个左右，在咨询公司手中但非公开的在50000个左右，实际使用量不可估量)都远远超过敏捷开发或其他体系提出的方法，包括“故事点”。而且“业务操作”的概念非常接近用户故事，也包括如减少依赖、完整交付客户价值等描述。项目经理圈子
下面举一个例子来看功能点到底是什么。这里将略去功能点中对数据、操作的复杂细节分析过程，而只说大概。blog.mypm.net
假设在一个OA系统中需要管理“用户”“角色”“权限”这三种业务数据，那么他们就是业务数据;而对他们分别进行的“增删改查”就是业务操作。比如“新建用户”“列出所有用户”都是业务操作。“业务”这个词在这里是相对于“技术”而言的，比如“新建用户”对客户而言是一个容易理解、认可的操作，而且客户管理员会告诉我们：项目管理者联盟
“是的，我现在每天都在新建用户，因为最近正在招人”而不会说“是的，我最近每天都在数据库表中新建记录，还会同步更新联系人数据表，因为最近正在招人”，虽然后者也的确发生了，但却不是客户日常工作的内容。转自项目管理者联盟
更神奇的是，“新建用户”这个操作，在无法获得更多细节的情况下，可以假设工作量为4人天(在OA系统中，其他系统有调整因子);而统计还表明，“用户”及所有与之相关的操作如刚才说的“新建用户”以及其他“删除用户”“列出所有用户”“编辑用户”……的总工作量(从需求到部署)大约是40人天，也就是2个人月，即使暂时不能确定到底有多少个操作。而“用户”“角色”“权限”及其所有操作完成的工作量自然就是大约6人月。尽管每个数据或操作的时间可能会有出入，但总体规模则误差不大。blog.mypm.net
这得益于大数定理及众多统计数据的分析结果。本段内容的详情可在Google查询“nesma”(一个总部在荷兰的世界第二大功能点组织)，这个简化体系称为“Indicative Function Point”(指示性的功能点)，在其网站上有荷兰语和英语介绍。项目管理者联盟
如果对用户故事的定义(而非“业务操作”的定义，因为后者更完善、严格)略作约束，则可以迅速与功能点中的“业务操作”兼容。兼容的结果有两个，首先是很容易把握颗粒度，其次是功能点与工作量的比例关系极佳，可以迅速推知工作量。项目经理圈子
二、需求结构问题项目管理者联盟
在敏捷开发中有一个不完善的答案：Product Backlog 和 Sprint Backlog。前者是整个产品的待开发项，后者是当前迭代的待开发项，两者内部都按优先级进行排序。www.mypm.net
这个答案对项目经理(可以模糊理解为Scrum Mast*r)和开发人员足够用了，因为他们主要关心时间上的开发问题，也就是现在让我做什么，什么时候要的问题。但对产品经理(可以模糊理解为Product Owner)而言，时间是一个维度，空间则是另外一个维度。www.mypm.net
所谓空间维度，就是系统-子系统-模块-大需求-小需求……之间的关系问题，这完全不是一个一维表格能解决的。由于敏捷开发主要是一线开发人员和项目经理发明并推动的，所以空间维度一直被忽略。但这是需求分解过程中一个绕不过去的问题，因为人们不可能面对一个一个一维表格回答这个问题：“我们所有的功能都包括在这里呢吗?哪部分还略显粗糙希望继续分解?这些大需求包含哪些小需求?”项目管理者联盟
在UML中的答案比较完善，“用户 - Use Case”(人-功能)很好地把一批相关的功能联系起来。虽然只是非常简单的表达，但比把几个毫无关联的故事按优先级排在一起，或把几个密切相关的故事相隔十万八千里放置还是进步不少。UML中的模块则是一个更宏观的需求“目录”。项目管理者联盟
FPA虽然没有需求关系表达，但如果把“业务数据 - 业务操作”作为一个树形结构，很类似把UML中的“实体 – Use Case”作为一个树，形成“数据-功能”的关系。不过，这个体系没有提供更宏观尺度上的需求结构问题。www.mypm.net
由于功能点、UML中的模块用例等概念都是有严格、确定化的定义的，所以分解的过程井然有序，很少出现“这个还要继续分吗?”“这样分是不是颗粒度太粗糙”之类的问题。我们自己正在做的项目需求就是借用FPA的业务数据-业务操作作为主要分解关系，上面再加上我们自己定义的子系统-模块两个级别形成了一个“故事树”。这个故事树比我之前所做过及所见过的任何其他方法表达的需求结构更为清晰。因此敏捷开发应该吸取或者配合这些方法，至少是其中的一部分思想来完成需求分解。talent.mypm.net
很多时候我们会觉得引入较为严格的定义会“有限制太难做”，但其实更难做的是“无规则无限制”下自由发挥。项目管理者联盟
记者：敏捷开发中需求拆分之后，任务应该怎样分工?
陈勇：即使都是使用敏捷开发，任务拆分和分工的方法也会因行业、产品的特点而有所不同。项目管理者联盟
在纯软件或技术相对单一的产品中，需求拆解到4天左右(也就是前面提到的“一个业务操作”的规模)就可以分下去或领取了，因为人们比较容易估算4天左右的工作量，也容易跟踪。在这种情况下，如果一个人同时负责几个“业务操作”，应该分解为多个任务来完成，而不是一个。因为这些业务操作可以独立完成并交付，合在一起不但不能持续交付，也会使得进展不透明。但再进一步划分没有必要，因为再划分就不能独立交付了。“独立性”是FPA中对业务操作的一个约束条件，如果按照FPA的概念来划分任务，会自动满足独立性。
在复杂环境比如嵌入式研发(涉及软件、硬件、工业设计团队)或游戏(涉及软件、美术、脚本、策划团队)，需求不能直接当作任务分下去，需要做进一步的分解。这里的分解目的是把不同工种的活分配下去，对其跟踪的过程则可增进各部门配合时所需的透明度。项目管理者联盟
也有一些团队喜欢把任务分解到短至1～2小时的时间。本人没有与这样的团队进行深入探讨以了解其这样做的动机及收益是什么，但要注意“更小的任务”不等于更敏捷。我们经常说敏捷开发有利于项目透明，但要知道透明的主体是“项目外部的人”，比如产品经理、高层领导;而开发人员本人，或者小团队的若干个人之间，任务和进度本来就是透明或半透明的。因此把详细技术细节翻个底朝天并贴在白板上很可能不但于事无补反而添乱，不如把有限的管理时间用在“对外表达需求的完成情况”或“各部门的进展及需要什么相互配合”上，也就是我们之前说的两种情况。项目管理者联盟
总之，对任务的分解应该本着“需要”与“必要”的原则。不能因为想“更敏捷”而采用“更小的任务”。项目管理者联盟文章
记者：Sprint会议是实践scrum中最重要的事件。您认为Scrum会议在团队中应如何进行的?项目经理博客
陈勇：要做好计划会，应该先建好团队模型。项目管理者联盟
计划会是少有的团队齐集一堂进行的活动，无论团队模型是怎样的，都应该有助于大家以集体的力量完成计划，并完成计划的任务。项目管理者联盟
因此，一些看上去很敏捷的团队模型或做事方法，很可能是很难鼓励大家做到这一点的。比如：所有队员都是平等的;大家在会上投票取平均值作为估算结果(还有一种做法：会上不需要估算，会后领取的人自己说了算);会后大家主动领取任务;领取的任务大家互相不干涉，自己愿意怎么做就怎么做……这里边存在什么问题呢?training.mypm.net
|
