我对scrum之思考

你们的开发流程是敏捷的吗？是的。你们的开发敏捷吗？没有。每个互联网或者IT公司都会提敏捷开发Scrum，可往往很多公司的开发并不高效敏捷，为什么呢？

什么是敏捷？

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。……以上摘自百度百科。

用户的需求真是需求吗？

20年前，在上海上班通勤效率还是很低的，如果有一个地铁在家和公司之间，就方便好多了。需求是地铁吗？不是，客户的需求是方便快捷。解决方案的重要要素是地铁，具体的方案就是找个地铁能到附近的公司上班，然后在地铁站附近买个房。

10年前，在上海上班通勤效率还是很低的，家离地铁站还有2站公交的距离，每天走走好累。需求还是方便快捷。解决方案是搞个自行车，最好是折叠的，可以带上地铁。

5年前，在上海上班通勤效率还是很低的，自行车不能带上地铁成为共识，也出现了相关的法规。那么，怎么满足需求？其实那个时候就有永安或者别的自行车公司搞的共享自行车了，有个停车桩，交上押金，就可以骑走。

2年前，在上海上班通勤效率还是很低的，当年的共享自行车渐渐没落了，找不到可用的车。因为，新的ofo和摩拜出现了，随停随用的共享自行车，扫码骑走，大大的便利了最后一公里的出行。

讲这个故事真的很反应问题，即使是一个很简单的需求或者说一直都没有大变化的需求，我们可以有好多的解决方案，从不同角度解决了同一个问题的不同方面。

其一，不要把解决方案变成了需求。

其二，解决方案有好有差，有快有慢，有层次递进，可以不追求大而全，可以从小而快开始着手。

其三，适者生存，只有更适应变化，才能活下来，环境变化快，解决方案变化也要快。这个例子还只是需求没有变化的情况，如果需求也实时的在变，开发如何才跟的上？方法就是小步快跑。

谁是用户都没搞清，你能搞清需求？

再说一个关于需求的故事：

当我们去一家医院的时候，先挂号，排个队，在就医，排个队，医生看完要去抽个血，OK，先排队缴费，再排个队抽血，再拍个片，继续排队，做完必要检查，终于回医生那里，医生给个结论，好，去排队拿药吧。

当我们一直抱怨医院体验差的时候，

从另外一个角度看医院的运营，发觉医院其实效率很高啊。一个医生，从早上8点到下午5点，可以看上上百个病人，平均下来每个人5分钟，100个人就是接近8个小时了。挂号缴费处也一样，每个窗口每天接待的人有数百，高的可以上千。抽血，X光机啥的，每天也是满负荷运行，绝对每时每刻都在创造价值。如果你是院长，医生的成本，辅助人员的成本，器械的成本，然后每个病人的收入来核算，根本就不需要关心每个病人就医的体验啊，病人的时间成本，根本就无法核算到医院的收入里。

好，那么假设你是产品经理，来服务院长提出的医院科技化项目，你会从哪个方面入手？

缴费处增加手机支付，减少找零的时间。

抽血等处增加自动拿号机，可以减少一个人工。

安排一个专职人员在医生诊室门外维持秩序，因为秩序越好，病人进出中间衔接的时间越短，医生的利用率越高。

还有网上挂号啥的，用互联网的方式替换一些人工工序，增加效率。

如果你是产品经理，来服务的是这个医院是个私立医院，真正掌权人是投资人，要求你从病人的角度来改善，你会怎么搞？

2个医生同时坐诊，一同会诊一个病人，互相商量，一同看诊，以防出现问题。

每个医生配一个专职的护士或者勤务，病人来了，帮忙把各种检查陪同做完。

X光，B超，最好每层楼都配上，随到随用，限定医生诊室到检查室步行距离不可以超过200米，不可以跨楼层。出来的报告都直接送医生的桌上。

看完病，护士一路护送你出门，并叫好快递，送药上门。做好记录，定期回访，如果之后还需要的话，按时快递药品给病人服用下一个疗程。

病人的病历啥的全都搞上系统，自己和家人可以方便的调阅。缴费？不存在的，病人的支付宝账号，医保账号都在系统里，用多少，哪些可以报销，勤务人员全帮你搞定，定期给你寄个账单，你签收就好了。

这个故事说的是同一个问题，面对不同的需求方的时候，解决方案可以很不一样。都说是用户的需求，哪个用户先搞清楚，差别会很大。

如何敏捷？

好了，说回敏捷，我们如何敏捷？

