善用工具——成就高效沟通协作的团队

《敏捷软件开发宣言》 

我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

个体和互动 高于 流程和工具 

工作的软件 高于 详尽的文档 

客户合作 高于 合同谈判 

响应变化 高于 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

小而精的团队,往往更具有战斗力。我们提倡敏捷,也愿意相信它的价值,然而敏捷的实践却不仅仅是清晨站会、打打估算扑克那么简单。在我看来,其中最容易被忽视的一句便是:尽管右项有其价值,我们更重视左项的价值。如果一个开发者不写文档的理由是“我敏捷”,这就大错特错了,我所理解的敏捷,是关于『沟通』和『协作』的方式。

沟通自然重要,信息在传递中存在损失的可能,所以提倡尽可能的与客户直接沟通获取一手信息,避免经手N个人才到最终的实施者。同样的,部分信息也需要共享给团队成员或者stakeholder,由于沟通存在成本,所以方式方法亦很重要。

团队也需要协作,看板驱动带来潜在的负面影响就是每个人只关注用例,对项目整体的看法缺失,成员间的协作变少,由此在整个项目上出现了不同的视角。短期内任务是完成了,长远看分裂会逐渐积累。

敏捷是关于一个团队整体的态度,那么什么样的态度对团队是有益的呢?我们不妨审视一下以Github为代表的开源开发方式,并引入多种可用的工具,看能不能从中受到一些启发。

信息的有效推送与管理

程序员不喜欢邮件,认为邮件是浪费生命。无缘无故的被加入到邮件列表中,看着大家开始扯皮,扯到最后发现和自己没有一分钱关系,尴尬的是不看又不确定和自己有没有关系。又或者突然转发给自己了一封邮件,打开里面长长的对话,读了很久才知道说了什么。

这里的问题在于,邮件并不适合归档和提取信息,并且是强干扰因素。不妨回想一下,有没有参与这样一种项目,就是全程没有文档,进入项目组的当天转给你N封邮件让你读?再或者,连看板工具也没有,大家通过一个excel文件,标成黄色背景的你做,标成绿色背景的我做,彼此通过邮件来发送这个excel文件?

换一种思路,如果没有邮件,我们如何沟通?

Github有个非常好用的工具:Issues,任何人有问题、建议、计划等都会在里面建条目,然后完善Issue的详情并且展开讨论。上千人协作的项目用它用的不亦乐乎,这里的关键在于,信息完全是公开的,任何人都可以讨论,每个人只在必要的时候介入。同时,信息的噪音也很小。

这也是为什么Github被称为社交化编程。形象的打个比方,邮件好比写博客打架,你写一篇我写一篇,观点被不断放大,而Issue为基础的工作流则更像是Twitter,我说『filtering()方法出错了,报null异常』,下面有人回复『L30的null检查没有做,@Javis 请看一下』。

接下来,对PM来说,看来这个优先级比较高,马上打了个critical的标签,然后放在了current-milestone并分配给了@Javis,即刻,@Javis的上桌面上收到了通知,1分钟改好后提交了。

由于故事本身被限制在了一个很小的Item中,每个人可以更加关注于其本身。如果需要引入类似看板的功能,推荐大家试用ZenHub扩展。

另外,诸如Teambition, Tower, Trello这样的工具也可以提供灵活的任务管理,将一个大的用例切成小的部分,针对每个部分单独讨论,可以降低沟通成本,并且为归档提供了更多参考,不过,这些工具更倾向于客户与开发团队间针对需求和进度的沟通。

如果只是开发团队内的沟通,Github Issues, Jira, Redmine这些耳熟能详的缺陷跟踪工具一定可以帮助团队,让信息更加的透明,尽可能的减少信息干扰,降低沟通的成本

知识传递——通过工具写文档,随时共享你的想法

任务管理,或者缺陷跟踪的本质,是为了让信息便于管理和推送,同时带来一个新的挑战就是信息的归档。有很多的任务,其下对应的讨论是很有价值的,如果整个Item都是有限定的在讨论,那么从中提取信息就会变得容易。更进一步,可以将用例的讨论变成使用手册吗?可以将针对某个具体技术点的讨论变成团队共享的知识库吗?

知识库是全团队受益的,虽然敏捷认为文档的优先级不是最高的,但是绝不是说它不重要。对于程序员来说,有时候并不是不愿意写文档,而是写文档的工具不好用。

