大中小构建高效软件开发流程和团队(8).docxVIP

大中小构建高效软件开发流程和团队 (8) 在一个产品发布并使用之后，其中肯定有许多地方不如意和值得改进 地方。客户在使用过程中会发现一些问题，提出更高需求，市场也在发生 变化，我们竞争对手也在发展，新技术不断地产生，这些因素推动着我们 产品不断地向前发展，使它版本不停地往上增长。这些发展需求不是一下 子提出来，在客户使用过程中发现某些不如意不方便地方，他们会向我们 技术支持人员提意见，而技术支持人员会把这些需求以 BUG 形式存入 BU G数据库中，其级别一般定义为下一个版本 Features有些上一个版本未解 决 BUG 也可能需要在本版本中来解决。因此当我们来开发下一个版本时， 其许多特性已经存在于 BUG 数据库中了。当然新版本特性不是只从 BUG 中获得，管理层可能从市场角度来提出新特性以求领先竞争对手，开发人 员本身也可提出某些要求来纳入新版本开发计划中，如要求对某部分代码 进行重构以使其结构更清晰更容易维护，执行效率更高。 每个人把同自己相关功能模块收集起来，同时预估时间，其中主要 包括写文档时间、开发时间和单元测试时间，一般要求精确到工作日。这 些信息发送给组长，组长再把本小组人员任务和预估时间发送给管理层， 由管理层对此任务及进度进行评估审核，管理层会根据产品发布时间及客 户需求、市场因素等方面作出选择，可能某些功能由于时间紧急会被推迟 到下一个版本中去。若预估出来时间同预计产品发布时间有较大冲突，而 且此功能是本版本中必须得做，则开发小组会被要求重新预估时间，加快 开发速度来达到这个要求。 虽然这个开发进度时间是一个大概估计时间，但我们要尽力按照这 个开发进度来执行。每个星期五下午我们有一个 Status Meeting (—般那 时工作效率较低， 适合开会)，在此会议上我们会根据这个进度来 review 我 们工作， 每个人手上工作是否按照这个进度在走，是否有人延后了，是否 b lock 住别人工作了。在此会议上每个人都要报告自己进度，同时还要报告 上个星期做了什么，正在做什么，以及下个星期打算做什么。通过这个会 议，会让你觉得有人在监督你，无形之中迫使你不断地督促自己不要使任 务延后，如果有延后迹象也会尽早发现而赶上。若某些经过努力不能赶上， 那也没有办法，只能修改原先进度表，因为那是我们估计与现实发生了偏 差，我们必须使我们进度表符合实际情况， 这可以避免许多项目发生最后 2 0%工作量会占据 80%甚至一直拖后情况。 修改进度表情况我们曾经发生过， 有一次在按照原先进度执行到将要完成状态时突然接到通知由于市场及客 户原因要求加入另一项重大功能，这个功能对我们程序结构有非常大影响， 因此我们就要重新制定一个进度来满足需求。在这种情况下，产品原先开 发进度被打乱，发布时间也因此推迟。当然这种情况应当尽力避免，尤其 在项目后期产生新需求，若不得已也应重新规划进度，而不是仍旧依照原 先进度去执行，因为老进度已不能反映现实情况。 3. 开发文档 在项目进度安排中我们已经把写文档时间也规划进去了，这里虽然 是写文档，其实是设计程序，整理一下思路与架构，磨刀不误砍柴工，这 样在实际写代码时会流畅很多，节省时间，因此可以说真正有思想性东西 都在写文档这段时间内完成了。当然我们这里文档格式不象 ISO 那样规定 了条条框框，我们文档格式相对自由，基本上能随意发挥，但对于几个主 要点一般来说是需要说明。要求写文档能让他人比较容易地看明白，能把 问题讲清楚，能反映你设计思想。文档数量也不多，开发文档有两类，一 类是 function Spec,另一类是 Design Document。 fun ction Spec中需要写明是本模块完成任务，解决什么问题，有 什么作用,为什么要这些功能,此外我们还会添加进适用范围,有什么不 足,注意点是什么, 还有哪些地方在以后可以进行改进。 在这个 function S pec中不涉及到任何非常详细算法。此文档不光给开发人员看，还让 QA及 其他成员以及后来新人能根据此文档来了解此模块大致功能，同时也会给 文档编写者看， 他们会根据这些 function Spec 整理出一份用户手册， 告诉 用户此版本中新增了哪些功能，各功能模块有什么作用，如何使用等信息。 因此在我们开发过程中 function Spec 是很重要文档， 此文档完成后会抽出 一段时间同相关人员及 QA 一起review这个文档，让QA 了解设计者意图， 同时熟悉新功能模块，为接下来测试作准备。如果其中有误解或不明之处， 大家会提出来探讨并由开发者修正。 Design Document 中主要描述实现此模块所涉及到主要算法、 数据 结构、类层次结构及调用关系。这个文档阅读者主要是开发人员，包括任 何想了解详细实现代码人，