1或2周一个迭代，站会，grooming，planning，回顾。scrum master，project owner，开发，测试。角色，制度等等都不是敏捷的必要因素，敏捷不是形式主义。既然以上这些都不重要，那么什么才是核心？敏捷定义已经说了，用户需求是核心。用户的问题越快解决了，我们就越敏捷。开发的速度，测试的速度，需求确认的速度，都不是敏捷的速度，敏捷讲究的是端到端，从用户提出问题，到看到改变和改善的时间，所有scrum小组的成员其实都只有这一个目标，围绕这个目标进行工作。

第一版本

为了让用户更快的看到效果，当然要更快交付，才能更快的改变。很简单的道理，要交付的更快，要让交付项更小，更少，更原子化。

特别是第一版的交付，交付内容特别要慎重。想象一下，我们需要一个贷款业务的系统，我需要App，申请系统，审核系统，风控系统，用户系统，营销系统，账务还有其他（短信）。怎样裁剪？什么是最核心，最重要，最原子化的？第一，主流程能跑的所有系统，

App，申请系统，风控的一部分，用户的基础系统，账务记录。

第二，从用例出发，排出优先级，去除不必要的用例

此处埋个坑，下次有时间找个地方专门讲删减不必要的用例的例子。

第三，将大的系统先化为小的模块，大的模块变成小的接口

App可以只选一个平台的，android或者ios

申请系统可以只做固定流程的，不搞动态流程或者多套申请流程的系统

风控可以只有框架，数据输入和结果输出，没有任何具体规则

用户系统只记录下数据就行

账务有个账务表记录，还款，结清等后续迭代再说

第四，用户能看的到的，优先级高些

界面上的东西，元素，可以先预留，功能再改或者做一些mock，真实交互这回事从现实角度来说，可能比产品经理画的各种饼都有效，用户是从真实产品的ui来认识我们的系统的，也只有看到真实ui后，产品经理再画饼才会更有效和真实。

日常迭代

在第一版之后，如果要快，就安排尽量短的迭代周期，2周或者1周迭代，尽量小而明确的功能，改进上线反馈，改进上线反馈。在这个过程中，核心目标是改进的点（解决方案）上线后用户是否能真实感受到效果。

如果PO对需求把握不对，或者没有充分调研，遗漏了重要细节，那么后面的全白扯。如果测试误算了测试范围，导致上线后，出现Bug，造成返工。如果开发自以为是的增加了附加功能，画蛇添足。这些都不敏捷，首先要统一敏捷的认识，就是我们这组人的目标是一致的，就是以用户需求为核心，解决真实的问题。

局部效率不能带来全局的效率，某个角色的效率可以影响但并不能决定真实的问题解决的效率

产品层面，分析和厘清真实需求，想一个合适的，性价比更高的方案（参考前面出行的例子），不是所有的产品都有这个能力，不过看准解决问题的方向，别带错路，这个是基本要求。

开发层面，需求变小了，原子化了，做的事情会更简单些，更长远的问题会考虑的少，从长久来说，会有问题，所以，要适时的提一些技术改进点和长远规划性的东西，前面贷款的例子，之后各个系统都需要做全，所以埋的坑都要自己填，在一开始的时候，不要挖坑太深。

运维方面，迭代的增多，会导致上线的频繁，复杂度的大大增加，更合适的DevOps的系统工具，和测试结合，单元测试，接口测试，集成测试，各个环境的部署等等问题，应运而生，在这个敏捷与微服务流行的年代，注定了运维会有更重的任务

测试角度，快速就代表着混乱，如何在混乱中生存，原始的方法论就变的过时了。刚才说的单元测试要和开发一起做，提高覆盖率。各种自动化 工具 用起来，jmeter，postman，配合写点代码，写点脚本，来跑自动化的接口和集成测试。

小结

这里说了很多具体的事项，还可以有很多，这些是敏捷的手段，而不是敏捷本身。敏捷在我看来只有一个核心：更快更好的解决真正的问题，用户的问题，让用户开心。最后说个玩笑，一天一个人跑来问我，南京东路地铁站怎么走？我说，离这里还挺远的，要2公里，先沿着XX路，再转弯……。你去那是见朋友？不是，想去做地铁。哦，这附近就有地铁站，可以不用去南京东路啊？因为我想去豫园玩，所以去南京东路坐地铁，最近的地铁站在哪？豫园人白天很多，可以晚一点去，人少，你可以先逛外滩，再去豫园，从外滩走到头就到豫园了。嗯，挺好，那外滩怎么去？你现在就在外滩……这里是陈毅广场。我想，这个游客后来一定玩的挺开心的。