01 | 灵魂拷问：如何利用敏捷思维更好地解决实际问题？

作者回复: 赞一个

作者回复: 这是个好问题，关于人员培养的问题是个永恒的话题。这里面涉及2个方面，一个是态度转变，一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感，参与到转型过程中，如后面05会有一些方法，让员工进到我们的转型过程，有参与感，同时也要意识到自己的能力需要提升，这样很多员工都有提升的动力；第二个问题，能力提升的问题方法也非常多，可以组织拆书会等等快速地了解一个领域的知识，也可以互相之间分享，老带新，反讲，建立辅导机制，能力高的辅导能力低的等等，非常多的方法，只要人发动起来，方法总能找得到。最后记住一点是，人毕生都是在发展的，减少对人的刻板印象，鼓励发动他动起来学起来跟上来，这个很重要。

作者回复: 现实中没有完美的敏捷模式，虽然这是我们一直追求的目标，但大家都走在路上，推进敏捷的方式有激进式的“貌似一步到位”，但其实后面也有很多工作，另一种渐进式的则是解决一个旧问题出现一个新问题，其实一直在做持续改进，有的企业先做了“形式”上的敏捷，后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发

作者回复: 第一个迭代结束，客户有反馈是可以的也是正常的，关键在于我们接受了反馈后的处理方式。一般我们是把新的反馈加到我们的需求列表中，并按优先级进行排列，下一个迭代继续从需求列表中选取优先级高的继续开发。这样不是所有的反馈都在下一个迭代中满足，就可以防止您的开发一直停留在几个需求上。要管理好需求列表

作者回复: 第一个问题，我们在04里有一些关于组织的说明，特性团队拆分在敏捷里如上面朋友所说，确实没有固定的死的标准，但有些原则可供你参考。一个是团队大小，是5-9个人，大了要进行拆分；第二个是全功能团队。 第二个问题，文档的留与否，需要根据实际情况来做剪裁，在剪裁前，评估文档为产品开发带来的价值大小和实际工作量，一般而言不建议省略接口文档，接口文档是开发中的重要文档，但如果团队找到了更好的工作方法替代这个文档除外。

作者回复: 思维方式转变确实是比较难的，仅靠口头说服是远远不够的，所以除了宣讲以外，我采取的方式有很多：带他们参观已经转型的团队，有一些感性认识；必要的时候带他们打个胜仗，团队在不同阶段需要的辅助也是不同的，还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。

作者回复: 第三个问题，确切地说，在敏捷当中，业务不仅仅需要确认原型图。我们希望业务能够更多地参与研发过程，具体来讲，在前期需求创意的时候，我们希望能够跟业务在一起梳理，可以是用设计思维的方式，也需要明确业务价值；在迭代准备中，梳理优先级、确认需求等等；在迭代中，有可以确认的东西，如有能演示的版本等都可以找业务来看看，征求他的意见。说到底，业务与开发测试团队之间目标要绑定到一起，要有及时的反馈，这样敏捷开发的效益最大

作者回复: 最简单的一个可行的办法是一直与客户确认当前最重要的最有价值的工作，并且让客户了解到我们在有限的时间精力内只做最重要的事情。如果项目是有时间盒限定的，那么到时间盒结束的时候，我们只能做这么多，但做的这些是最重要的。

作者回复: 以前有一个迭代式研发，这种一般是迭代周期不一定固定，只要产品有迭代就可以叫迭代式研发了；而敏捷涵盖的内容比它广。

作者回复: 这是个超级痛苦的问题，也有挺多公司遇到，无论是大公司还是初创公司都有遇到，即便是使用瀑布模型要求写了大量的文档也存在这个问题，原因是文档经常是不时时更新的，很多后期接手的人员非常痛苦，基本都要扒一遍代码。我没有特别好的灵丹妙药，只能告诉团队：这不是敏捷本身带来的问题，但从实际出发有几个问题我们需要来检视一下：第一个，研发过程一定要留有必要的知识库和重要的文档；如果开始开发的时候没有留，后来人来梳理的时候要把梳理成果留下，必要的时候需要补充文件。第二个，巨复杂的系统需要重构，里面的许多逻辑估计已经臃肿不堪了，需要重新梳理。