从Github得到的安利,就是好用的wikis工具,你值得拥有。结构化的文档体系,不需要安装任何软件就能写,每个人都能编辑完善,告别word和excel。

PM和开发人员应该对产生的Issues(或者叫Task)保持敏感,随时准备好提取和分享这些知识。而Email驱动的工作流养成的坏习惯,就是当需要将一些信息提供给他人时,不做任何修饰的把邮件列表转发出去。

当引入Issues(Task)驱动的工作流时,在它结束或close的时候,是最好的审视时机,回顾一遍,看有没有什么能共享的可以尝试归纳整理,分享是会上瘾的。

这件事,还有个非常著名的名词,叫做『知识传递』。

怕花钱?怕信息泄露?不妨试试Gollum(Github的wikis也是用它),其它的任务管理、缺陷管理工具也大部分也都提供wikis工具(例如Redmine, Jira),一朝架设,终身受益啊。

非正式的沟通

有时候面对面的沟通,或者电话会议是无法避免的。任务管理工具也有自身的短板,就是不适合讨论非常复杂的问题。

Skype在语音方面的表现相当的好而且免费,但是作为一个消息工具,它的确显得不怎么好用,或许在与客户沟通时使用Skype已经足够了,但是对程序员来说,频繁的分享代码片断,或者在群聊中@某个人时,它的表现并不抢眼,想加粗某段话都不支持。

QQ,微信,更不用说,只聊天还行,协作并不是他们所擅长的。

程序员需要更好的交流工具,尤其是文字的。如果已经使用了Github Issues,就会发现,@某个人,或者链接某段代码非常方便,再者,贴出的代码带有语法高亮让人看着非常舒服,毕竟,程序员之间经常说“黑话”,一段没有高亮并且不是等宽字体的代码非常跌份儿。诚然,Issues作为非正式的沟通工具还是显得太不正式了……

不如,试试火爆全球的Slack?基于轻量级的Channel(可以想像成一个随意进出的微信群)可以快速拉几个人进行讨论某个Subject,丰富的ref功能可以随意的@人和链接一切,尤为重要的,就是它支持Markdown,而且它足够的轻量,相信试用一下就会爱上它的。

这并不是故事的全部,最有杀伤力的一点,它可以集成进任何的系统,持续集成、持续部署、运维监测、自动化机器人,比如@WallE deploy production,就会触发部署消息传递到你的运维系统开始部署,试试吧。

当然了,国外有的中国就早晚会有,就像twitter和微博……国内的『简聊』(Teambition团队做的)做的也非常不错,功能类似,推荐一试。

善用VCS工具

Github带来的另一个启迪,就是关于源代码管理的方式。众多的VCS工具,从TFS到svn,从Mercurial到git,无疑给了我们太多的选择,用好哪一个都会带来极大的生产力提高,然而事实并不如此。

很多的团队,仍认为VCS就是个存代码的地方,这或多或少的会给流程带来一定的影响。Github提供的思路很独特,在git的基础上创新的提供了pull request工作流。我们都确信code review带来的价值,我们也认同unit testing为QA带来的红利,但事实上做的人很少,有流程和其它的原因,当然也有工具不够好用的原因。

而pull request这种方式为我们提供了一种思路。善用工具,就得理解工具背后的文化,比如从svn迁移到git,就不应该在同一个分支上死签入到底了。从任务管理或缺陷管理工具开始一个新的任务,马上新开一个分支,不断的提交与实现,当完成时发起pull request让团队内的其它人来review是一种很好的知识传递的方式,同时,在pull request的窗口期内也可以不断的改善,确保最终的合并是一种完整的合并,这种一致化的体验在其它的VCS系统中是很难做到的。

相信工具的力量,架个git试试吧,别用svn了,比如试试Gitlab, Gogs,或者用在线的coding.net、码云、Bitbucket,都是免费的而且提供私有托管,不费事儿。

真实案例

过去的一段时间,我有幸见证并参与改善了一个团队(以下称A)从土作坊开发到敏捷主动改变的过程,权当是一种茶余饭后的消遣吧,并为大家进行敏捷导入提供一种基于工具的思路。

A开发团队差不多20人左右,移动端、前端、后端、运维,开始的时候并没有很严格的流程一说,用的是TFS来管理所有代码(所幸用的是TFS git),前端没有仓库,手机端两个仓库,后端5到8个仓库分别对应不同的服务,沟通用QQ,但是与产品团队一起使用Worktile(类似Teambition)。

