很多软件开发团队都在使用Scrum、极限编程（XP）、看板等敏捷方法管理项目流程，持续迭代并更快、更高效地为客户持续交付可用的产品。除了团队，国内外很多个人独立开发者也在尝试将敏捷应用到自己的开发工作流程中，但大多数的结果都是收效甚微，这是为什么呢？个人践行敏捷是否可行？ 

敏捷开发需要坚实的团队基础，以及团队文化的保障，方可有效地落地执行。 

什么是敏捷

敏捷是一种以用户需求为核心、采用不断迭代的方式进行的软件开发模式。它依靠自组织的跨职能小团队，在短周期内做出部分成果，通过快速、频繁的迭代，迅速地获取反馈，进而不断地完善产品，给用户带来更大的价值。践行敏捷的方式有很多，主要包括Scrum、XP、Kanban、精益生产、规模化敏捷等方法论。

敏捷的工作方式是将整个团队聚集在一起，理想情况下，敏捷团队的成员不超过10人。通过践行一系列简单的实践和足够的反馈，使团队能够感知目前的状态，并根据实际情况对实践进行调整。 

团队是敏捷的核心 

敏捷是一种团队驱动方法，团队可以简单的地定义为“为实现某一特定目标，包括两个或两个以上的人的相互协作的群体”。敏捷的核心是构建一个自组织的团队，团队的能力在于协作，即两个人或更多人相互交流与合作，以共同地产生一个结果。例如当两个程序员在结对编程时，他们在协作；每人持续集成当日的工作时，他们在协作；当团队开计划、站立、评审、回顾等会议时，他们在协作。协作的结果可以是有形的可交付物、决策或信息共享。 

而对于个人独立开发者，协作、互动、沟通都是无从谈起的： 

自己无法实践结对编程；

自己开站立会议是否很孤单；

自己玩估算扑克牌会不会很无聊；

评审演示没有观众，自然也就没有反馈；

…… 

这里有一个常见误区：独立开发者通常有一定的跨职能工作能力，于是想一人“饰演”多个不同角色，从需求计划整理到任务分解估时，从迭代开发到测试，再到发布、回顾总结。这是不是也在践行敏捷开发呢？ 

当然不是。敏捷开发流程中任一环节都强调团队集体参与，并非由某个人独裁发号施令。例如项目计划制定、任务认领、工时评估，这些都不是某一个人的职责，而是需要团队成员来共同参与完成。然而，单个人的开发流程，很容易按部就班地走上了瀑布式开发模式（需求->设计->开发->测试->发布）。

[多重人格综合症，并确保精神上的新人是一个专业的“团队成员”]

敏捷团队中并不会要求每个人都成为全栈通才，在如今技术快速更新迭代的大环境下，期望一个人精通团队的所有技能是不现实的。取而代之的是重视具备跨职能的团队成员，这有助于管理各个工作岗位的平衡。例如，有时团队需要更多的测试人员，如果有一两个团队成员能转做测试工作，就能极大地提供帮助。 

敏捷是关于人，以及他们之间的协作交互，让每个人的能力得以充分的发挥并提升，从而创造优秀的产品。创造优秀产品的是人，而不是流程。所以，独立开发者即便一个人能跨职能走完整个开发流程，这跟敏捷强调的自组织团队中，成员之间高效地协作、交互以达到目标，完全不是一回事哦～

文化是敏捷的保障

很多个人独立开发者尝试引入敏捷的普遍思路，是从各种敏捷方法论中挑选一些个人能用，且有帮助的实践方法来用。这样确实能从中受益，但这真的是在践行敏捷么？

敏捷不只是一套方法论，敏捷也是一种思维模式。很多个人甚至团队尝试敏捷的过程中一个常见问题，是只取其方法实践，而未学其思维模式。这里说的思维模式，通俗讲就是指培养团队能够形成共识的文化，拥有一致的价值观和原则，塑造一个持续学习、自由、积极的团队氛围。以促使团队达到一种能够持续快速地交付有价值有质量的产品或服务的状态。

文化高于实践，成员能否融入团队文化，将会影响团队具体实践的高效程度。良好的团队文化，有利于促进团队内部的信息共享，从而产生更正确的决策。我们有时感觉自己已经引入敏捷了，但实则依旧保持着瀑布式思维，走的瀑布式开发流程，只是单纯学习并采用了一些好的敏捷实践，以至于最终达到的效果很有限。

这里引用《敏捷宣言》作者之一吉姆·海史密斯在他著作的《敏捷项目管理》中的一段总结： 

没有具体的实践，原则是贫瘠的；但是如果缺乏原则，实践则没有生命、没有个性、没有勇气。伟大的产品出自伟大的团队，而伟大的团队有原则、有个性、有勇气、有坚持、有胆量。

写在最后 

我们很难将整个敏捷的思维与方法流程应用到个人的独立开发工作中，因为敏捷需要坚实的团队基础，以及团队文化的保障，方可有效地落地执行。当然，我们并不否认个人可以尝试从敏捷中探索一些可借鉴学习的实践，并从中受益。

您如何看待这个问题呢，或者您是否有过将敏捷应用到个人的开发、工作、学习等方面的成功或失败的经验，欢迎在评论区一起分享交流。

参考资料：

《敏捷项目管理第2版》吉姆·海史密斯

敏捷开发网：敏捷开发