敏捷和小瀑布的相爱相杀
原创： 陈辉 敏捷视界 9月5日
敏捷和小瀑布的相爱相杀
光环学友会 • 敏捷实战分享
本文作者 陈辉
8月31日，我们有幸请到宿昱老师给大家分享了自己在日常工作和经验中看到的和了解到的，有关团队执行敏捷和团队执行小瀑布的一些情况。
分享嘉宾/
宿昱，光环国际管理咨询集团高级咨询顾问，近8年敏捷经验，先后服务于兴业银行、隆正、海关电子口岸、平安保险、伊利、IBM等企业。擅长工程实践类敏捷实践方法，重视项目管理的可视化，敏捷工件的使用。在自动化测试等实践上有丰富的实践经验，通过有效的使用优秀的敏捷工件解决产品研发过程中遇到的瓶颈问题，精进产品交付。
敏捷有自己的5大价值观和12原则。
核心价值观：客户合作高于合同谈判。
敏捷核心原则：可工作的软件是进度的首要度量标准。
只有这些价值观和原则，我们的项目如何落地啊？理论真的不重要吗？我们该如何看待理论在项目中的作用呢？为了让大家有更清晰的认知，我们来讲个故事。
举例一个团队，小明是项目经理，团队使用敏捷方法来执行的。
项目团队是一个大团队。分别是他们的产品团队、设计团队、研发团队、测试团队、项目团队和运维团队。每一个团队下都会附带着很多的职责。
产品团队有产品经理；设计团队有设计师；研发团队包括前端开发和后端开发；测试团队包括功能测试和自动化测试，还有性能和技术测试；项目团队包含了很多的项目经理；运维团队包含了部署和配置人员，还有运维人员和网络人员。
这就是小明团队的组织架构。每个团队都有自己的负责人。像产品总监、设计总监，研发团队和测试团队都隶属于CTO旗下，项目团队有自己的项目总监，运维团队有自己的运维总监。
团队使用的是迭代的开发方法。每个月迭代一次，每个月的月末都要进行上线。项目经理需要将所有的项目需求汇总，召集产品和业务PK一下决定优先级，然后让团队进行评估，确定前端和后端的联调时间，以及提测时间和外部系统联调时间（如果有外部联接的话）。
那么，他们迭代的开发流程是什么样子的呢？
业务部门提出自己的一些想法和需求，交由产品部进行分析，然后输出一些需求文档和原型图交付给设计团队。设计团队基于原型图进行视觉上的设计，切好图之后交给前端开发，产品将需求文档交给后端开发。前端开发和后端开发进行一段时间的开发之后，约定相应的时间进行前端和后端的联调，联调通过之后统一地交由测试团队进行功能测试。功能测试完成之后可能会上UAT，或者SIT环境去进行集成测试。集成测试完成之后再进行上线。
如上就是小明团队的迭代开发流程，从第一步业务部门的提出直到最后一步上线，这样一个开发过程。
那么小明作为一个项目经理，在其中应该做什么样的决定呢？他需要排一个工期表，按照开发+测试+UAT的时间可以囊括在一个月内的话，则把这次迭代上线的内容，要求在月底必须完成作为迭代的目标传递给团队。
当他们在进行的过程中，出现了一些问题。在需求宣讲的时候，A需求与外部系统对接产生了一些变化，需要对需求进行一些变更。但这个任务的前端开发已经完成，后端也完成大半，很快就要按原计划联调了。负责A需求的产品经理找到了小明，希望小明出面让团队解决这个问题。
经过深思熟虑，小明决定支持这项变更。这个任务客观上来说已经快要完成了，要是废弃掉太得不偿失了，不如彻底改好做完它。所以，小明让负责A需求的产品经理分别跟前端和后端开发进行了对应的沟通，沟通之后继续进行迭代操作。
团队有自己的任务看板，任务板上内容非常详尽。按照设计、前端开发、后端开发、测试、联调、部署、验证，每一个泳道都有很多的内容，站会就是在这个任务板前进行的。
小明团队有一个惯例，要做测试用例的对应评审。测试用例写完之后，需要团队成员，包括前端开发、后端开发和产品一起做测试用例评审。小明为了节省团队的时间，对应的开发、对应的测试和对应的产品，按照不同的模块不同的功能分别参与测试用例的评审。
评审的方式非常简单，由测试对测试用例进行一些说明。在这个过程中出现了三种情况：
需求A：外部产生变更，但产品忘了跟测试说这件事，导致测试的测试用例出现的情况和实际开发了解到的情况是不一样的。由于这个功能还没有进行测试，甚至还没进行提测。测试在听完新的变更讲解之后决定修改自己的测试用例。
需求B：联调已经完成，并且也进行了正式的提测。测试用例进行评审的时候，这个功能的准备测试工作也已经完成了，包括环境、各种测试用例都已经准备完成了。但是测试却和开发的理解不太一致。在某一个逻辑上，开发和测试用例中表述的内容产生了一些严重的偏差，产品经理本身对测试用例的内容也比较认可。但是之前给团队写的文档模棱两可，所以只能接受开发实现的逻辑，因为开发修改起来比较难。
需求C：本身比较复杂，已经快进入提测环节了，产品经理一直想要把这个功能往后放。开发已经开发了一部分，但还没有进行测试。产品要求先不着急做，于是……
“这个不做了”
“为啥”
“产品说不着急”
“那先做哪个？”
“先做这个和这个”
“行，那我就先准备这两个了”
测试用例评审之后，带来的一个问题就是，开发和测试在测试用例评审会上，就产品、需求和功能进行一个深度的讨论。这个讨论往往和最一开始会产生一些偏差，随之而来的就是一部分优先级要做对应的取舍。究竟要舍弃哪个呢？这个动作有三项。
第一， 需求是谁提的？
第二， 需求的重要紧急程度？
第三， 这个任务当前的执行情况？
最终，在一片紧急重要且的优先级中，找到一个感觉还可以进行舍弃。决定之后，小明和团队进行一个充分的沟通。
通过测试用例的变更，需求也对应产生了一些调整，提测的时间也就进行了相应的后置。而迭代的周期到月底结束，上线也是在月底完成，测试的压力就很大。
UAT测试，就是业务的验收测试。UAT是小明公司上线之前业务方对完成的内容进行验证的工作。UAT测试完成后上线，出现了各种各样的问题。
这一切仿佛是敏捷的锅。我们要是用传统开发，就没有这些问题了，一开始就会让业务方签字确认。那么小明公司的现状，真的是敏捷的锅吗？
他们执行了敏捷的活动，但真是执行了Scrum吗？如何调整小明公司的状态，才得以真正地执行敏捷呢？
我们的开发是为了什么？
大家都知道，开发团队开发是为了交付价值。交付价值最明显的方式就是上线，不上线的代码毫无意义。
怎么样才能让代码上线？以小明团队之前的流程来看，最后一步就是UAT。不通过业务的验收测试是不能上线的。
开发是为了通过验收测试吗？
验收测试是基于什么来进行测试的呢？需求文档？测试用例？
而大部分情况下，验收测试会有自己配套的验收测试用例。
验收测试用例，才是开发应该认真对待，基于此做分析设计开发。
我们的开发是为了什么？那么答案就很明显了，就是为了通过测试。
不是测试人员引领开发人员，而测试工作引领开发工作。
我们产品成功的标准是什么？公司是靠什么来盈利的？团队是靠什么来表证自己绩效的？产品和技术是相辅相成，而不是相互制约的。
产品的上线时间是谁来决定的呢？就小明团队的这种开发方式，是开发决定的？还是业务决定的？
真正的产品什么时候上线，这次迭代能上线什么内容，是由技术决定的。技术水平和技术瓶颈会直接制约产品上线的能力。所以，往往产品真正核心是它的价值和内容，而影响我们的是技术。
我们如何解决这个问题呢？
最核心：让价值交付代替功能交付。
确定完成价值之后，判断优先级。
优先级的正确打开方式：MoSCoW原则
Must：必须有
Should：应该有
Could：可以有
Won’t：不应该有
M、S、C三档究竟有什么意义呢？有两大意义：
第一，M、S、C是对比出来的。
第二，可以在一次迭代内进行不一样的划分。在一次迭代内，M最多只能有60%的工作量，Should20%，Could20%。既可以保证整个过程顺利执行，又可以保证收益达到最高。
当我们确定了优先级，确定了内容。小明要做的就是，要让他的团队可以做到独立交付。也就是说，团队应该包含了设计，开发，测试，项目经理，产品经理。只有做到这一点，我们才能真正地开始执行敏捷，或者说真正地实现敏捷。
当我们有了独立的团队，接下来我们要想顺利的执行敏捷，要考虑的另一点，不要让一个模块只能一个人做。
如何解决“不要让一个模块只能一个人做”呢？给大家推荐一个方法，叫做“结对编程”。
如何执行“结对编程”呢？我们可以采用一些优秀的方法，类似于“老代新”，一个老同事代一个新同事，又类似于“技能复制”，A同学技能复制给B同学。
估算，排计划是非常重要的。
如何避免工时估算造成的问题呢？
推荐方法：故事点估算，又叫对比估算。并且通过三个维度，进行对比估算。
工作量
复杂程度
不确定性
为什么故事点估算会比工时估算更有效呢？
工时估算会带着很强的个人属性，技术成熟度和业务成熟度会对内容产生很大的估算偏差。而故事点估算，是通过工作量、复杂程度和不确定性三个维度来进行估算，对个人属性相对地进行了一些调整。
工时估算和故事点估算最大的区别是什么？
故事点估算可以非常好地去做预测。一个敏捷团队的优秀与否并不看他单位时间完成的故事点的规模大小，而是看在单位时间内，多次的单位时间内，相同的单位时间内团队完成的情况是否稳定。故事点就是这个稳定的单位。
敏捷管理中的看板也被广泛使用。
从上面几张图，大家可以看出来，最大的问题出在了部署环节。部署环节是制约团队流动的真正瓶颈。所以，限制在制品起到的最好的作用，就是发现团队的瓶颈。
所有在部署环节出现的问题，我们就去解决部署。只要把部署解决，所有的条就可以流动。所以，优化瓶颈才是最好的消除浪费，而看板就是一种非常好的一种方式。
看板不是建立就可以，而是要使用起来才是真正的核心。
建立反馈机制，然后请说人话。
评什么？
l DEMO
l 所有可看出来的交付物，包括文档
怎么评？
l 基于故事的演示重点在验收标准上（基于测试用例，尽量不要基于需求文档）
l 最好一个代表从头演示到尾
结论如何？
l 不需要出什么评审文档，但是需要出来可用的版本给业务方
l 不需要会议纪要，但是最好能留存下故事
l PO需要对团队进行评价，团队自己看看承诺的情况完成的如何
如果是Scrum团队，找一个PO，然后找一个SM。可以理解为，找一个团队的负责人，再找一个团队的管理者。需要强调的一点是，无论是PO还是SM，都是对于团队所讲的。
敏捷和小瀑布，并没有谁优谁劣。在不同的环境内，不同的场景内，使用最合适的方法才是最好的。 END
陪你前进每一步
“ Walk you every step of the way.”
本文作者 / 王欢
发布 / 敏捷视界
未经允许，禁止转载
每当我迷失在黑夜里
您就像夜空中最亮的星
不断指引我前行
感谢老师的栽培和引导
帮助我从困惑中顿悟
在彷徨中相信，在焦虑中坚持
教师节马上来临，画一幅画作
送给你心目中最美的老师吧
我们会在教师节当天发布中奖者名单哦~
点击阅读原文，也可以参与活动哦~
阅读 767
在看4
写下你的留言
