石墨文档技术总监：敏捷思想在产品周期的延伸

李子骅--石墨文档技术总监。

一个产品有需求的提出、评审、肯定，以及实际的开发测试和交付这几个阶段。从2001年敏捷被提出开始到如今已经有愈来愈多的项目在使用敏捷。如今的敏捷已经变成一种常态，这个时候讨论敏捷实践中被你们的忽略点就变得很是有意义。

今天咱们会围绕两个关键的点来讨论：一个是关注非功能需求，另外一个是DevOps相关的策略。

关注非功能需求

这是一个网站的截图，上面有两个文本块，第一个是标题，第二个是答案。

看到这个图，首先你们会想它是什么东西，其次是为何会有人问这个问题。

这是如今最流行的前端开发框架 React 的新一代的核心算法，Fiber的提出有两个背景缘由。

第一个缘由 是如今愈来愈多的产品和网站很是复杂，尤为体如今交互和功能方面。就好比石墨文档可让不少人同时在线编写 Word 文档，这和以前传统的相似博客和新闻的Web 应用不同，如今咱们会有更复杂的交互，因此复杂交互带来什么呢？愈来愈多的用户发现虽然网站功能愈来愈多，可是好像网站也随之变得更卡了。滚动的时候会有一些延迟，打开一个网页会愈来愈慢。Fiber专门是为了解决这个问题，也就是说当你的网站很复杂的时候它可让你的网站速度响应更快一些。

第二个缘由是什么呢？ 通过长期的发展，React是如今最流行框架之一，全世界用户都在向它提各类需求：我想加这个功能，要那个功能，可是长期发展过程当中也积累了不少技术债，也有不少没有完成的重构的东西，因此他们也但愿可以经过Fiber的开发能够把这些技术债还上，把它变成更容易维护一些。

到如今，Fiber开发了满打满算两年时间，它已经推出了。推出以后你们惊喜的发现个人网站好像变快了，咱们也能够看到React市场占有率在逐渐升高，迭代频率也在逐渐加快。因此其实Fiber的开发就是一个很明显的非功能需求，你们收到不少需求反馈，可是最终团队仍是选择开发这样一个Fiber的工具。

因此，咱们当提到非功能性需求的时候，会有几个常见类别，包括响应的速度、负载能力和测试覆盖。每一个团队根据不一样的状况会有不一样的处理方式，把非功能的需求放到Acceptance Criteria里面，也能够放到Definition of Done里面做为这个用户故事是否完成的标准。

不一样的方式其实各有利弊，如咱们在开发石墨文档过程当中支持多我的在一篇文档实时编写内容，同时每个人看到编辑的东西，这是很明确的功能需求。

怎么去约定它背后的非功能需求呢？大部分状况下应该把它放到咱们的验收准则里面，就是说咱们能够约定一些通用性能需求。就多我的实时编写这个例子来说，可能会约定一我的数，好比但愿可以十我的都可以去实时编写，而后每一个人的保存时间能够控制在一秒钟以内。这样当咱们去完成这个用户故事的时候，咱们会看验收准则，若是它支持了在一秒钟以内保存，那咱们就肯定它是完成的，因此这是一个对于事情有没有完成的很清晰的量化标准，不会让人忽略掉非功能的方式。

但其实也有另外一种作法。有些团队会把这种非功能需求当成一个独立的项目，而后放在Backlog里面，这会形成什么问题呢，在时间宽松的状况下没有什么问题，可是当开发遇到一些阻碍的时候会发生什么事呢？就是咱们经常会倾向于优先解决客户能看到的东西。由于当我去交付这个项目的时候，客户看到有这个功能以为还挺不错，大家工做很快，而后大家也很卖力，这些功能对我也颇有用处。

可实际上隐含的非功能性需求很是重要：可以承载多少人、能不能在公司范围内使用咱们的产品以及安全性怎么样等等，还有一个很容易被忽略的点就是项目的可维护性是如何的。

长期迭代中，敏捷强调愈来愈频繁的跟客户沟通，去了解客户需求，响应用户的需求，因此开发速度会很是快，交互周期很是短。

在这个时候，很容易发现就是咱们会忽略掉咱们产品的可维护性，就好比咱们会引入不少技术债，会有不少投机取巧方法把这个东西快速上线。到下一个迭代的时候，却继续关心客户反馈的其余需求了，没有再去解决以前的技术债。这就会致使一个产品开发的时候，初始阶段速度很快，可是越到末尾越会发现速度愈来愈慢了，直到不能不得不停下来你们坐在一块儿讨论解决这个问题。

