产品思维学习(五)--产品敏捷开发和项目管理

一般产品人员进行过需求采集，分析，筛选后就会进行产品的设计。
在产品设计的过程中会产生PRD（Product Requirement Document 产品需求文档 ）,如果是新产品或者在大公司一般还会有BRD （ Business Requirement Document 商业需求文档）和MRD （Market Requirement Document市场需求文档 ）。
当写好PRD之后就会画出简单的线框图，在画好线框图后，为了后面更好的评估开发难度和开发时间，这时产品经理就会和开发经理和开发人员进行一次简单的会议，会议主要是介绍产品的功能点和交互。
这时开发人员进行给出开发难度，如果功能点太难以实现或者比较复杂且优先级不那么高的可能就会先实现主要功能（主要为了降低开发成本，看上线后用户的反应再进行深度开发同时也是为了把试错成本降低）。
没有问题后，产品就会让UI人员给出高保真原型图，同时开发人员进行开发。主要步骤如：

1. 确定需求后，产品人员写PRD和线框图。
2. 产品人员和开发人员进行讨论，评估开发难度和开发时间。（如果开发迭代时间固定，主要是评估难度）
3. UI根据线框图和PRD设计出高保真原型图，同时开发人员进行开发，项目管理开始。
4. 开发，测试，修改bug（开发中可能会出现需求更改的情况）

5. 产品经理（项目经理）进项验收，没有问题上线。
   
   以前的开发大部分都是瀑布式开发，现在一把都采用敏捷开发。项目经理这个职位一般也是只有在稍大的公司会有，在创业的小公司一般有产品经理或者开发经理来担任。我们公司是由开发经理来担任开发进度管理，最后由产品经理验收。
   一般敏捷开发流程（每个公司的迭代周期不同，但大致流程相似。下面是两个星期一个迭代）如下：
   

6. 如果我们需要从第1周周一开始开发新的迭代（假定第5个迭代）。那么就要在上周的周三，产品人员和开发人员进行PRD评审，如有需要修改的地方进行修改。（第四个迭代开发持续中，UI按照优先级开始绘制已经确定需求的高保真图）

7. 在上周的周五产品进行修改后，再次和开发人员进行评审，确定没有需求没有大的变动。（UI设计持续，启动新的开发迭代（第5个迭代），进行上次迭代(第4个迭代)总结会议和新迭代开启会议），这时项目也会在进行拆分，比如按照epic-story-sprint-task的方式进行拆分。然后把这个迭代的任务拆分成各个小的task，然后进行人员分配。task的时间颗粒度一般不超过两天，分的太粗容易造成delay。task维护一般使用看板的形式，我们使用过的有Jira，kanbanflow，icafe等。（可以根据喜好使用，里面有相应的曲线图和燃尽图）
8. 第一周周一上班，UI同学会给出一部分设计的好高保真图。这时服务端同学会根据安排好的优先级给出相应功能的接口文档。移动端的同学进行页面编码和设计。同时移动端同学会根据给出的接口文档先造一批假数据已备本地测试（如果有相应的接口测试工具会更好，我们是用的自己开发的接口测试沙箱，可以根据绑定的真假接口进行真假数据的测试）。同时，每天下班前都要有站会。站会主要说自己的三个问题：1.今天做了什么2.有什么问题3.明天做什么
9. 开发持续进行，到第一周周四时，会先发个测试包，让测试人员进行测试。当然开发过程中也在不断测试。出现问题就进行修复,bug修复不再安排时间，不会在看板上建新的task来修复bug,开发任务继续。
10. 到第二周的周三，要确保开发任务基本完成。然后发个测试包，进行测试。有bug进行修复。同时产品经理进行查看。同时和产品进行下的迭代（第6个迭代）的PRD评审。

11. 到第二周的周五，再发个测试包，进行测试。有bug进行修复。产品经理验收。（没有问题，一般会在夜里凌晨1-2点上线。)上线后可能要安排人员进行值守，看有没有问题。同时周五还要和产品进行确认最终新的开发。同时开总结会议和新迭代启动会议，这两个会议也可能放在周一开。
    至此，一个迭代开发周期完成。
    注意：

    • 在开发的过程中，项目经理每天要通过看板或者询问开发人员的进度是不是符合原来的预订计划，如果出现delay现象，可能就要通过加班来把进度提上来。
    • 测试人员也要参与需求的评审，方便后面业务测试。
    • 开发人员要对自己写的代码负责人，写好后要进行代码review和自测，不能把没有测试的代码进行提交。