关于敏捷研发流程

前言

最近刚把平台建设方案文档的初稿写出来就需要写一个分析结果的功能模块。由于我引入了kafka，希望通过上报数据之后实时推送分析结果而不是查询时统计或者定时跑批，所以，研发人员把这个活推给我自己做了。算是做个样板出来吧。不知道为什么，我的第一直觉是先开一个文档把设计思路记录下来。写着写着就有了今天这篇博客的灵感了，后面我们细说。

关于敏捷研发模型

在四五年前，我曾经从树上系统的研究过敏捷模型，找到一个叫做scrum的模型为蓝本，试过几次。和传统的项目团队相比，敏捷团队没有项目经理这个角色，更多说的是如何把事情做好出来。不过，在实际执行时，项目经理总是有的，而且事实上也是我经历的这些环境里必不可少的。
　　其实，我理解的敏捷的精髓，是更细粒度的迭代，而不是一次研发，大家卡需求、设计、研发、测试、上线这么几个节点。敏捷把这些节点拆分得很碎。很多人认为这是不可能的，但事实上，我认为这样更加高效。

传统上我们怎么做的

传统上，我们一般这样来操作。首先，产品经理把需求整理出来，产出需求规格说明书，然后评审。各方统一意见之后，研发团队或者说技术经理开始进行设计，产出设计说明书。有的时候设计很泛泛，有的比较具体，看具体人的风格。但无论怎样，设计评审之后进入研发。这个时候一般会有一个甘特图控制研发进度，给每个研发人员安排功能模块，大家按照进度来推进项目。到达某个节点，我们开发完成开始测试，最后上线。当然测试也有测试用例准备等阶段，这里我们只是简单说说这个流程。那么，这个流程有什么问题呢？反复次数太少。需求产出后进行设计，设计的时候肯定会对需求提出质疑，然后调整需求，但这个时候一般调整得很少或者说很小，因为需求评审会已经过了，不能进行大调整了。如果一定要进行大调整，项目进度就会延迟，而这通常是没有人愿意承担的，虽然不一定不可以。同样，设计完成之后，研发的时候也肯定会有对不上的情况，需要反复。这个时候因为任务已经分发了，所以调整也会尽量将就，降低影响范围。这样，问题就会堆积，最终降低产出的质量，而产出的质量一般在第一期甚至在第二期需求中表现的问题都不明显。所以，一般不会有人反对这些选择，但团队人员会慢慢变得没有激情。

敏捷中我怎么做

那敏捷中人们怎么做呢？其实吧，我也不是很清楚，我只能说我落地敏捷的经历和思考，我没经历过成功运作敏捷模型的真实案例。我在敏捷中注重这样几个点：

固定时间交付

这点很重要，与完不成延期相比，我更倾向于上线时间不变，减少交付的需求。这里有这样几个原因。首先，需要让团队认识到，时间定了，就不能变。其次，只有交付了，相关干系人才能看到结果，才能看到变化，才能对团队有信心。而团队由于总是固定周期交付，可以形成自己的研发节奏，提升效率。

以用户故事为需求粒度

这一点，是我这次重点思考的。一般来说，为了管理敏捷研发中的需求和任务，我会引入一个管理平台进行管理。之前，引入的都是禅道。因为在中国禅道用的人多，中文支持好，基本概念和流程比较全。但是，我个人更倾向于基于issue的管理。即，有需求，我们就列成一条一条的，录入进去，变成issue。然后我们再一条一条实现。从前用禅道的时候，总是需要把需求转换成对应的研发任务，然后再分给对应的人。这其中，其实后另一个原因，就是我们还是总是要写需求文档，过需求评审，然后再把需求已拆分出来录入系统，然后我们再看看这批需求什么时候能完成。所以，在那个文档完成之前，相关评审人员都不太关心上线的东西，所以，敏捷基本是徒有其形。
　　而这次，让我想起来了六七年前我在一家做美国外包的项目公司。当时，美国的项目经理（一个华人）分给了我和另一个人每人一条issue（他们用的jira），然后让我们先写设计文档。当时我层次很低，是很反感写文档的。而且，我也没啥写文档的思路，基本是先写好代码再补文档的，因为功能很简单。但是，我们沟通的时间只有上班和下班，因为美国的时差。这样的反馈效率很低，文档大概改了不到一周。这其中所有的变更都是上传到jira上的。而文档也没有标准格式，就是说明实现思路，以及准备做的核心细节。当然，当时没有这么清晰的思路，这是我回想起来总结的。当时那个项目经理要求我们把主流程画图，让我们表明我们动哪些类，主要业务逻辑包含哪些方法和属性。当时其实是很烦的，而且代码也要求很多，尤其是注释，还要写英文的。不过现在想来，那就是敏捷的蓝本。虽然，当时我那条简单的issue改了接近一个月。但是，我现在回想，那条issue有充足的文档，有充足的沟通。因为项目经理总是刨根问底，所以，我们的写的思路也需要对现有的代码有充足的理解，基本就是不会出现自己开个包然后打造一个自己的小王国的事件，我觉得，那条issue的完成，是很成功的。
　　虽然时间长了点，但是，能够有效得完成一个功能，而不是留下一个和项目耦合说不清楚的功能调整，我觉得，这就是我想要的模式。当时我效率低下其实还有个原因，就是，这种工作模式，不应该是当时那种能力的我参与的。只是外包公司为了省钱，才雇佣的我。
　　另一方面，需求的粒度是用户故事。每个用户故事，都是一个有价值的完整的需求。这句话我理解了好几年，我想我现在摸到门槛了。想要做到这是一个完整的需求，首先需求的来源就不能是需求规格说明书。而是产生需求的思路，然后一个一个描述，一个一个产生，并不是一次描述完我要把所有的事情做成什么样之后再拆分。而我昨天和今天编写设计文档的时候，就更深刻得体会到了这一点。

人员综合能力强

这个是现在前端后端大分家的现状引发我的思考。曾经有一家公司，前端后端是配置齐的，所以那家公司我实践敏捷的时候，研发团队有存在两个工种。而合作，其实还是蛮愉快的。但是，文帝是，人很多，而效率比较低。现在想来，一来有两个团队因为职责问题项目推脱，而来就是因为后端提供接口，前端调试细节，合作有前后衔接而各自对问题的理解又不全面导致的。所以，这一次，我设想的团队是，前后端由一人完成。或许，团队中我会存在专职前端，但是他是支持性角色，完成，是研发人员自己的事，前端代码要自己写，不会了只能找人问。这样，一个人就不会顾头不顾屁股了。而且，研发人员也要对整件事情有更深入的理解。
　　另一方面，也因为研发人员的单兵能力很强，所以，每个人都可以对方案提出自己建设性的意见或者建议，然后进行实践，而不是传统的任务分发之后执行。研发人员的话语权是很重要的，但是跟多的时候研发人员放弃话语权，并不是因为他们不想要，而是他们在这件事情上能力不足。

##总结一下
　　所以，我做敏捷就是这样。固定交付周期，团队成员之间只说合作，不说上下级，大家一起把事情做成。而这次对需求的更深刻体会，我相信这次能够把敏捷的完成度推的更高。