敏捷项目转型实践

1、现有项目问题

（1）需求经常变化缺少清晰的需求记录

（2）工作量不好评估，任务安排分配分配不均

（3）测试往往最后才能进入测试环节

（4）项目时间段长，里程碑缺失

2、敏捷开发的核心优势

（1）将较长的开发过程阶段化

（2）进行快速迭代、快速交付优化

3、敏捷管理流程介绍

 注意：

1、产品看板需要由相关方讨论后才能确定产品需求文档。

2、在一个迭代中所有范围不改变，可根据情况实施。

4、敏捷开发遇到的问题及改进

（1）产品待办清单由1个人指定，未经过讨论便开始讲解

原因：产品负责人可能缺少经验，导致不重要的或者错误的需求经常出现在迭代中，影响迭代进度。

后果：浪费团队成员的时间，增加返工风险。

建议：产品清单需要经过产品总监、相关方及更多上级讨论后形成。

（2）项目经过多次需求变更后，团队新人仅通过迭代需求无法了解项目需求

原因：项目迭代使用的pingcode工具，新增的需求在新的迭代里，多次后无法有效的获取最新需求。

后果：无法查看最新的需求文档，导致无法快速进入开发

建议：通过word文档管理产品文档基线。

（3）有很多非产品需求，例如项目部署、服务器安装、新技术研究、权限配置等未在迭代计划列表中

原因：产品经理对实施细节不清楚，记录不了部署、数据迁移、文档等零碎事情

后果：遗漏部分工作无人负责

建议：所有事项均记录在迭代计划中，属于某一个故事的放在任务下，属于公共部分的要尽早规划。

（4）测试人员与开发人员不能并行，前后端开发缺少顺序，导致迭代中测试时间较短

原因：前端开发人员选择一个需求开发顺序，后端选择另外一个顺序，根据自身便捷度选择

后果：测试迟迟无法进入测试环节，可能影响迭代按时完成

建议：迭代计划会上，对用户故事列出优先级。

（5）项目发布后，正式环境的代码与master分支的代码不一致

原因：内网环境，无法利用自动化部署一键部署

后果：test分支不断更新后，无法获得线上的分支代码进行修复 

建议：增加自动化流程，通过master分支实现自动化打包，每次部署下载master分支的代码

（6）团队成员选择工作项后，未及时跟进工作量是否平衡

原因：老员工可能选择较少的工作内容，导致新员工工作量大

后果：可能个别员工特别忙，其他员工不忙

建议：敏捷教练需要对项目的工作量进行平衡

5、敏捷中需求的类型

（1）史诗：基于产品的长期战略方向而被提出，颗粒度级别最大。

从产品维度中，可以认为是某个独立的子系统；（具体实施过程中可以命名为“XX系统V1.0”）

从项目维度中，可以认为是项目解决方案中某个业务系统板块。

（2）特性：作为某个史诗的子需求（比史诗更具象）和若干个用户故事的集合，承上启下，需要多轮迭代才能完成交付；

可以简单认为是在某个子系统中某些功能集合；

比如用户管理、角色管理等；可以对应为一个一级菜单。

（3）用户故事：从用户的角度来描述用户渴望被满足的需求，颗粒度级别最小，且能在一个迭代中开发完成。

用户故事，是最好理解，是一个能够独立讲解，独立运作的一个故事线路，一个典型的用户故事是支持可测试的；

（4）任务：需求是用户维度，任务是开发维度。

需求是一个完整的用户故事，具有独立性的功能，可测试可交付。

任务是在需求下拆分的具体任务，比如一个需求分成前台开发任务和后台开发任务，两个任务共同完成需求才可交付。需求有父子需求多层级展示，需求分类树形展示，自定义工作流状态，流转权限控制，需求统计等。而任务没有这些功能。

6、项目管理遇到的问题

（1）敏捷教练无法对团队打绩效，缺少项目职权

（2）敏捷教练无法对奖金进行分配

（3）项目过程文档缺失