|
项目管理者联盟
周三的下午，我像平常一样，写着代码听着歌，突然从天而降一份莫名其妙的故事列表，说让我给个人天，用来投标用。作为一个技术异常牛逼的高端程序员，这对我来说岂不是
A Piece Of Shit…哦不，Cake。拿着列表，打眼一看就知道是做什么 —
又是个审批流系统。注册、登录、忘记密码…这些也需要时间?!哦，还要做个SSO，可能要做点数据集成，给个15人天吧!又是一堆CRUD… CRUD
各给2人天一共8个。看起来有4个
Model，乘个4，32个人天差不多。前端还有些工作量，找前端估一下…还有些跟遗留系统集成的部分，这块应该比较麻烦，给个30人天差不多…还要用微服务架构，估计需要一些基础环境，每个组件给3个人天，一共8个组件，算24吧….总共算起来130个开发人天，差不多，再加点buffer，算150吧!差不多了吧…项目管理者联盟
这一幕是不是有点眼熟?不过，这样的做法可能会带来下面的几个问题：项目管理者联盟
1. 估计者的估计点数是否能代表团队的估计点数?项目管理者联盟
问题的答案显而易见。那么有同学会说，此时团队的人员还没完成配置，没办法让真实团队进行功能的估计。确实是这个样子，所以我们只能力所能及的去模拟真实团队进行估计。一般，交付项目的团队肯定不会全上非常有经验的同学，人员配比一定会有
leverage，也就是 Senior 人员和 Junior 人员的比例。所以，在估计的过程中，至少要引入 Junior
的同事，能够从不同经验的角度来看待同样的问题，来使估计不会过分“乐观”。项目管理者联盟
2. 是否有故事卡片之外的工作时间没有考虑到呢?项目管理者联盟
上文中的估计看起来是采用的经典的“理想人天”估计法，如果使用这样的估计方法，势必要考虑一些虽然没有在故事卡工作量中，但也一定会花费时间的事务，包括但不限于：项目管理者联盟
回复电子邮件(沟通成本)bbs.mypm.net
面试(内部耗损)项目管理者联盟
参加会议(包括内部会议，比如站会、Retro、Code Diff、技术研讨会议、客户沟通会议等)项目管理者联盟
为当前发布提供支持(上线支持)项目管理者联盟
培训?(内部的 Session)转自项目管理者联盟
任务之间切换/被人打断(程序员出栈入栈的消耗…)项目管理者联盟
修复bug(一定会有 Bug，一定会花时间修…)项目管理培训
写各种文档(对于对文档比较看重的客户，这一部分会占用不少的时间)项目管理者联盟
这些事务会伴随整个交付过程中发生，基本上都是正常交付必不可少的工作内容，而且根据笔者的经验，这些事情占据的时间并不比完成故事卡的编码工作要少。项目管理者联盟
3. 故事卡的需求是否清晰呢?项目管理者联盟
在项目启动前拿到的故事列表，往往只有 Epic 级别的，也就是很粗粒度的故事卡。故事卡中的 AC(Acceptance
Criteria，验收条件)往往只考虑了最简单的 Happy Path，然而大部分项目中(尤其是 ToB项目)，Exception
才是相对复杂的，这些异常情况往往需要花费更多的时间完成。在这种情况下进行估计，可想而知，一些隐藏的需求点往往难以发现。项目管理者联盟
问题可能的答案项目管理者联盟
那么想要解决上面的问题，或者说更好一点的缓解上述问题的方案是什么呢?《敏捷估计与规划》中介绍了一些基本的方法。项目管理者联盟
首先，要进行集体估计项目管理者联盟
集体估计可以缓解因为个人能力不同所引发的单点偏差，不同的开发成员对于某个需求在不同角度的阐述，也容易让大家对需求有更全面的理解，也易于发现潜藏在需求中的风险。阐述的过程中，出现复杂问题时，可以及时联系相应的专家资源。对于一些规模较大的卡片，也可以综合大家的意见，进行更合理的拆解。同时，需要由要做次工作的人来进行估计，这样会产生更多的责任感，可以在一定程度上缓解乐观估计的问题(Lederer
and Prasad 1992)。项目管理者联盟
其次，是方法项目管理者联盟
《敏捷估计与规划》介绍了2种基本的方法：理想人天法和故事点法。项目管理者联盟
(1)理想人天法
|
