Scrum的再次思考-让敏捷的实施也敏捷起来

最近的项目慢慢步入正轨，终于有时间梳理一下一年来关于scrum的思考。

“敏捷战略”作为高层决策的产物，我们需要在项目中贯彻执行。于是项目中每个人都在谈论敏捷。产品，开发，UI，经理，对于每个人似乎没有敏捷项目无法进行下去。对于我来说，敏捷从不陌生，有着五年多敏捷开发经验，使我对于敏捷有着特殊的感情。从带队进行敏捷开发的几个项目里，我充分体会到敏捷带来的好处。同时也感受到了敏捷实施过程中的一些痛苦。然而，这次的项目，由于刚刚启动时情况特殊复杂，敏捷的实施似乎并不合时宜。当时的情况，要求我们必须快速的产出原型，甚至需要快速做出一些复杂的功能，从别的组那里“抢夺”项目。同时，产品同学是传统行业的老手，但是对于敏捷并不熟悉。敏捷开发的推进非常困难。我们必须做出取舍。

让敏捷实施也敏捷起来

在逐步让产品同学尽快熟悉敏捷的同时，为了应对快速开发以及管理层对于敏捷的要求，我们暂时改进了我们的敏捷流程，我们没有一步到位的标标准准的实施敏捷，而是让我们的敏捷开发的实施先敏捷起来。

让敏捷实施也敏捷起来，就需要我们不能步子迈的太大，不要严格按照敏捷的思想以及流程步骤来做，而是我们慢慢前进，一步步迭代敏捷的流程，最终达到完全敏捷。

我们的实践

针对敏捷会议，我们逐步增多，先是站会，逐步固定时间形式，然后再加入计划会议，审查会议。一段时间后，经过一段时间的快速开发，项目有了一定进展后，我们适时的插入回顾会议，总结解决这段时间的遇到的项目中的问题，最终我们加入了backlog refinement会议。总体来讲，会议由少到多，由无规律到有规律，由无章程到逐渐团队自发的形成章程。

同时，针对每个会议也有不同的迭代。比如每日站会。从刚开始的时间不固定到后面每天定点定时，从刚开始的无序与杂乱到现在的有序高效，我们一步步做了很多的自我改进与迭代。

针对产品需求的迭代。刚开始由于项目压力大，要求速度快，我们的用户故事并没有非常细致的acceptance criteria。随着项目逐步的稳定后，我们加入了更加详尽细致的acceptance criteria，并最终文档化。

针对每个迭代的产物也在不断的精心迭代。从原先的没有DoD(Definition of Done)，到DoD的逐步精细化，从粗略的质量控制，到细致的质量策略及实施，从代码的快速合入到细致的审查讨论，我们都慢慢改进，逐渐迭代。

后续

虽然项目已经稳定，敏捷也已经步入正轨，但是目前还是有很多问题需要解决。未来，在保持继续敏捷交付产品的同时，我们还需要在敏捷的实施上不断的总结改进，以期到达更好的结果。

迭代永无止境。