敏捷开发-实践

一个项目团队包含了开发，测试，产品，交互设计等技术相关人员。

对于不同的人员需要在敏捷开发中找到自己的定位。

• 工作流程

角色\迭代时间(三周)	14	15	1	2	3	4	5	6	7	8	9	10	11	12	13
产品	需求详细设计	需求细评	回顾会、计划会	需求整理	需求整理，产品验收	上线	需求整理	需求整理	需求整理	需求整理	需求整理、用例评审	需求粗评	需求详细设计	需求详细设计	需求详细设计
交互设计		需求细评	回顾会、计划会		UI验收							需求粗评
开发	修改问题	需求细评	修改上个版本问题、回顾会、计划会	开发、修改上个版本问题	开发、修改上个版本问题	开发、修改上个版本问题	开发	开发	开发	开发	开发、 过用例，部分提测	开发 、需求粗评	开发	开发&修改问题	开发&修改问题、全部提测
测试	第二轮测试	第二轮测试、需求细评	第二轮测试、回顾会、计划会	第二轮测试	集成测试、发送验收邮件	集成测试、上线	用例编写	用例编写	用例编写	用例编写	用例编写、第一轮测试、 用例评审	第一轮测试 需求粗评	第一轮测试	第一轮测试	第一轮测试

• 需求粗评会议
  需求粗评会议不需要全员参与。相关的人员参与即可。
  需求粗评的标准：不用太详细，产品只需要解释需求价值，需求来源，达到的目的即可。
  开发人员评估需求的可行性，是否可达到产品的预期、可能的风险点和相关技术
  测试人员评估需求需要的大致时间。
  产品把其他人员提出的问题点进行汇总。

• 需求细评会议
  需求细评会议需要全员参与。这是一个很重要的环节，要把需求的疑问点全部解决，否则需求不能进入开发阶段。
  细评的标准：UI应该出图率达到80%，产品把粗评提出的点基本解决。
  开发人员根据需求和设计要评估出需求的规模（人天）。
  测试人员根据需求和设计要评估出需求的规模（人天）。

• 计划会
  整理出当前迭代的需要进入开发的需求，并进行人员分配。
  开发人员、测试人员按照自己领到的任务进行拆分，以天为单位。

• 用例评审会议
  测试写出用例后，需要进行用例评审。
  开发人员要过完用例之后才能提测。

• 回顾会
  总结上个迭代的问题的解决情况、当前迭代的存在的问题和解决方案、当前迭代做的好的点。

• 上线
  上线时间点一般不更改。

• 关于迭代周期
  迭代周期定位两周，对于某些大型的需求规模超过两周却又不好进行拆分的，可适当将迭代周期临时调整为三周。

• 关于早会（每日站会）
  参与当前迭代的人员参与（全员参与）。
  早会内容包含三个事：昨天的工作，今天的工作，风险点和需要协助的地方
  不讨论和这三项无关的事情，需要进行协调的，早会结束后，相关的人可继续讨论。

• 可能存在的问题

1. 需求产出不够
   加入技术需求，弥补需求不足的情况，技术需求也是产品成熟的一个重要的标志，刚开始技术需求不超过30%，产品建立稳定用户后，技术需求应不低于50%。技术需求不参与需求评审，直接评估时间即可。一般是大于0.5人天的才能作为技术需求。
2. 会议稍多
3. UI未在需求细评时及时出图
   需求粗评之后，UI要及时和产品沟通
4. 需求细评不仔细，导致开发阶段需要大量的沟通时间
5. 需求变更频繁，或未通知到相关人员
   进入开发阶段的需求，变更到导致增加到工作量大于了0.5人天的，上线应该适当的延期或去掉迭代中个别需求或功能点。