浅谈开源社区之建设与项目管理

Home » 心得体会 » 浅谈开源社区之建设与项目管理
心得体会 没有评论

摘要:

笔者作为玟茵开源社区联合创始人,在现代开源社区建设及项目管理的方面有一定心得体会,希望与大家进行分享。

(重要提示:本文仅适用于纯兴趣爱好性质的开源社区,商业性质组织请建立自己的规章制度。)

首先介绍一下我们玟茵开源社区的概况。首先本社区主要参与者和服务用户为女生,同时开发技术上并不十分成熟,也易于进行一些情绪化动作。当然成员基本没有太多空闲时间,也许是比较懒。我们并没有把这个当做一项事业来做,单纯为了爱好,并不考虑任何利益。

第一部分:开源社区的建设

1.闲聊灌水问题

开源社区并不是非常严肃的事情,一些志同道合的开源软件爱好者聚集在一起,做非盈利性质软硬件开发项目而已。所以我并不赞成一些开源社区管理者所做的,严格控制灌水的做法。大家闲聊是一种自由。当然闲聊不是无限制的,开源社区最好建立独立的灌水QQ群或者是IRC频道,在不影响正常开发交流进度的情况下,可以适当交流一些娱乐话题(huang duan zi),来提升气氛。不过应该注意的是某些限制性话题请勿接触,社区不应该是一个谈论政治性话题的地方。社区的气氛有赖于大家一起维护成长,理想的状态是不沉闷也不过分活跃。

社区不应该是一个只谈论枯燥的技术的地方,最好能建设成为一个开源爱好者共同的家园。也可以适当接收并不懂开源技术的用户加入。在一些开发的事情上,外行人往往比内行人更看得广阔,同时开源社区的推广也少不了大众的参与。作为一个负责人,我想对大家说,不仅仅是写代码重要,例如美工设计,用户体验等方面更加需要重视。尤其是对于规模较大的项目。

2.社区成员之间的沟通

作为一个开源社区负责人或者是管理者,一定要与所有新加入的社区成员进行一对一充分沟通和交流,了解他们的实际能力和自身的兴趣爱好。实际开发中,可以仿行敏捷项目管理中的站立会议方式,不一定是每天开会,但需要到特定时间期限进行整个社区的充分沟通讨论,以确定下一步的工作努力方向和进度。

敏捷开发它只写有必要的文档,或尽量少写文档,敏捷开发注重的是人与人之间,面对面的交流,所以它强调以人为核心。在开源社区中也是如此,不需要堆砌wiki和邮件列表,人与人的沟通远远比这些文档要有用得多。

3.性别问题

开源社区不应该存在对女性爱好者的性别歧视问题。这种歧视常常表现在,对程序媛的成果过分吹捧,或者是把程序媛当作“镇社之宝”什么的。言下之意就是,女性的实际能力都有问题,凭脸还是卖萌在这里混的一样。这会很让程序媛们寒心的。(本人也是程序媛一枚╮(﹀_﹀)╭)我的想法是,社区内应对男性和女性成员一视同仁,最起码不应该有太多差别,工作量做到基本平衡(不过根据情况也是可以进行适当照顾滴~)

4.喷子的处置

喷子,键盘侠,一种有天朝特色的东西。其特点是不管你在做什么他总能找出吐槽点进行吐槽→_→,还用各种不堪入目的语言非要逼你和他打口水战。对于混入社区内部的喷子应该采取果断清除出去的做法,懒得和他们费口水,毕竟这是我们的地盘,容不得你在这里撒野。如果实在社区外的公众交流平台上,成员应该坚决果断地维护社区的名誉和利益,坚决和这些人做斗争。

二.开源社区的项目管理

1.基于过程的全流程敏捷项目管理综述

对于当下的开源社区,国外通行的方式个人感觉并不适合,造成了大量拖延症患者存在,影响开发进度以及项目迭代。大多数开源社区的项目管理往往是基于issue(事务)形式,为每一个事务打上“未完成”,“已开始”,“进行中”,“已完成”,“已终结” 类似的标签,对于软件开发中的缺陷管理也是采用类似的方式。这种方法看似简洁,实际上存在一定隐患。只注重结果而不注重过程的管理方式,往往造成代码质量逐渐下降,拖延症问题日益严重。一定需要项目全流程敏捷开发管理,从只注重结果到过程与结果并重。由于开源社区往往所有者处在不同的时空之下,有必要使用在线的项目全流程管理工具。现在常用的项目全流程管理工具有Redmine,Jira,ZentaoPMS之类。本文中后续部分将基于ZentaoPMS(禅道项目管理软件)进行简要叙述。采用本套软件,主要是因为其搭建方便,可直接利用常见的PHP+MySQL网站环境进行搭建(Redmine和Jira分别需要Ruby和Java ME运行时)功能也比较全面,基本上可以做到开箱即用。

我们要理解,敏捷开发不是一门技术,它是一种开发方法,也就是一种软件开发的流程,它会指导我们用规定的环节去一步一步完成项目的开发;而这种开发方式的主要驱动核心是人;它采用的是迭代式开发,这里采用的是Scrum方式。

什么是Scrum?

Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程的名字取名为Scrum,我想大家一定能想象出一个开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,每个成员一定会感到非常兴奋的。

2.项目迭代

迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

