敏捷开发并不是组个小组吃个饭就好了

什么是敏捷

敏捷开发 Agile [ˈædʒaɪl]

简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

那现在就以一个微服务的项目来分享一下个我人眼中的敏捷开发。

我个人认识的敏捷

首先相关人员有产品负责人，团队Master，团队成员组成。

在项目启动之前，会由团队的产品负责人（Product owner）按照需求优先级来明确出一份 Product Backlog，为项目做出整体排期。

团队 Master 根据本次敏捷周期，负责将需求列表和计划梳理成对应的用户故事，细化一个个 Task 分配给团队成员，进行具体开发工作。

团队成员都会进行简会，根据情况更新自己的 Task 状态。

其次 scrum 有自己的生命周期。

当这一周期的 backlog 全部完成，团队会进行 Spring review meeting。并且进行 Sprint 回顾会议。最后CI，解散小组，再将得到的信息同步给领导。

在 scrum 中，每一位成员都对自己的项目有一个充分的了解，了解项目中主要的风险。在新的需求来的时候，个人之间的交流非常重要。这就是我经常在我们公司说，信息的同步。

任何一个团队中都有非常重要的管理者：他们帮助人们分工协作，他们保持团队中、团队与外部良好的人际关系。保证团队所有成员都能顺畅地彼此交流。因此，管理很重要。

团队成员中总有一些明星程序员，或者对于业务十分熟练的成员。他们对业务的处理，对于需求的分析都会非常到位，如果优秀的人能很好地合作，那么他们一定比普通团队做得更好。scrum 小组中，相对于其他团队来说，其实是更加需要一些这样的成员。

作为一名开发，浅谈一下如果我是组内成员，开发测试应该要做的事情。敏捷开发的产品会议是必须参与的，对于自己领域内的服务对应此次需求进行分析，Master 也会多次同步信息，此时开发必须对同步信息有所反馈。当成员信息拉平以后，开发者要做到测试驱动开发即TDD，XP编程。对于任何疑问的点，及时同步给组内成员。测试必须了解当前的业务，即理解用户故事、用户流，对于老业务的冲击也要进行梳理。

此次我们公司迎来一次尝试，开启了第一次敏捷。这个我从去年5月份进入这家公司就提出过，无奈少有同事和我同步这样的想法。我虽然这次没有进入小组，但是以一个备用成员来加深自己对敏捷的理解。

现在公司大部分成员对于敏捷有可能还不太理解，内部相关的管理制度也不完善。大家参与到敏捷里，而不是“管他三七二十一，先搞一个小组聚餐一顿，其余的事情以后再说”。大多数人都是抱着现在有这样的需求或者项目要上线，临时搞一个这样的小组冲刺一下就结束了。不过，现在有这样的机会，让大家学习到，认识到敏捷的好处。

对于敏捷，最重要的是思维上的转变（有道无术，术尚可求）。