最近又一个我的项目用瀑布形式做砸了（因为本文会屡次提到本我的项目，咱们就叫她我的项目 X 吧）。我的项目 X 刚开始的时候，咱们部门的麻利转型还没有起步，所有我的项目仍然用瀑布形式。这个我的项目我一开始就想采纳麻利，毕竟这才是我拿手的，和客户那边也沟通过，他们也不拥护尝试。而且我的项目的自主开发局部是用 Java 写的，有肯定的 JUnit 测试笼罩和继续集成（CI）根底。然而因为我始终没有想好这个我的项目能够如何拆分进而迭代，所以我的项目的麻利转型始终被搁置，其理论开发过程仍然是瀑布形式，也遭逢了所有瀑布形式会遇到的问题。
（传统需要难以描述用户的实在想法，传统瀑布开发没有疾速反馈机制）
瀑布不行，向麻利转型曾经是共识，然而具体怎么做呢？通过对我的项目 X 的复盘以及对其余我的项目的思考，以下是我的一些心得。
把我的项目拆分成用户故事才是硬本事
我也算是个“老麻利”，但像后面说的，在面对一个具体我的项目，不会把我的项目拆分成用户故事，就无奈麻利起来！真正的麻利开发必须是基于用户故事的开发过程。
所谓用户故事就是含有肯定业务价值的端到端交付。瀑布开发是把我的项目依照不同生命周期阶段横向拆分的过程。而麻利开发是把我的项目或产品或业务指标竖向拆分成若干可体验、可交付的用户故事的过程。一个用户故事，应该是用一两个月甚至几个星期或更短时间就能做进去的货色，咱们能够通过它更早地获取用户反馈，从而确定产品的正确性。这也合乎麻利提倡的“小步推动，频繁验证”的准则，是升高项目风险最无效的办法。
（瀑布和麻利的不同拆分过程）
只有基于用户故事开发能力疾速交付和继续交付
正如后面所说，咱们用一两个月甚至几个星期把第一个用户故事做进去并给用户体验和反馈，而不是大半年甚至一两年后在我的项目前期才把产品给用户体验，咱们更早、更快地交付并获取反馈，而一直反复这样的过程，就是继续交付的过程。在整个过程中，咱们都在交付业务价值，而不是战战兢兢地拿着一堆半成品面对那个死亡日期的迫近。
我的项目 X 最终出现给用户的是不同类型的基金报表，其实每一类报表就是一个用户故事。如果咱们一开始就以最重要的一类报表，作为首个用户故事进行开发，只须要两、三个月的工夫，咱们就能够把这个用户故事实现并交付给客户进行测试和反馈，有任何的反馈咱们都能够及时进行修改。失去客户认可后，咱们就能够如法实现其余报表。更重要的是，从第一个用户故事，也就是最早可测试产品取得的用户反馈将确保其余用户故事的开发也在正确的方向上。而在瀑布形式下，两个月后咱们才刚刚收到需要文档，什么开发都没有开始。
（尽早定义和交付最早可测试产品可及时获取用户反馈，确保产品正确）
因而，定义好用户故事是施行麻利的根底，没有这个根底，其余麻利实际的施行其实只是部分改善，仍然是战术上的改进，而不是策略上的扭转，久远来看，收效无限并容易倒退。麻利开发是一个有机体系，各种具体的方法论和实际须要打组合拳能力施展出其应有的效劳，基于用户故事开发是所有的根底：
- 如果不是基于用户故事开发，简略地把我的项目的长周期拆分成短周期并不是真正的迭代，因为每个周期都没有可体验、可交付的货色，仍然像瀑布一样在一直沉积半成品，这也不是真的 Scrum；
- 如果不是基于用户故事开发，测试驱动开发（TDD）和行为驱动开发（BDD）很难发展，因为不足具体用户场景的形容，很难写出具体、扼要的测试用例，因此很难累积足够的自动化测试进步零碎的可改性，外部品质、重构、继续优化便无从谈起；
- 如果不是基于用户故事开发，继续集成（CI）也意义不大，因为提交的代码并没有形成可交付的产品，其实并没有真的在集成。
既然用户故事是麻利开发的重中之重，那么如何定义好用户故事呢？诚然，这是麻利转型的难点。业界无关具体定义用户故事的说法并不多，这也是为什么用户故事始终被忽视，因为还没有标准答案，大家无从下手。《用户故事地图》是为数不多的较具体地论述用户故事定义方法的书籍。所谓用户故事地图就是从左至右按工夫程序列举用户行为（也就是流程的每一步），在每个用户行为下从上至下列举相应的细节，包含所须要的开发点，形成一个二维的“地图”。基于这个地图，还能够对每个开发点的业务价值进行扫视，找出最小可用产品（MVP）并制订公布打算。然而间接从整个我的项目或产品动手编制用户故事地图其实十分艰难。
（《用户故事地图》是为数不多的较具体地论述用户故事定义方法的书籍）
具体用户场景 + 用户故事地图则是我认为比拟可行的办法
所谓具体用户场景，就是构想一个用户在应用某个性能的具体过程。比方咱们应用共享单车，具体的场景是用户找到一辆单车、用手机扫码和开锁、骑行、达到指标地、锁车、领取费用。这个场景的每一步，依照工夫程序从左到右列举进去，而后再合成每一步所须要的零碎或模块，在每个零碎或模块下从上到下列举所须要的细节，包含所须要开发点，便造成一个用户故事地图。如果这个场景依赖于其余场景，比方注册，那么就构想注册的场景及其用户故事地图。如果注册就是所有其余场景的前置条件，就优先开发它。
（场景 + 地图是一对好基友）
再举一个传统金融我的项目的例子。比方银行开户，其中一个典型场景就是具体某类客户通过某个渠道开某类账户的过程。在这个例子里，能够设想它会有很多个不同的场景，而每个场景都是一个交付。有了一个具体场景，咱们就能够剖析要实现这个场景，背地须要哪些零碎来撑持，每个零碎须要开发什么，造成一个用户故事地图。
当然，以开户为例，开发首选场景的过程会绝对较长，因为软件从无到有有打地基的过程，业务实现也须要各个系统的兼顾配合，但它并没有看起来那么艰难和漫长，因为：
- 因为一个具体场景绝对于整个我的项目要简略得多，相比传统形式下各个系统各顾各围绕所有性能进行开发，开发内容绝对简略很多，集成的难度也绝对低；
- 首选场景的开发其实为其余开户场景打下了大量根底，其余场景的开发会绝对快和容易很多，交付会减速；
- 能够采纳微服务架构、云服务、容器和像 Spring Boot 这样的疾速开发框架在技术上大大缩短了从搭地基到业务逻辑开发的前置工夫。
我的项目 X 中，开发第一个用户故事的确会是开发周期最长的一个用户故事，然而因为它为其余用户故事打下了大量根底，它们的开发会大量重用第一个用户故事的代码，开发与交付会大大放慢。
基于场景更易了解和测试
因为场景具体和绝对简单明了，不像传统需要的性能形容那么形象和割裂，它更容易解释、了解和测试，也是测试驱动开发（TDD）和行为驱动开发（BDD）的根底。
基于场景思考用户体验
构想场景也是思考用户体验的过程，后面提到的更早和频繁获取的用户反馈也蕴含用户体验。
用户体验并不是互联网产品的专有名词，在传统的业务开发中，用户体验等同重要，只是它始终在瀑布开发中被忽视。
在我的项目 X 前期，离原定交付日期只有一个月了，客户提出在测试过程中发现，因为一个申请须要在不同零碎中解决，很难追踪，倡议减少一个对立的申请 ID 作为辨认。这时咱们有两个选项：
- 咱们的指标是依照打算把原定的所有报表按时交付，因而这是新的需要或需要变更，不应该在这个时候思考；
- 咱们的指标是实现业务价值，客户在测试中发现的这个问题在上线后必然会被有限放大，不解决这个问题，用户体验和可用性极差，咱们应该优先解决这个问题。因为工夫无限，咱们要和客户沟通是否先集中精力测试某类报表，确保操作的用户体验和可用性，把一个月后的公布指标改为先上线这类报表，实现局部业务价值，其余报表在这次公布后再测试和上线。
前者是瀑布的思维，后者是麻利的思维。而依照瀑布思维交付，就像咱们新装修完一间会议室，电视机、视频会议主机、电话都有，每个设施独自都能通电开启，然而电视机不能连贯视频会议主机进行视频会议，也不能连贯电脑进行演示，电话也没有设置好不能进行通话，也就是所有设施对用户来说其实都是不可用的。这样的交付有何意义？这几个需要哪怕只有一个能被满足，都比当初这种状况要好。
其实每个我的项目的需要或产品的设计，都是由一个个具体的场景形成的
如果咱们和客户能从一开始就以场景作为切入点，咱们的眼里就不再是一个个孤立的性能，而是一个个有具体业务价值、可交付的用户故事，开发的过程便是这一个个业务价值的继续交付过程，这也是一个产品长期演进的过程，我的项目只是产品演进的一个个小插曲，软件开发中最不可控的因素——工夫对于客户来说也变得不那么敏感。在此基础上，再联合其余麻利方法论和实际，精益求精。
总 结
传统瀑布开发是半成品沉积而且不足疾速反馈的过程，传统需要只思考性能而不思考场景和用户体验。麻利开发是基于用户故事的业务价值的继续交付过程。把我的项目拆分成用户故事是施行麻利的根底。具体用户场景 + 用户故事地图是定义好用户故事的一个具体方法。
作者：肯尼兹▪刘
晚期麻利践行者
起步于极限编程
相熟极限编程、Scrum、看板办法、测试驱动开发、继续集成、行为驱动开发
【IDCF 共创读书会】第 2 期汇报在【冬哥有话说】收费直播，关注公众号回复“共读”获取地址
- 12 月 9 日（周四）晚 8 点，共读《继续交付 2.0》