## 产品设计体会(五一)——敏捷的估计与规划
前段读了《敏捷估计与规划》,这本书很适合开发经理看,我只是很快的浏览了一下,摘录一些体会。
Ø 敏捷的里程碑是功能驱动的,先完成可交付的最“重要”功能,重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的,到了项目50%的时间,可能进入“编码”,但对客户来说,等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式,因为这里有个不合理的假设前提:所有功能都能够完成、必须完成,中间过程对客户是透明的。
Ø 项目估计的不确定性是会累积的,80%×80%×……,所以开始订的项目计划,在一个月后已经面目全非,强行的遵守是没有意义的,而应该不断的修正计划,当然,更好的做法是一开始的计划中间留有一些柔性的内容。
Ø 随着时间变化,必然有新的信息出现,特别是瞬息万变的互联网业界,死守着开始的项目计划不调整是没有逻辑的做法,敏捷的迭代刚好权衡了变化的成本和不变的成本,就是:不变本次迭代,更新下次迭代,这是一个将项目计划细化粒度的做法。
Ø 需求唯一不变的特征就是“不断变化”(plus不断细化),敏捷的思想就是欢迎变化,拥抱变化。瀑布模型一次性完成的需求分析,会存在“过度需求”的问题,降低整体效率。
项目管理理论的发展,从开始混乱,每个项目自有一套,每个PM自有一套;到后来人们非常想订出一个统一的简单的流程,减少人为影响(瀑布模型等出现),;再后来进入灵活的敏捷,看似又变得混乱,实则有序。又是宛如那个哲学的三段论:见山是山à见山不是山à见山还是山;也如管理的三个境界:人治à法治à无为而治。
- 前言
- (一)——变态吧,开始帖周报了
- (二)——数据分析
- (三)——性价比:做不做?
- (四)——需求管理
- (五)——有关流程
- (六)——再谈流程
- (七)——需求探针
- (八)——产品与项目
- (九)——关于学习
- (十)——团队合作
- (十一)——市场扫描
- (十二)——少而精
- (十三)——再说需求分析
- (十四)——做过的几个项目
- (十五)——PM、PD、UE与UI
- (十六)——Feature List
- (十七)——PD的几种文档
- (十八)——概念设计
- (十九)——UPA年会的流水账
- (二十)——有关改版
- (二二)——封闭开发
- (二三)——用户研究
- (二五)——当交互设计遇到敏捷开发
- (二六)——PD就是出来卖的
- (二七)——大产品设计
- (二八)——细节之文案
- (二九)——产品设计的五个层次
- (三十)——“体会”导读的思维导图
- (三二)——零散的体会
- (三三)——用户大会
- (三四)——土老板破冰必杀技
- (三五)——QA与测试
- (三六)——再理解“敏捷”
- (三七)——可用性测试
- (三八)——项目外包!=开发外包
- (三九)——CSDN专访精编版
- (四十)——销售渠道
- (四一)——用户创意无限
- (四二)——又是零散体会
- (四三)——说说评审会
- (四四)——项目外包不适合“敏捷”?
- (四五)——外行眼中的技术分工
- (四六)——UML学习摘录(上)
- (四七)——UML学习摘录(下)
- (四八)——资源战争与BRD
- (四九)——产品市场化
- (五十)——终点:Matrix
- (五一)——敏捷的估计与规划
- (五二)——MS Office使用心得
- (五三)——产品文档与规范
- (五四)——PD招聘广告词
- (五五)——项目Kick Off
- (五六)——《需求工程》培训记录
- (五八)——《项目化管理》培训记录