两个“负责人”

这个负责人是打引号的。为何打引号呢?

最近很火的一部电影 《绿皮书》 ，看过这部电影的同窗应该都知道《绿皮书》有两个男主角。

坐在后排的这我的得到了最佳男配角奖。其实你们很难想象他是配角，由于若是这部电影少了他，咱们很难想象这部电影怎么能拍得下去，怎么能把这个故事讲完。因此，虽然咱们会有主角，会有配角，但实际上颇有可能这两我的缺一不可，咱们应该作到不能忽略其中任何一我的。

在一个敏捷团队项目里面，咱们很关注PO的决策，很关注PO的倾向，他会去把咱们作的事情按照优先级排列。其实，咱们还须要另外一个负责人，就是说他须要可以很清晰地了解咱们如今的状态，咱们如今团队的状况，咱们的开发的速度，咱们对一些非功能需求的深入理解。

就好比可维护性究竟是如何，需不须要停下来作一些重构，仍是继续前进。

对石墨来说这个「负责人」不是一个角色，由于咱们不会设置一个职位作这个事情，若是专门设置一个职位这个事情的时候，整个团队其余人很容易说：「好像这个职位的人他只要作这个事情就能够了，咱们其余人不须要关心。」这反而会形成对整个非功能性需求理解的一个倒退，会起一些副作用，对于我来说更重要的是从文化角度把非功能性需求的灌输给整个团队可使得团队透明的理解和推进NFR，非功能需求。

什么叫透明的？ 简单留有必定比例的NFR时间不能帮助透明化。不少团队会有另外一种作法，就是我能够有不少功能性需求，可能有不少用户的反馈，可是我也要作一些可维护性的东西，我要作一些重构，我要去还一些技术债，我要去作团队的提高，我要作一些方便部署的事情。为此我须要在每一个迭代周期预留固定的10%或20%的时间来作这些事情。

这样会有什么问题呢？ 一个敏捷团队，或者正常一个团队，咱们最关注它是能不能自我成长，自我提升，自我进步，自我反馈。因此当讨论非功能性需求的时候，实际上是一个很好的契机，整个团队，包括咱们的PO、包括咱们的整个的开发团队，能够坐在一块儿一块儿讨论为何咱们要花这些时间去作这个重构；为何如今去作，而不是下一个迭代去作；这些会对咱们的用户、商业产生什么样的价值。咱们会发现这些讨论可让整个团队可以更快地去获得一些反馈，更快地知道咱们的产能究竟是什么，而不是说咱们尽快地去完成客户全部的的事情，直到由于技术债的各类包袱致使咱们不得不停下来。

因此透明地和整个团队讨论这件事情，使得团队能够自我提高，这是一个很重要的事情。

DevOps 的左移

提到非功能性需求，咱们很天然就会联想到DevOps，这是一个很天然的关联。

DevOps左移，看这个图就知道了：

咱们知道大部分的敏捷框架或者敏捷方法都会很关注软件迭代开发的部分，就是左边这个部分，咱们要有敏捷团队、咱们让开发团队和业务团队坐在一块儿、咱们可以实时去了解客户的需求、尽早根据不一样的环境作不一样的改变，咱们但愿可以尽早地频繁地去交付能够工做的软件给客户。

可是，右面是什么？ 右面是咱们传统的IT实施运维，他们最关心的是稳定，这个东西若是没有问题，就尽可能不要搞，上线的次数不要太频繁。咱们每次上线可能都会有风险，咱们要盯着这个上线的过程，而后运维同窗也要去，因此对于运维来讲，上线是一个很痛苦的事。

因而，你能发现，这个绿色的和黄色的好像是有一种冲突在里面，左边是但愿可以更加频繁一点，尽快交付，右边是冷静一点，不要这么快。因此，你们会发现当采用了敏捷的时候，若是咱们在运维层面不作任何改变的话，整个交付给客户的时间有可能并无缩短。

我要怎么作呢？就是标题所说的，咱们要将运维向左移，这个就回到我演讲这个话题，敏捷思想在产品周期的延伸，咱们何时延伸，当咱们敏捷的时候关注的是沟通，就是咱们会和环境沟通，咱们会和客户沟通。

那其实也同样的，开发团队要作什么？运维团队要作什么？这个其实也须要尽早沟通，就像这个图同样，咱们能够在更早的时间，好比说开发的第一天，或者是咱们在开发以前，就让你们坐在一块儿沟通。

DevOps最重要是什么，其实很难有一个确切的定义。

