大 中 小 构建高效软件开发流程和团队在一个产品发布并使用之后, 其中肯定有许多地方不如意和值得改进的地方。客户在使用的过程中会发现一些问题, 提出更高的需求, 市场也在发生变化, 我们的竞争对手也在进展, 新的技术不断地产生, 这些因素推动着我们的产品不断地向前进展, 使它的版本不停地往上增长。这些进展的需求不是一下子提出来的, 在客户使用的过程中发现某些不如意不方便的地方, 她们会向我们的技术支持人员提意见, 而技术支持人员会把这些需求以 BUG 的形式存入 BUG 数据库中, 其级别一般定义为下一个版本的 Feature。有些上一个版本未解决的 BUG也可能需要在本版本中来解决。因此当我们来开发下一个版本时, 其许多特性已经存在于 BUG 数据库中了。当然新版本的特性不是只从BUG 中获得, 管理层可能从市场的角度来提出新的特性以求领先竞争对手, 开发人员本身也可提出某些要求来纳入新版本开发的计划中, 如要求对某部分代码进行重构以使其结构更清楚更容易维护, 执行效率更高。 每个人把同自己相关的功能模块收集起来, 同时预估时间, 其中主要包括写文档的时间、 开发时间和单元测试的时间, 一般要求精确到工作日。这些信息发送给组长, 组长再把本小组人员的任务和预估时间发送给管理层, 由管理层对此任务及进度进行评估审核, 管理层会根据产品发布时间及客户需求、 市场因素等方面作出选择, 可能某些功能由于时间紧急会被推迟到下一个版本中去。若预估出来的时间同估计的产品发布时间有较大冲突, 而且此功能是本版本中必须得做的, 则开发小组会被要求重新预估时间, 加快开发速度来达到这个要求。 虽然这个开发进度时间是一个大概的估量时间, 但我们要尽力根据这个开发进度来执行。每个星期五下午我们有一个 Status Meeting( 一般那时工作效率较低, 适合开会) , 在此会议上我们会根据这个进度来 review 我们的工作, 每个人手上的工作是否根据这个进度在走, 是否有人延后了, 是否 block 住别人的工作了。在此会议上每个人都要报告自己的进度, 同时还要报告上个星期做了什么, 正在做什么, 以及下个星期打算做什么。经过这个会议, 会让你觉得有人在监督你, 无形之中迫使你不断地督促自己不要使任务延后, 假如有延后的迹象也会尽早发现而赶上。若某些经过努力不能赶上, 那也没有办法, 只能修改原先的进度表, 因为那是我们的估量与现实发生了偏差, 我们必须使我们的进度表...
