敏捷与开源水火不容吗？
极客时间编辑部
讲述：丁婵大小：2.30M时长：05:01
尽管敏捷与开源实践近年来受欢迎程度可谓齐头并进，但将二者融合同一对话中的场景倒是相对少见。毕竟在涉及这两个概念时，我们往往会发现这两种模式中存在的所谓矛盾观点。虽然存在核心差异，但敏捷并不一定是开源的敌人。近日，ZenHub 的联合创始人 Aaron Upright 在 SD Times 发文称，敏捷与开源是一对互补的好兄弟。以下是他的观点。
目前，我们在践行敏捷编程中采取的大部分方法，来自所谓“敏捷宣言”——这是一份以敏捷为核心原则的章程。最重要的是，敏捷宣言中强调了以下四项关键原则：
以流程与工具为基础的独立与交互；
以完备文档为基础的软件运作；
以合约协议为基础的客户协作；
以计划遵循为基础的变更响应。
而其中的前两条，似乎与大多数开源项目的结构方式有所冲突。
第一，敏捷编程强调协同定位与面对面交互的重要性。而开源则拥有自己明确的基础理念——任何身份、任何位置以及任何背景级别的参与者，都能够以有意义的方式为项目做出贡献。
第二，敏捷更强调有效代码而非完备的文档。但开源项目需要文档，以帮助提供与项目相关的历史记录，同时引导潜在贡献者了解自己能够参与的位置。
尽管存在这些差异，但敏捷编程并不一定就要站在开源开发的对立面。事实上，将这些敏捷原则引入开源开发能够带来诸多收益。
建立流程、理解流程
考虑到开源项目的分布式特性，维护秩序与设定工作重心无疑是最令开源维护者们头痛的任务之一。对于合作者而言，了解工作内容并理解项目贡献中需要遵循的准则，也是一大难题。通过敏捷与开源相结合的方式，我们将能够围绕工作的优先处理需求以及进度跟踪情况建立轻量化流程，从而为参与项目的每一位利益相关方提供最佳选项。
将简单的敏捷框架整合至项目当中，能够帮助贡献者们更好地理解自己的成果需要经历怎样的流程才能成为项目的一部分。再配合一套贡献者指南，这种简单的框架能够帮助潜在参与者之间快速建立信任，并了解如何对项目产生最大的影响。
为利益相关方提供可见性
对于有意为项目做出贡献的潜在合作者而言，最让人难受的就是弄不清项目是否活跃、是否还值得他们投入时间做出贡献。将敏捷元素整合至项目当中，能够帮助潜在协作者快速获取关于项目动态的信息、目前面临的首要问题以及哪些问题在项目当中具有更高的优先级。以此为基础，开发者将在更高的透明度之下贡献自己的力量。
测量速度并提高可预测性
虽然开源项目的分布式特性，确实导致其无法像其它商业项目那样快速变动，但我们仍有办法在推动开源项目的过程当中不断提高速度并改善其可预测性。也许我们很难在开源项目当中组织冲刺或者快速迭代等活动，不过只要能够正确引入一些其他的敏捷度量标准，我们完全有可能引导项目逐步提速，并呈现出明确的可预测性。
将敏捷概念引入开源项目
当下，大多数主要的开源项目都托管在 GitHub 之上，GitHub 在开源领域受到热烈欢迎，并已经成为大多数团队及项目不可或缺的分布式协作与沟通基础。除了围绕问题与 pull 请求提供的相关功能，GitHub 当中还内置（通过生态系统提供）多项其它功能，可帮助团队将敏捷元素（例如任务板、报告等）整合至自己的开源项目当中。
比如 GitHub Projects 是 GitHub 中的一项原生功能，为各团队提供一套基于 GitHub 问题的轻量化 Kanban。GitHub Project 板允许定制，能够为项目建立一套简单的敏捷流程，并向社区传达在批准与合并之前各项提交内容需要经历的不同阶段。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论