咱们能够说它是一种方式，一种工具，也是一种文化，因此最根本的就是沟通。就是说咱们在敏捷时已经证实了沟通的重要，咱们能够快速的把软件交付给客户，更快速地去确保咱们这个东西知足用户的需求。而不是之前那样埋头苦干一两年，丢给用户，用户却说这不是我想要的。因此项目部署也是同样，像过去若是咱们作埋头开发，最后丢给运维团队，运维团队说这可能不是咱们想要的，咱们可能部署不了。其实以前石墨常常会遇到这样的问题，就是咱们其实迭代会很是的频繁，客户需求也会很是多。因此对当时的咱们来说最痛苦的时候就是当一个迭代结束，要部署的时候，发现部署是一件很可怕的事情，咱们常常在部署时发现部署脚本有问题、代码好像有点问题、部署上线了但各类错误扑面而来，运维电话响个不停。

实践：石墨服务开发流程

如今去看以前，我以为石墨开发的最重要的一个基础的产品，就是咱们内部使用的交付平台。经过它，咱们的迭代周期能够更短，交付频率能够更快，部署上线的整个流程也会更稳定。

由于石墨是面向企业在线协做的软件，因此咱们本身也会用石墨写一些文档。这个截图能够看到及咱们会用石墨写一些案例、写一些值班计划、写一些工做日志、技术分享和假期安排。

石墨每一个员工都是本身产品的重度用户。刚才提到的敏捷，咱们最关心的是怎么可以接受反馈。其实内部员工的反馈每每比用户甚至种子用户来得更快，这是由于你们都坐在一个办公室里，每天见，也会更了解产品。

因此，咱们就在想两个事情:

第一个事情是咱们怎么可以尽早地收到咱们内部员工的反馈；
第二个事情就是怎么可以把咱们最惧怕的问题，部署的问题解决掉。

因此，咱们作了一个这样的功能。

“随时测试和部署每一个功能” 这个功能是怎么用的呢？石墨在开发每一个项目的时候，每一个小组开发每一个项目的时候都会建立一个特性分支，而后咱们全部的功能都会在这个特性分支里去开发。每一个石墨的员工，访问石墨的时候都会有一个特殊的页面，如截图所示，经过这个页面，每一个人均可以去配置每一个微服务使用哪一个特性分支来相应本身的请求。

举个具体例子

就是回到刚才这个图，前几个月咱们是没有左侧的树型目录的，可是不少内部员工会反馈，若是左侧有树型目录，就能更容易地找到和管理本身的文档。因此咱们决定加上这个功能。当开发进入第五天的时候，咱们已经能够经过这个平台把正在开发的树形目录能够给内部员工用了，咱们会发各类邀请连接，告诉你们能够到这里选择咱们特性的分支，而后刷新就能够看到这个树形结构来实际体验了。

在咱们开发以前，其实你们都应该知道咱们会把设计图会给利益相关者，会给老板看，但这个图给客户看的时候，客户说还不错,，可是咱们把软件交给客户的时候，常常发现他们说这个跟当初好像不太同样，不太能知足本身的需求。其实每一个人都同样，你们看设计图和在实际工做场景中使用这个东西的时候，感触是彻底不同的。

看图可能会忽略不少东西，但当你天天使用的产品出现这样变化的时候才能切实的感觉到这个东西到底好很差用，到底有没有改进的地方，第五天的时候能够把左边有树形目录的产品发给咱们的员工看，他们能够把资料放在石墨上，他们会平常体验，由于他们天天用这些文档，因此能很快发现这些东西到底合不合适，到底能不能知足他们的需求，因此也是经过这样咱们能够可以很是早地去收集到咱们用户的反馈。

相比于以前咱们会花很高的成本作AB测试的策略、作各类实验来分析咱们的用户使用场景。而后要过两三周的时间才能把这些数据汇总起来。

经过这样的功能，咱们就可以很是以一个最低的成本，最快的速度收集到客户最真实的需求。

第二个问题就是刚才说到了，咱们每次迭代最怕的就是部署的那一天。由于以前经历到一些部署的问题。如今咱们经过这个平台能够作成什么样呢？部署就像切换标签同样方便！刚才讲内部员工能够经过这个平台去选择每一个模块所要使用的分支，对于发布来说是同样的。

咱们能够设定一个比例，好比2%或者10%的用户能够访到某个分支，而后剩下百分之几的用户能够放到另外一个分支，其余的用户再访问到线上分支。它是一个很是快速、灵活的一种上线的方式。

文章来源：Worktile敏捷博客

欢迎访问交流更多关于技术及协做的问题。

文章转载请注明出处。