关于敏捷开发的想法

关于敏捷开发的想法

跟随公司两个IT团队开发项目，前一个团队使用敏捷开发的方式进行，团队有专职的scrum master进行指导；后一个团队几乎没有使用敏捷开发，仅仅在jira记录了任务，尽管如此，也没有真正将任务管理用起来。在经历两种模式一段时间后，在此记录一下关于敏捷开发的一些想法。

工程师与产品经理的交流

首先，产品经理一定要大胆的提前跟工程师的交流时间。

产品经理习惯于设计一个更完整的模型与原型，列举充足的需求说明，然后开始跟工程师对需求。通常 ，需求评审又臭又长，而工程师只是理解一个大概，并不能真的在评审中对需求充分解读。后续会有很多频繁对沟通与产品修改。

而我认为，敏捷开发模式下，产品经理应该大胆提前交出产品设计，只要产品设计已经完备。尽管还有很多设计没有完成，但是无需害怕，提前把设计中可能的不足直接暴露给工程师，等同于提前跟工程师进行交流，从工程师的技术实现经验中收集需求设计不合理的部分并进行改善。这有利于从一开始就调整产品设计的方向，也有利于让工程师提前理解产品价值。不要忘记，工程师理解产品价值，会为产品实现带来正向价值。

避免一群人的交流

敏捷开发最该避免的，就是把负责不同模块的角色聚集到一起开会。

会议是许多人喜欢也厌烦的工作事项。开会可以分享到很多信息，但是很多信息不一定是最核心的信息，不一定能产生最关键的价值。把一群负责不同模块的人聚集到一起，虽然可以收集到不同的想法，但是这可能造成熵增，反而乱了设计目标。

正确的说法是，独立找各个模块负责人进行交流，这样的交流可以大大减少工程师与用户的时间。如果他们认为他们给的答案不够清晰，请相信，他们会内部讨论后给你一个补充的反馈。

如果不可避免的组织开会，请记得收敛讨论的内容，如果不小心发散了，请及时终止，并单独开启交流。

记住，聚集是为了分享，不是为了碰撞。

避免专注于条条框框

专注敏捷开发中的规则，是本末倒置。

敏捷开发的模式提供了很多约定俗成的“纪律”，包括daily scrum。但是，当你专注在执行这些“纪律”的时候，就舍本逐末了。

曾经团队在执行敏捷开发的时候，出现过对于task的DOD与AC理解不透彻的问题，团队成员不能理解两个概念的区别。作为对敏捷开发模式的讨论，如果团队有兴趣，可以进行讨论。但是不要忘记，我们的目标是完成task。所以，不管使用那个概念，只要达到真正的目标，就可以了。大胆的放弃其中一个概念可能是合适的做法。记住，没有正确的做法，只有合适的做法。

开放平等的团队氛围

以上的讨论都是基于团队氛围开放平等，团队的最终目标都是完成产品。事实上，使用敏捷开发模式，也需要基于这样的团队认知。如果大家都是各扫门前雪，那么请考虑使用瀑布开发，指令下达即可。敏捷开发需要的大量的交流，交流需要团队热情参与，而不是任务完成式的参与。否则交流过程会非常辛苦。

以上。