在一个品发布ƈ使用之后Q其中肯定有许多地方不如意和值得改进的地斏V客户在使用的过E中会发C些问题，提出更高的需求，市场也在发生变化Q我们的竞争Ҏ也在发展Q新的技术不断地产生Q这些因素推动着我们的品不断地向前发展Q它的版本不停地往上增ѝ这些发展的需求不是一下子提出来的Q在客户使用的过E中发现某些不如意不方便的地方，他们会向我们的技术支持h员提意见Q而技术支持h员会把这些需求以BUG的Ş式存入BUG数据库中Q其U别一般定义ؓ下一个版本的Feature。有些上一个版本未解决的BUG也可能需要在本版本中来解冟뀂因此当我们来开发下一个版本时Q其许多Ҏ已l存在于BUG数据库中了。当然新版本的特性不是只从BUG中获得，理层可能从市场的角度来提出新的Ҏ以求领先竞争对手，开发h员本w也可提出某些要求来U_新版本开发的计划中，如要求对某部分代码进行重构以使其l构更清晰更Ҏl护Q执行效率更高?br />
每个人把同自q关的功能模块攉hQ同旉估时_其中主要包括写文档的旉、开发时间和单元试的时_一般要求精到工作日。这些信息发送给l长Q组长再把本组人员的Q务和预估旉发送给理层，q理层Ҏd及进度进行评估审核，理层会Ҏ产品发布旉及客户需求、市场因素等斚w作出选择Q可能某些功能由于时间紧急会被推q到下一个版本中厅R若预估出来的时间同预计的品发布时间有较大冲突Q而且此功能是本版本中必须得做的，则开发小l会被要求重新预估时_加快开发速度来达到这个要求?
虽然q个开发进度时间是一个大概的估计旉Q但我们要尽力按照这个开发进度来执行。每个星期五下午我们有一个Status MeetingQ一般那时工作效率较低，适合开会）Q在此会议上我们会根据这个进度来review我们的工作，每个人手上的工作是否按照q个q度在走Q是否有人g后了Q是否block住别人的工作了。在此会议上每个人都要报告自qq度Q同时还要报告上个星期做了什么，正在做什么，以及下个星期打算做什么。通过q个会议Q会让你觉得有h在监督你Q无形之中迫使你不断地督促自׃要d延后Q如果有延后的迹象也会尽早发现而赶上。若某些l过努力不能赶上Q那也没有办法，只能修改原先的进度表Q因为那是我们的估计与现实发生了偏差Q我们必M我们的进度表W合实际情况Q这可以避免许多目发生最后的20%的工作量会占?0%甚至一直拖后的情况。修改进度表的情冉|们曾l发生过Q有一ơ在按照原先的进度执行到要完成的状态时H然接到通知׃市场及客L原因要求加入另一w大的功能Q这个功能对我们E序的结构有非常大的影响Q因此我们就要重新制定一个进度来满需求。在q种情况下，产品原先的开发进度被打ؕQ发布时间也因此推迟。当然这U情况应当尽力避免，其在项目后期生新的需求，若不得已也应重新规划q度Q而不是仍旧依照原先的q度L行，因ؓ老的q度已不能反映现实的情况?
2. 开发文?/p>
在项目进度安排中我们已经把写文档的时间也规划q去了，q里虽然是写文档Q其实是设计E序Q整理一下思\与架构，刀不误砍柴工，q样在实际写代码时会畅很多Q节省时_因此可以说真正有思想性的东西都在写文档这D|间内完成了。当然我们这里的文档格式不象 ISO那样规定了条条框框，我们的文档格式相对自由，基本上能随意发挥Q但对于几个主要点一般来说是需要说明的。要求写的文档能让他人比较容易地看明白，能把问题讲清楚，能反映你的设计思想。文档的数量也不多，开发文档有两类Q一cLfunction SpecQ另一cLDesign Document?
function Spec中需要写明的是本模块完成的Q务，解决什么问题，有什么作用，Z么要q些功能Q此外我们还会添加进适用范围Q有什么不I注意Ҏ什么，q有哪些地方在以后可以进行改q。在q个function Spec中不涉及CQ何非常详l的法。此文档不光l开发h员看Q还让QA及其他成员以及后来的Ch能根据此文档来了解此模块的大致功能，同时也会l文档编写者看Q他们会Ҏq些function Spec整理Z份用h册，告诉用户此版本中新增了哪些功能，各功能模块有什么作用，如何使用{信息。因此在我们的开发过E中function Spec是很重要的文档，此文档完成后会抽ZD|间同相关人员及QA一起reviewq个文档Q让QA了解设计者的意图Q同时熟悉新的功能模块，为接下来的测试作准备。如果其中有误解或不明之处，大家会提出来探讨q由开发者修正?
Design Document中主要描q实现此模块所涉及到的主要法、数据结构、类的层ơ结构及调用关系。这个文档的阅读者主要是开发h员，包括M想了解详l实C码的人，帮助Z理解代码。在某些功能模块比较单的E序中，此文档所描述的信息会比较。此文档不象function Spec要在开始写代码前就~写完成Q它可以随着代码~写的进行而增加，但基本上遵@文档先行原则Q也是要增加新的代码或修改代码前若有涉及到文档部分的应先修Ҏ档，然后再修改代码?
3. ~写代码
׃我们用JAVA语言q行开发，因此我们借助了Jbuilder IDE工具。关于代码风|我们基本上套用Jbuilder中自动的代码格式~排Q但其中需要改变的是羃q是4个字W，cMcM间间?行，Ҏ与方法之间间?行，importcL用完整的cd。写代码时要对类及函数提供详l的注释及说明，基本做到看它们的说明p知道q个cL函数的功能以及主要算法的实现原理。在开发过E中对主要的模块要编写UnitTestQ同时要UnitTest先行Q也是遵@XP规则中的试驱动原则Q当所有的单元试代码通过Ӟ此功能也基本上完成了?
4. 代码理
我们采用VSS+SourceOffsiteq行版本控制Q其中存放了此品的所有源代码、库文g、文档及release时的安装E序Q各个部分存攑֜不同的目录中。每天早上要求开发h员从VSS中get latest version的源代码Q然后进行编译ƈ开始一天的工作。在下班之前理论上要求员工check in所有当天修改的代码Q在check in之前要保证编译是能通过的。若有谁check in的代码导致daily buildp|则会被要求某些惩|措施或警告Q象微Y公司要负责照看当日的每日构徏。有时我们编写的代码涉及到多个文Ӟ而且此改动是比较复杂需要花费多天的工作量，如果现在check inq去可能会导致BVTQBuild Verify TestQ测试通不q，因ؓ有些代码没有完全完成Q而之前的代码能BVT试通过Q而且q些代码基本上不会涉及到他hQ在q种情况下可以不check inq去Q直到全部代码完成能提交BVT试时再一起check inq去?br />
每天我们都会做daily buildQ一般是在凌?点进行，那时有个E序会自动从VSS中拉下最新的代码q进行编译。因为我们同国q行同步开发，因此如果惌把修改的代码q入到这个build中去那就需要在凌晨4点之前把相应的代码check inq去。若有hcheck inq去的代码导致编译通不q则会在本步骤中被发现。当~译完成之后自动产生安装包，试部门会对这些代码进行BVT试Q同时对VSS中开发库打上labelQ如果发C什么BUGpҎq个label知道是哪个时候开始出现这个BUG的。BVT是指Build Verify TestQ是对组件中基本功能的测试。这个测试每天都会进行，看新加入的代码或修改是否会媄响系l的基本功能Q便于及早发现错误?
5. 试
在开发h员完成了function Spec后，试部门开始了试规划Q确定需要测试哪些方面，如何试及进度安排。测试h员需要写许多试代码Q有些测试代码需要集成进BVT试Q有些可能需要进行单独的试Q目的都是ؓ了产品W合要求Q开发h员容易找出问题所在ƈҎ。品功能是否符合了要求Q是否能被发布是由测试h员决定的Q因此测试h员也比较辛苦Q责任重大。通过了每天的BVT试Q还有一些性能试、兼Ҏ测试、灾难测试等需要在产品发布前进行。在完成q些试之后由测试h员决定本产品是否能release出去了，如果没有什么问题则会给某些关系较好的用戯行β测试，之后再最lrelease出去?
6. BUG理
׃我们每天q行着试Q因此经常有BUG被测试部门发玎ͼ一旦发C新的BUGQ就会被dqBUG Tracking System中。目前较行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla{。BUG tracking system是开发h员和QA之间的纽带，开发h员和QA通过BUG tracking system联系着。每个BUG有其cd和别，预定的类型有Crash-Data Loss, Crash-No Data Loss, Incorrect functionality, Cosmetic, Feature request{? U别有P1、P2一直到P6Q它们分别代表了重要性及紧急程度，P1的BUG需要很快fixQP5之前的BUG在本版本release之前必须fix掉，若真的不能或不重要则由QA定q低优先q入C一个版本中去fix。QA发现一个BUG后在BUG Track中增加一个BUGQ同时填入相关信息ƈassignl相应的开发h员，开发h员收到BUG分析qfix后assignlQA去verifyQ其中要填上分析的结果以及如何解决的详细说明。若QAҎBUG verify通过则close BUGQ否则verify failedq新assignl开发h员ƈ{待其fix。每星期在Status Meeting上会q行BUG状况报告Q主要由QAl长报告BUG的状况，主要是新增BUG敎ͼfix掉多，q有多少处于open状态，有多处于等待verify的状态，据此可以了解开发及试情况。有时在Status Meeting上我们也会进行BUG ReviewQBUG Review有时是单独一个小l内q行Q其主要作用是重新明每个h头上的BUG以及了解每个BUG的状况，如开发h员对此BUG作何处理等Q以此来了解开发中是否有碰到比较棘手的问题Q增加了产品发布风险。在QA增加BUG和开发h员fix BUG的游戏中QBUG的数量曲U图会象股市曲线一样上下L动，但M势一般是前期BUGN攀升，后期震荡下挫Q若C后期新open的BUG数量一直上升则说明风险在增大，有可能无法控Ӟ也就是说fix了一个BUGD了多个新的BUG产生。在量化开发进度中也可以用代码数量的曲U图来粗略的呈现。在有大量新功能增加时可能代码量的增加会较快Q当在fix bug阶段Q代码的修改较多Q因此代码数量的增幅会降低，依据代码量可以看出开发的状况处于何种阶段?
需要指出的是我们对BUG的定义比较广泛，一些新功能也可以作为BUG被提出，只不q这些BUGU别比较低，让它们进入到下一个版本中d现。因此BUG的创也可以是技术支持h员、市Zh员甚臛_发h员本w。关于开发h员本w，因ؓ他可能会扑և一些BUGQ有些是其他开发者的Q有些可能是此开发者本w的Q把q个BUGdqBUG库中可以帮助开发h员在以后产生新问题时或类似的BUG时有一个借鉴和思\Q但此BUG的verify必须要让试本模块的试人员来verify?br />
7. Code Freeze
当P5之前的BUG都被修复了，q时M品发布日期也׃q了Q一般是2个星期后prelease产品Q这时要对VSS中的代码q行freezeQ以保证代码库的E_性。Code freeze阶段一般会把各开发h员的check in和check out的权限关闭，若在q时仍有BUG报告上来q经讨论定是重大的且必d本版本中fix的，则需要经理层同意ƈҎ地授予权限，在修改完成后修改者要把修改了哪些文gQ媄响了哪些文档{信息上报给各部门如QA、build人员、文档编写者等。在codefreeze阶段Q测试部门在紧张地进行着各种试Q得出各U数据，q决定本版本是否可以release了?br />
8. Tech Talk
计算机知识更新速度非常快，l常有一些新的术语、新的名词、新的思想、新的技术所产生Q如q离开此行业几个月后重新回来就会对q些新的事物不解Q而我们^时ؓ了自q目埋头苦干可能忘了周围的世界发生了什么。Tech Talk提供了一个让我们了解新知识和最新发展趋势的ZQ让大家把知识共享，共同提高。TechTalk一般会在项目不是太忙碌的时候进行，LZ提前一个星期指定某个hd备一下Tech TalkQ一般此人可能对某方面比较感兴趣Q然后他会花一些时间去了解q方面的情况Q写成一个文档如PowerPointq上传到局域网内，同时通知大家可以先去览。Tech Talk的内定w常广泛，不一定同我们的项目紧密相养IM新的思想、新的知识（当然一般是限在计算机领域内Q都可作为Tech Talk的内容，而在主讲完之后还有一D|间被大家提问Q共同对q个话题q行讨论Q答疑解惑。当然Tech Talk也可同我们的目相关Q如研究一下竞争对手的产品技术，本公品的架构{。研I本公司的品架构可以大家Ҏ公司的品有一个全局的概念，从整体上来看自己的品，Z整理一下品的架构使之更加清晰有条理。^时大安只注重于自己负责的其中的一块Q在Tech Talk中可以蟩q框框来了解全局Q同时这也是新员工了解公司核心技术整体框架的好机会。每个模块的负责人需要阐q此模块的方斚w面，让大家来了解q回{问题?
9. Code Review
当进行工作移交时我们会进行Code ReviewQ在到手的BUG时也会进行Code ReviewQCode Review是大家了解其详细实现的一个好Z。在Code Review之后会对此代码生亲切感而不是陌生惧怕感Q相信很多h在读他h代码时会有非常痛苦的l历QCode Review是减此痛苦感的好药斏V在q行Code Review前，主讲Z提前发出一个通知告诉相关人员要review哪些代码Q这样参与者可以抽出时间提前了解相关代码，对不懂的地方做个W记以便在Code Reviewq行中提出疑问。在我们到比较手的BUG没有什么思\或大惑不解时Q这时找几个相关人员或对此代码也熟悉的hq行一ơCode ReviewQ这时Ş式比较随意，大家可以临时提出问题Q让主讲{，在这个过E中可能听的人ƈ不会非常快地了解其中的详l过E，但是讲的人在q个q程中重新理了一下思\Q对所写的代码被迫重新审视了一遍，在其中可能就会发现出解决问题的办法。在Code Review时有时代码非常多Q但可以一个功能模块一个功能模块地从M到局部，由浅入深层层递进的方式进行。一ơCode Review的时间不要太长，但可以分多次q行。Code Review中大家会提出问题和徏议，集思广益，多个人共同出LQ有些可能一个h没有惛_的问题会被大家发玎ͼ互相学习Q共同进步?br />
10. 沟通与交流
大部分员工的大部分时间是在公叔R度过的，因此公司的生zL了大家主要组成部分。员工之间关pȝ融洽Q交的畅通显得非帔R要，同时大家也不惌q生活q样枯燥乏味Q一直同机器打交道。沟通无处不在，交流随时发生Q有许多关系是在工作之外建立h的。Y件公司内是很Ҏ产生各种矛盾的，因ؓq是׃的工作性质所军_的，比如QA或用户会对你的实C满意Q提出各U要求时Q我怿你有时会有所抱怨的Q无形之中就产生了对立，发展到后来会有抵触心理。我怿大部分h都会有此感受Q这不是你的错，q主要是由我们的工作性质军_的。如果你的工作是把胦富带l对方，则对方会非常Ƣ迎你的到来Q把你奉爷来对待，同你的关pM非常融洽友好。因此我们需要在工作之外来消除这U对立矛盄关系Q徏立一U融z的工作氛围。我们在qx吃饭的时候饭桌上大家互相聊天沟通。我们徏立了happy邮g列表Q其中会发一些幽默笑话之cȝ邮gQ给我们紧张的工作增加点L的氛围。在下班后大家可以组l一下活动，增加了公司的凝聚力。一个品发布后l织一下旅游，让h紧的经村ּ一下，更好地迎接下一个挑战?
]]>