进度表：
基于程序员的工作项目而制定的进度表，叫做自下而上进度表。
基于管理阶层而制定的进度表，叫做由上至下进度表。
通常需要对两种进度表进行协商。
“我该回答你什么问题，才能让你更有信心给出估算？”
多做几次估算（通过两个不同的开发人员）是一种明智的检查方法。
PERT:（最佳估算值+4X最可能估算值+最差估算值）/6
如果你的团队每周以90%的几率按时完成工作，随着时间的进展，延迟的几率将会持续增加。
远景文档很差或没有 + 规格说明书很差或没有 + 工作估算悲观或乐观 + 没有用于集成的预算 + 没有用于UI迭代的预算 = 进度表的祈祷
在写下工作花费时间的估算数字时，需要对墨菲定律保持真诚的敬重。
让测试/QA团队参与进度安排很重要，因为他们会用自然的质疑和批评的眼光来看待工程工作。
尝试在某一天，你开始和结束每件事情都严格准时。然后问问自己，是否值得这样？为什么是或为什么不是？
项目规划：
谁能对需求授权？
谁能对设计授权？
谁能对技术授权？
谁能对预算授权？
对需求及设计进行检查的频度如何？调整依据是什么？
（大体来说，你所拥有的授权越少，就越需要勤奋地查看好确认设计，并引导调整方式。）
规划产物：
市场需求文档（MRD）：这是业务团队或营销团队对世界的分析。MRD帮助定义了项目中的“What”。
远景/范围文档：延续并大量引用MRD。远景文档直接定义了项目的“What”。
规格说明书：捕获了项目最终成果的样子。继承远景文档的思想，从设计和工程角度定义项目的"how"。
待续···
扫一扫
631
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