初期的流程是这样的,产品团队预先一两周给出需要开发的任务,开发的任务会在Worktile上拆成单个最小需求,后端团队开始将任务分配到人(整体任务),并且是责任制度,谁负责哪个模块就分那个模块相关的任务,开发团队在一周内给出所有移动端和前端需要的接口定义,移动端紧接着开始开发。运维团队有自研的发布系统但几近瘫痪,因为大家都愿意用手动build去服务器覆盖的方式部署,并且通讯工具只有QQ。

进入团队后的第一件事,就是架设gitlab,将全线的产品从TFS迁移到gitlab,为什么呢?因为gitlab的工具生态系统很完善了,并且……免费。

之后,开始改善团队流程,引入每日站会,并严格按照敏捷站会发言不打断的原则执行,为什么呢?先培养习惯。几周后,从最初开始大家反映没什么可说,别人说的听不懂(因为只负责自己的部分),到开始限制每人的发言时间,是个极大的转变,团队成员开始对整个项目有了整体的理解了。

接下来解决后端的问题,发现几个仓库间代码重复严重,没有共享组件而是用原始的复制粘贴,于是大约花了近两个月时间,将原有的后端仓库拆分成十五个左右的独立子仓库,每个仓库安全按照Githab开源软件的方式管理,有问题或缺陷直接去仓库提Issue,也可以跨“职责”提交pull request,并将前端部分从后端仓库中拆出去独立管理和发布。

氛围变的明朗了许多,并且在本来时间就很紧的进度下,每周集体抽出一到两个小时分享自己“负责”的项目、心得等,虽然刚开始并没有多少人分享,但后来就多了,能明显感受到团队的信心值在增加。每次的分享结束后,我都会将整个分享整理成知识库放在wikis中,后来逐渐的整个团队开始参与,wikis数目上涨非常快。

这些流程在团队内完全理清后,最后一个团队大动作就是每周至少2小时的交叉code review,并不是说这种方式有多好,在进度压力过大的情况下的一种变通吧,有总胜过无,更何况code review还真提供了不少新的思路。

然后就是运维团队,发布时手动去生产环境覆盖这事儿我一直不太能接受,后来和运维的伙伴们一起引入持续集成和持续部署,为此还单独写了一个基于F#的DSL描述库,用来快速配置新服务进行持续集成和发布,最终的效果是所有后端仓库从建Issue到修改完提交,到进行单元测试、打发布包、蓝绿发布(或者发布组件的升级包到内部源),整个过程最快5分钟完成。

后来将整个流程逐渐推广到前端和移动端团队,团队气氛很不错。

到离开A团队时,后端大约有20个子系统以及40多个仓库在分别独立的以开源软件的方式运转,团队成员基本可以在所有子项目间无障碍的交叉提交代码,并且还开源了内部开发的用于Kafka的.NET SDK,上述的工具几乎都在使用。不用PM参与,成员就可以自发的对每个系统提出改善的建议和优化。

一个敏捷理性的团队。

结语

我们讨论一切,最终的目的是想让一个团队,尤其是一个敏捷团队变的理性和主动,要相信工具的力量,并且要变的乐于分享,这些文档、工具、流程不仅可以让团队的生产力更进一层,更重要的是积累下了宝贵的智力资产,这些是省钱省不出来的,也是买不到的。

相关内容:

我们如何从领域驱动开发当中获益–王德水

领域驱动设计,遇见你之前 我们公司推行和实践敏捷已经很多年了,SCRUM已经成功应用于大部分项目,得益与业界敏捷开发大师以及国内很多优秀工程师的分享和宣传,我们使用了很多优秀的软件开发实践,比如测试驱动开发(TDD),行为驱动开发(BDD), 持续集成(CI)等等为我们带来了很多收益。由于我们公司以……

IOT 研究 技术趋势 洞见与思考 观察与技术趋势 软件开发 180 阅读

如何选择靠谱的软件外包公司

在信息化建设中,随着IT与业务进一步融合, IT成为推动业务转型、管理变革的重要力量。很多企业在10几年前购买的软件产品,已经无法适应日益变化的业务需求,需要根据企业自身业务模式进行定制化开发,以助力企业发展及业务转型。 传统企业通常没有专业的软件开发团队,组建IT团队的成本比较高,后续IT人才维护……

