01 | 灵魂拷问：如何利用敏捷思维更好地解决实际问题？
请订阅文章所属专栏。
精选留言(39)
丁丁历险记一定要早点把客户拉下水。让客户早点确认各种细节。这样就不会后期唧唧歪歪了。作者回复: 赞一个
2020-01-07 2 19
李永智敏捷方法使用过，虽然效率有提升，开发理解需求有极大改善，但也做了测试驱动，尽管代价不小，发现有些产品交付质量差，经分析，主要是人员水平造成的，应该是敏捷相比瀑布开发对人员的要求多和高，但现实人员更换受限的情况下，如何提升?或者是我上述的归因有偏差，那问题可能出在哪里，针对这些，有啥应对原则?作者回复: 这是个好问题，关于人员培养的问题是个永恒的话题。这里面涉及2个方面，一个是态度转变，一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感，参与到转型过程中，如后面05会有一些方法，让员工进到我们的转型过程，有参与感，同时也要意识到自己的能力需要提升，这样很多员工都有提升的动力；第二个问题，能力提升的问题方法也非常多，可以组织拆书会等等快速地了解一个领域的知识，也可以互相之间分享，老带新，反讲，建立辅导机制，能力高的辅导能力低的等等，非常多的方法，只要人发动起来，方法总能找得到。最后记住一点是，人毕生都是在发展的，减少对人的刻板印象，鼓励发动他动起来学起来跟上来，这个很重要。
2020-01-07 2 11
qinhua-冰糖橙自产自销特点：快速响应变化，允许试错，小步快跑。
做法:固定小团队，优先级的需求池，客户参入，实时验收。2020-01-07 5
阡陌一直想尝试，但是总是事与愿违。说到底还是需要公司高层的支持和底层人员的不断尝试才行。2020-01-07 5- 吴言乱语利用敏捷的方法缩短项目开发时间是我们一直努力的方向，公司在高速成长，产品迭代必须紧跟业务发展，常常遇到的情况是业务部门临时的排版需求上线时间。
在实现过程中，产品经理会在同业务确定需求完成后的第一时间组织立项会议，UI，开发，测试共同参与，进行需求宣导。
接下来，
产品团队的方案设计，UI团队的界面交互设计，开发团队的技术实现拆分，测试团队的测试用例会同步并行开展。如果遇到需要外部协作，也是先沟通确定合作方案，然后各自开发最终联调，将等待时间不断的压缩，缩短项目开发周期2020-01-07 3 
王刚老师，请教几个问题：
1.团队拆分为特性小组的标准是什么？多少人为一组为最佳呢？
2.使用敏捷模式，开发前期的接口文档要不要省略呢？
3.业务参与需求分析，是不是就是确定原型图的过程？作者回复: 第一个问题，我们在04里有一些关于组织的说明，特性团队拆分在敏捷里如上面朋友所说，确实没有固定的死的标准，但有些原则可供你参考。一个是团队大小，是5-9个人，大了要进行拆分；第二个是全功能团队。
第二个问题，文档的留与否，需要根据实际情况来做剪裁，在剪裁前，评估文档为产品开发带来的价值大小和实际工作量，一般而言不建议省略接口文档，接口文档是开发中的重要文档，但如果团队找到了更好的工作方法替代这个文档除外。2020-01-07 4 3
桃子-夏勇杰第一步组建特性团队就是一个难题，这是一个思维方式的转变，改变了开发团队原有的开发习惯和思维惯性。宋老师是如何说服团队做这样的转变的呢？作者回复: 思维方式转变确实是比较难的，仅靠口头说服是远远不够的，所以除了宣讲以外，我采取的方式有很多：带他们参观已经转型的团队，有一些感性认识；必要的时候带他们打个胜仗，团队在不同阶段需要的辅助也是不同的，还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。
2020-01-07 1 2
escray我对于，“敏捷确实好，但是推进不容易”这个说法深表认同。如果真的落实敏捷，对于研发人员的要求还是比较高的，对于每个开发的工作会有定性和定量的尺度，上班摸鱼就没那么方便了；对于组织架构来说，可能也需要进行一定的调整，比如作者说的划分小团队，但是更主要的可能还是思想上的变革。
其实如果能够照着一成不变的需求文档或者详细设计来写代码，对于开发人员来说是相对简单的，但是往往做出来的东西，并不是用户真正想要的。
不过从另一方面，如果是类似于火箭发射或者是精密仪器之类的软硬件研发，还是瀑布模式更合适，主要是因为这一类项目的需求规格相对比较稳定。
还有一点，个人感觉其实小团队更容易实行敏捷，主要是比较容易形成共识。
但是现在似乎把敏捷的范围扩展了，只要采用了一部分敏捷的方法，就可以定义为敏捷。
在体制内单位，其中也有项目的外包方采用了迭代开发、滚动上线的方式，也可以说“敏捷”起来了。但是，没有单元测试、配置管理、持续继承、版本控制……这样也可以算是敏捷么？作者回复: 现实中没有完美的敏捷模式，虽然这是我们一直追求的目标，但大家都走在路上，推进敏捷的方式有激进式的“貌似一步到位”，但其实后面也有很多工作，另一种渐进式的则是解决一个旧问题出现一个新问题，其实一直在做持续改进，有的企业先做了“形式”上的敏捷，后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发
2020-01-07 2 2
solaris1. 研发过程中遇到的难题
1. 团队有在跑scrum，但是感觉成员态度比较随意，并且容易乐观估计时间点
2. 需求和顶层设计，有时候会面临调整，导致大范围改动，成员抵触情绪比较大，应该如何解决呢？
3.团队沟通不够充分，随着迭代次数变多，对系统模型、设计、实现的认识不太对齐
2. 使用敏捷方法或借鉴敏捷思想的经历
1. 先把主流程跑通，再优化
2. 不要有太多的流程和条条框框，快速迭代，快速试错
3.项目分解成几期，每期完成阶段性目标，找不同的业务团队来试用2020-01-13 1 1
J作为研发人员，宋老师列举的案例是真的感同身受。当时团队没有任何规范的研发流程，并且没有测试。按照瀑布模式，做出来的东西很自然遭到客户投诉。
后面复盘以及处理各个环节如需求挖掘，沟通力度，用人方向等所暴露问题。
而为了整顿就引入了敏捷开发的概念，各个环节的问题都没有妥善解决，最后整个系统虽然还是上线了，但时不时会就遭到客户不同岗位角色对于某一功能缺陷提了好几个月都没解决好的投诉。2020-01-13 1
jefferydevops和敏捷的区别是啥、听说devops是敏捷2.02020-01-10 1 1
原点有点多线程同步的感觉2020-01-09 1
海棠特性团队对于团队成员的要求其实是非常高的，自己的公司也是FT制，但距离理想的FT状态还差很远，感觉更像是组件团队与特性团队的中间态。所以，不仅推行敏捷难，转型特性团队也很难，在推行FT化的过程中，有什么心得吗？作者回复: 首先是组织设计问题，其次是人员培养问题和带团队的问题，我们后面有涉及，细看一下咱们专栏的实战篇
2020-01-07 1- 桃子-夏勇杰什么是敏捷思维？要解决什么问题？首先要回答好这个问题，否则，不存在所谓的灵魂拷问。2020-01-07 1
再不吃胖我们就老了不管是瀑布还是敏捷，对于人员的要求都是有的，只不过敏捷因为是快速迭代的，要求会更高。N年前接触敏捷，今天看完这篇发现现在的项目已经是敏捷式的开发了。现在大家都对MVP、迭代这些习以为常了。2020-01-07 1
Mark组建一个个小的特性团队的优势再具体描述一下吧作者回复: 所谓船小好调头，每个小团队的协作效率更高一些，而且当我们把需求拆下以后，对应这样的小特性团队会让整个开发过程更加的灵活。
04有讲具体怎么做。2020-01-18- Geek_wei哪些项目适合敏捷，哪些项目不适合呢？比如一些大型系统的系统架构环节是否适合敏捷呢？2020-01-18
镜花水月宋老师，我有两个问题希望得到解答。
1.没有做过开发的人能胜任敏捷教练吗？
2.来到现在的团队时已经引入了敏捷，一个团队如何转型敏捷并没有亲自参与实践的经验，感觉不是通过看书能够获得实际经验的，这个怎么办。作者回复: 1. 可以的，只要能够跟开发兄弟沟通，能够听懂他们的语言。
2.虽然团队已经引入了敏捷，但是一般而言，引入以后一般不能一步到位，团队还需要慢慢带领和培养，可以在后面的工作中慢慢体会和参与引导，从引导团队对话中慢慢地体会敏捷。2020-01-17
Binds.Chen让客户参与进来经常碰到的问题是他一开始只想要一碗羊肉面，做着做着想法就变了，最后就变成要满汉全席了。这个改如何解决呢？毕竟项目的时间和经济成本不会因为客户的想法深化而追加。作者回复: 这涉及一个客户期望管理的问题。始终要对客户灌输价值理念，让他自己挑选价值最大的需求，以及向其可视化你们的工作，让他理解到在有限的时间内，有限的资源不能完成所有的事情，但我们能保证的是在给定的资源和时间内给他最好的。
2020-01-16
海子老师你好，今天刚和同事再聊起敏捷，我们在对敏捷过程中的文档输出这块有一些争议，我认为无论采用瀑布或敏捷方式都应该有完备的技术文档输出但是对方说敏捷不需要太在意文档输出，针对这块您有什么想法？如果需要输出，文档本身会不会影响敏捷的效能？作者回复: 这一块内容我们在02有讲到，继续往后看哈：-）
2020-01-15