2020-01-13做个一个项目，将小瀑布方式当做敏捷来看待，造成这个状况原因有二：第一，对敏捷的理解不到位，当时认为需求、设计、开发、测试还是要顺序进行，虽然这些工作是顺序的，但是开展工作时要做到能同步开展工作，这个对团队人员的要求还是蛮高的。 第二，工作能力与工作量不匹配。当时工作量很大，但工期比较短，以当时的人员配比是无法完成的。虽然当时也安排了优先级，不过是按照功能进行拆解的，没有考虑有些业务场景是需要几个功能同时具备才能走通，而实际是各自小组按照自己负责功能模块划分优先级，没有从用户角度考虑某些使用场景需要多个功能关联推进。 6
2020-01-07如何拆分用户故事是敏捷开发一个很关键的部分，而评估是否是一个好的用户故事标准就是能否独立进行上线，如果做不到独立上线，那这个还不叫用户故事，测试也没办法并行进行，也不是真正的敏捷开发。另外敏捷开发跟现在到微服务架构是相辅相成，敏捷开发非常适合微服务这种开发模式，微服务能够提高敏捷开发的效率。总之，敏捷开发的精髓应该是团队至上，小步快跑，快速迭代，拥抱变化。不知道对于敏捷开发这样的理解有没有问题，请老师点评一下。作者回复: 赞一个！优秀用户故事的标准业界有通用的认识，公认的是符合INVEST原则。在《用户故事与敏捷方法》一书中有介绍，可以去看一下。
4
2020-01-15说透敏捷
08 | 避雷策略：如何防止你的敏捷变为“小瀑布”？
上一篇是避坑指南，这一次是防雷策略，看来推进敏捷还真是不容易。
其实我们单位现在的一个外包团队就是在采用小瀑布的方式在开发。首先，是因为这个项目本身就是一个比较长期的工程，针对的是在线系统的升级改造。以前采用的是瀑布开发方式，后来因为项目本身的发展，同时也因为瀑布的确出现了很多问题，所以改成了现在的迭代瀑布，其实已经算是一种进步了。
外包单位本身也是国有研究院所，这种迭代小瀑布的方式在他们那边也不被认可，因为软件系统要有“出所”的测试和评审，所以现在的迭代也只能低调进行。这个可能与合同签订的时候的约束条件有关，也可能与原有的外包团队的制度有关。
感觉虽然不是地道的敏捷，但是其实也还是有一定的益处，并且并没有过多造成工时的积压和浪费，可能那些需求分析人员以及测试人员都身兼数个项目。缺点当然也很明显，因为身兼多个项目，所以带来了投入时间的不充分。
之所以现在是小瀑布模式，首先是因为外包团队并没有准备敏捷转型，另外就是需求也没有被分解成可以在很短的迭代周期内完成，最后，我认为比较重要的原因，就是现有系统的架构，并不支持持续集成和连续发布。
把大需求拆分成能够独立开发测试的小需求，这个是否对于架构有很高的要求？我觉的似乎只有目前流行的“微服务”能够做到，但是微服务那边，本身也是一堆的坑要填。
文章中提到的那个 N 团队，在开发测试之余，还对产品进行了架构演化，拆分微服务，这个还真是厉害。展开 2
2020-01-14记得第一次真正开展敏捷实践，照搬Scrum全流程，结果被大家强力吐槽😂 1
2020-02-10我想请问一下敏捷的完整项目流程是什么？
2020-02-08做敏捷最关键的还是搞定高层领导团队，让领导团队理解认识、跟踪推动，这是一切的基础，否则组织和资源会是问题，阻力会非常大。然后就是挑选意愿和整体素质相对较高的团队，我觉得这个也是推行实践相对会顺利的重要因素。
2020-02-07有MCP的思想在就不会跑太偏，提供最小的最有价值的功能迭代，即使是小瀑布也挺好。瀑布的不一定就不好，只要做到小步快跑，做正确的最有价值的事就好
2020-02-07N团队是如何拆分需求保证需求开发测试独立性的，宋老师可以展开讲一下嘛
2020-02-07我在游戏行业，目前实行的就是2周迭代的方式，两周内安排是：
需求理解->设计->开发->测试->上线
要点：
1. 迭代开始时，需求是已经准备好的，准确来说是个需求池，最好能列好优先级
2.迭代开始时，开发测试从池子里挑选两周迭代能搞定的需求，同时考虑时间和需求优先级
3.切忌不要犯承若过多的错误
刚刚试运行时磕磕绊绊，经历多个迭代和回顾会议之后，目前开始正常运转，
个人觉得互联网行业唯快不破的节奏下很难存在瀑布开发模式，大部分都是各式各样的敏捷模式，
而敏捷的核心是让业务，开发，测试全链条热火朝天运转起来，如果能做到这个其实架子应该没有问题，
剩下就是利用回顾会议针对性的解决问题了。展开
2020-02-05我还没上过敏捷，不过今天的课有点启发：
把大需求拆分成独立的小需求，减少模块之间的耦合。
2020-01-30所以从这个角度来说，小瀑布依旧是瀑布，它并没有改变瀑布模式的宿命，它离真正的敏捷还有相当长的一段距离。
如何界定小瀑布与敏捷呢？从结果导向上来看，看你的需求拆分粒度，看你的测试人员在开发人员开发时，在干什么。
2020-01-28需求的细化和排期不单单是个流程化的东西，还得考虑一些团队情绪，因为即使开发提交测试以后继续下一个小需求开发，这个本身需要有个度，开发不是机械劳动，代码写之前需要充分思考，但在此期间如果总是因为配合测试而打断，也会很心累，所以这中间需要一个缓冲地带，就好比人与人之间的安全距离。可以看出敏捷的迭代频率快，对开发本身技能要求高，所以完全推进的话，对大部分企业还是有不小困难！
2020-01-181，我已前开发过一个ITLE产品，必须包括五个模块才能叫ITLE产品，由于市场压力老板一定要我们五个月完成，但时间的确不够，若用敏捷，该如何处理。2，DevOps中持续部署流。需求-设计-开发-构建－集成测试-发布-验收测试-部署-预生产环境测试-正式生产，这个是不是也是个小瀑布？作者回复: 1、挑能够完成的最小可行性产品MVP进行开发
2、这个不是小瀑布
2020-01-18一个2周的迭代，需求澄清应该在上个迭代，需求 和开发测试异步在上下2个迭代更合适，否则一个迭代内，一周的需求澄清加一周的开发测试都很累，产品质量还不好，特别是测试的时间因为需求和开发被消耗的时间都需要测试消化掉，测试就容易不充分，不充分意味着，上线风险大，只能菩萨保佑了- 2020-01-11敏捷和微服务有点天生就是好兄弟的感觉。说起这个小瀑布，就像那个系统拆分做成了一个一个小单体。
- 2020-01-11老师好，针对老师的这句话“我们工作的结束点不应该是把之前所有计划的工作做完，而是把客户需要的工作做完。”，在实施固定总价合同的客户项目时，如何比较好的控制项目的范围和成本呢？有时候客户和我们在项目初期都没有办法完全界定清楚，什么是客户需要的工作？
作者回复: 这里要管理好客户期望。始终要对客户灌输价值理念，让他自己挑选价值最大的需求，以及向其可视化你们的工作，让他理解到在有限的时间内，有限的资源不能完成所有的事情，但我们能保证的是在给定的资源和时间内给他最好的。
另外就是要让客户真正理解敏捷的概念，否则就变成对团队的压榨了。客户首先要能区分清楚他们的需求中哪些是价值大的要优先做的，其次是在每个迭代中要给开发团队反馈，让团队知道哪些已经做的可以了，哪些产品还需要优化。
再者一定要管理好需求列表。 
2020-01-10很难相信居然还有小瀑布这样的团队，游戏行业策划还能闲着等下一个迭代，早被喷死了。 1
2020-01-09老师说的大瀑布中小敏捷的累，我们正在踩。
我们公司内部的工具开发，面向开发做小工具，可能是开发提的需求一般都比较明确，所以效率并没感觉降低。老师说导入敏捷要先找到组织当前的痛点，如果现在并没有觉得“痛”，怎么办呢？作者回复: 一般都是有痛点的，很多时候是大家已经习以为常了，都感觉不到“痛”了。所以这里有两个问题，一个是确实目前研发管理方式不错，感觉各个方面没有任何痛点，这样保持现有方式即可；还有一个是有痛却没感到痛，这个是比较麻烦的，需要让团队感知到，一个是通过提问的技巧引发思考，还有一些就是请外部的“咨询师”来说出来。
- 2020-01-09我们是创业公司，主要工作就是主业务的日常迭代，都不是很大的需求。正常开发也是一周左右可以上线。任务故事根本无需拆分，这样怎么去实施敏捷呢？
作者回复: 主要看你们目前的研发工作组织方式有无痛点。如果一切运行OK，那么不需要做什么改变，如果现在感觉管理上有些混乱，那么可以找找原因，然后来具体应对。如果要选择实施敏捷，可以从一些小点开始，例如先把所有的工作用看板管理起来，开个站会，定期进行回顾来改进工作等等
- 2020-01-07在实际工作中，因为涉及外部团队的配合，所以需求拆分可以按照内部测试单元和外部测试单元进行分类，从而更好的评估外部依赖性，规避项目风险。