观察与技术趋势 软件开发 181 阅读

Mind Matter项目分享——设计不仅仅是设计

Mind Matter软件旨在促进企业的战略发展,并帮助推动战略的实践。其核心业务是开发下一代战略软件和服务。与各种类型和规模的企业组织合作,共同定义、设计和执行战略。 目前开发的软件作为一款简单精巧的协助工具,帮助用户定义、设计、讨论、决策和交付发展战略。 Mind Matter项目自2017年9……

技术趋势 观察与技术趋势 154 阅读

远程办公:谈谈我遇到的挑战与机遇

每每与身边朋友说起我在家上班,他们都会投来羡慕的目光,外加两个字:“真爽”。而我,只能无奈地回应:“其实也就那样了,并没有多爽。”这是心里话,但是他们只会觉得我矫情,得了便宜还卖乖,我也只能呵呵苦笑了。
我承认他们部分正确,是有点身在福中不知福,这也是人的天性吧,永远不满足。但是,我之所以如此笃定地说,在家办公没有那么舒坦,是因为这两年的远程办公经验让我明白,这种看似“爽”的工作方式,其实暗含着许多挑战,对远程工作者也提出了更高的要求。

敏捷实践 洞见与思考 软件开发 远程办公 195 阅读

引导客户不是靠话术 而是全然的负责

近期我们接了一个在线教育的客户,他们业务发展很快,旧有的系统虽然比较稳定但已经不能适应业务发展的需求,因此找到我们。充分了解需求之后,我们判断客户提出的任务不现实,在规定时间内完不成,既定目标不可行。于是我们将需求拆分,将功能实现的顺序重新安排:哪些在3个月内可以完成,哪些不行,同时接手客户的运维。

敏捷实践 观察与技术趋势 软件开发 远程办公 157 阅读

跟客户面对面确认需求是一种什么样的体验?

Matthew是个澳洲客户,前期有过很长时间的沟通和推进,我们对业务和项目需求目标大概了解了。但是针对第一个要发布的版本,要做成具体什么样的产品还是两眼一抹黑。故此,客户来我们办公室两周,专门讨论具体细节。期望经过两周的密集讨论,我们能有若干产出: 想想都挺多事情的。当然,理想都是很丰满的……过程不……

观察与技术趋势 软件开发 151 阅读

我的ODC项目经验分享

项目介绍:客户公司旨在为病人提供更加优质低价的治疗方案。其主系统联合病人、医师和医保公司,根据病人的病症、体检数据、过敏情况、生活习惯和过往服药方案等信息,结合其内部一套引擎工具,检查用药过程中的问题(Drug Therapy Problem)并提出给药建议。 在三年的合作过程中,我们不断丰富其主系……

观察与技术趋势 软件开发 174 阅读

敏捷实践系列(三):代码管理流程

我们已经从SVN切换到Git很多年了,现在几乎所有的项目都在使用Github管理。对于那些还在坚持使用SVN的,我实在想不出原因,权且称作守旧派吧。 Git的优点 Git的优点很多,但是这里只列出我认为非常突出的几点。 感兴趣的,可以去看一下Git本身的设计,内在的架构体现了很多的优势,不愧是出资天……

敏捷实践 观察与技术趋势 软件开发 163 阅读

敏捷实践系列(二)

大话西游里有一段因为没有沟通的经典, 结局如何大家都知道。 唐僧:你想要啊?悟空,你要是想要的话你就说话嘛,你不说我怎么知道你想要呢,虽然你很有诚意地看着我,可是你还是要跟我说你想要的。你真的想要吗?那你就拿去吧!你不是真的想要吧?难道你真的想要吗?…… 悟空:… 一. 敏捷项目沟通尤其重要 敏捷开……

敏捷实践 观察与技术趋势 软件开发 146 阅读

敏捷实践系列(一)

开篇: 悟空:师傅,为什么你写东西,喜欢写系列呢? 师傅:因为很多东西需要长期的实践呀。 悟空:怎么又开始说敏捷了 师傅:就像一本好书,常读常新,人生不同阶段过的都是不同的人生呀。 悟空:师傅,为什么你原来用上、中、下呢? 师傅:因为原来只写了个上中,别人一直问下,现在如果只写一二,别人要问,我就说……

敏捷实践 观察与技术趋势 软件开发 150 阅读