XX项目实践敏捷的总结

XX项目实践敏捷的总结


接手XX项目后，发现此项目有以下风险：
1、需求不确定（项目开始后四周才完成需求）且充满变化（和生命树其他子项目的接口）
2、人员不确定（前期只有两位开发加入，后期三名）且有变化（中期萝卜调去POSAPP项目组）
3、项目外部联调不确定（生命树时间不确定）

在对敏捷的核心原则了解后，我们根据以下原则来安排工作：
主张简单：由于需求不明确，有一点，我们就设计一点。
拥抱变化：XX项目的每一个迭代都允许需求变更，给需求方空间调整业务。
递增的变化：刚开始只能定一些简单的接口和规范，在每一个迭代都会有调整

同时，还应用了以下方式进行实践：
1、固定周期迭代
   实践结果：每两周一个迭代推进，每个迭代都有自己的目标，这块执行得较好。
2、单元测试先行
   实践结果：前期测试用例未能先完后，在第二个迭代开始调整为先写测试用例，这和开发人员的习惯有关，也和项目经理的经验和敏捷知识不够有关。
3、每日构建报告
   实践结果：使用了构建平台，每天能够看到用例的测试结果，但由于测试用例的覆盖面不够高，实际的帮忙不太大。原来对每日构建的理解更多是每天能够编译出一份所有人的可执行的代码，并能看到错误报告，实际操作中，都是分开检查的，提交上来的代码不能集成。如果此部份能够把集成包含在内，会减少后面的压力。

以下部份是传统项目管理方法：
1、项目周会（每周一）
2、项目周报（每周五）
3、工具 WIKI & REDMINE

项目过程值得总结的优点：
1、选择了合适的开发模式
2、项目组成员范围较大，SA前期参与有助于服务器的申请和部署，QA全程参与，有助于项目质量提升。
3、第一个版本发布提前减少了整个项目组和生命树之间的风险
4、技术系统设计的灵活性减少了因需求不明确和变更引起的风险。
5、实施了内测环节，让上线后的小调整变少。
6、发布计划的两步走方式减少了受其他项目发布的影响。
7、前期利用了用例和活动图建模，让需求过程更清晰更易懂。

项目过程值得总结的不足：
1、敏捷实践不够，特别是测试用例环节。
2、缺少开发集成时间，这种新工程特别需要这一环节，因为新工程未经过线上生产环境。
3、项目周会老是忘叫交互的同学，非常抱歉。

对敏捷的一些看法：
敏捷在以下场景有相当的优势
1、一个新的工程，一切从头开始或足够简单的环境下。如果在主站实施，就和敏捷这两个字无关了。
2、需求不定或短期内不断变化。
3、客户要求尽早看到成果。
4、项目不限时间，没有拍终点时间。
5、适合产品开发，不断改进的过程，而非一次性的项目。

不适合的场景：
1、完整且不太会变更的业务包，实施敏捷毫无意义
2、周期太长的项目。因为使用迭代会让整个项目组的时间较紧张，如果项目周期太长，整个项目组会非常疲劳。
3、时间要求紧，没时间写测试用例。
4、对系统设计要求高或纯技术研究的系统。这样的系统一般要求一次设计到位，零散补丁式的设计不可能做到这点。

    敏捷有它适应的场景和优势，但绝不是解决所有研发过程问题的法宝。我们应该领悟它的神，它的快速简单和应对变化的能力。