在社区的开发中,我们不可能做到商业化管理的严格细致程度,但Scrum的一些手段还是值得采用的。在此着重叙述一下社区开发中易于被忽略的部分:

(1)需求提交与整理

开源社区的软件作品,大多并无商业利益的关联。同时大多数开源项目参与度也并非很高,提出的需求大部分来自社区成员内部和爱好者的日常使用。从这点看来,我们既是开发成员又是客户,虽然是自己给自己提需求,这一步也是绝对不能省略的,在脑海中时常会显示灵光一现的想法,最好能及时做记录,分类后提交到项目管理系统的需求管理处,方便日后开发时整理。提需求时可以参考如下格式:

{我是xx样的用户/开发者};

{需要加入yy的功能};


{这项功能可以起到zz的效果}。

………

如上图,第一个画面为社区成员提出的需求,第二个画面为爱好者对玟茵系统提出的一些意见,这里也暂时整理为需求。不过融入产品迭代中。这类型需求还需要进行细分。

(2)关于开发中的Sprint方法

何为Sprint?

Sprint是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(笔者注:开源社区中这个周期可以更短一些,以能完成一项有意义的任务为准),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为Sprint。

Sprint简单的说就是版本更新。考虑到社区的实际情况,例如我们现在做的是GNU/Linux distribution这种比较大型的项目,可以把某系统组件的更新或者是某开发模块也算作一次Sprint。这里会用到上文(1)中的需求列表,根据优先级排列,交给所有参与此项目的Team成员进行一次Sprint计划会议,研究讨论,根据优先级选出一个Story作为本次Sprint的目标。还要共同确定一个迭代周期,一般不要太长时间,以刚好能做完为准。

接下来,要做的就是Story的分解,即需求细分。需求细分建议由社区的总负责人来完成,负责人必须高度熟悉这个项目的工作流程,善于领导成员完成自己应有的目标。创建这个Sprint Backlog后,到此,每个参与成员可以根据需求细分的结果来确定自己的task(每个任务在短时间内完成)这里要重点注意:每个成员接受任务应根据自己实际能力。创建的任务应该在选择好期限内完成,尽量不要拖延,否则会影响整个项目的开发。

上图我们看到了,存在一些长期性质任务,也要合理设置执行期限,尽快完成,防止过度拖延出现意料之外的后果,

(3)开发的总结过程

Scrum中的每日站立会议(Daily Scrum Meeting),在社区的实际情况中,可以做一定简化。每天只更新进度表和燃尽图,定期进行开发成员之间的交流。Daily-Build可以根据社区实际情况确定是否执行。

当一个阶段性目标Story完成,也就是一个Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),每一个参与开发的成员和社区负责人都要参加,需求的提出者则必须参加。每一个成员都要演示一下自己本阶段完成的产品,互相提出意见,做记录融入到下一轮Sprint中(这个会议非常重要,一定不能取消)。

每个较大模块开发完成后,我们要进行Sprint Retrospective Meeting(回顾会议),也称为总结会议,大家在一起总结并讨论改进的地方,放入下一轮Sprint的产品需求中。

(4)巧用任务管理列表和燃尽图

在禅道系统中,可以清晰显示出每位成员的工作进度和任务完成情况。如果有某位成员的工作进度图常处于停滞状态,社区负责人或者是其他伙伴们应该和这位成员做主动和及时地沟通,了解一下具体是什么情况,适当为这位成员的工作做出合理调整。

3.测试及缺陷管理

开源社区的开发当中,一般并不重视测试环节。大部分开源软件采取被动测试方式,即不稳定版本交给用户去测试,然后根据用户反馈粗略确定当下产品质量。这种做法实际上也是不合理的,软件开发者的工作为什么要推给用户完成?应做到开发与测试并重。

(1)Bug的全流程跟踪

每当用户或开发者反馈回一个Bug,跟踪机制应该立即定位出现在哪一个Sprint阶段,对应Story是什么,这个Task当时是由哪位成员负责的,等等。最好能做到责任到人。一定要详细记录这个Bug的重现步骤,出现结果以及用户期望。这并不是为了单纯追究责任,而是把这个问题融入到下一轮迭代开发中,以后尽量不要再犯类似错误。如果这个Bug是由上游某开源软件引起的,那么务必记录此软件的详细版本号,以及构建日期。同时要rollback到前一个能正常运行的版本。等到该软件发行下一个修正版本时进行相同测试(可作为一个长期任务)。

如上图,表示出一个Bug从提出到解决的完整步骤。

(2)测试用例及文档管理

可以记录一些常见模块测试的方法,作为测试用例,以后可以不断补充内容。

开发中的文档,是社区内部的重要资料。其中包括产品的需求文档,或者是开发中用到的wiki等资料,还有各种项目的开源许可证。这些一定要分门别类保存,作为日后开发的重要参考依据。

3.产品计划的建立

尽量为自己的产品发布做出一个合理的计划安排,比如多长时间发行一个版本,每个版本的迭代周期确定一个合理的程度,并力争按时完成,尽量不要跳票。(如下图)

尽量在规定时间内做完一样事情,不要养成拖延的习惯。

总结:

作为开源社区的创始人和主要维护者,我们反对过度民主的做法。那样会把大量时间浪费在争论上,最终什么事都做不成。社区也需要一个负责人,最终说了算的人。及时调节矛盾,让大家在祥和的气氛之下进行技术交流,为开源软件事业做出自己应有的贡献。