我对scrum之思考

博主: Simon Lin 创建于: Jun 8, 2018 更新于: Jun 9, 2018
分类: management
标签: management scrum

我对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路,再转弯……。你去那是见朋友?不是,想去做地铁。哦,这附近就有地铁站,可以不用去南京东路啊?因为我想去豫园玩,所以去南京东路坐地铁,最近的地铁站在哪?豫园人白天很多,可以晚一点去,人少,你可以先逛外滩,再去豫园,从外滩走到头就到豫园了。嗯,挺好,那外滩怎么去?你现在就在外滩……这里是陈毅广场。我想,这个游客后来一定玩的挺开心的。


打赏 支付宝打赏 微信打赏

如果文章对你有帮助,欢迎点击上方按钮打赏作者