| 有效资源 | 评估工作?/td> | |
| 1 | ?/td> | ?/td> |
| 2 | ?/td> | ?/td> |
| 3 | 相同 | 相同 |
有效资源Q指q代周期内，开发团队所能提供的有效工作日，单位?天?br /> 评估工作量：指P代周期内Q品经理提供需要实现的业务需求所评估的工作量之和?br />
上表描述以固定周期ؓ两周的P代中Q可能会出现的有效资源和评估工作量对比情c其中，1?两种情况因ؓ评估工作量小于或{同能提供的有效资源Q所以不会媄响P代周期。重炚w讨论的是有效资源于评估工作量时Q如何保持固定周期？
例DQ一q代周期Q能提供有效资源20?天，需求评估工作量30?天?br /> 1、功能较独立Q需求不能拆分发布；
安排一个releaseQ两个iterative。这U情况需要在q代2中附加一些技术改造或低优先的小需求、bugfixQrelease日期相对会慢几天?br />
2、一个P代中包括多个产品的需?需要各位品经理协商，军_需求优先)Q?br /> a)、以保证质量为重Q?br /> 忽略商业优先U，先处理一个P代中p全部完成的需求?br />
b)、保证h?br /> 分两个P代完成，一ơrelease?br />
通常情况下，我们力保证q代周期的稳定，但也允许例外Q如Q商业需求，产品上确定了发布旉点，或者节假期间团队请假比较多Q一个P代所能提供的有效资源相对比较的情况?br />
保持q代周期E_Q其核心是：固定Timebox和可提供的资源，让品经理来军_需求的优先U，每P代只接纳(开?QA资源)可承受的需求?/strong>
]]>
关于CodeReview的几点作用：
1、提高团队的~码规范Q培养良好的coding风格
旨在提高整个团队的编码规范程度，l一~码风格。通过每次的codereivewQ发现团队成员在实际开发中的一些细节问题，如不良的~码习惯、错误的调用方式{。通过多次的发现、解决问题，使大安L良好的编码习惯。review的内容一般包括：
1)、异常、日志的处理Q?br />
2)、常量的定义及用；
3)、字W串处理、BigDecimal.ZERO{；
4)、代码的装Q提高重用性；
5)、代码注释情况；
6)、javascript文g的抽取情况；
2、检查业务逻辑
寚w目实现的功能逻辑q行一ơreivewQ结合众人发散思维Q检查业务逻辑是否有盲Ҏ错误。通常需要参与review的成员能够静下心来深入地认真分析Q比较耗费旉?br />
3、分享和培训
每个目的工作安排相Ҏ说都是比较紧凑的Q所以每个团队成员在完成自己的开发Q务完Q没有太多的旉M解或熟悉其他成员的功能实现。但对于敏捷开发来_每个功能模块的开发者ƈ不是固定的，Ҏ目需要，很有可能由非原开发h员来完成增值功能或重构Q所以codereivew是一ơ不错的培训及分享机会，特别是对功能相对复杂的需求实现。可以让团队成员了解或熟悉基本的设计思想和相关的cd义，保在今后接手这一块工作时Q可以更快的上手或找到最到最合适的人去了解更深层的逻辑?/p>
关于reivew的方式：
1、集体review;
目成员一起参与codereiveQ成本比较大Q一般一个项目组l一ơ。比较适合开发经验分享，以及新功能的实现介绍Q利于其他成员了解、熟悉实现者的设计思\及代码结构，在后l项目接手这些新功能Ӟ更加从容?br />
2、TMl织若干开发经验丰富的一起review;
3、分l、交叉review;
h较好的灵zL，Ҏ情况随时扄关h员一起对已实现的代码q行reviewQ及时发现过E中问题q予以修正。比较适合分组\抱团开发，?-3Zؓ单位Q对具体的功能模块负责，一起分析、设计、编码，每位成员对于功能逻辑都比较逻辑Q对业务逻辑reivew有比较好的效果?/p>
实际工作中，Ҏ实际情况灉|选择合适的review方式Q不应拘于某UŞ式。reviewq程Q应有明的目的Q具有针Ҏ，而不是停留于表面Q避免逐渐成ؓ一U负担，于形式。另外，应对每次reviewl果Q整理出一份问题列表，q行分析和ȝQ避免相同问题的重复出现。同Ӟ也应按排相关人员跟进q解决问题。MQ通过codereivewq一手段Q尽可能的在提交试之前dC码中存在的一些实际问题，从项目经历中得到成长?/p>