2020-01-07一定要早点把客户拉下水。让客户早点确认各种细节。这样就不会后期唧唧歪歪了。作者回复: 赞一个
3 23
2020-01-07敏捷方法使用过，虽然效率有提升，开发理解需求有极大改善，但也做了测试驱动，尽管代价不小，发现有些产品交付质量差，经分析，主要是人员水平造成的，应该是敏捷相比瀑布开发对人员的要求多和高，但现实人员更换受限的情况下，如何提升?或者是我上述的归因有偏差，那问题可能出在哪里，针对这些，有啥应对原则?作者回复: 这是个好问题，关于人员培养的问题是个永恒的话题。这里面涉及2个方面，一个是态度转变，一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感，参与到转型过程中，如后面05会有一些方法，让员工进到我们的转型过程，有参与感，同时也要意识到自己的能力需要提升，这样很多员工都有提升的动力；第二个问题，能力提升的问题方法也非常多，可以组织拆书会等等快速地了解一个领域的知识，也可以互相之间分享，老带新，反讲，建立辅导机制，能力高的辅导能力低的等等，非常多的方法，只要人发动起来，方法总能找得到。最后记住一点是，人毕生都是在发展的，减少对人的刻板印象，鼓励发动他动起来学起来跟上来，这个很重要。
2 15
2020-01-07一直想尝试，但是总是事与愿违。说到底还是需要公司高层的支持和底层人员的不断尝试才行。 6
2020-01-07特点：快速响应变化，允许试错，小步快跑。
做法:固定小团队，优先级的需求池，客户参入，实时验收。 5
2020-01-07利用敏捷的方法缩短项目开发时间是我们一直努力的方向，公司在高速成长，产品迭代必须紧跟业务发展，常常遇到的情况是业务部门临时的排版需求上线时间。
在实现过程中，产品经理会在同业务确定需求完成后的第一时间组织立项会议，UI，开发，测试共同参与，进行需求宣导。
接下来，
产品团队的方案设计，UI团队的界面交互设计，开发团队的技术实现拆分，测试团队的测试用例会同步并行开展。如果遇到需要外部协作，也是先沟通确定合作方案，然后各自开发最终联调，将等待时间不断的压缩，缩短项目开发周期 1 4
2020-01-07我对于，“敏捷确实好，但是推进不容易”这个说法深表认同。如果真的落实敏捷，对于研发人员的要求还是比较高的，对于每个开发的工作会有定性和定量的尺度，上班摸鱼就没那么方便了；对于组织架构来说，可能也需要进行一定的调整，比如作者说的划分小团队，但是更主要的可能还是思想上的变革。
其实如果能够照着一成不变的需求文档或者详细设计来写代码，对于开发人员来说是相对简单的，但是往往做出来的东西，并不是用户真正想要的。
不过从另一方面，如果是类似于火箭发射或者是精密仪器之类的软硬件研发，还是瀑布模式更合适，主要是因为这一类项目的需求规格相对比较稳定。
还有一点，个人感觉其实小团队更容易实行敏捷，主要是比较容易形成共识。
但是现在似乎把敏捷的范围扩展了，只要采用了一部分敏捷的方法，就可以定义为敏捷。
在体制内单位，其中也有项目的外包方采用了迭代开发、滚动上线的方式，也可以说“敏捷”起来了。但是，没有单元测试、配置管理、持续继承、版本控制……这样也可以算是敏捷么？展开作者回复: 现实中没有完美的敏捷模式，虽然这是我们一直追求的目标，但大家都走在路上，推进敏捷的方式有激进式的“貌似一步到位”，但其实后面也有很多工作，另一种渐进式的则是解决一个旧问题出现一个新问题，其实一直在做持续改进，有的企业先做了“形式”上的敏捷，后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发
2 4
2020-01-07老师，请教几个问题：
1.团队拆分为特性小组的标准是什么？多少人为一组为最佳呢？
2.使用敏捷模式，开发前期的接口文档要不要省略呢？
3.业务参与需求分析，是不是就是确定原型图的过程？作者回复: 第一个问题，我们在04里有一些关于组织的说明，特性团队拆分在敏捷里如上面朋友所说，确实没有固定的死的标准，但有些原则可供你参考。一个是团队大小，是5-9个人，大了要进行拆分；第二个是全功能团队。
第二个问题，文档的留与否，需要根据实际情况来做剪裁，在剪裁前，评估文档为产品开发带来的价值大小和实际工作量，一般而言不建议省略接口文档，接口文档是开发中的重要文档，但如果团队找到了更好的工作方法替代这个文档除外。 4 3
2020-01-07第一步组建特性团队就是一个难题，这是一个思维方式的转变，改变了开发团队原有的开发习惯和思维惯性。宋老师是如何说服团队做这样的转变的呢？作者回复: 思维方式转变确实是比较难的，仅靠口头说服是远远不够的，所以除了宣讲以外，我采取的方式有很多：带他们参观已经转型的团队，有一些感性认识；必要的时候带他们打个胜仗，团队在不同阶段需要的辅助也是不同的，还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。
1 2- 2020-01-07什么是敏捷思维？要解决什么问题？首先要回答好这个问题，否则，不存在所谓的灵魂拷问。 2
2020-01-07不管是瀑布还是敏捷，对于人员的要求都是有的，只不过敏捷因为是快速迭代的，要求会更高。N年前接触敏捷，今天看完这篇发现现在的项目已经是敏捷式的开发了。现在大家都对MVP、迭代这些习以为常了。 2
2020-02-07讲得很好，还有其他课程吗 1- 2020-02-04瀑布开发干的是一锤子买卖。敏捷开发中的小步快跑，持续迭代，也反映了通过主动降低信息获取门槛，让项目内的信息公开透明。包括项目组内部产品/开发/测试人员，也包括外部的客户，都能时时获取到项目的最新状态，产生被尊重的感觉，参与的感觉，产生同理心，进一步可以不断给出反馈，形成良性循环 1
2020-01-15怎么跟精益创业提到的：开发-测量-认知循环这么相似 1
2020-01-131. 研发过程中遇到的难题
1. 团队有在跑scrum，但是感觉成员态度比较随意，并且容易乐观估计时间点
2. 需求和顶层设计，有时候会面临调整，导致大范围改动，成员抵触情绪比较大，应该如何解决呢？
3.团队沟通不够充分，随着迭代次数变多，对系统模型、设计、实现的认识不太对齐
2. 使用敏捷方法或借鉴敏捷思想的经历
1. 先把主流程跑通，再优化
2. 不要有太多的流程和条条框框，快速迭代，快速试错
3.项目分解成几期，每期完成阶段性目标，找不同的业务团队来试用展开 1 1
2020-01-13作为研发人员，宋老师列举的案例是真的感同身受。当时团队没有任何规范的研发流程，并且没有测试。按照瀑布模式，做出来的东西很自然遭到客户投诉。
后面复盘以及处理各个环节如需求挖掘，沟通力度，用人方向等所暴露问题。
而为了整顿就引入了敏捷开发的概念，各个环节的问题都没有妥善解决，最后整个系统虽然还是上线了，但时不时会就遭到客户不同岗位角色对于某一功能缺陷提了好几个月都没解决好的投诉。 1
2020-01-12您好，我遇到的问题是：
1.我们采用原型跟用户迭代确认，也形成需求确认书签字确认。但是在具体测试过程中，用户实际使用后，又有新的想法或者原先就考虑完整的，这时也只能继续进行迭代修改。
2.如果存在多个模块处于第1个问题时，因为交付模块一直迭代调整中，导致其他任务无法继续执行。由于成员有限，一个人负责多个模块，就会导致项目工期延期。
所以在后面的项目中为了避免出行这种问题，我们只能回到“原型+瀑布”模式，等到开发结束，再集中精力修改，但是这种模式存在的问题也显而易见。一直没有好的解决方案。
如果迭代一直停留在几个模块，导致其他模块无法执行时，有什么好的解决方案吗？展开作者回复: 第一个迭代结束，客户有反馈是可以的也是正常的，关键在于我们接受了反馈后的处理方式。一般我们是把新的反馈加到我们的需求列表中，并按优先级进行排列，下一个迭代继续从需求列表中选取优先级高的继续开发。这样不是所有的反馈都在下一个迭代中满足，就可以防止您的开发一直停留在几个需求上。要管理好需求列表
1 1
2020-01-10devops和敏捷的区别是啥、听说devops是敏捷2.0 1 1
2020-01-09有点多线程同步的感觉 1
2020-01-09老师您好，能说一下敏捷和迭代的关系或不同吗？作者回复: 以前有一个迭代式研发，这种一般是迭代周期不一定固定，只要产品有迭代就可以叫迭代式研发了；而敏捷涵盖的内容比它广。
1 1
2020-01-08老板常在嘴边说的一句话，要先把系统做出来，能卖，回头再来修改和优化，在我看来，这就是一个敏捷的例子，只是时间长了，产品变成了一个巨复杂的系统，再加上文档不全，开发和业务人员的离职，造成现在每修改一个逻辑要从头到尾读一遍逻辑，很痛苦，现在公司风雨飘摇，也不可能把产品再重新开发一遍，请问补文档和代码持续部分重构可以慢慢改变这个现状吗？还有什么办法可以改变这种情况？望指教！作者回复: 这是个超级痛苦的问题，也有挺多公司遇到，无论是大公司还是初创公司都有遇到，即便是使用瀑布模型要求写了大量的文档也存在这个问题，原因是文档经常是不时时更新的，很多后期接手的人员非常痛苦，基本都要扒一遍代码。我没有特别好的灵丹妙药，只能告诉团队：这不是敏捷本身带来的问题，但从实际出发有几个问题我们需要来检视一下：第一个，研发过程一定要留有必要的知识库和重要的文档；如果开始开发的时候没有留，后来人来梳理的时候要把梳理成果留下，必要的时候需要补充文件。第二个，巨复杂的系统需要重构，里面的许多逻辑估计已经臃肿不堪了，需要重新梳理。
1