尽管敏捷与开源实践近年来受欢迎程度可谓齐头并进,但将二者融合同一对话中的场景倒是相对少见。毕竟在涉及这两个概念时,我们往往会发现这两种模式中存在的所谓矛盾观点。虽然存在核心差异,但敏捷并不一定是开源的敌人——事实上,我倒认为这是一对好兄弟。
在开源的基础上对敏捷开发的核心概念进行分层,不仅能够提高项目整体的透明度与协作水平,同时也有益于参与度,进而为参与进来的每个人提供项目价值。
敏捷与开源真的水火不容吗?
目前,我们在践行敏捷编程中采取的大部分方法,来自所谓“敏捷宣言”——这是一份以敏捷为核心原则的章程。最重要的是,敏捷宣言中强调了以下四项关键原则:
以流程与工具为基础的独立与交互。
以完备文档为基础的软件运作。
以合约协议为基础的客户协作。
以计划遵循为基础的变更响应。
而其中的前两条,似乎与大多数开源项目的结构方式有所冲突。
第一,敏捷编程强调协同定位与面对面交互的重要性;而开源则拥有自己明确的基础理念——任何身份、任何位置以及任何背景级别的参与者,都能够以有意义的方式为项目做出贡献。
第二,敏捷更强调有效代码而非完备的文档;但开源项目需要文档,以帮助提供与项目相关的历史记录,同时引导潜在贡献者了解自己能够参与的位置。
尽管存在这些差异,但敏捷编程并不一定就要站在开源开发的对立面。事实上,将这些敏捷原则引入开源开发能够带来诸多收益。
建立流程、理解流程
考虑到开源项目的分布式特性,维护秩序与设定工作重心无疑是最令开源维护者们头痛的任务之一。对于合作者而言,了解工作内容并理解项目贡献中需要遵循的准则,也是一大难题。通过敏捷与开源相结合的方式,我们将能够围绕工作的优先处理需求以及进度跟踪情况建立轻量化流程,从而为参与项目的每一位利益相关方提供最佳选项。
将简单的敏捷框架(例如Scrum或者Kanban)整合至项目当中,能够帮助贡献者们更好地理解自己的成果需要经历怎样的流程才能成为项目的一部分。再配合一套贡献者指南,这种简单的框架能够帮助潜在参与者之间快速建立信任,并了解如何对项目产生最大的影响。
为利益相关方提供可见性
对于有意为项目做出贡献的潜在合作者而言,最让人难受的就是弄不清项目是否活跃、是否还值得他们投入时间做出贡献。将敏捷元素整合至项目当中,能够帮助潜在协作者快速获取关于项目动态的信息、目前面临的首要问题以及哪些问题在项目当中具有更高的优先级。以此为基础,大家将在更高的透明度之下贡献自己的力量。
举例来说,敏捷元素(例如轻量化任务板)能够针对维护者工作流程中的特定问题或者 pull 请求提供良好的可见性。贡献者不用再苦等 pull 请求提交或者合并期间的被动反馈,而是在任务板当中实时跟踪自己的问题,并了解决策者如何优先考虑已经提交至项目的其它合并请求。
测量速度并提高可预测性
虽然开源项目的分布式特性,确实导致其无法像其它商业项目那样快速变动,但我们仍有办法在推动开源项目的过程当中不断提高速度并改善其可预测性。也许我们很难在开源项目当中组织冲刺或者快速迭代等活动,不过只要能够正确引入一些其他的敏捷度量标准,我们完全有可能引导项目逐步提速,并呈现出明确的可预测性。
以提前期时间与周期时间为例,这两项指标能够帮助团队衡量从首次发生(或者首次处理)问题或故障单,到完成处理所需要的时间。此外,提前期与周期时间也能够帮助维护人员发现异常或陈旧问题。如果某一问题的开放时间超过平均提前期或者周期时间,则可能表示该问题已不再重要,或者需要社区提供额外支持方可解决。
将敏捷概念引入开源项目
当下,大多数主要的开源项目都托管在GitHub之上。如果大家希望为某项目做出贡献,那么首先需要注册 GitHub 账户。除了拥有近 3800 万开发人员的繁荣社区之外,GitHub 在开源领域也受到热烈欢迎,并已经成为大多数团队及项目不可或缺的分布式协作与沟通基础。除了围绕问题与 pull 请求提供的相关功能,GitHub 当中还内置(通过生态系统提供)多项其它功能,可帮助团队将敏捷元素(例如任务板、报告等)整合至自己的开源项目当中。
GitHub Projects 是 GitHub 中的一项原生功能,为各团队提供一套基于 GitHub 问题的轻量化 Kanban。GitHub Project 板允许定制,能够为项目建立一套简单的敏捷流程,并向社区传达在批准与合并之前各项提交内容需要经历的不同阶段。
由于 GitHub Projects 内置于 GitHub 当中,因此大多数轻量级开源项目倾向于直接使用,从而为利益相关者以及更为广泛的社区提供与项目相关的信息更新。另外,GitHub Projects 的创建方式也非常简单,可以说是将敏捷融入 GitHub 的理想起点。
除了 GitHub Projects 之外,还有一个极为强大的第三方工具市场,能够在问题与 pull 请求基础之上进一步增强 GitHub 的项目管理功能。如此一来,各团队能够将问题组织成 Epics、分配 Estimates、实现跟踪分析等等。与 GitHub 本体一样,其中部分工具同样免费向开源团队开放。由于这些工具不受成本或者学习曲线的限制,因此能够推动诸多极具价值的社区项目,带来更好、更快的结果,并通过强大的框架将敏捷开发与开源实践紧密结合在一起。
原文链接:
Agile and open source can complement each other
评论